1 page about "Generator"
Central GraphQL for Big Organizations
There are two main ways of using GraphQL:
- as the core method of defining & accessing APIs
- as an alternative way of accessing existing APIs (a proxy)
The original idea here is not about the technical way of doing it as it is pretty standard.
I focus on a specific context where this idea may become very interesting:
- An heterogenous system,
- made of mixed protocols (Rest, gRPC, GraphQL, …),
- multiple languages,
- standalone/autonomous teams (not working in the same office),
- legacy code,
- third-party services,
- mix of big monoliths and small micro-services,
- etc.
A Central GraphQL for Big Organizations is a tool that allows to aggregate everyone on a common format while preserving the diversity of the ecosystem, with a very limited risk, and with “free documentation” as a bonus.
It may also be a solution for smaller organizations as the secret is to only involve a small team or even one person to bootstrap the project.
Important steps
- choose a way of defining contracts
- You can choose to write in the GraphQL definition format directly, in protobuf and then generate the GraphQL code, probably even in swagger, etc
- implement (at least) two different services using this format
- bootstrap a PoC implementing the two services, you may have to develop some “drivers” for common feature: authentication, retry policy etc
- show your PoC to some other key people (architects, team leaders, etc.)
- motivate people to help you write missing API specifications and “drivers”
- profit!
Conclusion
- you now have three options:
- to try to make everyone fit in the same API formats and everything (your initial plan?) 😉
- or ask them to maintain a specification file for their existing APIs
- you can now use advanced features of GraphQL: cross-services unions, streams, validation, type safety, client code generation, etc…
- it can be tested without risk, if this project fails, you only involed a small team, not the whole organization
