Michał Tyszkiewicz
11/22/2022
As you probably already know REST has been the established industry standard for years and GraphQL is supposed to be an alternative if not an outright replacement. True it boasts a lot of significant improvements, but is that enough to declare it a successor and deep REST obsolete?
So what are those improvements? The most widely touted one is data fetching efficiency. With REST you query a number of endpoints to get the needed data. For a simple Twitter like app you’ll probably have a directory with users, posts, followers etc. and to get all data pertaining to a particular user account you might need to query all those endpoints with multiple simple queries. While this might seem like an insignificant problem it gets compounded the bigger or more complex the app, the more users it has and the more queries it has to execute to get the needed data. Long story short it should be quite obvious why Facebook decided to go a different route. With GraphQL you only need one endpoint and one query to get everything you need:
Data fetching in REST by howtographql.com
Data fetching in GraphQL by howtographql.com
While the advantages are clear it's also obvious that REST isn't all bad, if it was it wouldn't continue to be so widely used. REST is still better for simple apps where using GraphQL can be overkill as you’re unlikely to take full advantage of its features in a noticeable way. Additionally while GraphQL can drastically reduce the amount of work needed in a big and complex app it can actually make things more complicated for small and simple apps where instead of just a few fields you’ll get types, queries, resolvers and other components. The other big difference is in the learning curve which for REST, with its simple hierarchical structure, is much less steep than for GraphQL, where it can sometimes be a turnoff for beginners.
The learning curve question opens a whole another aspect of this discussion. For one person learning a new language will be a fun addition and building their skills, for another it might look like wasted time. Similarly while GraphQL is designed as an improvement over REST you can still do much of the same things in REST that you can do in GraphQL. It just requires using some third party libraries. Sure GraphQL supports those functions natively and you’ll be dependent on those libraries being maintained and working as intended, but it is nonetheless possible if you just want to avoid using GraphQL. If we’re being honest a lot of devs are very stringent with how they like working and if they’re convinced they want to stick with REST they will be more than likely to jump a few hurdles to do so.
At the end of the day the key points to weigh is the functionalities you get with GraphQL vs the simplicity of REST. It does mainly come down to whether you want to learn something new that is gaining popularity or you just want to stick to your guns. On top of that while simple apps might not get much use out of GraphQL if you’re envisioning them growing at any point down the line it is much more efficient to jump to GraphQL earlier rather than later. Finally the key is actually personal preference and balancing how you like to work against what is required and weighing the benefits for you and your projects.