Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Productionizing a GraphQL API - santiago esteva - dfw oct 2019

Productionizing a GraphQL API - santiago esteva - dfw oct 2019

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

Santiago Esteva

October 23, 2019
Tweet

Other Decks in Technology

Transcript

  1. 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: [email protected]
  2. 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
  3. 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
  4. 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.
  5. React UI | | Mule API Gateway (Authentication/Authorization) <----------> In-House

    Identity Provider | | GraphQL | | | | | | | | Billing DB Anypoint Salesforce TBD
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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
  11. 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.
  12. 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
  13. Code Organization § Schema § Resolvers § DataSources § Method

    + Reducer -> easier to support future underlying changes § Context § __tests ADRs
  14. 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
  15. 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
  16. Need help on Web or GraphQL? § Consulting § Corporate

    talks § Training § [email protected] § https://www.santiagoesteva.com/ § @sesteva