unborn arrow
I see from time to time projects where they are split in microservices, but keep everything in mono repo. What might be pros & cons of developing application this way instead of doing it traditional way?
It makes sense from infrastructure costs perspective, but other than that?
violet steeple
I haven't really worked with microservices heavy apps hence I might be slightly confused here but I'm not following your question. Whether you have your services in different github repos or not shouldn't really matter. I can only assume you are asking about modular monoliths vs microservices in that case; go for a modular monolith and when it's time (rarely?) you can deploy them as separate services with probably only having to adjust the communication between the services depending on how much effort you put into modularity.
rugged tinsel
I'd like to know what you consider to be "the traditional way". @unborn arrow
unborn arrow
@rugged tinsel I mean by using modules etc. Keeping everything in one project (or container) when you run it.
rugged tinsel
You know, you can also have a monolith, but also have libraries, where the code is not within the monolith, but where you can import the code via linking of a monorepo system like with pnpm workspaces?
unborn arrow
@rugged tinsel sorry, im new'ish to microservices in a practical sense. But yes, its monorepo with pnpm and apps are generated with nest g app <app name>