Determining the right architecture design when adopting Apollo Fed.
summary
Fidelity moves a BFF-backed financial planning app into Apollo Federation as a proof of concept and proves the distributed graph can preserve existing capabilities while removing duplication. Planning uses a business architecture framework plus domain-driven design; implementation exposes domain services as subgraphs, tests financial planning POC against both managed and manual composition, and validates patterns: core entities, field contributions via the requires directive and use of external/shareable for cross-subgraph data. Result is a flatter architecture that works functionally but surfaces cultural and stewardship work.
AI-written summary · about
chapters (9)
- 0:00Intro
- 0:27Determining the right architecture design when adopting Apollo Federation
- 4:47Business Capabilities
- 6:10Financial Planning Application
- 9:51Financial Planning Domain Services
- 16:33Contributing Fields to Core Entities
- 17:50Contributing Computed Fields
- 19:36Computed Fields from Multiple Subgraphs
- 20:14Financial Planning Federated System
related talks
31mDesign Principles of Federated GraphQL
36mGraphQL Federation - The @key to Your Platform API Strategy
48mApollo Federation: Connecting GraphQL Microservices
28mBuilding a distributed graph w/ Apollo Federation
06mEscape the GraphQL Monolith
17mThe year ahead for GraphQL Federation: Combining APIs for the AI era.
23mBlueprints of Successful GraphQL Architectures
20mThe State of GraphQL Federation