mirror of
https://github.com/ByteByteGoHq/system-design-101.git
synced 2026-04-01 16:57:23 -04:00
ee4b7305a2
This PR adds all the guides from [Visual Guides](https://bytebytego.com/guides/) section on bytebytego to the repository with proper links. - [x] Markdown files for guides and categories are placed inside `data/guides` and `data/categories` - [x] Guide links in readme are auto-generated using `scripts/readme.ts`. Everytime you run the script `npm run update-readme`, it reads the categories and guides from the above mentioned folders, generate production links for guides and categories and populate the table of content in the readme. This ensures that any future guides and categories will automatically get added to the readme. - [x] Sorting inside the readme matches the actual category and guides sorting on production
40 lines
1.7 KiB
Markdown
40 lines
1.7 KiB
Markdown
---
|
||
title: 'GraphQL Adoption Patterns'
|
||
description: 'Explore 4 popular GraphQL adoption patterns for your team.'
|
||
image: 'https://assets.bytebytego.com/diagrams/0208-graphql-adoption-patterns.png'
|
||
createdAt: '2024-02-13'
|
||
draft: false
|
||
categories:
|
||
- api-web-development
|
||
tags:
|
||
- GraphQL
|
||
- API
|
||
---
|
||
|
||
|
||
Typically, teams begin their GraphQL journey with a basic architecture where a client application queries a single GraphQL server.
|
||
|
||
However, multiple patterns are available:
|
||
|
||
* **Client-based GraphQL**
|
||
|
||
The client wraps existing APIs behind a single GraphQL endpoint. This approach improves the developer experience but the client still bears the performance costs of aggregating data.
|
||
|
||
* **GraphQL with BFFs**
|
||
|
||
BFF or Backend-for-Frontends adds a new layer where each client has a dedicated BFF service. GraphQL is a natural fit to build a client-focused intermediary layer.
|
||
|
||
Performance and developer experience for the clients is improved but there’s a tradeoff in building and maintaining BFFs.
|
||
|
||
* **The Monolithic GraphQL**
|
||
|
||
Multiple teams share one codebase for a GraphQL server used by several clients. Also, a single team owns a GraphQL API that is accessed by multiple client teams.
|
||
|
||
* **GraphQL Federation**
|
||
|
||
This involves consolidating multiple graphs into a supergraph.
|
||
|
||
GraphQL Federated Gateway takes care of routing the requests to the downstream subgraph services that take care of a specific part of the GraphQL schema. This approach maintains ownership of data with the domain team while avoiding duplication of effort.
|
||
|
||
Over to you: Which GraphQL adoption approach have you seen or used?
|