#starting a monolith but with a microservice in mind

52 messages · Page 1 of 1 (latest)

wild thistle
#

exactly what the questions says, i wanna make a project as a monolith so i can move faster bringing new features but at the same time i would like to keep it kind of modular so if i ever need to move one feature to a microservice it's a easy process

unborn falcon
#

Well, in general, Nest's module system, if done correctly, leads to a code base that is "separable". By that I mean, if you follow the concepts Nest offers with its modules, then you are building semi-standalone features to your application in modules. The logic in a module supports a service and only the means of implementation must be changed.

To embelish on that, the big difference between a monolithic module and a microservice Nest application is the means of communication. And that is where the two differ greatly. The "switch" between using Dependency Injection to share APIs across module boundaries and using a form of bus system or other messaging broker process are completely different. This communication change is where breaking out a module into a microservice has its biggest hurdle.

One way to overcome that is to have a communication process already set up in your monolith that is microservice-like, where the API is very similar and deals with messages/ a bus-like system. In fact, larger monoliths usually needs such a system anyway, so that sibling modules can communicate with each other and avoid a spaghetti DI graph. So, it isn't too far fetched to go ahead and just use a bus system internally inside your monolith (and avoid crossing most module boundaries with DI).

I've been researching this topic for some time and the only real and proper solution I could come up with is to use a system like Temporal from the start. Temporal allows you to build 100% standalone modules. You could almost call it a microservices inside a monolith.

Now, there are trade-offs of course. Latency is one big one, because no matter how you do your decoupled communication process, be it message brokering, Temporal, event sourcing, etc. (this problem has a lot of solutions), you'll end up having it take more time to get work accomplished. And getting it all to work is also time consuming.

Open Source Durable Execution

Build invincible apps with Temporal's open-source durable execution platform to guarantee successful execution, even in the presence of failures.

#

Time you could be taking to just get work done. If you aren't 100% certain you will need microservices, don't optimize for them prematurely. It will cost you more than it will be worth.

wild thistle
#

do you think making this real state app like a microservice would be a bad idea?

#

i already know i wont have a lot of users there because it's for a real state business in a town where maybe at most 5-10 users will visit the website

unborn falcon
#

If you are alone or have a very small team, absolutely it's a bad idea. Microservices solve zero problems for you and will only cause a lot of heartaches to get right.

wild thistle
#

but i'm still unsure if i should go like a microservice or try a microservice app but in like a smaller scale

wild thistle
unborn falcon
#

If you wish to learn how to do microservices and the tech around it, then do it in a side project that is NOT business critical.

wild thistle
#

when it comes to a concept or design pattern

#

i know you get better at coding by coding but still wanna know what things should i aim for

unborn falcon
#

Do coding. 🙂 Also learn coding patterns (if you don't know them already).

wild thistle
unborn falcon
#

Or take a Udemy course or similar. 🙂 They are better, as usually you can code along with the training.

wild thistle
unborn falcon
#

Naw. I can't recommend any off hand. I'm certain there are many. 🙂

wild thistle
thorn jackal
#

You should read about modular monoliths, that's the way to go. It's pretty much having a microservice-ready architecture but in a monolith.

wild thistle
wild thistle
unborn falcon
#

Following Nest's module concept is in effect, creating a modular monolith.

wild thistle
#

from listingService, it is ok for me to inject the userService and use it that way? and if so what would be the upcomings steps or things i should do to convert the listingService to a microservice and call it

unborn falcon
#

Depends on what you define as "loosely coupled". Using DI is a form of coupling (where the better form is IoC). Requiring services outside of your module is coupling. Needing messages to get a task done is coupling. Needing data from other domains is coupling. And the question needing answering in the end is, what does maintaining this coupling cost me? Cause, you'll always have coupling in some form. And you must know what "loose coupling" means for your purposes.

You can use simple Nest DI and import the User Module into the Listing Module to use its services. This, however, won't work in a microservice. You could create a bus system and send messages. However, an internal bus system isn't exactly a broker type bus system. But, the API could be a lot closer, so making it a tick better for later conversion to microservices. You could put in an actual messaging broker, but that is absolute overkill and majorly silly for a monolith application.

Again, don't overthink your application i.e. don't do premature optimizations like trying to build for future microservice swapping of parts of your application. If you wish to learn microservice architecture, then build a todo app or something similarly simply with a microservice architecture, but be sure it is something non-business critical. Then you'll start to see why you should just start off iwth a Nest monolith and worry about switching to microservices, once you have either scale in usage or scale in development.

wild thistle
#

plus i like the devops world and wanted to have a little bit of experience deploying stuff like microservices but yeah i think i'm doing a little too much right now

unborn falcon
wild thistle
#

like knowing about cloud hosting ect ect

unborn falcon
#

Well, you should have a good knowledge of devOps as a developer. But, choose which line you wish to be an expert in. I actually like devOps more myself. 🙂

wild thistle
#

or

#

i should go directly to devops

unborn falcon
#

Just like a dev should know about devOps, a devOps dev should know about normal development too.

wild thistle
#

thanks for your time scott i really appreciate it

unborn falcon
#

Docker is "mainly" for development purposes and to containerize applications. Just be sure about that. It's not really a good choice for production setups.

wild thistle
#

i see it's very common that people put their apps into dockers images and then like host it like that

unborn falcon
#

They may put their apps in containers. And you can host containers in a Docker(-like) environment, but you are missing out on a number of features for highly availability, like the restarting of containers on failure. Nobody seriously using containerized apps uses them outside of Kubernetes.

#

Docker Swarm was made to be a solution for using Docker in an HA environment, but it's died since k8s has taken over on popularity.

wild thistle
#

ok i get it

unborn falcon
#

Or, you put the apps in something like AWS' ECS.

#

Which is a sub-service to me that tries to simplify k8s.

wild thistle
#

i like cloud and i think that's where i wanna move to

unborn falcon
#

Naw. Do a couple to few simple full-stack apps. Then take on learning devOps.

wild thistle
unborn falcon
#

Once you have an app or two, you can build your own devOps process around them to learn what it all means.

wild thistle