Customer Convos: Marcus Noble, Elsevier

This piece is a part of our Customer Convos series. We’re sharing stories of how people use npm at work. Want to share your thoughts? Drop us a line.

Q: Hi! Can you state your name, what you do, and what your company does?

A: Hi there! I’m Marcus from Elsevier. I work in a team building their global ecommerce platform.

How’s your day going?

Not too bad. Had a kickoff meeting for an exciting upcoming project.

Tell me the story of npm at your company. What specific problem did you have that private packages and orgs solved?

Our backend is made up of mostly microservices. Various APIs to handle things like orders and customers have a corresponding custom client as an npm module that we publish to a private npm Org. This helps us handle changes to API gracefully through versioning of the endpoints and clients as well as distributing TypeScript type definitions for the requests and responses of all our APIs.

Can you tell us a story about a specific package you wanted to make that private packages really enabled you to do?

As a platform, we handle multiple online shops within the company. Some are built by us, others are built by other teams. We have a single API that takes in all orders, stores them in a database and passes off to various fulfillment systems. We created an npm module to expose the types for a submitted order along with a generated .JSON schema that our API uses to validate orders sent to it. This module gets an upgrade as our endpoint is versioned to handle new data. These types are now only available as TypeScript definitions but we are currently working on generating types for PHP also.

Does your company do open source? How do you negotiate what you keep private and public (feel free to be as vague as you need to be)?

Not as much as we’d like. A lot of what we work on is specific to our organisation. Anything that’s generic we try to open source, like the above-mentioned json-schema-php-generator.

To people who are unsure what they could use private packages for - how would you explain the use case?

I think anything that is shared across multiple applications (be that logic, type definitions or something else) is a great candidate for private packages. As I said above, we use them heavily for sharing type definitions, but we also have a few modules that simply contain organisation-wide logic (such as country/region data) as a .JSON file with some helper methods.

How’s it going? How’s the day to day experience of using private packages/orgs? 

Mostly it’s working well. We use npm extensively already so incorporating our own modules has seen very little friction. With tools like np we can make sure our packages are published in a consistent way with passing tests.

How would you see the product improved or expanded in the future? 

We have run into one issue. With our versioned endpoint we still need to support older versions until we can ensure all clients have moved to the latest. We have an npm module containing our .JSON schema to validate against but we were unable to import multiple versions of a single module. Ideally, we’d like to be able to have version 1, 2, and 3 as dependencies and import them separately into our validator. We managed to work around this by moving the old version to a sub-directory and publishing that as its own package with the version appended to the end of the name.

Would you recommend that another org or company use private packages or orgs and why?

If you have a use case that requires some form of shared code or assets between applications it’s definitely worth giving private npm modules a try. They fit nicely into existing workflows and are easy enough to remove or replace if they don’t fit.