未加星标

Node.js architecture: 8 helpful tips - HelpDev

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二03 | 时间 2019 | 作者 红领巾 ] 0人收藏点击收藏

Node.js architecture: 8 helpful tips - HelpDev

There are many good reasons to think about architecture before and during development of a Node.js application. One of the most important reasons is that constantly new requirements are placed on the own application and these can change over the course of time. Therefore, the application should have a degree of flexibility using a good Node.js architecture.

Not only from the requirements view, a stable and consistentNode.js architecture in an application is important, it also helps to handle the constant change that you face in thejavascript world. In this article, you will learn about some aspects of Node.js architecture that you can apply in your application to make your daily work easier.

General: Use tool support

Many Node.js application development issues now have some tools to help you get started. In general, however, you should make sure that you automate repetitive tasks, if possible through the use of tools or libraries. This saves time and reduces the potential for errors.

An example of such a tool is ESLint, a static code analysis tool for JavaScript. ESLint can be easily integrated into a project and then integrated as an action in the build process of the application as well as directly in the development process as a plug-in of the development environment. If you agree on a code standard in the project team, such as the Airbnb Style Guide, for example, you can use ESLint to ensure compliance with the code standard. There are a few more aspects that contribute to a good Node.js architecture I’ve collected eight helpful tips and tricks.

Modularization

Node.js has a modular system that allows you to structure your application into smaller units. This enables the single-responsibility principle to be implemented. It says that each module and class has only one responsibility, so it’s just about taking care of one thing. Adhere to this principle, compose your application from a lot of smaller components. These should be as close together as possible to ensure independence. If you build your application using this principle, you have the option of modernizing or exchanging individual modules independently of the overall application.

Already in the first versions of Node.js such a modular construction was supported by the modular system. Originally the CommonJS module system with the require function for importing modules and the module.exports construct for exporting interfaces was used. For some versions, the ECMAScript module system is also supported. This is initially deactivated by default and must be activated by the -experimental-modules option. The module system uses the keywords import to load modules and export to define interfaces. The files that use the ECMAScript module system must end in .mjs instead of .js . If you do not consider this, you will receive an error message.

Unlike client-side JavaScript, Node.js does not have to worry about bundling or optimizing source code because the source code is available on the server, wherever it runs; the transfer of the code via a network connection is therefore eliminated. The Node.js module system also has some optimizations that ensure that splitting into a large number of small files does not create any performance penalty. Some of these optimizations come directly from the core of Node.js. When starting the application, all directly accessible imports are evaluated, the files are read in by the JavaScript engine and converted into bytecode. However, as a result, during the development process, you must restart the Node.js process for the changes to take effect.

Another optimization concerns the caching behavior of modules. If you embed a module via import or require , the code will be executed. As a result, all side effects, such as function calls, take effect directly in the module. The result of the module execution, ie the public interface, is then written to the module cache. Then, if you insert the module a second time elsewhere in your application, the module will not be run again but will use the result from the cache. This means that no side effects occur more. Instead of emptying the module cache, you should export functions for intentional side effects and execute them explicitly, making your source code easier to read.

Directory structure

The structuring of the source code in the file system is directly related to the modularization of an application. In this context, some success models have emerged in recent years, all of which pursue the goal of keeping an application clear, even if the scope of functions is growing steadily. In general, you should start with a flat and simple directory structure and extend it as needed. For structuring, it is advisable to structure the files according to their purpose in small applications with little defined expertise. For example, build your web application by the MVC pattern, create directories for your models, views, and controllers and sort the files there. In addition, it makes sense to create a shared directory in which you can place help constructs.

If your application has a larger range of functions, in which you can differentiate the individual specialist areas more clearly, you can use this as a structuring feature. Each area is then represented by a separate directory. For example, user management could be placed in a user directory. Depending on the size of the module, you can create additional sub-modules or group the files again according to their technical structure.

For file names, you should avoid capitalization and name the files with lowercase letters only. An alternative to the widespread CamelCase notation is the kebab-case notation, in which the individual words are separated from each other not by large initial letters, but by hyphens. This will work around problems with file systems that are not case-sensitive.

If you divide your application into different modules, you can use another feature of Node.js in connection with the module system. If a directory has a file named index.js , it will be the default entry file for that directory. So importing the directory loads the index.js file. In this you can then collect all the interfaces of the module export. This has the advantage that when using a module you no longer need to know every single file and its interfaces, but only have one central export file per module.

Asynchrony

Working with Node.js will quickly confront you with asynchronous operations. The connection of third-party systems as well as access to system resources is generally asynchronous. This means that you are performing an operation and have no direct access to its return value. This feature strongly influences the structure of the source code and the communication within an application. There are a number of ways to deal with asynchrony. The first question that needs to be answered is whether it is an operation with only one result or a continuous flow of results. In the first case, you can callback functions or promises. In the second case, streams are usually used. Streams and their underlying EventEmitter are also used for communication within applications and with third-party systems. The next section deals with this aspect of Node.js architecture.

The simplest solution for an asynchronous operation is the use of callback functions. These are function objects that are passed to a function and executed after the asynchronous operation completes. Basically, you can make these callbacks free, but in Node.js a convention for the design of callbacks has evolved. The first argument that you pass to the callback function represents an error. If successful, pass the value zero . All other arguments represent the results of the operation. If an error occurs, pass an object representa

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

代码区博客精选文章
分页:12
转载请注明
本文标题:Node.js architecture: 8 helpful tips - HelpDev
本站链接:https://www.codesec.net/view/628204.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(43)