Show Buttons
Share On Facebook
Share On Twitter
Share On Google Plus
Share On Linkdin
Share On Reddit
Share On Stumbleupon
Contact us
Hide Buttons

Organizing your expressjs routes in separate files.

When you first start out build­ing nodejs/expressjs appli­ca­tions, there are a tonne of things to think about. One of the most cru­cial of them is — how to orga­nize your routes. A lot of begin­ner exam­ples start with defin­ing routes in the main file of your appli­ca­tion (app.js or server.js or index.js). Althought that helps you pick up the con­cepts quicky, you’re kinda on your own when you start build­ing your application.

In this post, I will talk about an appli­ca­tion orga­ni­za­tion struc­ture that I set­tled on. It took me some time to keep refin­ing and arrive at this stage, and it has served me well for quite some time now.

The struc­ture.

This is prob­a­bly one of the sim­plest ways in which you can orga­nize your express routes while still main­tain­ing a good level of clarity.

nodejs code organization

The app.js acts as the start­ing point of the appli­ca­tion. In this file, you instan­ti­ate
1. An instance of express — app
2. An instance of a con­fig­u­ra­tion object — appEnv. This may con­tain infor­ma­tion such as your data­base con­nec­tion, any other com­mon objects that needs to be shared by mul­ti­ple route handlers.

One of the key advan­tages of this orga­ni­za­tion is that it makes it super easy to unit test express routes since you can stub your con­fig­u­ra­tion objects for your test cases pretty easily.

We keep all of our routes han­dlers in the routes folder, orga­nized by the routes they han­dle. But there are also 2 other files -
1. index.js:- This is the default file which gets loaded when you require the routes folder, or any other folder what­so­ever. In this file, we export a func­tion which receives an app and appEnv objects as argu­ments. These argu­ments are then passed down to the indi­vid­ual route han­dler func­tions in the same man­ner which them­selves export a func­tion the same way that index does.
2. main.js: — Any arbi­trary routes that can’t be grouped together log­i­cally in their own files (like users, orders, etc).

There are other approaches that let you require all the files in the routes folder directly in one com­mand from the app.js itself instead of writ­ing mul­ti­ple require state­ments in the routes/index.js. If that works for you, its great, but I explic­itly chose to stick to the approach described above for one main rea­son — When devel­op­ing, if there’s some­thing wrong with a route, you can sim­ply turn it off by com­ment­ing out a sin­gle line in routes/index.js. Whereas if you require all the files in a folder, you lose this flex­i­bil­ity. The down­side of this approach is that when­ever you plan to expose a new route, you have to remem­ber to add it to your routes/index.js because adding it to the routes folder alone is not enough. I think I can live with that :).

The nodejs-starter-kit appli­ca­tion uses the same struc­ture as dis­cussed above. If you are start­ing out afresh, you might want to try it out.

Ryan Sukale

Ryan is a UX engineer living in San Francisco, California.

You may also like...