Michał Tyszkiewicz

Michał Tyszkiewicz

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:

  • single source of truth: GraphQL requires only one endpoint & one query. All you have to do is structure the query to get the data you need and it will get that with just one round-trip to a single endpoint.

  • no over or under-fetching: The query will get exactly and only what you requested, no need for multiple queries and no issues with excess data. This as mentioned has an impact on bandwidth not only for singular mobile devices running the app, but even more so for large app providers running them for thousands of users.

  • type-safety: With GraphQL all the types are defined in a schema written in SDL (Schema Definition Language) which is a strongly typed language. This means both frontend and backend teams know the exact structure of the data and can work independently right away and both also enjoy features like automatic validation and introspection.

  • easy prototyping: Any updates to your app or for example UI are much smoother as you only need to adjust the one query if it now needs to fetch more or less data. With REST you’ll have to adjust the entire backend and every affected endpoint and probably also multiple queries to get that additional data you need.

  • data transparency: With just a single, even if complicated, query all the information is in one place. This way understanding what data is exchanged is much simpler than crawling over a whole patchwork of endpoints and simple queries getting bits of data from here and there before you can make out the whole picture.

Data fetching in REST by

Data fetching in GraphQL by

Is it all bad?

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.

Personal preference

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.

Plan ahead

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.

⚡ Speed up your GraphQL API development

The GraphQL Editor is a supportive tool for both advanced GraphQL users as well as those taking their first steps with GraphQL APIs. Our all-in-one development environment for GraphQL will help you build, manage & deploy your GraphQL API much faster thanks to dozens of built-in micro features. Its graphical interface will also fix communication within your product team. Visualization is the key!

Try it for free