In this talk, I go over some of the concerns people initially have when adding GraphQL to their existing frontends and backends, and cover some of the tools that can be used to address them.

1. Adding GraphQL to
your Existing Architecture
Sashko Stubailo
Open Source Lead, Apollo
@stubailo

2. • Client-side developer ergonomics
• Flexibility means fewer API changes
• Better efficiency, fetch just what you need
GraphQL makes everyone’s life better
So what might block people from using it?

3. • Where do I start?
• Can I use this at work without rewriting my
existing stuff?
• How do I get running in production?
First questions people ask

4. • Sometimes presented as totally new way of thinking,
which makes it seem like a big investment
• In practice, it’s a standardization of things people were
already doing
Is GraphQL really that different?
SIDE NOTE

5. • It’s what made React so easy to adopt
• Can you use it for just one feature or component?
• GraphQL can be done the same way
The golden ticket: Incremental adoption

6. Web App
Elastic Search MongoDB Dynamo DB
C L I E N T
S E R V E R
API Server
Existing app

7. Web App
Elastic Search MongoDB Dynamo DB
C L I E N T
S E R V E R
API Server
Existing app + GraphQL
?
?

8. • Fetch GraphQL anywhere you can do an HTTP request
• For fancier features—caching, network state
management, mutation handling—we’ve worked hard to
make Apollo Client compatible everywhere
• For some projects, great opportunity to improve your UI
and data management together
On the client, incremental is easy

9. • Model virtually any kind of application data
• Start with client-side needs, fill in API bit by bit
• Uniquely suited to being an API gateway, calling
your existing backends
• Suggestion: Experiment with clients that you can
push code to easily, like web or React Native
Incrementally adoptable API?

10. Two ways to present GraphQL
• Brownfield, existing app with existing
backend, every situation is different
• GraphQL addresses critical problems
• Greenfield, new app with new
backend, easy to write tutorials
• GraphQL sets you up to grow

11. • Most content builds “hello world” style APIs from
scratch, or starts with existing GraphQL API
• After you get a taste of the GraphQL experience, you
need a way to get it running in your existing app
• Everyone’s situation is unique
• Can we cut the problem into small bits?
Problem: Not enough guidance

12. Share live examples of GraphQL server patterns
Launchpad

13. • Mocking: launchpad.graphql.com/98lq7vz8r
• Neo4j: launchpad.graphql.com/3wzp7qnjv
• MongoDB: launchpad.graphql.com/vkmr1kl83
• Share your own patterns—DataLoader, pagination, etc
—at apollographql/awesome-launchpad
Existing samples on Launchpad

14. GROW
GRAPHQL COMMUNITY

15. Getting ready for
production
THE NEXT STEP

16. 1. Understand what is going on inside your server
with instrumentation
2. Know the tools available to make improvements
3. Ensure that backend services are not adversely
affected by the new API layer
Production learning checklist

17. • You need your instrumentation to understand GraphQL
• Need to have some way to identify common queries,
expensive fields, critical paths, and schema usage
• Write your client code and queries in a way that lets you
identify what you see on the server
First: Instrumentation

18. Two classes of problems
• High latency or bandwidth usage causes bad experience
for the end-user client app
• Inefficient execution or expensive requests result in too
much load on the API or backend

19. Client-side improvements
• Load data judiciously to avoid
performance issues
• Load less data at a time, split into
multiple queries, avoid expensive fields
• Improve client-side caching with an
offline cache, cache redirects, and
optimistic UI
• Otherwise, need to improve server
query Human {
human {
name
weather
friends {
name
}
}
}
query Human

20. Biggest question: Server performance
• Executing each query with low latency needs to be
balanced with load on the API server and backends
• Two dimensions that can be optimized: GraphQL server
overhead, and work done by backend APIs and databases

21. GraphQL server overhead?
• GraphQL execution engine itself is quite efficient for the value it
provides, usually not the main thing to optimize
• Caching parsing and validation helps a lot, those are some of the
most expensive steps
• Make it stateless to scale horizontally
• Break out of GraphQL data model if necessary with custom scalars
• In general, overhead is easy to limit

22. Backend API usage
• GraphQL API is much closer to the backend, so
same number of roundtrips is less time
• We should try to make sure we do the same
number of fetches or less than we were doing
without GraphQL
• How can we reduce fetches to the backend or
make them more efficient?
REST

23. Reducing backend load
• Leverage backend features when you can
• Use something like DataLoader to collect requirements,
then make one batched request and avoid extra roundtrips
• Make sure GraphQL server manages backend load by
listening to backpressure or rate limiting calls
• In theory GraphQL can be very efficient since all data needs
are known ahead of time

24. Persisted queries?
• Save queries to a database and only send the ID instead
of the whole query string
• Supported by Apollo Client and Relay Modern
• Important to distinguish several possible concepts:
• Static queries - no runtime modification of queries
• Whitelisted queries - only accept known queries
• Persisted queries - send query ID, look it up on server
• Compiled queries - do some optimization in build step
• Different potential benefits from each one
{
id: ‘23235’,
variables: …
}

25. Preventing malicious queries
• Simple: Basic rate limiting
• Medium: Statically calculate cost from the query
document before execution, reject if too high
• Advanced: Track cost of each client over time, to block
people loading too much data quickly
• For extreme cases: Explicit whitelisting

26. Advanced performance ideas
• Get the same performance as a hand-crafted REST endpoint
but with no loss of generality
• For certain applications that have extremely common
queries, hand-optimize queries or fragments
• In the resolver, check if we are looking for that selection set
and run a more efficient batched fetch for the subtree
• HTTP caching of whole query results

27. • You can incrementally adopt GraphQL, start with a quick
prototype to get a feel for it
• Instrument everything to avoid unnecessary optimizations
• Work with backend devs to make sure the databases and
services are happy
• The normal thing is usually fine, but if you discover issues
there are many paths to optimize your GraphQL API
Conclusions

28. Help grow the community!
• Write more content about intermediate GraphQL topics,
to help people get this amazing API with their data
• Write about your production experiences, performance
optimizations you’ve made, and new patterns you come
up with
Tweet or DM me, let’s work together: @stubailo