JavaScriptは、その誕生以来、単純なWebページから本格的なアプリケーション、さらにはサーバーに至るまで、長い道のりを歩んできました。 ただし、アプリケーションが複雑になるほど、それらに適したアーキテクチャの問題はより深刻になります。
swarm.js（ https://twitter.com/gritzko ）の作成者であるVictor gritzko Grishchenkoとともに、サーバーとクライアントの両方でJSアプリケーションのアーキテクチャを構築するための最新のアプローチを検討します。
-モノリシックWebアプリケーションについて話すとき、通常は、すでにクラシックになったアーキテクチャを意味します。 いわゆる層状モノリスは、多くの企業の決定に根付いています。 実際のプロジェクトでこのアーキテクチャのどのような欠点に対処しなければなりませんでしたか？
-私はロシア銀行で2000年にそのような古典的な建築に初めて出会いました。 さらに、緊急時の実装の過程で、それ自体が発生しました。 システムが完全に稼働し、完全なデータベースを備えたサーバー上でしか実行できない、非常に普通のエンタープライズJavaの悪夢であることが判明しました。 結果として得られたモノリスで何かをすることはすでに困難でした。すべてはすべてに依存していました。 その後、Yandexで同じfakapyを見ました。 これは、アプリケーションのアーキテクチャが大きくなる場合、避けられないステップです。
-モノリシックプロジェクトをサービスに分割するときだと理解する方法 兆候はありますか？
-「共有する時間です」-これは「切断する時間です」というシリーズからです。 大きなタスクの小さな直交サブタスクへの分離は、設計段階で実行する必要があります。
-Node.jsは非常に活発に開発されており、記事やマニュアルはすぐに陳腐化しています。 今日に従う価値のある良いプラクティスはありますか？ おそらく、マイクロサービスアーキテクチャを構築するための参照ソリューションはありますか？
個人的には、RESTベースのマイクロサービスはプロファイルのみが同じミニオンであるように思えます。 何らかの方法で、サブシステム間の非同期通信が必要です。 古典では、これらはメッセージキューであり、どこでも使用され、常にどこでも使用されます。 今、トレンドのあるものがあります-カフカ、アッカ。
-モノリシックアプリケーションの場合、通常、ロードバランサーと適切な数のコピーがあれば十分です。 ただし、マイクロサービスの場合、システムのどのコンポーネントをスケーリングする必要があるかを理解する必要もあります。
-このようなバランサーは、非常に単純な、理想的にはステートレスなアプリケーションでのみ問題を解決します。 そうでなければ、データの同期と競合アクセスの問題が始まり、地下にポータルが開き、そこから悪魔が出てきます。 そして、1つの明確な機能を備えたコンポーネントは、間違いなくスケーリングが容易です。 専門化と規模の経済は、18世紀後半のAdam Smithです。
一般的に、レポートはマイクロサービスに関するものではありません。 「不変のインフラストラクチャ」のアイデアをフロントエンドに直接適用し、ブラウザで機能するものに適用します。
-さて、クライアントのコードについて説明しましょう。 現在関連している問題は何ですか？
-たとえば、ファッショナブルなフレームワークを使用する場合、クライアントバンドルの特徴的なサイズは既にメガバイトのJavaScriptです。 不快な、特に電話で。 前線を組み立てるプロセスは、すでに大したことです。
クライアントへのデータのプルは本格的です-最初にコードを引き出し、SPAが登場し、今では徐々にデータを引き出しています。オフラインファースト、速い応答時間、およびその他の利点が必要です。
同時に、UIコンポーネントは純粋な機能であるべきだと言い始めたとき、これは奇妙とは見なされません。 つまり、人々は準備ができています。
-実際、平均的なWebアプリケーションのサイズは増加しているだけです。 状況を改善する方法について何か提案はありますか？
-私の考えは、フロントエンドで発生するすべてを（A）データと（B）その他すべて（コンポーネント、コード）に厳密に分割することです。 さらに、データではないものはすべて関数です。 考えてみると、関数もデータです。 コードをバージョン管理システムに入れると、データになります。 つまり、同じ方法でクライアントに配信し、同じ方法でキャッシュして更新する、バージョン管理されたデータと機能があります。
-そしてもう少し？
-例で説明します。 100個のボタンが表示されたページをユーザーに送信します。 100個のボタンのコードを1つの大きなバンドルに入れたり、データベース全体をダウンロードしたりするのではなく、レンダリングに必要なもの（データの一部とコンポーネントの一部）のみを送信します。 ユーザーがあらゆる場所を探し回ると、より多くのデータ、より多くのコンポーネントを取得します。 同時に、すでにクライアントに配信されたものは永久にキャッシュされます。 必要に応じて更新。
これは、マイクロサービスに一部似ています-不変/バージョン管理されたコンポーネントに多くのコードをソーイングするようなものです。 ところで、私は個人的に、免疫よりもバージョン管理と呼ぶことを好みます。 バージョン、少なくともデータ、少なくともコードは、定義上、不変であり、トリックはこの中にあります。
最終的に、ここでの基本的な問題は同じです。コードとデータの両方が同時に複数のデバイスで動作する必要があります。 プロセッサがどこにでもあるからこそ、分散システムを構築します。 電話-コンピューター、本-コンピューター、テレビ-コンピューター。 メインフレームがなくなると、クライアント/サーバー思考は過去のものになります。 そして、置き換えられるものは興味深い質問です。
-おもしろそうですが、既存のライブラリやフレームワークとどのように互換性がありますか？ アプリケーションの部分的な操作であっても、大きな基本的な依存関係が必要になります（AngularJS、jQuery、...）。
-さて、preactは何とか3KBに収まります。
このコンテキストでは、角度は本当に不要です。
-この概念はすでに別のプロジェクトに形成されていますか？ 詳細はどこで確認できますか？
-積み上げ。 今では実験に似ています。 12月までに何が起こったのかを説明します。
HolyJS会議 （12月11日、モスクワ、Radisson Slavyanskaya）での Victorのレポートに加えて、以下のレポートに注意することをお勧めします。
- ECMAScript：最新および今後の機能
- インタラクティブなnpmコマンドラインモジュールの構築
- 白鳥のガンとパイク：テクノロジーがどのようにフロントエンドを下に引き寄せるか
- 3L3M3NT5
- 最新のWebアプリケーションへのアプローチ方法
- 実稼働環境でのNode.jsパフォーマンスの問題のデバッグ
- WebVRは次のフロンティアです
- エルムとフロントエンドの至福に少し近づく
- V8のパフォーマンスプロファイリング
- DIY（開発）ツール
- Draft.jsを使用したリッチテキスト編集
- オフラインは新しいブラックです
- JavaScriptを使用したP2P共有フォルダーを使用してファイルやデータを友達と共有する