Upgrade to Pro — share decks privately, control downloads, hide ads and more …

So you Want to Distribute your GraphQL Schema?

So you Want to Distribute your GraphQL Schema?

Marc-Andre Giroux

June 20, 2019
Tweet

More Decks by Marc-Andre Giroux

Other Decks in Technology

Transcript

  1. GraphQL Conf 2019 @__xuorig__ Distributed GraphQL The Basic Case GraphQL

    API query GetRepositories { viewer { repositories(first: 10) { name owner { name } } } }
  2. GraphQL Conf 2019 @__xuorig__ Distributed GraphQL Distributed Case query GetRepositories

    { viewer { repositories(first: 10) { name owner { name } } } } Search Service Monolith User Service
  3. GraphQL Conf 2019 @__xuorig__ Distributed GraphQL Distributed Case query GetRepositories

    { viewer { repositories(first: 10) { name owner { name } } } } Search Service Monolith User Service ?
  4. GraphQL Conf 2019 @__xuorig__ Distributed GraphQL Distributed Case query GetRepositories

    { viewer { repositories(first: 10) { name owner { name } } } } Search Service Monolith User Service
  5. "Though there is only one graph, the implementation of that

    graph should be federated" - https://principledgraphql.com/ GraphQL Conf 2019 @__xuorig__
  6. GraphQL Conf 2019 @__xuorig__ query { search(query: "stuff") {} issue(id:

    "abc") {}
 user(id: "def") {} } Search Service Monolith User Service
  7. GraphQL Conf 2019 @__xuorig__ Search Service Monolith User Service type

    Query { search(query: String!): [SearchResult!] } type Query { user(id: ID!): User } type Query { issue(id: ID!): Issue }
  8. GraphQL Conf 2019 @__xuorig__ Gateway type Query { search(query: String!):

    [SearchResult!] user(id: ID!): User issue(id: ID!): Issue }
  9. GraphQL Conf 2019 @__xuorig__ API Gateways •Types, and even singular

    fields, can possibly be resolved by `n` services •Nested fields may need to be resolved outside the current service •Resolution logic is extremely complex (Avoiding N+1's, handling failure scenarios within resolution of a query, etc) GraphQL
  10. GraphQL Conf 2019 @__xuorig__ Search Service Monolith User Service type

    Query { search(query: String!): [SearchResult!] } union SearchResult = User | Issue type Query { user(id: ID!): User } type Query { issue(id: ID!): Issue } type Issue { owner: User! } Schema Stitching The Harder Parts
  11. GraphQL Conf 2019 @__xuorig__ Schema Stitching The Harder Parts Search

    Service Monolith User Service type Query { search(query: String!): [SearchResult!] } union SearchResult = User | Issue type Query { user(id: ID!): User } type Query { issue(id: ID!): Issue } type Issue { owner: User! }
  12. GraphQL Conf 2019 @__xuorig__ •Individual Schemas are invalid on their

    own, only the final merged schema is valid. •The Gateway is now much more complex than just simple "proxying" Schema Stitching The Harder Parts
  13. GraphQL Conf 2019 @__xuorig__ Schema Stitching Developer Experience Search Service

    Monolith User Service Gateway Add the "User.pullRequests" field Add the "User.pullRequests" link
  14. GraphQL Conf 2019 @__xuorig__ •Brittle Gateway Code •Business logic often

    creeping into the Gateway •What we wanted to decentralize often ends up being centralized Schema Stitching Developer Experience
  15. GraphQL Conf 2019 @__xuorig__ Netflix's Server Side Adapters - Daniel

    Jacobson The better approach for handling API design [...] is to create true separation of concerns, rather than have all server-side decisions made by the API provider.
  16. GraphQL Conf 2019 @__xuorig__ GraphQL API query { viewer {

    repositories(first: 10) { name owner { name } } } } "I want this resource in this shape pls"
  17. GraphQL Conf 2019 @__xuorig__ GraphQL API query { viewer {

    repositories(first: 10) { name owner { name } } } } "K, it's accessible at /api/abc"
  18. We remain concerned about business logic and process orchestration implemented

    in middleware [...] Vendors in the highly competitive API gateway market are continuing this trend by adding features through which they attempt to differentiate their products. This results in OVERAMBITIOUS API GATEWAY products whose functionality — on top of what is essentially a reverse proxy — encourages designs that continue to be difficult to test and deploy. https://www.thoughtworks.com/radar/platforms/overambitious-api-gateways GraphQL Conf 2019 @__xuorig__
  19. GraphQL Conf 2019 @__xuorig__ Do we really want to commit

    to GraphQL for inter-service communication?
  20. GraphQL Conf 2019 @__xuorig__ •Make sure you're not designing your

    API according to how your services are split up. •Dynamic / runtime "stitching" is scary, proceed with care. •Consider statically building a gateway from a distributed schema using tooling as a middle of the road approach.
  21. GraphQL Conf 2019 @__xuorig__ •Configuration based / make it hard

    to do the wrong thing. •Thinest layer achievable •The API Gateway is "just" another service. •If distributed schemas are necessary, make it easy to "import" them into the gateway. •However, the gateway schema is its own thing that represents the source of truth for our exposed API. It requires •Resolution is done through your service communication of choice.
  22. GraphQL Conf 2019 @__xuorig__ It is very hard to operate

    a large GraphQL schema at scale, even as a single schema
  23. GraphQL Conf 2019 @__xuorig__ GraphQL has all we need to

    build a great aggregator or gateway!
  24. GraphQL Conf 2019 @__xuorig__ Before choosing a solution, ask yourself

    if the schema itself needs to be distributed