Goals

• Build institutional knowledge about GraphQL
• Better understand adoption requirements
  • Code complexity
  • Configuration changes
  • Performance
  • What API conventions will help us be forwards compatible?
  • How should we structure front end state/logic code to be forwards compatible?

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
• Intermediary service for aggregation/translations of REST services.

Document:

• Graphene assessment (and comparison with competing tools, if applicable)
• Complexity of GraphQL/Python integration

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

Resourcing

Ideally this spike should be completed within 2 weeks using two developers at ~70% capacity.

External

• GraphQL Resources