GraphQL Article

Introduction

GraphQL is an open-source data query and manipulation language for APIs and a runtime for fullfilling queries with existing data.

It was developed internally by Facebook in 2012 before being released publicly in 2015. It was created by Lee Byron - His goal is to make GraphQL omnipresent across web platforms (ooh scary!)

Features

GraphQL supports reading, writing and subscribing to changes to dara (realtime updates).

GraphQL servers are available for multiple languages such as JS, Haskell, Perl and Python.

The Schema Definition Language (SDL) is part of the GraphQL specification.

Pros/Cons

GraphQL has its pros and cons: (vs REST)

Pros	Cons
Good fit for complex systems and microservices - By integrating multiple systems behind its API, GraphQL unifies them and hides their complexity. The GraphQL server is then responsible for fetching data from the existing systems and packaging it up in the GraphQL response format. This is particularly relevant for legacy infrastructures or third-party APIs that have expanded over the years and now present a maintenance burden.	Web caching complexity - GraphQL caching at the database or client level can be implemented with the Apollo or Relay clients that have caching mechanisms built in. However, GraphQL doesn't rely on the HTTP caching methods, which enable storing the content of a request. Caching helps reduce the amount of traffic to a server by keeping frequently accessed information close to the client.
Fetching data with a single API call - The main difference between GraphQL and REST is that the latter is centered around individual endpoints, so to collect all needed data, a developer has to combine multiple endpoints. Whereas GraphQL focuses on the task itself, in this case, a developer can request the needed data with just one API call.	Performance issues with complex queries - While enabling clients to request exactly what they need, GraphQL query can encounter performance issues if a client asks for too many nested fields at once. So, to be on the safe side, it might be worth using a REST API for complex queries: Retrieve the data by means of multiple endpoints with fine-tuned, specific queries. Although multiple network calls can also take up a lot of time, it'll be safer from the server maintenance perspective.
Permissions - Creating a GraphQL schema, you get to choose which functions to expose and how they work. In their turn, REST views tend to be all or nothing. So, every view should have knowledge of what can and cannot be exposed in various circumstances, which isn't that simple to do. Otherwise, if a query includes some private information, REST architecture won't even reveal public portions of the requested data.	Overkill for small applications - While GraphQL is the right solution for multiple microservices, you'd better go for REST architecture in case of a simple app, REST can be also a valuable approach for a connecting resource-driven apps that don't need the flexible queries offered by GraphQL.
Detailed error messages - In REST, we simply check the HTTP headers for the status of a response, based on which we can determine what went wrong and how to handle it. Contrarily, if there is an error while processing GraphQL queries, the backend will provide a detailed error message including all the resolvers and referring to the exact query part at fault. They don't have to be a particular standard, you can choose if they could be a stack trace or just plain text etc.	Takes a while to understand - With GraphQL, be prepared to have a lot of pre-development education like learning the Schema Definition Language. As not every project has the time and resources to get properly acquainted with GraphQL, they may go for REST as it offers less complexity. While offering nice convenience operations, understanding and implementing simple GraphQL queries can burn some time.
Rapid Application Prototyping - If the goal is to provide a prototype, CRUD operations can be time-consuming, GraphQL speeds up this process by providing a single API endpoint that serves as a data proxy between the UI and the data storage. Additionally, the velocity of development is closely related to improved developer experience that GraphQL offers: Easier coding with the data right next to the UI, resusable fragments, less thinking of error handling etc.	File uploading - Since GraphQL doesn't understand files, a file uploading feature is not included in its specification. You won't have to deal with this limitation in case of REST, as there you can POST or PUT whatever content you want to.

Extra Programs

Alternatives - REST, JSON, APIs, etc
Database Technologies - mySQL, MongoDB, ArangoDB, MariaDB
Programming Languages - Haskell, JavaScript, Perl, Python
Web Frameworks - ReactJS, VueJS, Angular

Sources

Summary

In conclusion:

GraphQL is an interesting new-ish technology to use whilst developing web applications. It offers more flexiblity than the old REST Architecture and APIs associated with it. Consider changing in the future if it is possible for you. However, there are cons (of course) with GraphQL, such as GraphQL not understading files (yet) but that should change in the future. Depending on what sort of app you are making you may want to consider which architecture you'd want to use.