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:

  1. 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:

Add the .babelrc configuration file to the project root

Script run example

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:

Add the .eslintrc configuration file to the project root:

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.

Using a stricter linter

Now there are several popular configurations based on the same style guides.

Google

Airbnb

Idiomatic

Accordingly to this, it will be necessary to correct .eslintrc

It is also necessary to add the launch of the linter to a separate script.

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.

To use the above commands, you may need to install the following packages:

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.