What is it GraphQL?
“GraphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your data. GraphQL isn’t tied to any specific database or storage engine and is instead backed by your existing code and data”.
GraphQL was developed by Facebook in 2012 because the team needed “a data-fetching API powerful enough to describe all of Facebook, yet simple enough to be easy to learn and use by our product developers” when building the mobile applications.
Actually, the real secret is that GraphQL ensures that the developer and application only load the relevant and absolute necessary data, even if it’s from multiple sources.Alex McPeak, 2019
When to use GraphQL?
With the given facts, anyone can use GraphQL where the requirements are fit with the GraphQL features and where you have to work with lots of data fetching.
- Best to use where bandwidth usage matters.(apps for mobile phone, smartwatches, IoT devices etc).
- Applications where the nested data need to be fetched in a single call. (Social networking platform where posts need to be fetched along with nested comments and commenters details).
- Where application retrieves data from multiple, different storage APIs. (a dashboard that fetches data from multiple sources such as logging services, backends for consumption stats, third-party analytics tools to capture end-user interactions).
What are the pros and cons of GraphQL?
- A GraphQL schema sets a single source of truth in a GraphQL application. It offers an organization a way to federate its entire API.
- GraphQL calls are handled in a single round trip. Clients get what they request with no over fetching.
- Strongly defined data types reduce miscommunication between the client and the server.
- GraphQL is introspective. A client can request a list of data types available. This is ideal for auto-generating documentation.
- GraphQL allows an application API to evolve without breaking existing queries.
- Many open source GraphQL extensions are available to offer features not available with REST APIs.
- GraphQL does not dictate a specific application architecture. It can be introduced on top of an existing REST API and can work with existing API management tools.
- Autogenerating API documentation.
- Design for make API faster, flexible and developer-friendly.
- GraphQL presents a learning curve for developers familiar with REST APIs.
- GraphQL shifts much of the work of a data query to the server side, which adds complexity for server developers.
- Depending on how it is implemented, GraphQL might require different API management strategies than REST APIs, particularly when considering rate limits and pricing.
- Caching is more complex than with REST.
- API maintainers have the additional task of writing maintainable GraphQL schema.
|Based on the concept of a resource and can specify IDs for resources.||Based on the concept of a resource and can specify IDs for resources.|
|Can be fetched via an HTTP request.||Can be fetched via an HTTP request.|
|Can return JSON data in the request.||Can return JSON data in the request.|
|Data fetching can cause over-and under-fetching issues.||Impossible with GraphQL.|
|In REST you define the object on Backend.||On GraphQL you “define” this object on Frontend.|
|The server determines the shape and size of the resource.||The server simply declares the available resources and the client can ask for exactly what it needs.|
|Automatically puts caching into effect.||This has no automatic caching system.|
|Error handling is simpler.||Typically gives you a 200 OK status code.|
|Hard to get consistency and feature parity across platforms.||Ease transition to microservices.|
|Server driven architecture.||Client drier architecture.|
|Organized in terms of endpoints.||Organized in terms of schema and type system.|
|When making a request, filter down the data, perform waterfall request for related data and aggregate the data yourself.||Receive exactly what you asked and no aggregating or filtering data.|
More awesome features of GraphQL
- Make multiple queries in one request – you can get multiple result set using single request.
- Pagination queries – you can select which set of results to retrieve from a connection by using cursor-based pagination.
- Everything is typed and part of a schema – can use the schema to build queries that return only the data that you need. This solves the problem of over-fetching data. It also means that we know which fields each app is using, making it easier for us to evolve our APIs over time.
No under fetching and over fetching
What is this? This is very common problem when it comes to the REST. REST APIs are always returning fix data set according to how it is developed in back-end.
What does this mean? Imagine for an example a UI that needs to display list followers only with their names. In REST API, this page load hits usually ‘/followers’ endpoint and receive follower’s detail in JSON array. This result set might include more info about followers like mails, ages, addresses, birthdays that are useless for that particular page. In simply this is over-fetching. Instead of avoid this in REST, it must be written separate endpoint for this particular scenario. In that case, it will be increased the number of endpoints that returns same results with few additional fields. Look at the given figures, both can use for above scenario but second one cases over-fetching.
Then, what is under fetching? Under fetching means completely opposite of the over fetching. In other words, under-fetching means that REST API does not provide enough of required fields. In that case, client will have to make another request for completing data fetching.
Schema and type system
GraphQL has very strong schema and type system. Once schema and type system implemented and release from the back-end side, front end developers no need to wait for endpoints. FE developers can access what they exactly need through queries. Schema and type system allows to access those data. In GraphQL, Shema serves as contract between client and server to define how a client can access data.
Followings are the list of features that can be used with schema and type system.
- Type System
- Type Language
- Object Types and Fields
- The Query and Mutation Types
- Scalar Types
- Enumeration Types
- Lists and Non-Null
- Union Types
- Input Types
Here, I am not going to talk much deeper as this is an overview for GraphQL. We will talk these in deeper in another blog.
Who is currently using GraphQL?
- And many other worldwide companies.