Goals
- Build institutional knowledge about GraphQL
- Understand adoption requirements
- Code complexity
- Configuration changes
- Performance
- Assess whether GraphQL is worth implementing within our APIs
- If yes, make an adoption plan
- If no, document why
- If not sure, determine next steps for reaching certainty
Plan
Developers involved in the spike will regularly share updates with the rest of the arch squad and pull in additional muscle as necessary. When the spike is completed, folks involved on the spike will present their findings to the squad and the squad will make an assessment as to whether GraphQL is worth adopting. The squad will present this assessment to the organization at large via arch lunch and eng demo/all hands.
Server
Create a DONTMERGE PR against an existing Python service. Discovery is a good candidate for this.
Implement:
- A single endpoint from which to READ data (query)
- Time allowing, an endpoint to which to WRITE data (mutation)
Assess:
- Graphene (https://github.com/graphql-python/graphene)
- Any other viable Python/GraphQL competitors
- GraphQL query performance
Document:
- Graphene assessment (and comparison with competing tools, if applicable)
- Complexity of GraphQL/Python integration
- Whether GraphQL is a worthwhile investment from the server-side perspective
Client
Create a DONTMERGE PR against an existing frontend.
Implement:
- Visible chunk of UI that READS from the GraphQL endpoint
- Time allowing, UI that WRITES to the GraphQL endpoint
Assess and compare:
- Apollo (https://www.apollographql.com/)
- Relay (http://facebook.github.io/relay/)
- Any other viable GraphQL client competitors
Document:
- Apollo/Relay comparison
- Complexity of read/writes from client side
- Whether GraphQL is a viable API solution from the client-side perspective
Resourcing
Ideally this spike should be completed within 2 weeks using two developers at ~70% capacity.