Arch/Enterprise GraphQL Sync

Team

Adam StankiewiczDave Ormsbee (Deactivated)Nimisha Asthagiri (Deactivated)George BabeyBrittney Exline (Deactivated)Greg Sham (Deactivated)

Goals

  • Reach decision on GraphQL for building apps today
  • If we can't reach a decision, let's figure out how
  • Not immediately blocked, but wrapper question is on the horizon

Making the Decision

  • Operational impact
    • Separate servers to maintain
    • Node in production (new system)
    • Monitoring, scaling, etc.
    • Devops potential stakeholder
  • Team impact
    • New tech to Enterprise
      • Less concerned about this, because "everything is new"
      • Risk points are integrations with the existing systems
      • OK with extra efforts for the experimentation benefit
  • Architectural vision constraints:
    • GraphQL as horizontal monolith/gateway/API aggregator/potential SPOF
    • BFF: one GraphQL instance per domain
    • GraphQL lives at the service layer
  • Devops should be an A in this decision
    • Need: understanding of scope of operationalizing this pattern
  • Implementing team is the D

Findings

  • BFF vs universal GQL schema decision can be deferred
  • Implementation details of enterprise GQL schema vs. universal GQL schema currently unknown
  • Operational cost currently unknown

Miscellaneous:

  • Adam: Here's the talk I briefly mentioned from Spotify about how they think about & build microservices for their products. Feel free to take a look if interested:
    •