Is GraphQL the future of HTTP requests?
GraphQL developed by Facebook is described as a ”query language for your API“, giving developers the flexibility to choose which data gets returned to them, how it gets produced, and providing self-written documentation for an API, but is it replacing the regular HTTP requests servers we all know and love? Yes and no, while the nature of classical HTTP requests servers is never going away, they might not be in your significant future.
Firstly, GraphQL is written using HTTP Requests in the hood with you being able to access the server directly through npm packages such as express-graphql and as described on the GraphQL server website. Secondly, the architecture of GraphQL style requests has been implemented in Javascript so far among many other languages with server frameworks being built upon the existing GraphQL system such as Apollo Server, and what was previously mentioned Express-GraphQL. Other popular language solutions include Hot Chocolate for ASP.NET Core and ASP.NET and API Platform for PHP.
Thirdly, the GraphQL schema and type definitions allow for easy data storage, and collection and you are able to know exactly what data you are getting every time. This not only allows for engineers to easily diagnose problems and troubleshoot within their server when data isn't being returned correctly but also allows for the self-documentation of the server which saves hundreds of hours of wasted time in asking “What does this route do again??”.
With this combination of usability, readability, and ease of use among platforms, it makes sense why GraphQL is being so widely adopted, and while it seems like an amazing improvement on the already groundbreaking work of HTTP requests, it is not all sunshine and rainbows. For years HTTP servers have been built all across the internet and they have reigned supreme for years, services like Spring for Java or Express for Javascript have allowed for ease of use when creating servers, and cannot be easily replaced with GraphQL. As with any technical shifting, there is a price to pay, which is time. Shifting between technologies within existing servers or finding some way to interact with existing HTTP servers from a GraphQL server will take time and resources to be able to provide integration.
Overall, the technology behind the GraphQL server and the existing technologies that power it is amazing advancements in terms of server use and readability, all that is left is more adaptability in the community, and many are hesitant to adapt. Adaptation of the new technologies in existing codebases is slowed for the fear of destroying the tried and true but as with anything with technology, the only way forward is collaboration.
