How we do localization
summary
Babylon replaces a synchronous localization service with a dedicated localization subgraph so domain subgraphs no longer call a shared service for strings and the router can manage preferences and resiliency centrally. It implements a localized string as a “utility type” in Apollo Federation by misusing @key to carry a JSON context scalar and returning a public text field while tagging the context internal via Apollo contracts. The result is fewer cross-service dependencies and a single place to resolve locale preferences.
AI-written summary · about
chapters (6)
- 0:00Start
- 0:43Babylon Native App
- 3:22Domain Subgraph SDL (IAM)
- 4:20Entity Type Recap
- 6:00Localized String
- 7:26LocalizedString Consequences
related talks
25mBuilding Relay Spec Compliance in Federation
21mSafely Merging Subgraphs in a Distributed World
29mScaling the Data Access by Leveraging GraphQL Federation for Service to Service Communication
38mBFF vs GraphQL: A critical perspective
48mApollo Federation: Connecting GraphQL Microservices
36mGraphQL Federation - The @key to Your Platform API Strategy
49mBFF (Backend For Frontend)
28mBuilding a distributed graph w/ Apollo Federation