- What is it?
GraphQL is a query language for your API. You can send a single query to the GraphQL server that includes the concrete data requirements and the server will respond with a JSON object where these requirements are fulfilled. GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data, so you can define how you want to get what data. In short, it creates a single endpoint responsible for accepting queries, rather than relying on the REST API approach of having separate endpoints for each service. In GraphQL, you don’t use URLs to identify what is available in the API. Instead, you use a GraphQL schema.
- How can it be beneficial over RESTful CRUD endpoints?
GraphQL can be beneficial if you have rapidly changing data and you want to make requests that may have required multiple enpoints while using a REST API. You can retrieve only the data you need in a pre-determined format, which makes working with BE and FE more straightforward because the schema is defined and the format of the information known and can easily be mocked by FE developers.
- Build a list of 3 or more pros/cons of having your team implement GraphQL in the upcoming Consultancy project
Pros:
- No overfetching of data because you can specify exactly what information you need.
- You can make one call for data instead of 3 if you need information from different "REST endpoints."
- It's database agnostic.
- You can specify the exact data you need in a query, and the structure of the server’s response follows precisely the nested structure defined in the query and not the fixed structure of a REST endpoint.
- Since clients can specify their exact data requirements, no backend engineer needs to make adjustments when the design and data needs on the frontend change.
- Since the client specifies exactly what data they want, you gain insights into what data is actually used, and you can alter the API in future iterations if some data is never requested.
- GraphQL is "strongly-typed" and provides a syntax that describes how to ask for data (called a Schema). When using GraphQL, all the types that are exposed in an API are written down in this schema using the GraphQL Schema Definition Language (SDL). This allows FE and BE engineers to know exactly what data types to expect and they can more easily work indepently.
- You can traverse from the entry point into related data in a single request because there can be relationships defined in the schema.
Cons:
- Queries always return a HTTP status code of 200, regardless of whether or not that query was successful. This makes error handling much more difficult.
- There is no built-in caching, so you may have to refetch data or set up your own caching system.
- GraphQL is more complex than using REST endpoints, so it may not make sense to use if you have relatively consistent data over time rather than rapidly changing data.
Resources: