GraphQL, is an open source technology originally put forth by Facebook which has continued to gain momentum since its release in 2015. Some large companies have decided that it works better for them as an architectural style for their APIs including GithubTrack this API, YelpTrack this API and ShopifyTrack this API. There are many devs that have used it and yes, some of them have even gotten caught up in the hype. Many of those devs believe that GraphQL is the way to go when developing their next API. As with any technology though, it has its strengths and weaknesses.
So.. the questions are: Should I use this technology? Do I need it?
If these are questions you have asked yourself, then keep reading!
There are many good reasons to adopt new technologies; because it’s cool and trending is NOT one of those good reasons. As a development company, we are always looking for the best tools to solve our client’s challenges. Looking for ways to cut time and get applications back into the hands of our clients is a mission for us.
As you well know, different products need different API architectural styles to get the desired results, properties and business objectives. There is no “Always” in software development, if you are looking for the silver bullet you will not find it in any technology. Being an architect, it is your responsibility to have multiple styles under your belt and to know which one to use and when.
Pros & Cons of GraphQL
Pros of GraphQL
- It combines ideas from the world of databases with Web API features to enable deves to build data-rich applications
- Reduced complexity and back and forth between the back-end and front-end devs, more efficient queries as compared to typical REST.
- Devs can fetch for the exact slice of data they need and want
- Front-end devs can basically see every possible API query they could make
- Back-end devs do not have to maintain explicit documentation, it automatically discovers APIs.
- Community tooling helps devs validate their API calls before deploying, reducing the typical requirements to integrate APIs into apps
- Accelerates development with less URLs needed for loading and querying.
- The GraphQL ecosystem is growing, which is always helpful in flushing out the problems.
Cons of GraphQL:
- Not very good tool for the specific needs of mobile clients, many who use layers of queries on top of the REST APIs
- Weak on Large system applications using domain modeling which is critical in maintaining agility in large networks of applications.
- Another problem is rate limiting. Whereas in REST it is simpler to say “we allow only so many resource requests in one day”, it becomes difficult to make such a statement for individual GraphQL operations, because it can be everything between a cheap or expensive operation.
- Implementing a simplified cache when having GraphQL becomes far more complex, each query can be different even though it operates on the same entity.
Will GraphQL replace REST APIs?
One great example of a very large system of applications that has not failed us in the many years that it has been in service (so far) is the web itself. According to SDtimes.com “The web provides powerful evidence of the benefits of REST that stood the test of time; it seems much easier to imagine meeting the needs that GraphQL addresses by building on top of REST, versus recreating all of those advantages anew for GraphQL as robustly.”
There are benefits of GraphQL over REST and people will flock to it to reap those benefits. It will all be determined by how broad the adoption will be.