Learn GraphQL federation #1826
Open
Learn GraphQL federation #1826
+253
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@kamilkisiela is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel. A member of the Team first needs to authorize it. |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
kamilkisiela
commented
Nov 21, 2024
Urigo
approved these changes
Nov 21, 2024
andrewicarlson
approved these changes
Nov 22, 2024
Comment on lines
+9
to
+12
| In today's world of distributed systems and microservices, | ||
| organizations face the challenge of efficiently managing and scaling their APIs. | ||
| As applications grow more complex, traditional monolithic approaches often fall short. | ||
| This is where federation comes into play - an architectural pattern that has found particular resonance in the GraphQL ecosystem. |
There was a problem hiding this comment.
I wonder if reorganizing this intro would make it land a little clearer for folks unfamiliar with Federation. For example: Problem -> parallel solution (metaphor) -> How it relates to Federation.
Suggested change
| In today's world of distributed systems and microservices, | |
| organizations face the challenge of efficiently managing and scaling their APIs. | |
| As applications grow more complex, traditional monolithic approaches often fall short. | |
| This is where federation comes into play - an architectural pattern that has found particular resonance in the GraphQL ecosystem. | |
| As applications grow more complex, traditional monolithic approaches often fall short. At scale, monolithic architectures can become cumbersome, brittle, and increasingly hard to test and validate. This has led to a rise in the adoption of new patterns like distributed systems and microservices. In some ways, GraphQL Federation is like microservices for GraphQL – an architectural pattern that has found particular resonance in the GraphQL ecosystem. |
|
|
||
| GraphQL Federation gained widespread adoption after [Apollo GraphQL introduced Apollo Federation in 2019](https://www.apollographql.com/blog/apollo-federation-f260cf525d21). | ||
| Their implementation has become a reference point for the GraphQL community, | ||
| helping establish federation as a standard architectural pattern in the GraphQL ecosystem. |
There was a problem hiding this comment.
Suggested change
| helping establish federation as a standard architectural pattern in the GraphQL ecosystem. | |
| helping establish federation as a standard architectural pattern for building a distributed graph in the GraphQL ecosystem. |
| Their implementation has become a reference point for the GraphQL community, | ||
| helping establish federation as a standard architectural pattern in the GraphQL ecosystem. | ||
|
|
||
| The GraphQL ecosystem is moving towards standardization of federation patterns. |
There was a problem hiding this comment.
Suggested change
| The GraphQL ecosystem is moving towards standardization of federation patterns. | |
| With more companies and developers seeing the benefits of building a distributed graph with federation, the GraphQL ecosystem is now moving towards standardization of federation patterns. |
|
|
||
| ## What is federation? | ||
|
|
||
| Federation is an approach to organizing and managing distributed systems. |
There was a problem hiding this comment.
Suggested change
| Federation is an approach to organizing and managing distributed systems. | |
| Architecturally, federation is an approach to organizing and managing distributed systems. |
|
|
||
| - Define their own GraphQL schema | ||
| - Deploy and scale their service independently | ||
| - Contribute to a unified API without tight coupling |
There was a problem hiding this comment.
Suggested change
| - Contribute to a unified API without tight coupling | |
| - Contribute to a unified GraphQL API without tight coupling |
|
|
||
| ### Scalability and Performance | ||
|
|
||
| Services can be scaled independently based on their specific requirements. |
There was a problem hiding this comment.
Suggested change
| Services can be scaled independently based on their specific requirements. | |
| Subgraphs and services can be scaled independently based on their specific requirements. |
|
|
||
| ### Single, Unified API | ||
|
|
||
| Thanks to GraphQL gateway, clients get a single endpoint with unified schema. |
There was a problem hiding this comment.
Suggested change
| Thanks to GraphQL gateway, clients get a single endpoint with unified schema. | |
| Thanks to GraphQL, clients get a single endpoint with unified schema spanning multiple subgraphs. |
|
|
||
| ## Federation vs. Monolithic Architecture | ||
|
|
||
| While monolithic GraphQL APIs have their place, federation offers several advantages for larger applications: |
There was a problem hiding this comment.
Suggested change
| While monolithic GraphQL APIs have their place, federation offers several advantages for larger applications: | |
| While monolithic GraphQL APIs have their place, federated architectures offer several advantages for larger applications: |
| 1. **Identify Service Boundaries**: Define clear boundaries between different domains in your application | ||
| 2. **Design Schemas**: Create schemas that reflect these boundaries while considering how they'll interact | ||
| 3. **Implement Subgraphs**: Build individual services that implement their portion of the schema | ||
| 4. **Set Up Gateway**: Deploy a federation gateway to compose and serve the unified schema |
There was a problem hiding this comment.
Suggested change
| 4. **Set Up Gateway**: Deploy a federation gateway to compose and serve the unified schema | |
| 4. **Set Up a federated Gateway**: Deploy a federation gateway to compose and serve the unified schema |
| 4. **Set Up Gateway**: Deploy a federation gateway to compose and serve the unified schema | ||
| 5. **Monitor and Optimize**: Implement monitoring and continuously optimize query performance | ||
|
|
||
| Organizations can gradually migrate from a monolithic to federated GraphQL, one service at a time. |
There was a problem hiding this comment.
Suggested change
| Organizations can gradually migrate from a monolithic to federated GraphQL, one service at a time. | |
| Organizations can gradually migrate from a monolithic to federated GraphQL implementation, one service at a time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I thought about creating a page that explains what federation in context of GraphQL even means,
to create a good entry point for people interested in this space and looking for information.
It could help to shine more light on Composite Schema Working Group and the spec that's in progress.
The WG would have a page to explain what, how and why.
It's an initial draft, something to iterate on, think what to include etc. Happy to hear your thoughts.