Node.JSへの移行は、Linuxでのクラウドオフィスの開発の論理的な継続でした。 彼の最初のバージョンは、ほぼ1年前に登場しました-それから、Monoプロジェクトを使用することにしました。 コラボレーションシステムをMonoに移植する際に発生する問題については既に説明しました 。 当時、Linuxのエディターでの作業は始まったばかりでした。 最初に、同じくMonoを使用して記述されたONLYOFFICE Document Serverベータ版がリリースされました。 現在、オープンソースバージョン3.0で利用可能です。
新しいONLYOFFICE Enterprise Editionサーバーソリューションには、Node.JSにある更新済みのONLYOFFICE Document Editors 3.5エディターが含まれています。 なぜ、どのように、何が起こったのかをさらに説明します。
モノケア動機
1.バグの数を減らす
他の誰かの製品を使用することは、良いことではありますが（今はMonoについて話している）、バグを指数関数的に増やすことに悩まされます。 比較的言えば、「ブラックボックス」でコードを実行します。「ブラックボックス」では、ほとんど何でも起こります。 バグの数に他の誰かの製品のバグの数を掛けると、その結果、安定性のための無限の闘争が始まります。これは、多くの場合、次の（そして異常な）アップデートのリリースで新たに開始する必要があります。
2.クロスプラットフォーム
モバイルを含むすべてのOSで動作するデスクトップエディター用のクロスプラットフォームコードが必要でした。 ごく最近、テキストを編集し、表、pdfファイル、およびプレゼンテーションを表示する機能を備えたONLYOFFICE Documents for iOSがリリースされました。 私たちはこれにこだわるつもりはありませんが、後でその計画について考えます。
一般に、ASP.NetとMonoがニーズに対応しなくなったことに気づき、次の質問をしました。
Node.JSを選ぶ理由
いくつかのオプション（Ruby、Java、Python、Node.JSを含む）を検討した後、後者を選択しました。 選択の理由は非常に明白です。このプラットフォームでの作業は既に十分な経験があります。エディターのサーバー部分はNode.JSで作成されました。共同編集サービス（CoAuthoring）とスペルチェック（SpellChecker）です。
その過程で、より安定した動作、スケーリング、およびクラスタリングのアーキテクチャの可能性を築こうとしました。 さらに、Node.JSの機能に関連するいくつかの困難に直面する必要がありました。 これについて詳しく説明します。
Node.JSへの移行の難しさ
1.ビット操作の問題
内容： JavaScriptでは、ビット演算の前に、数値は32ビットの符号付き整数に変換されます
たとえば、C＃コードがありました。
var byteCount = Math.Min(5, data.Length - i); ulong buffer = 0; for (var j = 0; j < byteCount; ++j) { buffer = (buffer << 8) | data[i + j]; }
問題： Node.JSでは、ループ後、バッファー変数が2 ^ 40になり、無効な数値が含まれます。
Node.JSでのソリューション： 「変換」を回避するために、ビット操作なしでそのような場所を書き直しました
buffer = (buffer * 256) + data[i + j];
2.ファイルのダウンロードに関する問題
内容：ファイルは、ドキュメントを変換するときにリンクでダウンロードされます。 C＃では、ダウンロードにSystem.Net.HttpWebRequestクラスが使用されました。
問題： Node.JSには、Web要求用の2つの標準モジュール-httpとhttpsがあります。 モジュールのインターフェースはまったく同じであり、開発者はそれぞれの場合に使用するモジュールを手動で選択する必要があります。 同時に、サーバーがステータス301または302を返した場合、標準モジュールは転送ヘッダーで指定されたアドレスへの自動移行をサポートしません。
Node.JSのソリューション：標準モジュールをラップし、httpとhttpsのどちらを選択するかという問題とリダイレクトを自動的に解決する追加モジュールを使用しました。 Node.JSにはいくつかの同様のモジュールがありますが、そのうちの選択はリクエストに応じて決まりました。
3.リクエスト処理の問題
概要： C＃では、リクエストを処理するために、IHttpAsyncHandlerまたはIHttpHandlerから継承クラスを作成しました。 したがって、すべての要求処理はすぐに使用できました。
問題： Node.JSにはリクエストを処理するための組み込みモジュールがないため、「単独で」アセンブルする必要がありました。
Node.JSでのソリューション： Node.JSでリクエストを処理するには、expressモジュールを使用し、POSTリクエストの本文にアクセスするには、body-parserモジュールを使用します。
multipart / form-dataを使用してPOSTを処理するために、同様の機能を持つ多くのモジュールから選択しました。 可能なオプション（マルチパーティ、バスボーイ、恐ろしい）は、インターフェイス、設定、一時ファイルの記録を一時的に無効にする機能、およびスレッドのサポートが異なります。 「マルチパーティ」を選択しました。これにより、データをAmazon S3ストレージのストリームとして直接記録できます。
4.言語および標準ライブラリの機能に関する問題
概要： C＃の主な利点の1つは、その大きな標準ライブラリとさまざまな構文です。
たとえば、C＃では、参照によってパラメーターを関数に渡すことができます（ref）
private int CreateIndexByOctetAndMovePosition(ref string data, int currentPosition, ref int[] index)
問題：この関数をJavaScriptの「額」で書き換えると、引数として渡された行がコピーされます。 大きな文字列を使用する場合、これにより、文字列をコピーするためのプロセッサ時間が不必要に浪費され、メモリ消費が増加します。
Node.JSの解決策：関数に渡すときに大きな文字列をコピーしないようにするには、それらをバイナリ形式（バッファ）に変換するか、オブジェクトにラップして渡す必要がありました。
さらに、Node.JSには、空ではないディレクトリを削除したり、親サブディレクトリなしでディレクトリを作成したり、xmlを操作したりするための「すぐに使える」機能がありません。 彼らは手作業で仕上げなければなりませんでした。
結果と計画
ASP.Netを使用せず、重い負荷に耐えることができる新しいサーバーを取得しました。 エンドユーザーにとっての長所：落下せず、ハングしません。 開発者として私たちにプラス：それは落ちず、ハングしません。
しかし、もちろん、Node.JS上のサーバーだけでなく、すべてが開始されました。クロスプラットフォームコードが必要でした。 これで、エディターはどのOSでも作業できるようになります。
Windows、MacOS、Linux向けのデスクトップエディターはリリースの準備ができています（はい、ブラウザーでの作業にはいくつかの制限があります）。 さらに、オンラインエディターの改善を続けています。 たとえば、 先ほど書いたiOS用のONLYOFFICE Documents 、テーブルエディター（現在テスト段階）とプレゼンテーションエディター（同上）がすぐに表示されます。 Android向けのエディターは2016年にリリースされます。