Why you should (not) use GraphQL ?

Azhan7 — Sun, 19 Feb 2023 19:25:03 +0000

Recently, I read about the GraphQL which is a query language for APIs. I thought to give a try and share the experience with you.

What is GraphQL?

As described earlier, GraphQL is a query language for APIs. Basically, it gives clients the power to ask for exactly what they want.

To understand it further, consider that your backend APIs are consumed by two front-end interfaces: web and mobile. And for some reason, both interfaces require separate fields. Without GraphQL, either you need to implement two types of APIs, one for your web client and one for your mobile client, or you need to send the exact same data to both of your clients.

Problems with sending excess data

Slower API performance
Increased network bandwidth

To solve this problem, GraphQL comes into play. It lets your client ask for what he/she wants and filters the results automatically depending on the client's needs. How do we use GraphQL?

To use GraphQL, we need to define the graphQL schema. The schema consists of types that define the fields inside it, as described in the image below.

The ! at the end of the ID present in book type makes it a non-nullable type. The Query depicts the methods that endpoints can use.

Notice how I have used the allBooks and getBook methods defined in the Query type of the GraphQL schema.

Testing via Postman:

Now, let's see how we can test the newly implemented GraphQL API. Look at the below-mentioned image. I requested three fields: title, description, and author. And the API has given me the exact same response.

Now, let's ask for some different parameters. And GraphQL has given the exact same response which we have asked for.

Problems of using GraphQL?

It is hard to cache the response. Although it is possible to cache the response, it becomes difficult as clients are free to ask for whatever field(s) they want.
Generally, when we use REST APIs, we find out if everything runs smoothly through the status code, but this is not the case with GraphQL. If you get an error in GraphQL, you need to parse the body.

When you should use GraphQL ?

It is advisable to use GraphQL if you have a complex API.
If you have multiple interfaces, using GraphQL can be a good idea.
If you're worried about bandwidth, GraphQL might be a good option.

When you are getting data from multiple sources. For example, if you are making a dashboard and want to receive data from multiple services, such as a logging service, an analytics service, and a monitoring service, It is a good idea to use GraphQL so that the client can specify exactly what it wants.

I've also attached the github repository link incase you want to explore in depth.

Azhan7 / Exploring-GraphQL

Project Idea

Recently, during my reading sessions, I've came across GraphQL. I found the idea exciting and wanted to give it a try by implementing a basic project using GraphQL.

What is GraphQL

GraphQL is a query language for APIs. Basically, it gives clients the power to ask exactly what they want. To understand it further, consider your backend APIs are consumed by two front-end interfaces, be it Desktop and Mobile. And for some reason, both interfaces require separate fields. Without GraphQL, either you need to implement two types of APIs, one for your Desktop client and one for your Mobile Client, or you need to send the exact same data which you are sending to Desktop to your Mobile interface as well. But the problem is you are sending quite many fields to your mobile which is not being used by your mobile. To solve this issue GraphQL comes…

View on GitHub

Why Microservices are more complex than you think ?

Azhan7 — Sun, 12 Feb 2023 21:57:19 +0000

Microservices are a distributed system architecture, and they have lots of problems associated with them. Nowadays, more and more companies claim they are using microservices, whereas the reality is quite different from what they claim.

The defining characteristics of microservices are

They are small.
Focused on One Task
Aligned with a bound context
Autonomous
Independently deployable
Losely coupled

They are small.

Early pioneers of microservices used to respond to the question by saying that

An ideal microservice fits inside James Lewis' head.
James Lewis was the one who popularised the idea of microservices. The rationale behind that was to compartmentalise a problem.

How to measure if the given microservice is actually micro

If you can recode the microservice in a week or two, I think you are on the right path. That's one of the ways to measure if you are on the right scale.

Focused on One Task

To segregate a monolithic architecture, we must first determine which sub-problems our microservices should be divided into.Each microservice aims to achieve one task when viewed from the outside.

Aligned with a bounded context

This idea comes from the book Domain-Driven Design, written by Eric Evans. As per Eric, "bounded context" can be defined as

A defined part of software where particular terms, definitions, and rules apply in a consistent way.

This means that if we fail to segregate our services well, breaking our application into microservices could actually backfire as it will make services tightly coupled.

Autonomy

The team handling each microservice should be autonomous in changing the implementation. The true value of microservices is that the autonomy and lack of coordination they provide enable organisations to scale quickly.

Deployable on its own

Since microservices give the team options to deploy without being constrained by other teams, it makes their progress more significant.

Now the problem arises: if you always test your service with others before release, it is not independently deployable.

The real value that microservices bring to the table is that they can be built, tested, and deployed independently.

So, in short, one can say,

Microservices are an organization's decoupling strategy.

Losely Coupled

The interface to a microservice is a public API. Therefore, it should be changed with great care. If you keep changing the API too often, this defeats the whole purpose of the microservices architecture. Also, when consuming an API, use the minimum data that you can to reduce coupling.

Forem: Azhan7