Graph as a Gateway

Gateway.md

GraphQL as a Gateway Architecture Flow

Objectives

• Create a promotion based deployment flow for clients, instances of graphs, and backend resolvers.
• Each node in this network has the potential to be live but only those which are tested and reliable are production-worthy.
• Data and the metal are always guaranteed to be the latest usable pieces of the platform.

Flow

1. User requests and runs client application
2. On initialization, client application verifies identity
3. Auth0 is asked for credentials if identity is unfulfilled
4. Application makes a GraphQL request with identity to AWS API Gateway
5. AWS API gateway passes the GraphQL request to latest GraphQL lambda
6. GraphQL lambda requests the backend gateway
7. Backend gateway passes to backend resolvers
8. Backend resolver authenticates or rejects identity
9. Backend resolver handles response for request using authentication for authorization
10. Backend resolver fulfills request with response for GraphQL lambda
11. GraphQL lambda fulfills graph response for Client
12. Client resolves graph response
13. Client stores authentication for further requests and utilizes graph data

Pros

1. Should not have to worry about environments.
2. Objects like Users are atomic and don’t have different possible states. When I test something, I only have to test for the real functionality instead of potential or adverse functionality.
3. Features or changes aren’t blocking the entire system.

Cons

1. Going back to environments or stateful data will make everything painful.
2. There’s a lot more working parts to worry about that each have their own IAM roles
3. System or E2E tests may be much more challenging.
4. Features and changes need to be incremental.