Code organization – both the code in a file, as well as the way the files are organized – is an important aspect of maintenance. It’s no surprise, then, that larger frameworks have very strong opinions on the subject. Unfortunately, though, many smaller frameworks and libraries lack this organizational guidance. This doesn’t mean we should ignore code and file organization – it just means we have to do it ourselves.
When it comes to organizing the code of Express apps, I’ve written and recorded extensive materials around this idea… but until recently, I never had a good way to organize application initialization.
When you run the Express generator command-line tool, it gives you a good starting point for an app. There will always be things you want to change, but it sure beats having to create the core structure on your own.
One of the problems, though, is figuring out where to initialize external services and connection. You’ve got a database? You want to connect to a message queue? Oh, that mail server configuration? Yeah, sure… you just… umm… well…
The app.js file tends to become the garbage collector of initialization code for Express apps. This file shouldn’t be used as the garbage collector of all things initialization. It is meant to setup Express, not the rest of your app.
But even if you take the initialization code out of the app.js file and put it in the bin/www file (which is a better place – more suited to initializing all the parts of the app), you end up with a giant mess of configuring libraries:
Anything and everything is thrown into this file, and it becomes a nightmare that no one wants to touch. Each additional service requires yet one more layer of waiting for another service to start. Sure, this can be cleaned up with promises and other techniques, but I want to get rid of the ugly list of require statements and simplify the entire initialization process.
Enter ‘nanit’ – Node Application Initializers.
Cleaning Up w/ nanit
Nanit is a small library that moves application initialization into a series of small files in specific folder. It allows you to write initialization code focused one thing per file, and provides a single API call to run all of the initializers!
For example, a project might need MongoDB and AWS before the web service starts. To handle this, create an “initializers” folder in the project and add these two files:
When you need to add more initializers – RabbitMQ and other things – you don’t need to update either of these files. Add a new file for each thing that needs to be initialized:
Once all of the initializers are in place, run nanit from the bin/www file:
Now, when the callback for initialize is fired, all of the initializers will be run. Once they have completed, the callback to nanit will be fired. If there’s no error, then the main web server can start!
Clean Code Starts With File Organization
Cleanliness in code improves readability, understanding and maintenance. But cleanliness in code also starts with good file organization. If you can’t figure out what files you need to look at, it’s hard to find the code you need. If you can’t find the code you need, it’s hard to modify the right thing or keep the code clean when adding and changing.
Application initialization is no different than any other code in this respect. Keep your initializer code clean and organized. Ensure it is all tucked away nice and neat in a folder where it belongs, and use a single API call to execute them when you need them.
Check Out nanit On Github
If you’d like to know more about the API for nanit and how it works, check out the code on the Github repository for nant!
I’ve been using nanit in my production applications for a while now, and it has helped me immensely, in keeping my application initialization nice and clean.