pliant prawn
NestJS docs, "Philosophy" section states the following:
"Nest provides an out-of-the-box application architecture which allows developers and teams to create highly testable, scalable, loosely coupled, and easily maintainable applications. The architecture is heavily inspired by Angular."
Can anybody elaborate on it? Is any particular architecture encouraged / discouraged?
south belfry
Nest is pretty opinionated and the way you actually implement a nestapp naturally leads to having a more structured architecture. Look at some example nest projects on github to see how they all look quite similar and are structured sensibly.
Have you built many express apps in the past? I think the advantages of nest are most clear after you've already got a decent bit of experience with express and then start a new nest project. For me over half the effort I put into express apps was already done for me with nest, the various modules nest provide make it super easy to add new advanced features, and organising the project via modules makes for a much cleaner overall architecture with much clearer separation of concerns.
pliant prawn
Is my understanding correct that Nest imposes architecture through its features, approaches suggested throughout documentation in its entirety?
If that's true, does it mean that "Clean Architecture" is not quite aligned with NestJS' design?
@past light seeing how you previously responded to questions related to "Clean Architecture", I would really appreciate your input here, as it wasn't completely clear.
Would you recommend using "Clean Architecture" with NestJS?
I am trying to settle a debate at work.
Each microservice currently we use has a module per every single API endpoint (use case) and it feels completely non Nest-ish to me.
How is one supposed to re-use a module that is meant to serve a single endpoint?
Thoughts?
past light
@pliant prawn - If you work with Nest as it was intended to be used, you basically get Clean Architecture OOTB.
A Nest module should be a set of Nest components (controllers, guards, services, pipes, etc.) which make up a feature of your application, for instance "user management" or "authentication" or "authorization". Looking at the Clean Architecture diagram, a Nest module encapsulates both the layers you see in that diagram (i.e. controllers, use cases, entities, etc.), but only to the extent of the feature being "modularized". Nest then takes the metadata you offer in the components (including the module definition) and pieces your app together during the bootstrap process to make the final "big clean architecture app".
I like the Onion Architecture take better, where modules are mini-onions and Nest builds them together to make the big onion. 🙂
If you substitute "Use Cases" with what Nest refers to "Services", then that Clean Architecture diagram should make better sense.
In the end, the whole idea of Clean Architecture and also Nest's module system is to give parts of an application, i.e. business logic, controllers, entities, database connectors, etc. clear separation (of concerns), so that when you run into a problem or you need to enhance the application, you know exactly how things work and exactly where to look to make the fix or change.
It also helps people new to the Nest code to find themselves in it faster, to reason about it all and get to work on it quicker too.
pliant prawn
Thank you, this answers my question.