Arch/Enterprise GraphQL Sync
Team
Adam Stankiewicz, Dave Ormsbee (Deactivated), Nimisha Asthagiri (Deactivated), George Babey, 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
- New tech to Enterprise
- 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: