How to improve your API service on node.js. Part 1
A decent amount of material is now available about writing the API on node.js. Most of them are in the form of tutorials and demos in the documentation. This is enough to quickly figure out and write something of their own. But they rarely find details of why this is done that way. And some points are omitted altogether for simplicity and brevity.
This article is intended to fill in some gaps that might arise, and ultimately improve your service on node.js.
Project file structure
File structure is a basic, but very important thing. When creating it, it is worth considering the possibility of scaling the service, for this reason it is not worth placing files in the flat structure of one directory. We need a hierarchy, we need modularity.
When naming directories, you must adhere to established standards. This will help colleagues and in a couple of months to quickly find out where and what is located.
File structure example
src/
controllers/
users/
index.js
index.js
db/
mongo/
index.js
index.js
helpers/
middlewares/
auth.js
models/
users.js
routes/
users/
index.js
index.js
index.js
.eslintrc
.gitignore
README.md
…
package.json
src/ controllers/ users/ index.js index.js db/ mongo/ index.js index.js helpers/ middlewares/ auth.js models/ users.js routes/ users/ index.js index.js index.js .eslintrc .gitignore README.md … package.json
Notes:
- All executable files must be located in ./src
This will allow to separate the source files from compiled typescript or babel, which will be located in ./dist or ./build.
It will also make it easier to configure linters and other configurable tools, since the target files are located in a separate directory.
2. Place all controllers and routes entities in separate directories
This allows opening ./routes or ./controller to see only one index.js file, importing and exporting subdirectory entities.
This will allow you to quickly navigate the existing functionality, since it describes only the interface of controllers or routers without delving into their implementation.
About Javascript Compilation
Of course, you can not use babel or typescript to convert your javascript. As a rule, new ECMAScript standards quickly end up in node.js, and you, with the exception of browser-based javascript, are able to control their support.
But I am convinced that they are worth using. And that’s why:
The latest version of Node.js is not always available for production.
Node.js (v. 13) still has problems with supporting ECMAScript modules, although they appeared and left the flag, they are still experimental. To sell early.
Consider adding babel to the project:
Install the dependencies:
1 |
npm install @babel/core @babel/node @babel/preset-env --save-dev |
Add the .babelrc configuration file to the project root
1 |
{ "presets": [ "@babel/preset-env" ] } |
Script run example
1 |
"start": "nodemon --exec babel-node src/index.js", |
Notes:
Do not forget to set the –save-dev (-D) switch when installing dependencies, which are necessary only at the development stage. This is necessary at least for semantics.
About the need for linter
Let’s start with the obvious fact: linters are needed. We write code, a lot of code. So much of that, we ourselves are not able to control its uniformity. This item is incredibly enhanced in team development.
And uniformity is the key to code readability.
The question remains about the rigor of the linter. The choice of which should be based on the size of the team, their professional level, an important criterion is the project itself.
Adding a simple linter to a project
Install the dependencies:
1 |
npm install eslint --save-dev |
Add the .eslintrc configuration file to the project root:
1 |
{ "env": { "node": true, "es6": true, }, "extends": "eslint:recommended" } |
As a rule, such a config is not enough. Here either expand the rules yourself or take a closer look at the more rigorous options prepared.
1 |
... "extends": "eslint:recommended", "rules": { "quotes": ["error", "single"] } } |
Using a stricter linter
Now there are several popular configurations based on the same style guides.
1 |
npm install --save-dev eslint-config-google |
Airbnb
1 |
npm install --save-dev eslint-config-airbnb-base eslint-plugin-import |
Idiomatic
1 |
npm install --save-dev eslint-config-idiomatic |
Accordingly to this, it will be necessary to correct .eslintrc
1 |
{ "env": { "node": true, "es6": true, }, "extends": "google" | "airbnb-base" | "idiomatic" } |
It is also necessary to add the launch of the linter to a separate script.
1 |
"lint": "eslint ./src --cache && echo \"eslint: no lint errors\"", "lint:fix": "eslint ./src --fix && echo \"eslint: no lint errors\"" |
About application launch
Anyone who has access to the project repository should be able to run it. Whether he can do it and how much time it will take for him to do this is one of your project quality criteria.
It is important to document in advance how to step-by-step start the service in the README.md file, as well as prescribe commands for the main actions.
1 |
"start": "npm run dev", "dev": "nodemon --exec babel-node ./src/index.js", "build": "babel ./src --out-dir ./build", "prod": "NODE_ENV=production node ./build/index.js", "lint": "eslint ./src --cache && echo \"eslint: no lint errors\"", |
To use the above commands, you may need to install the following packages:
1 |
npm install --save-dev @babel/cli nodemon babel-node |
Note:
If you even added the basic commands to package.json, still describe the startup process in README.md.
Conclusion
Initially, the article wanted to cover much more recommendations for writing an API on node.js, but I want to fit in 3-5 minutes. reading the article.
Related Posts
Leave a Reply Cancel reply
Service
Categories
- DEVELOPMENT (102)
- DEVOPS (53)
- FRAMEWORKS (25)
- IT (24)
- QA (14)
- SECURITY (13)
- SOFTWARE (13)
- UI/UX (6)
- Uncategorized (8)