folder structure

Folder structure

This is how I personally envisioned structuring my folders when I created this skeleton. It might not be your preference, and it is just that.

So take this article as a suggestion, rather than a how-to.

root/
├─ bin/            - Place to put command-line access points.
├─ src/
│  ├─ actions/     - Route end-points.
│  ├─ models/      - Place to put TComb models.
│  ├─ routes/      - Routes for loading into app.js.
│  ├─ processes/   - Place to put complex, long-running processes.
│  ├─ services/    - Place to put services.
│  ├─ types/       - Place to put TComb type-enhancements used by models.
│  ├─ util/        - Place to put utilities.
│  ├─ app.js       - Server entry-point.
│  └─ index.js     - Main entry point.
└─ test/
   ├─ integration/ - Integration tests
   ├─ unit/        - Unit tests
   └─ index.js     - Test runner

Action structure

I like to map the folder structure of my actions as closely as possible to the URLs that lead to calling them. For example: GET /users/1/friends/1 would be dispatched to the action living in actions/users/friends/read.js. The name "read" is based on the fact that this is a GET request (CRUD). Naming conventions I use for other types of requests are listed below.

Action naming

method	url	name	description
POST	/collection	create	insert a new item into the collection
GET	/collection	index	read the entire collection
GET	/collection/item	read	read an item within the collection
PUT	/collection	replace	replace an entire collection
PUT	/collection/item	update	replace an item within the collection
PATCH	/collection	upsert	insert or update many items in the collection
PATCH	/collection/item	patch	modify an item within the collection
DELETE	/collection	truncate	remove all items from a collection
DELETE	/collection/item	delete	remove one item from the collection