[ramenmeal]

I've never used GraphQL and have a question. If you're at a larger company with many services, how many GraphQL servers are running? Who owns them? Is it a server per product? Per org? One for the whole company?

Obviously there's no set rule, but I'm curious how its playing out.

[jsjaspreet]

At my current workplace we're moving to GraphQL slowly and use it as a Gateway to front our backend REST APIs.

Backend feature teams own their APIs, but are all consumed by one GraphQL API which is the nexus of backend communication for things like periodic tasks and our client applications. None of the APIs call each other directly.

I think it's working out really well for the front end teams and aligning well with our engineering organization as a whole. As for who owns the GraphQL repos, everyone contributes to it but we rely on engineering leadership to keep an eye on changes as the system solidifies.

[strken]

Although we're not a very large company, we do something similar, using it as a gateway for everything but file uploads and some other special cases. It feels like a cross between a system-wide statically typed interface and HTTP routing. The tools (graphiql, graphdoc, apollo, the apollo eslint plugin) are really good and they help make the API feel discoverable and flexible.

[krschultz]

The endpoint that resolves GraphQL requests scales horizontally, so the answer is likely a high number.

I think what you're really getting at it is how many different GraphQL schemas are there? In general I would expect the answer to be one for the whole company, unless the services are truly not related at all. The power of GraphQL comes from being able to compose random sets of data that are not obvious up front.

[petetnt]

Schema stitching[0] is a rather powerful tool so in the end it doesn't really matter that much whether you have one schema or hundred of them as long as you have an idea of the available schemas.

[0] https://www.apollographql.com/docs/graphql-tools/schema-stit...