This article deals with the problem of choice of tools on the JavaScript-based platform Node.js. The platform is aimed at solving a wide range of tasks which include web applications development. That could be done with bare platform modules but to increase development speed and reduce the number of errors an additional layer of abstraction over the network interfaces of the platform is used in the form of small libraries and frameworks. However selecting the right framework often takes a lot of time. That is so because the Node.js ecosystem introduces a great variety of such solutions from independent developers. Thus a huge problem arises: application developers should make a lot of researches on the existing frameworks. This study partly solves that problem in several steps. First, this article presents a classi cation of frameworks by type for their clustering. Then, the performance of frameworks is obtained but it is not measured directly because such benchmark cannot be examined on the frameworks themselves. Therefore a template application is introduced and implemented on each framework. Consequently all the systems are stress tested. As a result of the study, the measurements and conclusions on them are suggested. Obtained measurements could be applied in a form of a basis for further researches or use recommendations for developers.
REST This article is devoted to the Node.js server frameworks performance study represented by the example of simple web applications which implement REST (Representational State Transfer) API (Application Programming Interface). The main goals are forming frameworks' e ciency rank of and also nding recommendations for these frameworks usage. In order to achieve these aims several steps are required which are: determine framework types; choose application model and de ne minimal set of modules; select optimal productivity criterion.
Copyright c 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
REST architecture design template is in high demand for many years. At the present time it makes integral part of single page, mobile applications and micro services server side organization. Particularly it is essential for this kind of applications to be constructed with restricted amount of resources and more importantly without implantation of bulky technologies. However, to increase the development speed and reduce the number of errors, an additional layer of abstraction over the network interfaces of the language is used. These are small libraries and frameworks, which will be discussed later on the Node.js example.
Building a RESTful API can be performed using a variety of languages and
platforms for compiling and launching them. And yet Node.js pick is a common
way to solve this task due to some features, namely asynchronous requests
handling based on an event generation, the so-called event-driven runtime [
Therefore Node.js platform is a su cient tool for developing REST systems but thus a more specialized problem of creating applications arises that is the choice of an appropriate framework. This issue appeared because originally, when the platform just started its evolution, there was no large suitable framework for implementing any complexity applications. As a result, independent developers created their own solutions on a basis of Node built-in modules. Consequently, nowadays the platform ecosystem has a large number of libraries and frameworks for building web applications that overlap in capabilities or have only minor differences. This problem forces developers of nal products to constantly conduct their own researches on that topic in order to identify suitable frameworks. The article aims to simplify this kind of search. 2
Initially it is required to identify types of frameworks since structural features of the framework a ect many parameters of a future application including potential size, complexity and scalability. For further research small libraries or frameworks that have the minimal necessary functionality to form a REST application are preferred.
The following types of frameworks by usage purpose are de ned:
1. HTTP server library is a set of functions that grant the ability to build
applications based on them; due to the fact that these libraries allow to
organize web systems, they belong to the class of frameworks, but they are
not completely such [
At the rst stage of the study Fastify developers and TechPower researches [
On the basis of frameworks documentation and their description, the most
suitable frameworks for comparing performance based on REST applications are
listed below [
Node.js. 5. Koa is a framework with an intentionally minimal set of functions, modular form and a new request transfer through middlewares unlike Express. 6. Hapi is a framework with built-in functionality that allows to develop any applications expandable by Hapi's plugins. 7. Sails is a popular MVC framework that imitates a framework like Ruby on
Rails but focuses on the informational API and service architecture. 8. Nest is Typescript-based framework that combines object-oriented and functional application structures, is an abstraction over Express or Fastify depending on the choice of the developer; it allows building both simple APIs and large applications. 3
The problem of comparing the quantitative characteristics of frameworks arises because all frameworks di er in built-in functionality, organization of interaction with requests, creation of a requests queue, extension libraries. In order to unify the task of performance measuring, in this study it is proposed to introduce a general application template that will be implemented with di erent frameworks but which will provide a standard functionality.
REST API applications are in most cases used to provide clients with remote resources. In this study the system is de ned which organizes the CRUD (Create, Read, Update, Delete) process for the application log. Also it is necessary to add static les middleware for subsequent performance measurements on requests for the formatted text and les.
The application state management should be taken into account as well. Although the REST architecture implies an absence of storage for client states, session information or a websocket may be in need for storing during data transfer to the client. In this case, the types of these applications are distinguished: with a state where this kind of data is stored in a running application, and without state where such information is stored in special repositories, for example, Redis.
Node.js frameworks have a similar structure, so the application composition can be pre-determined as: 1. Logger is a middleware which saves the information about requests. 2. Bodyparser is a module that selects a request body which is required for
Create and Update operations. 3. Logger is a middleware which saves the information about requests. 4. Static handler is a middleware issuing static les from the public directory. 5. Application state storage. 6. Router which processes the requested paths for further the task allocation to functions; in this application should include: (a) Path for index.html.
(b) Paths that form CRUD operations, in other words application APIs. 7. Log storage middleware for the json le. 8. The errors handler which were generated along the request processing, for example, 404 Bad Request or 500 Internal Server Error.
Application e ciency is characterized by a large number of its parameters including the technology's e ectiveness, the architecture organization accuracy, resistance to external loads and so forth. Therefore it is necessary to adhere to a uniform approach of metering.
There are two approaches in the system performance testing. The rst one is simulating a workload by means of arti cial scenarios of the application's utilization. The second one is beta testing which is carried by end users. In this work the simulating approach was selected since it allows controlling each round of tests and varying measurement parameters.
Moreover there are several types of performance testing that web applications
may be brought to, which are presented below [
In this paper, the load testing approach was chosen as the most reproducible way of the performance determining for di erent applications. Stress testing and stability testing to a greater extent show the fault tolerance of web applications but not their quantitative e ciency parameters.
It is important to indicate that Node.js processes originally run on one
core [
It should be noted that there are several basic metrics of the application undergoing stress testing, namely: consumed processor time and RAM units, the disk subsystem usage, processed number of requests per time unit, response time. This study is focused on determining characteristics that are irrespective of the physical platform and can be measured both on the application side and on the client. Thus selected application parameters are processed requests per second and the application response time in milliseconds.
Moreover there are universally recognized tools for measuring performance.
In this research it is suggested to use the same platform for testing system
as for creating applications and utilize performance measurement tools which
are available for Node.js. One of the most popular load testing utility on this
platform is AutoCannon [
Further the created systems were benchmarked in order to detect the most e ective framework. Several tests have been conducted simulating clients connections to the application. The measurements started from 25 connections and ended with 1000 by the increment of 25 connections. In order to combine previously selected load testing metrics for a better representation, this study proposes to divide the number of processed requests by the response time. The results of the measurements are presented in Figure 2.
The graph depicts that the best results are shown by modular frameworks Fastify and Koa, while the slowest ones are large frameworks Loopback and Hapi. The chart also displays that after about 300 connections, a sharp decrease of the frameworks performance becomes more gradual. Thus for this research testing stand 300 connections is the most optimal criterion and therefore Table 2 presents the framework characteristics for this round of tests.
Proceeding from the data which was obtained during the applications creation and their testing, the following frameworks and libraries usage recommendations are formulated: 6
In this article types of frameworks were selected to classify these frameworks in accordance with their purpose. For each type, representatives were identi ed as well as its features in the form of advantages and disadvantages. Due to the fact that abstract frameworks load testing execution is extremely di cult without an existent application, a template of the REST system was introduced and then implemented on all frameworks. Finally all applications were benchmarked with Node.js tool and use cases were proposed based on the frameworks classi cation as well as on the carried load testing.
The study can be used as the foundation for further researches or for the initial choice of web project framework.