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
Top comments (0)