Last week we looked at mimicking the functionality of a REST endpoint with its own module (e.g. retrieving a User, or a list of Users, refreshing a token, etc).
For complex integrations that rely on a large set of resources from an external system, you might start to pile up a bunch of these modules, which will start to clutter your module dependency list.
Follow along with the code here.
Take, for example, a Map/Reduce script that needs to touch a whole bunch of the SMA endpoints to consolidate data in NetSuite:
The more endpoints a single module needs to leverage, the longer this list gets. To shorten the list and organize our dependency imports a little, we can use what I’ve been calling an “alias module”. The idea is to use the alias module as a wrapper for the long list of closely related dependencies.
Since we know our Map/Reduce needs a ton of the API modules, let’s make an API alias module specifically for use by the Map/Reduce (filename:
As you can see, there is no logic here, only a wrapper that imports a long list of modules just to re-export them. What do we gain by doing this?
Essentially, we have given our Map/Reduce the ability to import all of these dependencies as a single Object, effectively “grouping” the dependencies together:
The dependency list gets vastly shorter, and the code even gets a little cleaner as it becomes very clear where our “User” data is coming from.
By the way, there’s nothing here that’s unique to integrations. You can use this same pattern to group any modules you wish, regardless of functionality.