diff --git a/packages/web/docs/src/components/federation-page.tsx b/packages/web/docs/src/components/federation-page.tsx index 686550e07..7f4a4ad1d 100644 --- a/packages/web/docs/src/components/federation-page.tsx +++ b/packages/web/docs/src/components/federation-page.tsx @@ -115,7 +115,7 @@ function WhyFederation(props: { className?: string }) {
Federated architecture is a powerful, yet advanced concept.
- It brings quite a lot of complexity, definitely has some learning curve, but in most
+ It brings quite a lot of complexity, and definitely has some learning curve, but in most
cases, the benefits are worth it.
GraphQL federation is perfect for domain-driven design or when you want - to write GraphQLs API in different languages. It allows teams to + to write GraphQL APIS in different languages. It allows teams to contribute data from their isolated GraphQL APIs (subgraphs) to the shared space called{' '} Supergraph.
@@ -144,11 +144,11 @@ function WhyFederation(props: { className?: string }) { className="flex-1 basis-full rounded-2xl md:basis-0 md:rounded-3xl" >- Subgraphs can be scaled independently based on their specific requirements, deployed on - their own schedule. + Subgraphs can be scaled independently based on their specific requirements, and deployed + on their own schedule.
- Different parts of the API can evolve at different pace, and making changes in the + Different parts of the API can evolve at different paces, and making changes in the GraphQL schema no longer requires coordination between teams.
@@ -290,27 +290,26 @@ function HowFederationWorks(props: { className?: string }) { description={ <>- First of the three components are subgraphs. A subgraph is a standalone GraphQL API - that can be developed in any language or framework, and{' '} + The first of the three components are subgraphs. A subgraph is a standalone GraphQL + API that can be developed in any language or framework, and{' '} deployed independently from the rest - key benefits of federated architecture.
The downside of a monolithic GraphQL API is that all teams have to work on the same - codebase, in the same language, using the same tech stack. On one hand, it's - actually a good thing, because now everyone shares the same knowledge and can help - each other. + codebase, in the same language, using the same tech stack. On the one hand, it's a + good thing, because now everyone shares the same knowledge and can help each other.
On the other hand, it's a bottleneck as it can slow down the development process, as the deployment queue may get longer, and one bad change can take down the whole API - (or decrease performance of a deployed instance). + (or decrease the performance of a deployed instance).
All of the mentioned problems are solved with GraphQL federation.
- The next component,and the most important one, is the schema composition. - Composition is process of validating subgraph schemas, combining them into one + The next component, and the most important one, is the schema composition. + Composition is the process of validating subgraph schemas, combining them into one coherent API and ensuring the integrity of the supergraph.
@@ -348,7 +347,7 @@ function HowFederationWorks(props: { className?: string }) {
The schema composition is most often done with a tool called{' '}
- Schema Registry. Schema Registry is a central place where you
+ Schema Registry. The Schema Registry is a central place where you
register your subgraphs (their location and schemas), validate them and combine them
into a supergraph. It's a crucial part of your GraphQL workflow, and it's a{' '}
The result of schema composition is a supergraph schema. It's stored in the schema - registry, and contains all the types and fields, but also information about in which + registry and contains all the types and fields, but also information about which subgraph and how to resolve them.
- The process of resolving a GraphQL request is called query planning. During the - query planning, the gateway decides which subgraph should resolve a given part of - the query, and then sends the query to the appropriate subgraph. The subgraph - resolves the query and returns the data. The gateway then combines all the data and - returns it to the client in a single response. + The process of resolving GraphQL requests is called query planning. During the query + planning, the gateway decides which subgraph should resolve a given part of the + query, and then sends the query to the appropriate subgraph. The subgraph resolves + the query and returns the data. The gateway then combines all the data and returns + it to the client in a single response.
A good GraphQL gateway should offer features like JSON Web Tokens (JWT) - authentication, role-based access control (RBAC), and have a good observability - story. It should be able to handle a large number of requests. + authentication, role-based access control (RBAC), and a good observability story. It + should be able to handle a large number of requests.
A critical yet often overlooked aspect of the GraphQL gateway is its correctness and - compliance with the Apollo Federation specification. Federation's effectiveness + compliance with the Apollo Federation specification. The Federation's effectiveness depends on the gateway's ability to correctly resolve queries, mutations and subscriptions.
When choosing a federation gateway, verify its compliance with the Apollo Federation - specification. This will help you prevent unexpected runtime behavior, and data + specification. This will help you prevent unexpected runtime behavior and data resolution failures.
@@ -432,7 +431,7 @@ function HowFederationWorks(props: { className?: string }) { > an open-source Federation Testing Suite {' '} - to verify gateway's specification compliance. This test suite helps ensure your + to verify the gateway's specification compliance. This test suite helps ensure your gateway correctly implements federation features beyond basic directive support.
>