Multi-database private REST API in Node.js - node.js

Question

I'm looking to set up a REST API for a number of my apps to consume & publish data to/from Mongodb Atlas. I have a number of organisations as customers, and have a number of different contracts (to build information models) with each customer, each of which must be kept in separate databases (for various reasons I shalln't go into here). Its basically an information model management system (lets call it IMMS) where every model has the same schema.
In Atlas I'm modelling this as:
Organisations - one to represent the system (IMMS).
Projects - one per Customer Organisation.
Clusters - generally just one per project, but could be more in some exceptions.
Databases - one per contract (model).
Collections - 5 per db, common across the whole IMMS.
The client app which my customers use allows them to select a file to open, representing a specific database, which contains the (private) connection details for connecting to the relevant cluster & db. The app will bake the relevant cluster & db values into the API requests when it posts or gets data (post & get are all we use, there's no updating or deleting required).
I intend to host this API on a publicly accessible API, but have it set up to only respond to my authorised user(s) using my client app(s).
My initial stab at prototyping such a service on Node can be seen below (note: I'm a total node newbie):
//app.js
const Express = require("express");
const BodyParser = require("body-parser");
const Mongo = require("mongodb");
const port = process.env.PORT || 5000;
const URL_TEMPLATE = "mongodb+srv://writer:writer#<db-cluster>.mongodb.net/test?retryWrites=true&w=majority";
var app = Express();
app.use(BodyParser.json());
app.use(BodyParser.urlencoded({ extended: true }));
app.post("/:cluster/:db/party", (request, response) => {
var client = Mongo.MongoClient;
client.connect(URL_TEMPLATE.replace("<db-cluster>", request.params.cluster), { useNewUrlParser: true, useUnifiedTopology: true }, (error, client) => {
if(error) { throw error; }
client.db(request.params.db).collection("parties").insertOne(request.body, (error, result) => {
if(error) { return response.status(500).send(error); }
response.send(result.result);
});
});
});
app.get("/:cluster/:db/party", (request, response) => {
var client = Mongo.MongoClient;
client.connect(URL_TEMPLATE.replace("<db-cluster>", request.params.cluster), { useNewUrlParser: true, useUnifiedTopology: true }, (error, client) => {
if(error) { throw error; }
client.db(request.params.db).collection("parties").find({}).toArray((error, result) => {
if(error) { return response.status(500).send(error); }
response.send(result);
});
});
});
app.get("/:cluster/:db/party/:id", (request, response) => {
var client = Mongo.MongoClient;
client.connect(URL_TEMPLATE.replace("<db-cluster>", request.params.cluster), { useNewUrlParser: true, useUnifiedTopology: true }, (error, client) => {
if(error) { throw error; }
client.db(request.params.db).collection("parties").findOne({ "_id": new Mongo.ObjectId(request.params.id) }, (error, result) => {
if(error) { return response.status(500).send(error); }
response.send(result);
});
});
});
app.listen(port, () => {
console.log(`Server running at http://localhost:${port}`);
});
I have a few concerns which I'd be grateful for advice / feedback on:
Most examples I've seen open a single mongo connection in the app.listen function & appear to hold it open indefinitely. My approach needs to switch between clusters & databases on each request (and indeed does, above). Is this a good or bad idea, from a performance & reliability perspective?
I've put the :cluster & :db identifiers in each API route, but it will be common to all requests. Should this be baked into the header instead, and/or is there a neater way of doing this?
With the code above, I can see I'm getting quite a lot of repeated code on each route. Any ideas for quick / easy refactorings I could do to incorporate a function along the lines of GetCollection(request)?
I'm toying with having my GET routes allow a mongo query object to be passed (instead of the plain old :id selector route), which would permit a lot of flexibility to my end-client app(s). Again, does that sound like a good / bad idea? I see mongo query anywhere does something similar & handles user roles/permissions (though my apps deal with user permissions etc so I'm not sure I'd benefit from stitch & query anywhere)?
Any help / advice on any of the above would be much appreciated. Thanks. :)

Answer 1

I've now come to a solution on this after investigating / researching / prototyping further myself, so am publishing it here for any others with similar queries...
Mongoose's createConnection() method was what I was after. I ended up using the default connection mongoose.connect() for my main system database (managing users, organisations, invoices etc), and then created a database service class to provide connections to multiple other databases on a request by request basis. Something along th lines of the following:
"use strict";
const mongoose = require('mongoose');
const options = { useNewUrlParser: true, useUnifiedTopology: true, useCreateIndex: true, bufferCommands: false };
module.exports = async function ( connectString ) {
let conn;
let models;
try
{
if( !conn )
{
conn = await mongoose.createConnection( connectString, options );
conn.model( 'Current', require('./model') );
conn.model( 'History', require('./history') );
console.log( 'Connected: ' + connectString );
}
if( !models )
{
models = {
Current: conn.model( 'Current' ),
History: conn.model( 'History' )
};
console.log( 'Models compiled: Current, History' );
}
return models;
}
catch ( err )
{
throw err;
}
};
That would allow the server API to manage the model connections, however I'm considering delegating the model db connections to the front-end clients, allowing them to connect directly by connection string.
Anyhow, I hope the above is useful.