As software engineers, we are extremely familiar with the core functionality of REST for APIs. Recently, a modern alternative, named GraphQL, has been developed to provide improved flexibility of queries when compared to the comparative static nature of REST APIs. GraphQL has been developed to mitigate the existing problem inherent within REST APIs, Overposting, where a request returns far more data than necessary. This, understandable, slows down requests by adding complexity to the process of organising data into the required structure and hierarchy. GraphQL provides an ability for queries and requests to only return required data, rather than having to call multiple endpoints to receive subsections of a request.
While GraphQL provides simplicity for developers of complex systems, this can be problematic when attempting to handle more complex queries. The main disadvantage of GraphQL currently is the learning curve. REST has been around for a while now, and many developers have experience working with the traditional API construction with REST in mind. The strength of GraphQL comes from simplicity and flexibility when set up, requiring minimal effort to update and return new data, while a REST API would require a new endpoint to provide a new feed of data. Although GraphQL is flexible, using it effectively requires the same thorough planning and design as a traditional REST-based API.
Ultimately, GraphQL provides a refreshing approach to API creation, which speed up development and help simplify complicated systems. However, this approach is not a complete elimination of REST, as an API can be created capable of supporting both GraphQL and REST endpoints, providing an opportunity to leverage the advantages of both approaches rather than committing to one solution. The speed and simplicity of GraphQL, combined with the ability to handle complex queries make this a great option to consider for development.