Dexter's nodeJS application structure
Structure
app- main app (details below)docs- documentationlib- the complied app code goes which is used for production envmigrations- all the table schema. (e.g, use knex.js or any ORM written on top of itnode_modulestests- all unit testsconfigandconfig.sample.js- configuration related to database, authentication, external api keys etc are storedeslintrc- the lint logicmigrateis the file that pass the configuration from config.js to ORM and help to run migration from CLIgitignore- path to folder or filename that don’t want to push on repositorypackage.json
The app Structure
server.js- the file that start the server and will have all middleware that is required for request parsing likebodyparser,cors,multeranderrorhandlersetc and finally add routes middlewareroutes- have sub-files or sub-folders made as per the entities in project. Note: We can abstract a big entity like teams in a folder and can call it as teams which can then have sub sub-folder like members, contacts, dashboard etc. under routes. A file under routes is where all request handler or sub-routes are written and the only purpose of them is to either call the action that is responsible for that route or the sub-route folderactions- most of the times actions folder will have same the same structuring as the routes folder. Each file in actions is for business logic i.e all code that store, get, change real entities either in database tables or doing queuing function like enqueue and dequeue etc all happen here. Note: Actions can call other actions toomiddlewares, utils, helpers, tasks- follow the same way of structuring as action or routes do i.e main entity will act as a root folder and then will can have sub-folder as per sub-entities and repeattasks.js- used for running tasks from CLI created under task folder like database seed, clean database etc- nsqd - use case specific for distributed messaging. Note: NSQ - https://nsq.io/ is one the best for distributed messaging it works great with no pain in production