Best practice to pass db and logger to routes

[paultman]

to pass single instance references like a logger and/or db to routes, I see three options currently.

First is to attach it to the request object via a middleware:

app.use(function(req,res,next){
req.db = db; //this db comes from app.js context where you define it
next();
});

or in app as:
app.set('db', db) // db was previously set

then to use:
req.app.get('db').[collection].[whatever op](

---

Next way is to call some init method on the controller, ie:
const users = require('user.js);
//setup logger, setup db, then call:
users.init(logger,db); // init method sets local logger and database inside user.js

---

Last is a variation on the above which forces init to happen once when the module is required:
// setup db and logger, then later call:
require('user.js')(db, logger) //not great style-wise by not having all requires near the top of doc

and in your user.js, set your export like so:
module.exports = (db, logger) => { // returning public functions

This is what I really hate about vanilla JS, and even a framework like Express. It's part of the reason why frameworks like react are so popular because there are set ways to do things.

Ok, back to the topic. What's the best practice for passing single instance things like a logger and database to all your routes/controllers?

Unfortunately If you search for "express best practices for routers", you'll get dozens of variations. Is there some goto reference/bible?

Thanks for any advise/feedback,
Paul

[dougwilson]

To really be able to answer your question, it would be import to state what the expected lifecycle of those objects are. Different lifecycles would have different constraints to where you can place them for access in your routes.

As for best practices, I think the Node.js ecosystem still has not determined what these are, and as a web framework, this is where express itself is "unopionated" on: how you want to perform IoC/DI in your application.

[paultman]

Wow, I feel privileged to get a message from such a prominent Express contributor.

Ok, I've gotten back into using express after a long break and things seem pretty similar to how they were years ago when i stopped. Even with a somewhat deep experience, I don't quite understand what you mean by, " it would be import to state what the expected lifecycle of those objects are." The lifecycle should be as long as the app is running.

Ok, let me set the context. First, i'm talking about single instance objects, like a logger and database. Once they are setup, I'd like to pass them into my routes/controllers. I have a few options as I mentioned above

1. I could use a custom middleware to add them to each req object,

2. I could pass them as function params when I do a require on my controller

3. I could call some init function on my controller which would take the previously instantiated logger & database, and set a local logger/db property.

My thoughts on each:

1. I'm not crazy about calling app.use to set the logger/db on every request, nor even as a middleware and making the call on all my controller routes to add the logger/db to the request for each applicable route.

2. For the require with params, I would have to wait till the db and logger are ready, and hence could have the require further down in my code, not with all the other requires at the top.

3. Do the require like normal, setup logger/db, and after, call my [controller].init(logger, db)

For now, I guess I'd use the third, OR if I could find some best practice for what should be a common design pattern, that would be best.

Yes, I know what you mean about being "un-opinionated", however I think common design patterns or best practice (beyond the basics of just learning the framework) could be very helpful, and not hard for an experienced person/group to put together. Or maybe it exists and I've just been distracted by too many basic how-to's, to find it.

Again, thank you very much for your attention,

Paul

[dougwilson]

Hi Paul,

Maybe there is some confusion on what is part of a web framework and what is just general code organization and application design. What I mean by unopiniomated is everything that is not related to Express. Express does not require you divide anything up in to different files; that is orthogonal to what Express itself is. That is all I meant. Any design here would be unrelated to Express; it would apply just the same to any other Node.js based web application. And yes, perhaps someone has wtittwn up a good pattern, though I am unfortunately not aware to provide any references.

As for lifecycle, sorry I wasn't very clear, that is my bad. Here is a wiki entry about what I am referring to: https://en.m.wikipedia.org/wiki/Object_lifetime

It sounds though like the objects have the same lifecycle as the process, so you are right, setting them in a middleware is going to be overkill. You could put them on the app instance as properties or in to the Express settings that that would probably be good enough for your use case if you don't want to pull in some kind of full IoC lib or deal with constructor DI requirements.

[paultman]

Hello Doug,

Again, thank you very much for your taking time to answer me personally. How you find time with all your code contributions is beyond me, and I certainly appreciate it.

Yes, I see that viewpoint and you are completely right. Fortunately, being un-opinionated has its pros & cons, and I'm brushing up against a con right now.

But, developing with that clear viewpoint does put things in a more manageable perspective. As an older dev I've come to appreciate best practices and good design pattern, and just coming back to Express development, that's what I was looking for. And yes, I will not find that from the framework itself, rather I am looking some best practice guides. To be honest, regarding my previously asked question above, I had already looked though the top express projects here on github and couldn't find any common implementations, nor any that I liked.

Most likely, I'll come up with putting together a few things and come up with my own best practices or design patterns. Better, I'll share them here (on github) and get feedback so they can be improved and might serve as step stool for others.

Anyway, thanks for not only keeping express development going, but being involved in the community at well.

Cheers,
Paul

[romulovalez]

I'll add some opinionated design patterns to the topic for anyone who might need it.

Since getting the db client is normally a single line of code, and in our codebase we tend to use a db client on authenticated endpoints, we prefer to create a middleware that not only obtains the db client but also manages user authentication:

const { Pool } = require('pg')
const pool = new Pool()

// Create an authentication middleware
const auth = async (req, res, next) => {
  // Get the db client from pool
  const client = await pool.connect()

  let user
  if (req.body.email && req.body.password) {
    // Manage authentication with email - password
    const result = await client.query(
      'select id from users where email = $1 and password = crypt($2, password)',
      [req.body.email, req.body.password],
    )
    user = result.rows[0]
  } else if (req.cookies) {
    // Manage authentication with cookies
    // ...
  }

  if (!user)
    throw new Error('User is not authenticated')

  // Save db client and user on request object,
  // but it could be more apropiately to save it on res.locals:
  // http://expressjs.com/en/api.html#res.locals
  req.db = client
  req.user = user
  next()
})

// Get user profile, using auth middleware
app.get('/profile', auth, async (req, res) => {
  // We are using the db client stored in req.db
  // and the user stored in req.user from auth middleware
  const result = await req.db.query(
    'select firstname, lastname from profiles where id = $1',
    [req.user.id],
  )
  // We will not be doing more queries, so we can release the client back to the pool
  req.db.release()
  res.send(result.rows[0])
})

// Don't forget to handle the client release in case of errors
app.use((err, req, res, next) => {
  // Release client to avoid a leak
  if (req.db && !req.db._events.error) {
    req.db.release()
  }

  // Copied from express documentation
  if (res.headersSent)
    return next(err)

  res.status(500)
  res.render('error', { error: err })
}

In case I need to make a request to the database without authentication I can get the db client directly on the endpoint, there is no need to create a middleware, since I just need one line of code to get the db client:

const { Pool } = require('pg')
const pool = new Pool()

// Get users count
app.get('/users/count', async (req, res) => {
  // Get the db client from pool
  const client = await pool.connect() 
  const result = await client.query('select count(*) from profiles')

  // We will not be doing more queries, so we can release the client back to the pool
  client.release()
  res.send(result.rows[0])
})

// Don't forget to handle the client release in case of errors
app.use((err, req, res, next) => {
  // Release client to avoid a leak
  if (req.db && !req.db._events.error) {
    req.db.release()
  }

  // Copied from express documentation
  if (res.headersSent)
    return next(err)

  res.status(500)
  res.render('error', { error: err })
}