paint-brush
Abstracting mongoose CRUD operations into a shared fileby@luukgruijs
1,873 reads
1,873 reads

Abstracting mongoose CRUD operations into a shared file

by Luuk GruijsOctober 14th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

When building an <a href="https://hackernoon.com/tagged/api" target="_blank">API</a> with <a href="https://hackernoon.com/tagged/node" target="_blank">Node</a>, Express and MongoDB you can choose Mongoose as your ODM. Mongoose helps you to easily do CRUD operations. When your API grows, usually the amount of models grow and therefore also the amount of express routes grow. In a lot of cases those routes just do simple create, read, update or delete operations. If those routes do not contain any other logic it would be nice if we can just forward the request to a reusable shared function which takes care of the request, right?

Company Mentioned

Mention Thumbnail
featured image - Abstracting mongoose CRUD operations into a shared file
Luuk Gruijs HackerNoon profile picture

When building an API with Node, Express and MongoDB you can choose Mongoose as your ODM. Mongoose helps you to easily do CRUD operations. When your API grows, usually the amount of models grow and therefore also the amount of express routes grow. In a lot of cases those routes just do simple create, read, update or delete operations. If those routes do not contain any other logic it would be nice if we can just forward the request to a reusable shared function which takes care of the request, right?

by Matteo Catanese on unsplash

well, yes! Abstracting easy logic can help speed up the development process, increase maintainability and also reduce potential errors or bugs. Let’s assume we’re making an application which let you and your colleagues manage their lunch orders. To get one order, the GET route could look like this if we would write out all the logic:

This on it self is fine. But apart from model.Order this route would be the same if we would create a GET route for getting a specific item that you can order for lunch and also if we would create a GET route to retrieve a specific user. Writing out this code every time for each route would work, but is not really maintainable. One way to solve this, is to move this logic to a higher level in the application, abstract it a bit and then make it importable for every GET route that requires the above logic. The abstracted logic can potentially look like this:

Now that we have abstracted the logic we can use this in our GET route like this:

we pass along the request, response, next and model.Order and the get function takes care of the rest. By exposing this function we will speed up development for the next route that needs a simple GET and we increased our maintainability as the logic is only in one place.

Now of course there are more common operations. Let’s look into POST for creating a new resource. The route for a POST operation can look like this:

Let’s abstract it again:

and use it like this:

We can then do the same with UPDATE as well. Since i think you’re getting the point now. Here’s the full rest.js file for CREATE, UPDATE, GET and DELETE :

Conclusion

We created a rest.js file with reusable helper functions that can take care of common logic. You can extend/change this file to your liking and incorporate things like populates or query paramaters. Happy coding!

Thanks for reading. Please hit the clap button if you liked this article. Any feedback? Let me know. Also check my other articles:

Follow me on Medium or twitter and let’s connect on LinkedIn