GraphQL vs. REST: A Dev's Guide to Picking Your API Poison (and Why You Should Argue With Me)

If you're building anything web-related these days, chances are you've got a nagging question at the back of your mind: REST or GraphQL? It certainly feels like the old, trusty workhorse pitted against the shiny new toy in this battle. Which one will be right for your project?

Let's hash this out.

REST: Good Old Days

It is no wonder that REST has been here for a long time; it is very easy and liberal. This method is so easy to understand and start working on. REST operates with the client-server model and uses the following conventional HTTP methods to execute the CRUD: GET, POST, PUT, and DELETE.

The beauty of REST lies in the simplicity and wide adoption. It is almost like a trusty toolbox that everyone knows how to use – a huge amount of documentation, libraries, and tools are available, and pretty much any developer you hire will at least have experience with it.

…but REST isn't perfect….

The probably largest disadvantage of REST at this point is that you always end up either over- or under-fetching data. You either get too much information back at a time, wasting bandwidth and processor cycles, or it makes a bunch of requests to get all the data you want. It's really a pain, especially when it comes to bandwidth-hungry mobile apps.

Another annoyance is the rigidity of REST endpoints. You need to define them up front, and when your front-end requirements change, you have the potential pain of redesigning your API.

GraphQL: The Shiny New Toy

GraphQL was born out of frustrations at Facebook with the limitations of REST. It's a query language that lets one request exactly what is needed and nothing more or less. You basically define a schema that describes your data, and then clients can send in queries to retrieve specific information as per their requirements.

The really cool thing about GraphQL is that there's only one endpoint for all of your requests. That could help a lot in reducing the number of round trips to the server, making your application snappier. And the strongly typed schema allows you to catch errors way too early; it also makes it easier to maintain your API.

Hold Your Horses, GraphQL Ain't All Sunshine and Rainbows

While GraphQL is undoubtedly very powerful, it comes with its set of challenges. First of all, there is a bigger learning curve since you need to understand the concept of schemas, queries, and mutations, which might become overwhelming at the very start.

Another problem is caching. Since GraphQL queries are capable of being so dynamic, having efficient caching strategies in place is trickier compared to REST.

And then there's the performance factor. Unless you're careful, complex GraphQL queries can really tax your server.

The Smackdown: When to Choose Which

So, when should you go with GraphQL and when should you stick with REST? Here's my opinion, but don't worry - I love a good argument about this:

Use GraphQL if:

• Your app has complicated data requirements.
• You're developing a mobile app and you want to reduce the number of network requests.
• You're using microservices architecture.
• Your frontend requirements are changing all the time.

Stick with REST if:

• You have a small API with simple data requirements.
• You are building a public API that must be easily consumed by a broad base of external developers.
• Caching is of the highest priority for your app.
• The Hybrid Option

Of course, there's no rule saying you must pick one or the other. In many cases, a hybrid approach that combines GraphQL and REST might be the perfect solution.

Now it's your turn!

On a final note, now that I have shared my two cents, I would be interested in hearing from you on what you think. So, have you tried GraphQL or REST in your projects? What was your feeling? Have you had any unexpected challenges? Maybe you just have a bit of a completely different angle about this whole debate.

Drop a line in the comments below, or hit me up on ([e-mail])

Let's start this chat!