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

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

• 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

// 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

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

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

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

require "spec_helper"
require 'fastimage'

describe "Image Compression" do

  Dir[Rails.root.join("app/assets/images/*.{jpg,png,gif}")].each do |file|
    context "#{file}" do
      it "should be properly dimensioned" do
        FastImage.size(file).each do |dim|
          dim.should < 2000 # pixels

southpolesteve

• Raspberry Pi Newark
• Short SD card adapter Newark
• Power Supply Newark
• Short HDMI cable (Thin, 1ft) Parts Express
• Monitor (VESA mount, HDMI port) Amazon
• Micro SD card [Amazon](http://www.amazon.com/SanDisk-MicroSDHC-Memory-Adapter-SDSDQU-016G-AFFP-/dp/B009QZH7D8/ref=sr_1_2?s=pc&ie=UTF8&qid=1374527634&sr=

southpolesteve

I have been playing with a lot of client side apps lately (mostly Ember). Writing the APIs to back these is often a bit tedious. I find myself writing code over and over to match Ember Data's expectations when really I just wanted Rails to automatically expose my models as these APIs. I struggled to find an existing gem that did this.

So over the past couple weekends, I built one: https://github.com/southpolesteve/api_engine

What is it? A Rails engine that automatically exposes your models in a Ember compatible API (including bulk operations). Serialization is done via Active Model Serializers. There is still a bit to be done before it is ready for wide release, but the basic functionality works.

Short term issues
- Add ability to create a model white list.
- Add ability to restrict exposed actions on a model.
- Do a proper release on rubygems