Apollo is about make building great applications simpler and more staightforward, with GraphQL. They think GraphQL is one of the highest leverage ways to improve app developer experience.
Why GraphQL and why APIs?
It’s important to separate concerns, not technologies
GraphQL is all about providing the correct split of responsibilities across frontend and backend parts of your app.
Today’s apps are complex:
GraphQL and Apollo help coordinate this by living in the middle of all your frontends and backends. GraphQL enables a whole world of tools to live in between all the different moving parts of your app.
Yesterday, they announced Apollo Client 2.0. Even before the release, people in the community jmped on this release and built out integrations into Angular and Vue.js (in addition to the one for REact written by Apollo).
It’s now easier to write a GraphQL server in any language (JS, Scala, Elixir, Python, Ruby, Java, Go).
The GraphQL duality:
The GraphQL Query is a unit of data fetching
Some of the main questions we hear about Apollo
Q: How many people feel like they should be caching their API? Audience: Everyone raises their hand.
“Very relatable topic”
Their are tradeoffs with GraphQL and caching. Current approaches become harder to use but there are opportunities for new features and caching types.
In REST, a common way to do caching is to use a Cache-Control header and set “max-age”.
Here’s an idea for how to cache in GraphQL: Put your cache in your GraphQL Server. But:
So caching doesn’t belong inside your API server.
Either want to do it above or below. This suggests a new caching layer that supports GraphQL features like POST requests and fine-grained TTLs. This should keep the copmlexity of caching out of the API server.
He presents the idea of a GraphQL Gateway… Introducing Apollo Engine: the first-ever GraphQL-specific Gateway technology. If you used Apollo Optics, this is the next version of that.
The server provides cache-control data in responses. The Gateway reads these cache-control settings and implements the complicated caching logic for dealing with these settings. The Gateway and server are completely decoupled.
The gateway can then inform the client-side data store how to expire data. You can reuse the same cache controls on the client (since everything is GraphQL).
How to implement this? The GraphQL spec has a feature called extensions that lets you add additional data to a response without breaking clients that don’t understand the additional data.
Tracing and errors is all about getting information from your server. You want detailed information about what happened in a GraphQL query. You can’t just track performance on a per endpoint basis.
GraphQL is the first API with fine-grained insights built in. You have to have the schema and query language to show what the performance cost of each part of the data that was fetched.
This makes the data more actionable. Not only can you track performance at the top level, but you can fix it on a fine-grained level. If a particular field is taking too long, you can omit it in your client request.
You can do performance analysis in the gateway, so you can correlate your caching logic with perf bottlenecks.
They have an open specification for GraphQL tracing: github.com/apollographql/apollo-tracing. It’s a way to get performance data on a per-resolver level from any GraphQL server.
GraphQL enables development tool integration, because the schema exists up and down the stack. He presents a mockup of a new version of GraphiQL that includes a tracing window.
The GraphQL spec is robust enough to spawn thousands of companion tools for every imaginable platform.
Correct division of responsibilities. This time, we’re talking about communication between the GraphQL API and the backend services.
It’s a good idea to have exactly one GraphQL client and one GraphQL schema. Today, many folks have multiple GraphQL clients hitting multiple schemas (each tied to a different backend service). But he hopes in the future, schema stitching will address this issue.
See an example: launchpad.graphql.com/130rr3r49. Schema stitching combines data from two different schemas to get information about location AND weather.
Many ways of schema stitching from Abhi Aiyer at Workpop, Jason Lengstorm at IBM, and Apollo has its own way. Not sure which one will become the standard, but will be interesting to see.
He sees the ideal app architecture for GraphQL is one where the gateway does the schema stitching. This will be especially useful if you’re in an enterprise scenario, where there’s a lot of different independent teams (and thus independent schemas).
Back to the GraphQL duality:
This enabls a lot of the features that make GraphQL great. Caching, transparency, and modularity will be continuously improving. HE wants to live in a world where all cells in this table have a green checkmark: