Sometimes, a simple idea leads to very interesting projects. This article will detail the reasons of the creation of REserve best described as a lightweight web server statically configurable with regular expressions that can also be embedded and extended.
Why inventing the wheel again?
If you are familiar with the Node.js ecosystem, you know that there are many ways to build a web server. From the framework based solution (namely express) to the turn-key command line (for instance serve), the choice is yours.
As a lazy — but prolific — developer, I own many projects that require files to be available in a browser. For instance, the articles of the gpf-js blog are first redacted locally using the markdown syntax and then exported to HTML to be published. Another example, the time sheet generation tool uses a web interface to enter the parameters…
Here is a quick overview of some selected packages that are available.
Express is easily the most popular Node.js framework to build web applications. It contains the necessary tools to develop a server by offering a strong routing mechanism and giving access to the low level requests and responses. It is highly extensible and the most expected features of the web are implemented through middlewares, for instance:
- passport: to enables authentication
- cookie-session: to implement a cookie-based session
- cors: Cross-origin resource sharing
- … and more
So you might be wondering why I don’t use express ?
First of all, the servers needed in my projects are publishing mostly static files. As a consequence, a very basic express server would be sufficient, like in the following example.
But then, this code would be copied in each project with a dependency to the express package. And, talking about dependencies, express itself requires 51 additional components. This explains why the package contains only 204 KB of code but, in the end, has a digital footprint of 1.61 MB.
If you now consider licensing, express is under the MIT license. But since it owns so many dependencies, you also have to look for the license of each individual component being required.
And they are not all sharing the same licensing model (even if they are pretty close), as summarized below.
Whenever express is updated, you might need to recheck again the list.
On the other hand, the serve package is the perfect tool to publish static files in a simple way. Actually, I used it for a while before switching to REserve.
There are two ways to install and use it:
- Globally: after running npm install serve --global, the tool can be executed in any folder using the command serve
- Locally to a project: after adding the dependency with npm install serve --save (or --save-dev if it is a development one), you may create an NPM script to run the tool, like in the following example.
It suffers from the same drawbacks regarding dependencies (it is even bigger) and licensing. But, most annoying, the tool offers very little configuration support.
server.js for Node.js
This example is listed to illustrate how uncontrollable dependencies may become: 218 components and 8 different licenses.
When it comes to deliver only static files, serve is the simplest — yet heavy — solution.
However, there are few projects that requires more than just static files. For instance, the GPF-JS dashboard relies on some middleware (as explained in this article). Consequently it relies on the grunt connect server (lazy me did not want to start a specific express app).
Not satisfied with the current solutions, I kept this problem in the back of my head and continued working on the projects.
Origin of REserve
As a very last part of this presentation, a prototype demonstrates how OPA could be used to do end-to-end testing. One of the key challenges is to be able to run the local test code on a remote iFrame. Because of the same origin policy, it is not possible. However, with the help of a proxy that aggregates the remote website and the local files under a unique server, it becomes possible.
This proxy code was part of the node-ui5 project and already contained some concepts of REserve:
- Handlers (file, url and a specific mock one)
- Mappings that use regular expressions to match incoming URL
The REserve project
At that time, the code was small and had very little dependencies.
REserve was born.