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
35 lines
1.7 KiB
Markdown
35 lines
1.7 KiB
Markdown
---
|
|
title: 'REST API vs. GraphQL'
|
|
description: 'Explore the differences between REST API and GraphQL for API design.'
|
|
image: 'https://assets.bytebytego.com/diagrams/0036-rest-vs-graphql.png'
|
|
createdAt: '2024-03-11'
|
|
draft: false
|
|
categories:
|
|
- api-web-development
|
|
tags:
|
|
- API
|
|
- GraphQL
|
|
---
|
|
|
|
|
|
|
|
When it comes to API design, REST and GraphQL each have their own strengths and weaknesses.
|
|
|
|
**REST**
|
|
|
|
* Uses standard HTTP methods like GET, POST, PUT, DELETE for CRUD operations.
|
|
* Works well when you need simple, uniform interfaces between separate services/applications.
|
|
* Caching strategies are straightforward to implement.
|
|
* The downside is it may require multiple roundtrips to assemble related data from separate endpoints.
|
|
|
|
**GraphQL**
|
|
|
|
* Provides a single endpoint for clients to query for precisely the data they need.
|
|
* Clients specify the exact fields required in nested queries, and the server returns optimized payloads containing just those fields.
|
|
* Supports Mutations for modifying data and Subscriptions for real-time notifications.
|
|
* Great for aggregating data from multiple sources and works well with rapidly evolving frontend requirements.
|
|
* However, it shifts complexity to the client side and can allow abusive queries if not properly safeguarded.
|
|
* Caching strategies can be more complicated than REST.
|
|
|
|
The best choice between REST and GraphQL depends on the specific requirements of the application and development team. GraphQL is a good fit for complex or frequently changing frontend needs, while REST suits applications where simple and consistent contracts are preferred.
|