0

We currently deploy the same node.js express API for 3 different customers. They each have their own config .env file, using a different port, different database, and different log file. They also each have their own reverse proxy through Apache.

Everything else, all the back-end source code and node_modules are the same. This means that whenever we need to update the back-end, we have to redeploy (i.e. rsync) each instance. It works but it's not super efficient, especially as we add more and more customers.

Is there a way we could maybe deploy the source code in a single template API and have each instance point to it except for the .env file? We could symlink everything to this template (except for the .env file) but there's a lot of files and this doesn't seem much better.. Wondering if someone already figured a better solution to do something like this.

Thanks.

greenkarmic
  • 429
  • 4
  • 17

1 Answers1

0

There are some scalability advantages of instancing your API in the way you're currently doing it - ensuring that each client has a slice of compute, disc and memory will alleviate single point of failure, bottlenecks and resource draining. This usually has some additional cost involved though (but not always).

Your deployment instruction could become more streamlined and automated to remove some of the frustration involved in synching all instances up.

Breaking up your API into Services

You could look at breaking your API up into isolated and encapsulated services that are utilised across many leaner instances - this would mean single deployment nano or micro services that get used (typically) by glacial client-locked instances.)

Clients as Data

One solution, depending on your data-protection and integrity needs, is to move client/customer data from file to database and have all customers interface with the same hard-API, loading their data through an authentication layer (and storing any client/customer configuration in the database). Then you could deploy once for everyone.