Arch/Enterprise GraphQL Sync

Arch/Enterprise GraphQL Sync

Team

@Adam Stankiewicz (Deactivated)@Dave Ormsbee (Deactivated)@Nimisha Asthagiri (Deactivated)@George Babey (Deactivated)@Brittney 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:

    •