Male Android engineer working in front of a monitor showing a code and a laptop with a SumUp card reader and white POS device on the table.

GraphQL — When to consider using it?

Written by Mohamed Gamal

In case you want to receive real-time data from the server and get many other benefits, GraphQL is definitely something to consider!

Notes:

  • This article only covers the decision-making process and when to consider GraphQL as an option.

  • The other part about the GraphQL integration with the client side is coming in another article soon (it'll cover the integration with the Android client, but the logic is the same for all clients anyway).

What is GraphQL? I definitely won't describe it better than their official website.

What will GraphQL bring to my project? Oh boy - welcome, you're in the right place! You'll get the answer while reading this article, and I'm sure in the end, it'll help you to build your own point of view 😉

Let's talk business?

Case #1

You've joined an awesome startup that's building an app. It's a clothes donation app, so the main screens are about some fixed data you'll get from the backend (addresses, pictures and info about the org) and a form that the end-user will fill out and say, "I have clothes that I wanna give away, please come and get them".

As an engineer in the discovery phase, you want to decide with the backend engineers on the tech stack you'll use. If they said this is a straightforward REST, would you mind? — I'm sure you won't mind! Maybe you'll challenge it, but you'll be okay with REST.

Case #2

You were up for a change, so you decided to join another awesome startup building an app (for sure 😁). It's a real-time chat app, so the main screens are about your conversations and the real-time chat itself.

Luckily you're involved in the discovery phase again. Here there're many options on the table to use:

  1. REST, covering all the app functionalities. Yes, you can still get the chats and repeat the `GET` request calls every x seconds/milliseconds -> Polling, for example.

  2. A mix of REST and Firebase real-time database (check https://firebase.google.com/docs/database). So, in this case, you'll use the real-time database to get the chat messages and also to send the chat messages.

  3. A mix of REST and WebSocket (check https://socket.io/). So, in this case, you'll use the WebSocket to have a stateful protocol that you can rely on to get the chat messages in real-time.

  4. 5. 6. Endless options, all of which have pros and cons! But have you considered GraphQL?!! Here's the reason why you should add the very powerful GraphQL to your options:

I heard about the mix of REST and WebSocket. Come on, why?!! If you'll start from scratch, GraphQL is way better (sorry, sounds a bit opinionated) because it'll enable you to do the REST work (in a different way and really more efficient one because you can get from the server exactly what you want and no more) and also the WebSocket work (yes, it may end up by exactly the WebSocket implementation in a much easier way).

But the big question of "How" remains. Well, let's simply answer it in some points:

  • What exactly do you need from REST? GET, POST, PUT, and so on? Cool, GraphQL will enable you to do this (the stateless side) using 2 main operations: Query (a `read‐only` fetch that will replace the GET) and Mutation (a `write` followed by a fetch that will replace all of the others from POST to DELETE).

  • What exactly do you need from the WebSocket? To receive real-time data flows and to have an open connection with the server? Great, GraphQL will also enable you to do this using the Subscription operation in different ways — open the link to read more about it — one of those ways is to use WebSocket to get the job done.

Doesn't it sound cooler to have all you need in 1 powerful and well-maintained place? Please check Apollo for more.

Case #3

You've joined the same company but in a late stage, and you want to advise them to migrate to GraphQL.

This is a tough one from the backend and infrastructure side, and I will leave it to the backenders. But for the client side, it'll be covered in the implementation part (next article) - stay tuned!

For any questions or further discussions, don't hesitate to reach out to me 🙌🏼

Interested in an engineering career at SumUp?