Is it a good idea to wrap node.js package functions in a micro-service architecture?

Our development team works with a micro-service node.js architecture. This means we work with a very large amount of repositories that currently each take care of their own dependencies. To avoid having to do the same set up in each of our services, we have created a private node.js package that handles some of this for us, which allows us to, for example, set up a RESTful service in a couple of lines, uniformly configured as we like. The main idea is to avoid having variations of the same bits of code in multiple services, mainly for stuff we generally use in a large portion of our repositories: Setting up RESTful server Handling messages from a queue Creating report files Fetching and handling large amounts of data ... But recently, we've come across the idea that we should also we adding support for node.js packages, for instance: the MongoDB driver for node.js. There are a couple of small bits that we do each time, in every service connecting to MongoDB. An example of that is that when we create a connection, we pass in certain options regarding the app name that's creating the connection and some timeout options. Currently this is the same in each of our repos, and whenever we have a connection that does not have an app name, that interferes with trying to figure out support issues. The idea would be to wrap establishing that connection in our private package, and maybe even have that integrated in the set up of the RESTful server. Another reason for doing that would be to protect the code in our microservices from breaking changes in the node.js packages. With each major version of the MongoDB driver, we run a risk of having to deal with breaking changes. For instance, in version 5.x, they removed support for the insert() function, with the advice to use either the insertMany() or insertOne() function. This currently poses a big problem for a micro-service approach, since updating to a new major version might require additional changes in each of these repos. The idea would then be to have an insert() function for MongoDB in the private package, and handle any breaking changes there instead of in each separate repo. Not everyone in the team feels this is a good approach, though. One of the breaking changes in the MongoDB driver was dropping support for callbacks, and adding support back in for that might not be ideal. Is anyone familiar with this kind of approach, wrapping functions of something like drivers to prevent variations in code and try to keep updates backwards compatible? Our there more downsides that upsides for this?

Feb 21, 2025 - 12:26

Our development team works with a micro-service node.js architecture. This means we work with a very large amount of repositories that currently each take care of their own dependencies.

To avoid having to do the same set up in each of our services, we have created a private node.js package that handles some of this for us, which allows us to, for example, set up a RESTful service in a couple of lines, uniformly configured as we like.

The main idea is to avoid having variations of the same bits of code in multiple services, mainly for stuff we generally use in a large portion of our repositories:

Setting up RESTful server
Handling messages from a queue
Creating report files
Fetching and handling large amounts of data
...

But recently, we've come across the idea that we should also we adding support for node.js packages, for instance: the MongoDB driver for node.js.

There are a couple of small bits that we do each time, in every service connecting to MongoDB. An example of that is that when we create a connection, we pass in certain options regarding the app name that's creating the connection and some timeout options. Currently this is the same in each of our repos, and whenever we have a connection that does not have an app name, that interferes with trying to figure out support issues. The idea would be to wrap establishing that connection in our private package, and maybe even have that integrated in the set up of the RESTful server.

Another reason for doing that would be to protect the code in our microservices from breaking changes in the node.js packages. With each major version of the MongoDB driver, we run a risk of having to deal with breaking changes. For instance, in version 5.x, they removed support for the insert() function, with the advice to use either the insertMany() or insertOne() function. This currently poses a big problem for a micro-service approach, since updating to a new major version might require additional changes in each of these repos. The idea would then be to have an insert() function for MongoDB in the private package, and handle any breaking changes there instead of in each separate repo.

Not everyone in the team feels this is a good approach, though. One of the breaking changes in the MongoDB driver was dropping support for callbacks, and adding support back in for that might not be ideal.

Is anyone familiar with this kind of approach, wrapping functions of something like drivers to prevent variations in code and try to keep updates backwards compatible? Our there more downsides that upsides for this?