REserve — Rational

Arnaud Buchholz
4 min readMar 1, 2020

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

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:

The cherry on top of the cake is yeoman that provides hundreds of templates (or generators) to initiate a new server project.

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.

An example of a web server publishing static files using express

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.

License type / count
MIT/48
ISC / 3
BSD-3-Clause / 1
Licenses used in express

Whenever express is updated, you might need to recheck again the list.

serve

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.
Example of package.json that executes serve through npm start

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.

So what?

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

Last year I had the pleasure to present at UI5Con and I introduced node-ui5: a Node.js wrapper for UI5 to leverage tools like MockServer or ODataModel.

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.

I started to draft a separate project that would reuse these simple concepts and enforced reusability by offering the possibility to externalize the configuration in a JSON file.

An example of a web server publishing static files using REserve

REserve was born.

--

--

Arnaud Buchholz

Passionate developer, always keen on finding new ways to do things, welcome to my thoughts.