From a Remix monolith to microservices

A small story of me learning micro services, gRPC and a multitude of things.

From a Remix monolith to microservices

Greetings, brave software voyagers! Today, we're here to discuss a transition that's as dramatic as a soap opera breakup but with significantly fewer tears (we hope). Picture this: you and your trusty Remix monolith, once the power couple of your development universe, are now contemplating a conscious uncoupling.

I'm working on developing a SaaS product that assists content teams not only with content management but also with their day-to-day operations. This includes features such as issue tracking, content storage and management, file versioning, a review system, calendar integration, email functionality, Shopify store management, and analytics for various platforms.

At first, I made it as this big remix app, like a remix monolith, with all the backend logic crammed into loader functions, actions, and a bunch of different handler routes. It seemed alright at the time, but with the crazy number of APIs, I started wondering if that would cut it... This is a kind of reason I should have said but to be honest this project is my learning experiment I am trying to built a production ready performant software so that I can learn a multitude of things.

So when I started working on this project I could already make a application that might sometimes work, I mean the one perfect way to do things always work but will it work if you click slightly to the left. Well god knows, so I made the first version,i.e, the monolith with the aim of learning error handling and good practices. And now I can successfully make applications that can run in more than one scenarios.

But I wasn't very happy with the UI and an extreme lack of separation between frontend and backend code. As well as the horrific performance I was getting out of the damning combination of prisma + mongodb. All of that with no TS.

So here's my plan to kick of a microservice based architecture.

I will still have a remix SSR that talks to RESTful API which acts as a auth proxy, this auth proxy then delegates traffic to all the other services via gRPC.

Ignore the (express app) written under the services, I have decided to give up node from my backend stack it's most GoLang and Python. This happened because I started with Golang for auth proxy because it would need to be very performant. That continued along in the pursuit of performance, I hear ya I hear ya performance and python ?

I use python ony for services that are just basic crud and to be crud performance depends mostly on the database and the queries you run (correct me if I am wrong).

This seems like a good idea, the go auth proxy on look is giving me extremely good performance. On my local setup with postgres and redis cache the auth proxy responds with sub millisecond responses.

This seems to be great performance I mean for sure it's local but these services in a k8s cluster with the postgres database in the mix, and redis running on all these individual services it should be very fast.

You can look at this project here:

Did you find this article valuable?

Support Iresh Sharma by becoming a sponsor. Any amount is appreciated!