Designing a clean REST API with Node.js (Express + Mongo)

We walk through the code of a REST API written in Node.js with Mongo and Express.js and talk about some design decisions and the application of several Architecture Principles including Separation of Concerns, designing for change, and more...
source code: github.com/arcdev1/mm_express...

[@DevMastery]

Here's a link to the article I mentioned in the video. Elegant patterns in modern JavaScript: Ice Factory medium.freecodecamp.org/elegant-patterns-in-modern-javascript-ice-factory-4161859a0eee

[@logicjs]

You are the only one I found on KZbin who talks about architecture of an application! Million of bows!!!

[@gideonidowu8271]

Good architecture is really about reducing the cost of future change. Love that.

[@jacobyoungblood1787]

This video was an excellent resource. Just getting into Node and was trying to wrap my mind around how to keep entity models, routing, and custom logic layers distinct in such an open ended platform. This ticked all those boxes and also highlighted how to stay framework agnostic. Definitely subscribed.

[@SMasta]

thank you so much for making these videos, you're one of the best and most informative teachers i've found on programming and web development!

[@PlamenAndreevX]

Hey, I just watched the replay from Barcelona. Amazing video, Bill! I really like how calm and clear your explanations are. The topic for the architecture is right on the spot (at least for me). This is something that troubles me for long time and I still struggle to wrap my head around. I've been trying to implement the "Clean Architecture" by Uncle Bob but I have trouble designing the layers and connect them. Your video is very helpful and I feel I understand more :). One important conclusion from watching your video is that, SRP (Single Responsibility Principle) is crucial to make things neat and organized. I see that you give objects different responsibility that is well encapsulated, provides an interface and all you need to use it is inject an object to generate some concrete output :). Beautiful! I'm looking forward to seeing more content! Great work! Honestly!

[@MultiMarty1987]

Hi Bill, I really like this and the other video you made on clean architecture. I've been coding for about 4/5 years now, mostly front end and this way of architecting an application is sorely missed in my learning so far! Hungry to learn more now with as many practical examples as I can find! :)

[@dantesta4123]

I just want to say thanks for doing this show. This particular episode kick started me down the clean coding path using Node.js. I was looking for a good example to get me started and this was exactly it. Kudos!

[@neilr7935]

Your application architecture videos are the best I've ever seen. Most are either too abstract to be useful or too in the weeds with unimportant details. Here everything is presented perfectly. Thank you for sharing your wealth of knowledge/insight on the subject.

[@MauricioRobayo]

This is gold! Thank you and please keep uploading.

[@adrian.barylski]

The Ice Factory pattern seems very interesting! I think I'll start to implement it in a project I'm currently working on! :) Good job on the videos btw! Waiting for more :)

[@DUNIACARA]

This is the tutorial I was looking for. Thank you very much.

[@thecodeclass4433]

@Dev Mastery, many thanks for the video. There is some real, practical learning here. Can you show (or make a video) us how to deal with nested documents. let's take an example of Society/Property management db where there are many entities e.g. A residential complex -> wings -> floors -> rooms -> tenants -> more -> more . You can see there is a lot of nesting and the stuff can be real complex (at least to some of us). It would be great if you can also show us how to club together data from different documents which aren't related, as there may be similar use cases. Apologies if it's too much to ask.

[@DongoBongKong]

very good and instructive video

[@firojsiddiki2207]

it's really very informative

[@haimif]

Thank you so much!

[@jacsurfing]

wow, subscribed. i need more your video. please film more

[@sparkman786]

Excellent series! Really like the topics! I noticed in contact-list.js, you reference db.collection. Is "collection" a mongo client library function? What happens if I switch the DB object to Postgress? Will this still work or is the expectation that refactoring contact-list is ok in this when switching DB engines?

[@chrisli337]

more video please thank you

[@EddyCaffrey]

Great video. the architecture of the application is very interresting and very strong. But actually i'm thinking about the scalability of the code. how can I make the API evolve (create a version 2 while keeping the version 1) without duplication of code while maintaining the same design ?

[@dantesta4123]

I like the use of the pattern "function makeContact(contactInfo = requiredParam('contactInfo') {...}". However, it does not catch the case when contactInfo is null. Are you intentionally ignoring nulls (ie, consider it a programmer error) instead of checking for it and throwing an error?

[@DevMastery]

That's a good point. requiredParam only handles the case where contactInfo is undefined, if it's explicitly set to null or any other invalid type, then the destructuring in the validate function will catch it instead and throw a system error. In a real app I'd look at the error and decide if it's clear enough on its own or if it's worth adding more checks and throwing an explicit error. In the case of this code, I threw it together too fast and didn't really think of it. Good catch.

[@thomasmcguire3294]

I'm interested in your build process as well.

[@oboiteosahon8156]

Thanks for these videos. I have a request: If it's not too much to ask, do you mind leaving comments on your code so beginners like me could follow along even without the video? Again, thank you very much.

[@ravinder19rikhi]

Hi ! I have studied OOPs during my college days but I started working on Javascript instead. Now I am heading to Typescript . Can you please adjust a lecture in which you can explain on how to conceptualise the major OOPs concepts like inheritance, interfaces, abstractions, etc in a real world project implementation. Basically I want to know how to think while working on Class based concepts.

[@DevMastery]

When working with javaScript and even Typescript you need to mostly forget everything you know about Class-based OOP. JavaScript is not a Class-based OOP language, it is prototype-based.The fact that we can now use the "class" keyword and use pre-processors like TypeScript which give us more keywords like "Interface" does not fundamentally alter how JavaScript actually works. You're best bet for understanding this is Kyle Simpson's book series: "You Don't Know JavaScript". In particular Book 3 called "this & Object prototypes" does an excellent job of explaining it. You can get this book online for free from the author himself at: github.com/getify/You-Dont-Know-JS/blob/master/this%20&%20object%20prototypes/README.md#you-dont-know-js-this--object-prototypes if you end up finding it useful and have the means to do so, I also recommend you buy it to support the author's work.

[@dantesta4123]

ject into makeContactList() to switch from mongo to something else? I see references to mongo inside makeContactList() as well.

[@DevMastery]

Thanks for watching. There's no direct reference to mongodb in makeContactList, it's injected. However, the contactList is indeed tightly coupled to mongodb in that it expects a "database" object which conforms to the mongodb spec. That's why the rules about a contact live in the contact.js module and the code that produces the httpResponse lives in the endpoint module. So, if we change to a CRM and inject an SDK that can talk to the CRM, we do have to change the code inside contactList, BUT the endpoint code and the makeContact code remain blissfully unaware that we swapped out the underlying datastore. So, this change is less risky because we don't have to go anywhere near with the business logic or http request/response logic. Hope that answers your question.

[@luizmeier]

@@DevMastery I'm planning to create another option: a memory driver instead of Mongo.

[@ganeshmain009]

Instead of writing validation in old school javascript.. is it good to use packages like "joi" for request validation?

[@DevMastery]

Packages like "joi" which work by allowing you to define a scheme in the package's own domain-specific-language and then use a "validate" function that relies on that scheme make the implementation of your business logic completely dependent on a thrid-party which, in my experience, is extremely dangerous. The business logic is the most precious part of your application and needs to be as unencumbered as possible from third-party dependencies. Having said that, using third-party code for low level assertion can be okay as long as it's abstracted, for example, injecting a function like "isNil" from lodash and using it is probably fine and with injection you're free to swap out the implementation of isNil should lodash break or go away or no longer meet your business definition of "Nil". I'm also weary of bringing in an entire library when you only need a few functions from it, sometimes, if the functions are small and simple enough and the library's license permits it, i just make my own copy and save the overhead.

[@ganeshmain009]

@@DevMastery Awesome. super useful informations. can i able to contact you?..

[@ganeshmain009]

need some conversation with experience developer like you

[@ganeshmain009]

@@DevMastery I become a fan of your work

[@sufiyaanrajput7533]

What do we call such an architecture if anyone wanna know more about it?