Using Clean Architecture for Microservice APIs in Node.js with MongoDB and Express 

By injecting dependencies to function args, aren't we loosing out on intellisense? Is there a better way to inject dependencies ?

+Kashif Minhaj Editors like VS Code do a decent job of guessing after a while, but intellisense still suffers a bit for sure. One option is to use Flow or Typescript along with an Editor that supports it so that you can specify the type of each parameter on the way in. No guessing.

If we use something like mongoose, should we make entities become mongoose schema? Or we should pass a entity to a function which creates and returns mongoose schema?

@@blackdiz2603 thanks for asking such a great question. Mongoose belongs to the outermost circle, so it would occupy the same role as our MongoDB Driver. Meaning, we would inject a Mongoose model into our CommentsDB module and use it exclusively to interact with the database. It's very important not to confuse a Mongoose model with a business Entity. We need to make sure that business rules are as independent as possible from third-party frameworks like Mongoose. A mistake I see too often in legacy code bases is that they built their Business Objects on top of - or even inside of - some third-party framework and then after a few years their codebase becomes an unstable mess because the underlying dependencies have been deprecated but no one wants to touch them because it would risk breaking all the (often poorly or not at all documented) business logic of their app. Clean Architecture was designed specifically to avoid this situation.

Do you think the upcoming class features (public/privates, getters, setters) will change this implementation at all? in the comment entity: export default (dependencies = {}) => class Comment { constructor(data = {}) { // code to validate and store the comment data in 'this' goes here } #author; #text; #replyToId; } in a use case: // instead of const comment = makeComment(info) const comment = new Comment(info) Also as a side note, it's really hard to find examples of people working with the clean architecture, in nodeJS, using more than just one entity. It would be super helpful if, for example, you changed the comment author to an Author entity and showed how you establish and validate things like many to one relationships at the business-logic entity level.

I had to pause the video right here, so true! haha

client: Will it have AI? Me: Yes.

It is indeed one of its kind.

Agree

@@RaffaCaboFrioAgree!

Totally agree.

100% agree if only I'd have seen it a year ago 🤦‍♂️

I have been learning NestJS for a while, that framework highly uses this concept. You should try that out if you are a Node.js dev

@@tea_hanks1230 do you still use it?

The inject is not the important part; the adapters and interfaces are the important part. He said the outer layers should depend on the inner layers, which means the external tools and frameworks should depend on our adapters and interfaces. The make-callback.js at the end of the video is a perfect example. Also, imported/required modules can still be mocked in tests. Injection with the wrapper function is not necessary and even adds bloat.

I think it is part of SOLID principals, in the D part, dependency inversion principals. where the high level module should not depend on low level module, those two must depend on abstraction. high level module is the code that we write ourself, and low level code is the dependency such as mongoose, node-postgres, mysql that 'abstracted' as db connector

@@fikriseptriananggara5922 you don't need to use an explicit "inject" pattern if the module being imported provides interfaces for any external modules it uses.

Yea 100%. I feel like when I was first introduced to NodeJS and didn't understand a single concept. How is your understanding now, 11 months later? Are you applying this architecture (honestly)? Or are you applying a different strategy? Monolith?

I think it's a little bit too late, but this is not about nodeJS, in particular this is about programming in general, these concepts could be applied within any other language, I mean, maybe just oop ones? I'm not really sure

@@Melvin420x12 I didn’t get chance to implement it as I am working on existing applications but I have kept in bucket whenever my new project will start I will be going to think on it

@@no-name2031 no you can apply these concepts to any type of programming language. Even in this video dependency inversion is achieved through functions. Whereas in pure Oop language there will be an intermediate interface.

I was about to write the same thing....

@@grzegorzg944 same lol.... years I've needed this

I will be watching this several times until I understand more clearly. Great video!

Yes agreed, so much content that talks about clean architecture, but this actually shows it in action! And only now I’m starting to understand what it’s all about.

will do it too!

​@Ellie Maynard I agree. Virtually everyone has their own concept of how an Express or React project should be structured. There are very few standards in JavaScript compared to other languages. The approach shown in this video is an attempt to carry over architectural concepts that are more commonly found in C#/.Net and Java. I'm not saying it's bad, but you're correct that it's far from being a standard in the JavaScript community. While I applaud the idea, I really don't see this catching on anytime soon. Many JavaScript developers argue that moving in this direction is going back to the old OOP model they didn't like in languages like C# and Java because of all the boilerplate code necessary to get up and running. Plus, IMHO, to do this properly you'd really want to use TypeScript anyway. Not many bloggers or tutorials use a JavaScript "clean architecture" approach. I asked one prominent advocate (who promotes clean architecture along with domain-driven design or DDD) 'Why not go with ASP or Spring Boot in the first place?'. The reason he said was that he'd already built his startup on Express and later ran into maintainability issues as the project grew, so he borrowed enterprise development concepts popular in other languages and refactored his existing code base to accommodate these patterns. Because of his earlier struggles, he was now attempting to spread the word in the JavaScript community about the need for better design. I like what he's doing, but again, I don't see these patterns becoming the norm amongst JavaScript developers. As for me, I originally returned to Node (Express) because I got frustrated with all the boilerplate I was writing in ASP Core to build a basic REST API (albeit with repositories and a layered architecture like the one shown here). Express is great a first. However, it didn't take long before I was fighting to get popular third-party npm packages to play nice together without all kinds of hacks and workarounds. Having worked in software development for around two decades, the conclusion I came to is the Microsoft ecosystem is more mature and standardised. Microsoft's packages work together without a lot of hacking and compromise. So, I think it's worth the extra boilerplate code in the long run to go with ASP Core. (However, I might still choose Node if time and money were a constraint and I expected the structure of the program to change a lot. i.e. Node is better for the uncertainties of a startup but less suited to enterprise applications.) I continue to use React for my front-end, but I've switched to TypeScript. I still wish there was more consensus on how to structure a React application and how and when to sync state with the back end, rather than being left to fumble around and see what works. Again, unopinionated frameworks create a wild-west situation where everyone can argue their way is the correct way. Hence the reason why, as you said, no one's code seems to make sense until it's explained. People love to criticise PHP, but I suspect there are as many anti-patterns floating around in JavaScript projects these days as anything written in PHP. And while there are better, more organised Node frameworks than Express, Express is by far the most common Node framework you'll run into in tutorials or in the workplace.