Suggestion: Plugin-style module architecture

[rdelhommer]

Currently, MEAN.JS is very monolithic. API modules are integrated fairly tightly into the server application when they could be encapsulated as modules and kept independent of the application.

Essentially, my suggestion is to turn Riess into a shell-server whose API endpoints are plugged in and bootstrapped at application start. We could bake in some modules like for user and and auth endpoints, but keep everything else separate.

An architecture like this would ideally provide the following benefits:

• improved stability of the core server shell -- some code churn would be isolated to endpoint modules

• improved maintenance of downstream projects -- Ideally, the core shell of downstream projects would be more similar to the origin/master and thus bug fixes and improvements would be easier to merge. I've found that most of the changes I make in my MEAN.JS downstream projects are related to the user module. If this were encapsulated separately, it would be easier to merge security updates from the master branch

• Just thought of this one... downstream projects could even consume the shell application as a module which would be awesome from a maintenance standpoint. Updating the shell for bug fix and security updates would be as simple as running yarn or npm upgrade

• a more flexible architecture that users could independently write plugins for to provide additional functionality -- I'm currently working on a project that is conceptually similar to a microservice marketplace. I started with MEAN.JS, but ended up changing a lot as the architecture required me to make a monolithic application when ideally, I would put each microservice in its own repository and require it in to the shell. Right now, I'm doing all the development myself, but my vision is to eventually provide a platform that other people could ~~~contribute to and write their own microservices for or even~~~ roll their own custom service using my application as a starting point.

There are a few downsides that I can think of:

• Fairly large refactor
• Dependency hell if the core shell is maintained poorly and churns its interfaces too much

Edit: The part I struck through was dumb and half baked, but I think the rest is still good

[lirantal]

I'm not sure I'd describe current MEAN.JS as monolithic but rather as an opinionated project scaffold and what I like about it is it's flexibility.

I understand your points but I think if you're searching for some pluggable architecture kind of framework then you're probably looking for what MEAN.io was trying to do initially (and it didn't go well for them IMO), and these days you can consult feathers for what you're describing.

I don't like this approach because it creates complexity on the core framework and turns it into something that is by-design less flexible if you try to do simple things for users, or has too many abstractions.

Another reason I don't see much value in a complete pluggable framework is that these days microservices rule, and you'd probably be keeping your services very small and business-logic oriented to the point where you wouldn't really be "managing modules" per say across different projects, but instead you'd probably be sharing libraries and externalizing core functionalities out to their own microservices (like service discovery, users, auth, config mgmt, etc).

With that said, I like mean.js's vertical modules architecture and it does allow you to compartmentalise features or capabilities into their own module which in turn has its own routes, controllers, services, tests, etc). If you build them well then maybe you can wrap them as npm libs, and this way just share them across projects and simply do a drop-in module by just "sticking it" there in the modules/ dir.

The architecture I'd like to further build-on in Riess.js for the server-side is with regards to cleaner separation of concerns (addition of repository, services), general utilities (log, error handling),while keeping it flexible.

[rdelhommer]

Yeah that all makes sense.

Thanks for taking the time to write out such a good response. I'm still pretty new to web development and architecture so thanks for humoring my thoughts and providing such a constructive response :)

[lirantal]

No problems, keep on challenging and asking questions it's welcomed.