From 800cce6bdaca1499c9e67961961bbdaa3e6e2332 Mon Sep 17 00:00:00 2001 From: Kamil Kisiela Date: Fri, 22 Nov 2024 20:32:35 +0100 Subject: [PATCH] Fix grammar in federation-page.tsx (#6025) Co-authored-by: github-actions[bot] --- .../docs/src/components/federation-page.tsx | 53 +++++++++---------- 1 file changed, 26 insertions(+), 27 deletions(-) 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.

@@ -128,7 +128,7 @@ function WhyFederation(props: { className?: string }) { >

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.

@@ -325,8 +324,8 @@ function HowFederationWorks(props: { className?: string }) { description={ <>

- 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{' '} } - callToAction="Read about Schema Registry" + callToAction="Read about the Schema Registry" callToActionLink="/docs/schema-registry" callToActionTitle="Learn how to use Schema Registry to compose your schema and validate it" /> @@ -380,16 +379,16 @@ function HowFederationWorks(props: { className?: string }) {

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.

Query Planning

- 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.

What a Good Gateway Should Offer? @@ -400,21 +399,21 @@ function HowFederationWorks(props: { className?: string }) {

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.

Specification Compliance - Very Important

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.