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

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.

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.

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

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.

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

need some conversation with experience developer like you

@@DevMastery I become a fan of your work

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.