Skip to main content

JavaScript: Apollo Day Notes

These are my notes from Apollo Day:

Opening Talk


There are about 100 people at the conference. is coming November 6-8, 2018 in San Francisco.

Proof of concept -> initial production use -> principle production use -> company-wide standardization.

We no longer just have a single backend talking to a frontend. We have multiple services now. We're writing for a lot of platforms these days--not just web and mobile. How do we connect all the backend services to the different frontends?

Instead of defining specific APIs for each backend, use GraphQL for the backend to describe the data it has and the frontend to describe what the frontend whats. Apollo is in the middle. It's the implementation. Apollo is the tooling that extends across the entire stack. Apollo is about tooling, workflow, and integration.

Schema-centric development is the anchor between the frontend and the backend teams.

GraphQL Playground is a UI to explore a GraphQL schema.

The tooling helps with the whole development process.

They have schema validation in the Apollo tooling. You can integrate it into your CI. They integrated with GitHub using the Checks API.

Apollo Engine tracks how each client uses the backend services. They don't just check for static compatability. They compare queries from active clients against the proposed schema. Understand the impact of the change you're going to make even against the third-parties that are using your API. They can give you a field-by-field view of how expensive each thing is.

Apollo Engine:

  • Source control and CI
  • Editors and devtools
  • Alerts and monitoring
  • Metrics and APM
  • Logging and errors

Apollo Server translates the incoming query to a set of fetches from various data sources. This is the hardest part of adopting GraphQL today. However, it's getting easier.

Apollo Server 2 is specifically designed for standing up a GraphQL server in front of whatever you have today. It's in beta today. It's recommended for production use.

It's 100% open source JavaScript. He recommends building your GraphQL layer in JavaScript.

Apollo Server 2 has standard patterns out of the box, all wired up for you: error handling, caching (including whole query caching, partial query caching), etc.

Data Sources is a pattern for fetching from REST endpoints. It rewards teams that have built great service APIs.

Interesting: Serverless is a good fit for GraphQL. They've been working with Cloudflare to build GraphQL inside a Cloudflare edge worker. Hence you can use Apollo Server at the edge. Cloudflare has something like 151 pops around the world. However, this isn't quite ready for production. See

Airbnb has separate GraphQL services that are stitched together. In the future, GraphQL might live at different layers.

He talked about "GraphQL Orchestration". That's his vision for where GraphQL and Apollo are going.

How they can help:

  • Open source collaboration
  • Support, training, and architectural reviews
  • Implementation partners

Contact them via:

Making it with Apollo

Jake, solutions architect. @jakedawkins. His job is to make GraphQL easier to use at any scale.

Start with Apollo Server. Get started writing a GraphQL schema.

Apollo Server 2.0 has everything you need right out of the box, including GraphQL Playground. Build your query in the Playground, and then copy it into your code. It's "secure by default".

It supports subscriptions (i.e. real time).

GraphQL Playground has autocomplete based on the schema. There's a schema explorer with types.

There are some things hidden by default in Apollo Playgraph, such as field deprecations.

Schema Orchestration: making intelligent decisions on how to manage changes to your schema.

He talked about how it used to work with REST versioning.

GraphQL removes the need for hard breaks in API versions.

He talked about schema validation. You can make sure you're not removing something that people use.

SDL: Schema Definition Language.

He showed commiting a change to the schema. A GitHub check flagged that he changed a field in the schema.

He said, "It might take a few moments...let's see if Circle is having a good day or not." ;)

Apollo Engine doesn't just know schema structure. It also knows schema usage. After all, it's a monitoring tool. Schema validation gives us automatic insight into the impact of changes.

You can evolve your schema:

  • Make additive changes where possible. They don't break your schema.

  • Avoid removing or renaming fields and arguments where possible:

    • Unused resolvers don't get run and don't cost anything.
  • Use the @deprecated directive.

  • Monitor usage with something like Apollo Engine and retire dead code.


The next step is to make it fast. Apollo Engine helps you see what needs work.

Whole query caching:

  • For public, commonly requested data.
  • Bypass GraphQL execution completely.
  • Results served directly from a CDN with automatically persisted queries.
  • You can dramatically reduce the number of things that even make it to the origin.

Partial query caching:

  • Making GraphQL execution faster.
  • Cache requests made to 3rd-party services.
  • Memoize requests made in a single query to prevent duplicate requests.

They're working on something called "REST Datasource". It can automatically cache responses based on HTTP headers. It can be used with Redis, Memcache, etc. It automatically handles batching for a single request lifecycle.

He showed some Apollo Server code. It's basically a configurable JavaScript proxy.

He talked more about pushing GraphQL to the edge with CloudFlare. "Distributed partial query cache around the world."

The Apollo team is very helpful if you have problems.

Make it work. Make it right. Make it fast. -- Kent Beck

GraphQL at Brigade

Steve Rice, @steve.rice

They've been using it in production for about a year. It serves all their requests. They have web and mobile clients.

Kong does authentication, etc. It does HTTP-level stuff.

GraphQL is the layer in front of the backend services.

They had a Rails monolith. They used ActiveModel::Serializers.


  • When nesting things in a response in REST, cycles might be a problem
  • Versioning

They talked about flattening API responses by providing a list of objects that have ID references to each other.

They looked at json-api.

They picked GraphQL over json-api. He explained a long list of pros and cons.

They started small.

They first started by building the GraphQL using Ruby. They moved to Node which had the most mature tooling for GraphQL. They stood up the service side-by-side with their monolith. You could go through the GraphQL layer to get to the monolith or go directly to the monolith.

They have React and a home-grown FLUX implementation.

They started playing with Relay. He had some minor complaints about Relay.

They have native clients to enable mobile apps to talk to GraphQL.

GraphQL schemas are really helpful for getting the frontend and backend teams to be on the same page.

It makes sense to let the client team build the schema. It's okay to abstract away your data model.

Schema -> Resolvers -> Models -> Services -> Transport Layers (HTTP, Thrift, etc.)

You can unit test things individually.

They also do e2e query testing.

They use Datadog and statsd.

Errors are tricky. GraphQL is a focal point for errors. Error handling is pretty rudimentary. Consider where an error occurred and where it originated.

He wishes they had Apollo Engine a year ago:

  • Metrics
  • Traces
  • Errors over time
  • Daily reports
  • Datadog metrics

Fanout (parallel) vs. depth (serial) requests. They limit their request depth to 1. Microservices don't talk to each other. Although, there is an event bus behind them all.

Lessons learned:

Start simple. Pay as you go.

Don't believe in Relay's magic.

Don't build out schema you don't need.

Choose a simple part of your application.

Graph your own graph.

Add and optimize when you need it.

Use automated tooling.

Don't expect humans to be perfect.

Check for breaking schema changes.

Express chema with the IDL.

Fill in descriptions and deprecationReasons.

Semantic scalar types help define automation.

Love null. Don't try to avoid it.

Don't use non-null just because the API docs have it.

Don't require arguments unless the field is meaningless without them.

Keep GraphQL stateless.

Don't talk to the persistance layer directly.

Don't try to replicate DB query exeuction.

Don't cache data without understanding it.

Put GraphQL on top of services.


Embrace unpredictability.

Don't lock everything down.

Don't worry too much about duplication.

Identify broader trends.

Favor general optimization strategies.

Foster collaboration.

Make it easy to contribute.

Keep interfaces visible.

Iterate at the resolver layer.


Prototype with a schema.

Use type guarantees.

Build better services, not better JSON.

Collaborate with teams on the API.

Cleanly addresses client and service needs separately.

Easier to integrate new services.

Embrace the GraphQL workflow.

Iterate as needed. Start simple.

Measure and improve.

Hello. I'm James Baxley.

James Baxley, tech-lead at Apollo, @jbaxleyiii

He hopes people will get promoted based on the work they do integrating Apollo into their companies' infrastructure.

A large percentage of the audience is using GraphQL. An even larger percentage is using React.

Building applications is about finding the right tools.

HTML is the right UI primitive.

However, it's not great for building apps.

DOM code -> jQuery (this doesn't scale) -> Backbone (brings structure)

Why React? Control your UI.

({ data }) => <ui/>


  • Lifecycle events
  • Unified event handlers
  • Local state management
  • Full control over the underlying primitive

Not everyone needs every advanced feature such as:

  • Environment-based primitives (React Native, etc.)
  • Portals (beyond a single browser window; few people use these things)
  • Server-side rendering (a few people use this)

React isn't really designed to deal with all the details of fetching data.

GraphQL provides:

  • A description of the data
  • Centralized schema
  • Efficient fetching

query => { data }

You need to declare your data needs. That's where Apollo comes in.

It's all about making the lives of real engineers easier.

He showed an example of some GQL tied to a React component.

Advanced data:

  • Control over fetching policies
  • Custom store updates
  • Optimistic UI
  • Live data bindings
  • Data prefetching
  • Environment independent fetching

This allows: query => <ui/>

Apollo Link (?) allows you to fetch data in any way (WebSockets, local cache, etc.).

Optimistic updates are important.

Pagination is important.

"There's no silver bullet, so we built a lot of bronze bullets"

Control how you fetch your data.

(I think he's using some Microsoft Surface device. However, everyone around me is using a Mac.)

Understand your data with powerful tools.

They have robust TypeScript support.

He talked about the importance of server-side rendering.

Apollo extends React to provide the best SSR experience possible. See react-apollo.

"Full stack aware errors." Apollo Server 2.0 will help more with error handling. It'll handle transient errors.

"Let your data guide your schema."

"Full stack caching": everything from local cache, CDN, server-side, etc.

"Co-located data without the spinners." It's ready for "React suspense" (some new feature in React?). It was easy for them since they've been dealing with data loading errors for a long time. It only took a single line of code.

Async SSR without sacrifice: built in async renderer.

You can use Apollo as a single source of truth to manage all your data. You can use Apollo with all your data. I think he took a swipe at Redux.

Remote data, local data, live data.

{ Apollo } => <React/>

Reconciling Thrift and GraphQL at Airbnb

Adam from Airbnb.

They moved from a monolith to a SOA/Thrift.

In the beginning, they had full-stack engineers and a monolithic Rails app.

They had a single model that was 4000 lines of code. Shared data models were a huge source of strife.

They moved to Java on the backend. The API was in RoR. There was an emergence of frontend.

They invested in strongly typed data objects in Thrift. The requests and responses are also strongly typed.

The frontend engineers were excited about GraphQL. The backend guys definitely weren't.

There's a danger of adding a really expensive field to the query.

They ended up with something more balanced between the backend and frontend. There are presentation services in Java.

He talked about field-level performance. Some fields are practically free. Some are really slow and expensive.

They grab everything at the same level from the service at the same time, and then "down select" at the GraphQL level.

They built some library to do Thrift/GraphQL translations. They may open source it.

There's a GraphQL gateway service built with Node and Apollo.

Schema switching, query routing, query registration.

They compile Thrift IDL to GraphQL schemas. They're generating GraphQL client code.

They're exploring TypeScript at Airbnb.

"Client-driven UI."

They're moving toward having the backend drive the UI. Consider a search response returning all sorts of different types of things. GraphQL does support this via interfaces and unions.

GraphQL gateway service:

  • Schema stitching
  • Query routing
  • Query registration

They have very decentralized presentation services.

They're launching this to all to production this week. They want to move everything to TypeScript and GraphQL by the end of the year. They were saying no to GraphQL only 8 months ago.

apollo-link-state is great. All data should be in Apollo.

SSR via Hyperloop.

Persist data on devices. 85% of their users have service workers.

Cloudflare Workers & Apollo

Jonathan Bruce, Product Management, Cloudflare Platform

Whole owned datacenters -> IaaS on demand -> Serverless computing

With Amazon, it's really impossible to understand exactly how much things are going to cost.

With serverless, you can think of $/request.

152 PoPs. 9 million customers.

10% of Internet traffic globally runs through Cloudflare's infrastructure.

Interesting: Cloudflare Workers: it opens edge computing to the masses. They have the same API as service workers. Runs faster and with less memory than a Node.js process. Allows arbitrary sub-requests and computation. As simple as possible. Easy to reason about. Based on V8.

  • Deliver personalized UX
  • Simplify A/B testing
  • Detect bots
  • ... is a DNS resolver that helps with internet data privacy.

Patch Point (?) lets you run your requests from different places in the world.

He was the JDBC architect at Sun.

Then, he did ODBC and ADO.NET stuff at some other place.

Then, he did HBase stuff at Salesforce.

With Cloudflare Workers, he had the same questions about how to access data. His solution was GraphQL:

  • Developers get the data they need.
  • Avoid overfetching.
  • Minimize round trips.
  • Maximize flexibility.
  • ...

He wants to build a universal GraphQL API on top of existing REST APIs.


Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p