|
| 1 | +--- |
| 2 | +Title: 'GraphQL' |
| 3 | +Description: 'A flexible, efficient API query language that allows clients to request precisely the data they need.' |
| 4 | +Subjects: |
| 5 | + - 'Computer Science' |
| 6 | + - 'Web Development' |
| 7 | +Tags: |
| 8 | + - 'APIs' |
| 9 | + - 'Developer Tools' |
| 10 | + - 'Dependency' |
| 11 | + - 'Interface' |
| 12 | +CatalogContent: |
| 13 | + - 'paths/computer-science' |
| 14 | + - 'paths/front-end-engineer-career-path' |
| 15 | +--- |
| 16 | + |
| 17 | +**GraphQL** is a modern query language and runtime for [APIs](https://www.codecademy.com/resources/docs/general/api), developed by Facebook in 2012. It provides a more flexible, powerful alternative to traditional [REST](https://www.codecademy.com/resources/docs/general/rest) APIs by enabling clients to define exactly what data they want to retrieve. |
| 18 | + |
| 19 | +## History |
| 20 | + |
| 21 | +- Developed internally at Facebook in 2012 to address limitations in mobile application data fetching. |
| 22 | +- Open-sourced in 2015, gaining rapid adoption in web and mobile development. |
| 23 | +- Created to solve inefficiencies in data retrieval and provide more precise data manipulation. |
| 24 | + |
| 25 | +## Working |
| 26 | + |
| 27 | +GraphQL operates through a single endpoint where clients can: |
| 28 | + |
| 29 | +- Define precise data requirements using a strongly typed schema. |
| 30 | +- Request multiple resources in a single query. |
| 31 | +- Retrieve exactly the data needed, reducing over-fetching and under-fetching. |
| 32 | +- Provide a contract between client and server about data capabilities. |
| 33 | + |
| 34 | +## GraphQL vs. REST |
| 35 | + |
| 36 | +| Feature | GraphQL | REST | |
| 37 | +| ---------------------------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | |
| 38 | +| **Data Fetching** | Clients specify the exact data they need | Server defines fixed endpoints returning predefined data | |
| 39 | +| **Over-fetching & Under-fetching** | Avoids both by allowing precise queries | Over-fetching (getting more data than needed) and under-fetching (making multiple requests) can occur | |
| 40 | +| **Endpoints** | Single endpoint (`/graphql`) for all queries | Multiple endpoints for different resources (`/users`, `/posts`, etc.) | |
| 41 | +| **Performance** | Efficient as only required data is fetched | Can be inefficient due to multiple round trips | |
| 42 | +| **Flexibility** | Highly flexible; clients control response structure | Less flexible; fixed responses based on server design | |
| 43 | +| **Versioning** | No versioning needed; schema evolves dynamically | Often requires versioning (`/v1/users`, `/v2/users`) | |
| 44 | +| **Batch Requests** | Can retrieve multiple resources in one request | Requires multiple requests for multiple resources | |
| 45 | +| **Real-time Support** | Built-in support via subscriptions | Requires WebSockets or polling for real-time data | |
| 46 | +| **Ease of Use** | Requires learning a query language (GraphQL) | Familiar, follows standard HTTP methods (GET, POST, PUT, DELETE) | |
| 47 | +| **Error Handling** | Centralized error handling with structured responses | Error handling varies by endpoint and implementation | |
| 48 | +| **Caching** | More complex; requires custom caching strategies | Easily cached using HTTP caching mechanisms | |
0 commit comments