DEV Community: Omar Belghaouti

Microservices are bad for some cases…

Omar Belghaouti — Tue, 27 Sep 2022 16:37:32 +0000

Microservices are bad (for some cases as well)!
One of the most trickiest things to have when dealing with Microservices is that sometimes there are chances to have problems during the communication between services, maybe one of the services is down at the moment, one solution for that is having some replicas for that service (like having PaaS tools like Kubernetes or Docker Swarm to orchestrate your services).

Having said that, it may become difficult to manage large amount of services, especially when some services are dependent to other ones.

One of the hardest things as well is that the testing may become complex over a distributed environment. Sometimes you may create some fake APIs for your testing to unit test your single service, it’s not ideal but it can do the job.

So keep in mind, not all solutions are the ideal ones, there are always drawbacks and challenges to deal with them. Sometimes your problem can be solved in a Monolithic architecture instead of Microservices, maybe you want vertical scale instead of horizontal scale? It’s always about choosing the path and design your system that suits your problem..

Hands on gRPC

Omar Belghaouti — Tue, 27 Sep 2022 16:34:58 +0000

gRPC is becoming the standard to communicate between microservices. It uses HTTP 2.0 (released in 2015) as its underlying transfer protocol which is more faster and efficient compared to HTTP 1.1 that was released at 1997 and still used in the modern days.

And with all that it secures the connections by default with SSL/TLS, so not only performance but also security are included.

Unlike REST APIs which uses json communication which takes a lot of size and latency, it uses what it is called by ProtoBuf (Protocol Buffers) that are way minimal and faster with communications.

For now, gRPC is used a lot in micro services and mobiles, especially for mobiles because it is faster and the transferred data is minimal and can be delivered in minimal time compared to HTTP 1.1. For web it’s still not there yet but there are some workarounds like making some gateways for that matter.

Also one of the cool features about gRPC framework is that it is language agnostic, meaning that it works for any language out there, you just need to write a proto file which has a simple syntax and then let the protoc (proto compiler) handle generating the code for the language you want like C++, Go, Java, … etc. All what you need to care about is the implementation for the services.

There are 4 types of APIs in gRPC, unary, server streaming, client streaming and bi directional streaming. Which holds a new way for communication, especially the streaming ones compared to REST.

In this example, I have created a blogs service that handles all the CRUD operations with MongoDB, it has unary rpc for all the operations and a server streaming to list all the blogs from the database. You can see in action how simple it is, because as I said above you just need to care about the implementation, all other things are generated for you!

To test the example yourself, check this repo

A dashboard in microservices architecture

Omar Belghaouti — Mon, 26 Sep 2022 15:49:56 +0000

Microservices are good (for some cases)! they help organize your architecture in a meaningful and more approachable way, they help teams to focus on specific tasks not to worry about other things. You can totally work separately and even with different technologies, all you need to do is a way to communicate between services, it could be REST, it could be gRPC or it could be both, why not!

These past days I was working on a personal open source project that shows dealing with microservices in action. It honestly felt like building Lego parts as we did when were kids. Once you have an architecture in mind you can do the building blocks way easier, you'll just think about the execution and it is preferred to keep performance in mind.

So without further ado, here's an explanation of what I did:

First of all, there are 4 internal services ("Customers", "Suppliers", "Orders" and "Auth") which communicate with each other with gRPC. Each service is communicating with MongoDB as it's the chosen database for this example and each one of them have their collection in the DB.

The "Customers" and "Suppliers" service are solely communicating with Redis when trying to get one customer or one supplier by id. it helps to get data from the memory cache and not getting from MongoDB each time. In my local machine, I got around 24ms when I get a supplier for example, when it's cached in Redis I got 3ms so you see the importance and performance that Redis provides.

Of course, not all suppliers or customers are cached in memory but only the ones that are to be retrieved from MongoDB, at first time they are going to be retrieved from the database, but in the subsequence times they are going to be retrieved from the cache. And in this example, they are cached for 5 minutes just so we cannot fill memory with a lot of data. Also it is important to notice that when deleting or updating a supplier for example, the cache memory also needs to be updated.

You may notice that there are some gRPC calls between services in the graph below, that is because it guarantees performant and simplicity to talk to each other on top of HTTP 2.0 as we spoke previously about it.

In this example, there are gRPC calls when getting orders by customer id or supplier id we need to check if they exists in the database, so each service can do that specific job so the "Orders" service will check the existence of this supplier id or customers id by talking to "Suppliers" or "Customers" services respectively with gRPC. Also the "Auth" service help with authenticating the user by the used token in all the REST calls to all services, it will verify the token if it's valid and not expired as well.

Now, let's talk about Nginx. Here it is working as a reverse proxy and load balancer between services, it forwards all the calls that are coming from the client to all services.

Lastly, the dashboard is built with SolidJS as it helped me a lot with the built-in state management.

To test yourself you can check the GitHub repo here