From ASP.Net to Node.JS: how we rewrote the server part of ONLYOFFICE editors

To the release of the ONLYOFFICE Enterprise Edition corporate solution, we rewrote the server-side code of our online editors at Node.JS and now, in fact, we want to share the experience of exemption from ASP.Net, which we were trapped five years ago.

The transition to Node.JS was a logical continuation of the development of the cloud office on Linux. The first version appeared for him almost a year ago - then we decided to use the Mono project. We have already talked about the problems that arose when porting to Mono systems for collaboration. At that time, work on editors for Linux was just beginning. First came the beta version of ONLYOFFICE Document Server, also written using Mono. Now it is available in open source version 3.0.

In the new server solution ONLYOFFICE Enterprise Edition, we have included the updated ONLYOFFICE Document Editors 3.5 editors, already on Node.JS. Why, how and what happened next.
')


Mono Motives

1. Reducing the number of bugs

The use of someone else's product, albeit a good one (now we are talking about Mono), is fraught with multiplication of bugs exponentially. We run our code, conditionally speaking, in the “black box”, in which almost anything happens to it. The number of our bugs is multiplied by the number of bugs of someone else's product and, as a result, an endless struggle for stability begins, which often has to be started anew with the release of regular (and extraordinary) updates.

2. Cross-platform

We needed a cross-platform code for desktop editors running on all operating systems, including mobile ones. Just recently, ONLYOFFICE Documents for iOS was released, with the ability to edit text and view tables, pdf-files and presentations. We do not plan to dwell on this, but plans are on later.

By and large, we realized that ASP.Net and Mono had stopped responding to our needs, and we asked ourselves: what should we write on next?

Why Node.JS?

Having considered several options (among them Ruby, Java, Python, Node.JS), we chose the latter. The reasons for the choice are fairly obvious: we already had quite a good experience with this platform - the editors of the server parts were written on Node.JS: the CoAuthoring and SpellChecker services.

In the process of work, we tried to lay in the architecture the possibilities of more stable operation, scaling and clustering. In addition, I had to face some difficulties associated with the features of Node.JS. Tell about it in more detail.

Difficulties in moving to Node.JS

1. Problem with bit operations

What happened: In JavaScript, before bit operations, the number is converted to 32-bit signed int

For example, we had C # code:

var byteCount = Math.Min(5, data.Length - i); ulong buffer = 0; for (var j = 0; j < byteCount; ++j) { buffer = (buffer << 8) | data[i + j]; } 

Problem: In Node.JS after the loop, the variable buffer becomes 2 ^ 40 and contains an incorrect number.

Solution in Node.JS: To avoid "transformations", we rewrote such places without bit operations.

 buffer = (buffer * 256) + data[i + j]; 

2. The problem with downloading the file

What was: Files are downloaded by reference when converting documents. In C #, the System.Net.HttpWebRequest class was used for downloading.

Problem: In Node.JS there are two standard modules for web requests - http and https. The interfaces of the modules are exactly the same, and the developer must manually select which module to use in each particular case. At the same time, standard modules do not support automatic navigation to the address specified in the redirection header, if the server returns status 301 or 302.

Solution in Node.JS: We used an additional module that wraps standard modules and automatically solves the problem with the choice between http and https and redirects. There are several similar modules in Node.JS - of which our choice fell on “request”.

3. Problem with processing requests

What happened: In C #, we created a descendant class from IHttpAsyncHandler or IHttpHandler to handle requests. Thus, all request processing was out of the box.

Problem: Node.JS does not have built-in modules for processing requests, so it had to be assembled “by itself”.

Solution in Node.JS: To process requests in Node.JS, we use the “express” module, and in order to have access to the POST request body, the “body-parser” module.

To handle POST with multipart / form-data, we chose from a variety of modules with similar functionality. The possible options (multiparty, busboy, formidable) differ in the interface, settings, the ability to disable the recording of a temporary file in the temp and support threads. We chose “multiparty” —with it, you can directly write data as a stream in the Amazon S3 storage.

4. The problem with the features of the language and standard libraries

What was: One of the main advantages of C # is a large standard library and a diverse syntax.

For example, in C # you can pass a parameter to a function by reference (ref)

 private int CreateIndexByOctetAndMovePosition(ref string data, int currentPosition, ref int[] index) 

Problem: If we rewrite this function in javascript “in the forehead”, then the string passed as an argument will be copied. When working with large lines, this will lead to wasting CPU time on copying them and increasing memory consumption.

Solution in Node.JS: To prevent large lines from being copied when passed to a function, we had to either translate them into a binary format (Buffer), or wrap it into an object and pass it.

In addition, in Node.JS there are no “out of the box” functions for deleting non-empty directories, creating directories without parent subdirectories, working with xml, etc. They had to finish their hands.

Results and plans

We received a new server that does not use ASP.Net, which is able to withstand heavy loads. Pros for the end user: he does not fall or hang. Pluses for us as developers: it does not fall or hang.

But, naturally, everything was started not only for the sake of servers on Node.JS - we needed a cross-platform code, and we received it. Now our editors will be able to work on any OS.

Our desktop editors for Windows, MacOS and Linux are now preparing to release (yes, browsing also has some limitations that we want to overcome). In addition, we continue to improve our online editors. For example, very soon ONLYOFFICE Documents for iOS , about which we wrote above, a table editor will appear (currently in testing) and a presentation editor (ibid.). Android editors will be released in 2016.