4. Kinds of technical diversity
1. Different data sources and backends? Easy with GraphQL
2. Different teams collaborating on one API? Might cause coupling and political
3. Different technologies, APIs, GraphQL implementations? Might be hard.
a. Frequently end up with multiple GraphQL servers
5. Making a single GraphQL API modular
● Commonly asked question: How do I avoid coupling
together my types?
● Our suggested approach:
○ Schema: Definition of external interface
○ Models: Business logic
○ Connectors: Details about backend implementation
● Organize Query, Mutation, Subscription initial fields
together with the relevant types in a module
6. Making a single GraphQL API modular
But sometimes, modularity in the code is not enough
7. Benefits of microservices
● Core idea: Iterate on your part without blocking on others
● Write different backends and features in different technologies
● Own your own data and enable more vertically integrated teams
● Independently version the backends and avoid a monolithic release process
GraphQL makes our backend feel a lot more flexible and "modular" - shouldn't we
be able to get these benefits quite easily?
8. Integrating multiple GraphQL services today
● GraphQL can call any backend, so it can call GraphQL too
● We often talk about using GraphQL as a gateway to REST, GRPC, etc
● Unfortunately GraphQL to GraphQL is not any easier; no virality
9. Example: Integration with Graphcool and GitHub
● Integrate via a serverless function
● Retrieve data as if it were a REST API
● It should be way better!
13. Demo: GraphQL Summit 2017
● Universe ticketing API:
● Dark Sky weather API on Launchpad:
● Can we figure out the weather at the location of GraphQL Summit 2017?
Spoiler alert: Yes!
16. Things to consider
● Making it work with all of GraphQL
● More efficient batching of requests to the backend services
● Not always easy to split a schema cleanly into parts
● Overlap between schemas, duplicate types
● Not clear if this is a good architecture, but the only way to find out is to try
17. Potential benefits
● Increase virality of GraphQL: The more people use it, the easier it is to
● Versioning, testing, and deploying subparts of a schema independently
● Implement different parts of your schema with different technologies
● Easily integrate with public APIs
18. Action items for you
● Tell us about your use case!
○ Join #schema-stitching on Apollo Slack
● Try the alpha releases of GraphQL Tools 2.0
● Build more GraphQL APIs
Follow me at @stubailo
We're hiring! DM for info.