12 pages about "Ideas / RFC"
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,
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.
- 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”
- 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
Create a tool that allows to colleboratively define, visualize (with graphs) and query dependencies.
a.k.a. “The perfect mix between Neo4J, Wikipedia/Wikidata, and LucidChart“
- can be done manually
- can be done using scripts/APIs to aggregate external sources
- should be typed yet flexible
- Wikibase, the engine behind https://wikidata.org, to store and manually manage the dependencies
- An existing or a custom solution to import/synchronize existing data
- Well-defined base entities to ensure a good overall quality
- A custom frontend to provide useful visualizations
- Some process/guidance to have collaboration