Productionizing a GraphQL API - santiago esteva - dfw oct 2019

From idea to production, a walkthrough of all Architecture decisions made on a graphql API.

Transcript

1. Productionizing a GraphQL API Dallas Meetup Oct 2019
2. Who am I § Sabre – Front-End Architecture Director § https://graphqlscalars.com/ § https://graphqlworkshop.io/ § https://www.santiagoesteva.com/ § @sesteva § For consulting, talks and training on Web/Mobile/GraphQL: santigoesteva@gmail.com
3. Oracle DB Anypoint REST APIs SalesForce REST APIs ELK REST APIs Other Internal Requirements: - Dashboard UI - Auth Identity Provider - Personas: - Client User - Internal User - Fast and Great
4. UI stack This Photo by Unknown Author is licensed under CC BY-SA ADRs
5. Orchestration Integration UI Spring Boot Mulesoft Gateway GraphQL UI http calls 180+ 1 1 1 Under-fetching Yes No No No Over-fetching Yes No No No Flexibility No No No Yes Dev Experience N/A Swagger RAML Docs, Mocking, Playground, etc. Skills required JS Java Java JS or Java or … Dev Cost No Diff No Diff No Diff No Diff ADRs Principle 10 - Separate GraphQL Layer from Service Layer
6. Authentication Authorization § Identify Provider: in-house § Option 1: GraphQL § at Context or Resolver or § at Data Model or § Custom Directive § Option 2: Leverage Mule Gateway with existing in- house Policy § Bonus: Rate limiting, Analytics, Security ADRs Principle 8 - Grant access to the graph on a per-client basis, and manage what and how clients can access it.
7. React UI | | Mule API Gateway (Authentication/Authorization) <----------> In-House Identity Provider | | GraphQL | | | | | | | | Billing DB Anypoint Salesforce TBD
8. Iterative Schema Development § UI driven § Delegate data massaging to Graphql ADRs UI dev create story Any dev fulfill Any dev update tests UI dev integrate Principle 5. The schema should be built incrementally based on actual requirements and evolve smoothly over time.
9. Demand Control § Trusted or Untrusted users? § same devs on UI/BE -> trusted § Large number of queries? § Given product use case, we anticipate low volume. § Decision: § No need for query approval workflow § No query cost based limitation ADRs Principle 8. Grant access to the graph on a per-client basis, and manage what and how clients can access it.
10. Testing § 10% E2E + 85% Integration Tests + 5% Unit Tests § Why lack of focus on unit tests? § GraphQL should delegate logic to Service Layer. § We chose to cover negative scenarios as part of our integration tests § Tools § Test Runner: JEST § Enable GraphQL env without an HTTP Server: apollo- server-testing § Mocking http requests: NOCK or JEST.mock § Validate Data Structures: Jest custom matchers § Mock Context and allow DataSource mocking: Custom Helper ADRs
11. Performance § Focus on supporting the actual query shapes that are needed in production § Caching § Schema § type Org @cacheControl(maxAge: 100) § Resolver § info.cacheControl.setCacheHint({ maxAge: 60, scope: 'PRIVATE' }); § RESTDataSource § this.get(url, params { cacheOptions: { ttl: 60 } } ADRs Principle 6. Performance management should be a continuous, data-driven process, adapting smoothly to changing query loads and service implementations.
12. Deployment § UI § Local: NextJS § Prod: AWS S3 § Why static? § In-House design language library heavily depends on window object. § GraphQL § Local: Apollo-Server § Prod: AWS Lambda § Why not AppSync? § Apollo offered us simplicity to code/test § Automation: § Jenkins + Cloudformation Scripts ADRs
13. Monitoring § Structured Logs: § Apollo Graph Manager § Grafana § wrap resolvers? wrap RestDataSource? § tracingOn + formatResponse? § apollo server plugin? § Health Check § Out of the box: /.well-known/apollo/server-health § BYO: onHealthCheck <Promise> ADRs Principle 9. Capture structured logs of all graph operations and leverage them as the primary tool for understanding graph usage.
14. Error Handling § Actionable § Unexpected Errors § Server problems (5xx HTTP codes, 1xxx WebSocket codes) § Client problems e.g. rate-limited, unauthorized, etc. (4xx HTTP codes) § The query is missing/malformed § The query fails GraphQL internal validation (syntax, schema logic, etc.) § Expected Errors § The query returns no results § The query returns partial results § Non Actionable § Unexpected Errors § An uncaught developer error occurred inside the resolve/subscribe function (e.g. poorly written database query) § An unexpected error occurred when querying underlying service (500 when requesting data from a REST api) ADRs
15. Code Organization § Schema § Resolvers § DataSources § Method + Reducer -> easier to support future underlying changes § Context § __tests ADRs
16. Dev Tools § Playground § Docs § @deprecated § Voyager (http://localhost:4001) § Mocking § Mocks § graphql-faker ./schema.faker.graphql § TypeScript definitions ADRs Principle 7. Use Graph Metadata to Empower Developers
17. Total Cost § UI ~90 hours § GraphQL ~ 90 hours § CI/CD ~20 hours
18. Last Minute Significant Change § Principle 4 - Abstract, Demand-Oriented Schema § The schema should act as an abstraction layer that provides flexibility to consumers while hiding service implementation details. ADRs
19. Need help on Web or GraphQL? § Consulting § Corporate talks § Training § santigoesteva@gmail.com § https://www.santiagoesteva.com/ § @sesteva