Node.js RESTful project structure

Goals (in descending order of importance)

• Deploy as little as possible
• Have "watch" functionality for dev env
• When there is an error in the build, it should fail as soon as possible
• Set up new dev machine as easy as possible
• When there is no error in the build, it should not do redundant/duplicate actions
• Have "watch" functionality for tests

Option 1: passwordkeeper-way

Goals

• Deploy as little as possible
• Have "watch" functionality for dev env
• When there is an error in the build, it should fail as soon as possible
• (not ideal) Set up new dev machine as easy as possible
• When there is no error in the build, it should not do redundant/duplicate actions
• (possible but not implemented yet) Have "watch" functionality for tests

How

Separated Docker images for front-end, back-end, e2e.

---

In order to run lint checks, we need:

• build front-end
• build back-end

What should we actually need:

• just eslint

---

In order to run Karma unit tests, we need:

• build front-end
• build e2e
• pull selenium image

What should we actually need:

• build front-end
• pull headless chrome

---

In order to run back-end unit tests (which we currently don't have), we need:

• build front-end
• build back-end

What should we actually need:

• build back-end

---

In order to run e2e tests, we need:

• build front-end
• build back-end
• build e2e
• pull selenium image
• pull PostgreSQL image

What should we actually need:

• exactly that

---

In order to run REST API tests, we need:

• build front-end
• build back-end
• build e2e
• pull selenium image
• pull PostgreSQL image

What should we actually need:

• build back-end
• mocha, axios
• pull PostgreSQL image

Other Issues

• Adding/removing any npm module from subproject requires complete redownload of all npm modules for that subproject
• If 2 or more sub projects require same npm module, it gets downloaded 2 or more times (for each sub project separately)
• Webpack build in front-end image gets completely ignored in the front-end container and has to be built separately - can often lead to frustrating behavior in dev environment

Option 2: kladovka-way

Goals

• Deploy as little as possible
• Have "watch" functionality for dev env
• When there is an error in the build, it should fail as soon as possible
• Set up new dev machine as easy as possible
• When there is no error in the build, it should not do redundant/duplicate actions
• (possible but not implemented yet) Have "watch" functionality for tests

How

Separated Docker images for production and dev. All test-related stuff is inside dev container, and project is physically monolithic, but logically is split into sub projects while having common root node_modules directory managed by yarn.

Other Issues

• Base image for dev is slightly over-weighted - by not a significant margin though, ~100 MB
• Proper management of logs requires a bit of extra effort to set up
• Partly duplicate set up actions for dev and prod images and Travis
• In order to achieve fast response on fail build, Travis configuration is more complicated than it could be