0

I'm building a nodejs app I would like to make available under various settings by my customers. I want my customers to build their websites on top of my app, so:
- the app can be configured in a way that domains "A.com" and "B.com" use the configuration "X" of the app, while "C.com" uses "Y", etc.
- I'm thinking about using kubernetes and dockers containers to isolate version "X", "Y" etc. of my app - I'm also thinking about using nginx for reverse-proxy

Each domain will have its distinct documents in a mongodb collection. Because I need a way to retrieve the right data, I'm giving each domain a unique token matching their documents. All the tokens are also saved in mongodb and will be retrieved on my (nodejs) server's start or updated on the fly. The tokens will be saved on a "app.locals" variable:
- I'm thinking about having a middleware that will grap the domain from every request (req.hostname) and get the corresponding token

// set locals
app.locals.domainTokens = {};

after retrieving and assigning the tokens, "domainTokens" will look like:

app.locals.domainToken = {
    "Acom" : "token_1",
    "Bcom" " "token_2"   // and so on
}

// the middleware
function grabToken(req, res, next) {
    var tokens = app.locals.domainToken,
        host = req.hostname;
    req.params.token = host ? tokens[host] : undefined;
    next();
}

When new customers register, tokens will be assigned on the fly for their domain (containers talk to each other, right?).

So basically, when a request is made for "A.com", my middleware sets the "token" so that the mongodb documents related to "A.com" can be found and sent back to client running version "X" of my app (nginx).

What do you think about this approach ? is it unsafe? a bad practice? do you have a better suggestion to implement it?
Am I better off using one container per domain ? (I would have to monitor hundreds of nodejs instances instead of 3 or 4)

Also, is it possible to dynamically configure a Nginx server?

  • 1
    Are you going with 1 db per customer or one shared db for all customers? – scriptin Nov 14 '15 at 20:00
  • one shared db for all customers. every doc has unique token property (related to the domain) – Fabrice K. Nov 14 '15 at 21:41
  • I think it's very easy to get the data of other clients by just forging the Host HTTP header, unless you check something else to identify clients. – scriptin Nov 14 '15 at 21:58
  • do you mean, like using an interceptor? could you give an example please? since each version of the app will serve multiple domains, I need a way to fetch data specific to them. That's why I was thinking of assigning a unique token to each domain – Fabrice K. Nov 14 '15 at 22:11
  • For example, do you also check if a user actually belongs to this domain, and thus can get a token? In other words, is it fine if someone could get a token for any domain by sending a fake request, thus pretending that they are using that domain? I'm not sure if your tokens are meant to be kept/used privately for/by each domain. – scriptin Nov 14 '15 at 22:30
0

I have a very similar issue with deploying our own API. I think this solution becomes unwieldy fairly quick as your code now has deployment specific information in it. It is tempting to have the code auto-configure itself like this but I think it makes it harder than it needs to be.

In my case I choose to separate out similar information into a configuration file. This has several benefits:

  1. It is more inline with most other software that people are used to installing and configuring.
  2. Someone can administer the installation without touching (or having access) to the code (and also in your case the database).
  3. It will be much easier to script deployments / setup new environments.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.