southpolesteve

Moving away from ember-cli

I love ember. It is awesome. But I recently stopped using ember-cli. Here is why. Be warned this is a pretty raw stream of thought and may not be particularly well reasoned. Maybe some day I'll edit it into a proper blog post.

es6 modules

I get es6 modules. They are awesome and I look forward to using them one day. But right now I find them to be more of the PITA. IF I had a extremely large app I might feel different, but committing to es6 from day one has led to problems for me and my team. "How do I make this existing lib cooperate that needs to tie into ember?", "How do I debug this issue?". With globals this stuff is trivial. Open web inspector. Poke around. With es6+ ember inspector it isn't terrible, but it is not great either :/ This is has been a definite sticking point for people new to ember on our team. Hard to learn ember and battle ES6 weirdness at the same time.

ember-cli-addons

Everyone keeps saying that this is for modifications to ember-cli internals,

southpolesteve

Keybase proof

I hereby claim:

• I am southpolesteve on github.
• I am southpolesteve (https://keybase.io/southpolesteve) on keybase.
• I have a public key whose fingerprint is 6960 5225 7E52 6009 E88B 3019 C30F 8688 EE21 D009

To claim this, I am signing this object:

southpolesteve

import { AWS } from 'infastructure-as-code'
import fs from 'fs'

AWS.region = 'us-east-1'

const ENV = process.env.NODE_ENV || 'development'

const lambdaRole = new AWS.IAM.Role({
  RoleName: `lambda-execution-${env}`
})

southpolesteve

// Search every field and swap out the resolvers if an `authorize` key is present
export function authorize (schema) {

  // We require auth for all mutations
  const mutations = (schema._mutationType && Object.keys(schema._mutationType._fields)) || []
  mutations.forEach(mutationName => {
    const field = schema._mutationType._fields[mutationName]
    invariant(field.authorize, `Mutation: "${mutationName}" must have an "authorize" property. Use "*" for no auth`)
  })

southpolesteve

• GraphQL is awesome. I was not a fan at first, but I have since been converted. I wouldn't hesitate to use it for anything new. Its not perfect though.
• Running on Lambda is pretty straight forward. We have our own custom code for that, but if I was starting fresh, I would use the Apollo GraphQL server. They have one that is designed to run on Lambda. I've played with it and it works well.
• If your graphQL resolvers are talking directly to a DB, make sure to share connections between requests. One connection per lambda instance. If you spin up a new connection per request you will have a bad time. I guess this is generally true for not-graphql lambda things too.
• You need dataloader. It will batch DB queries for you. It (or something like it) is pretty critical to making any graphQL setup performant. Or at least not overload your DB.
• You proabably need to follow the Relay spec. We didn't d

southpolesteve

export async function userAbortableFetchWithTimeout(url: string, options?: any) {
  // We need our own internal abort controller even if the user passed one
  const controller = new AbortController();
  const signal = controller.signal;

  // Setup timeout
  const timeout = setTimeout(() => {
    controller.abort();
  }, options.timeout);

southpolesteve

const nativePromise = globalThis.Promise

globalThis.Promise = new Proxy(nativePromise, {
    construct(...args){
        const promise = Reflect.construct(...args)
        const proxy = new Proxy(promise, {
            get: function(target, prop) {
                const value = Reflect.get(target, prop);
                if (prop === "then"){
                    proxy.awaited = true