Adding GraphQL to your existing architecture
7 likes3,057 views
The document discusses adding GraphQL to existing architectures, emphasizing its incremental adoption and flexibility without necessitating a complete overhaul of existing systems. It highlights key considerations for implementing GraphQL, such as performance, client-side improvements, and optimizing backend load, along with practical guidance for getting started in production. The importance of community support and sharing experiences to enhance GraphQL implementation is also stressed.
Adding GraphQL to your existing architecture
- 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
- 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