Modular monolith vs microservices

1

Recently I came to the conclusion, that actually only two issues bothers me in relation to the monolith pattern:

  • necessity to pull the whole application:
    – extremely sub optimal in case if you need to take care for some tiny feature or a bug
    – potential risk of an access to a fragile or confidential part of a code by a programmer who could potentially use it without accordance with our intentions
  • resources overload needed to engage even for some tiny requests
  • huge scalability issues

But what if…

we build a monolith that consist of specialized modules, being able to operate both as integrated parts of a monolith an at the same time (when needed) as independent standalone services?

This approach allows to solve mentioned at the beginning issues and some time ago I started to work on the solution with I thing quite a success thanks to SLIM.

I wonder if anyone has some similar experience, attempts with this kind of approach.

2

i think if an application “modules” end up having radically different dependencies etc then they should go into their own application. but stuff like auth / profile / front end / admin / etc that “share” dependencies should be modularized within the app (i prefer this).

if you build an API onto the system that is headless, then it doesnt make sense to add the “head” part that consumes the api in the same code base for instance. the “head” part doesnt need access to the database for 1.

i think the amount of “wireing” you’re going to need to build an app that can be standalone or part of a bigger app would really increase your code a lot. for one you will have to duplicate a ton of stuff or have checks if exists type thing.