この春、ハブブログでVKontakte は次のように書いています。「製品の外観の背後にあるものについて話し始める準備ができています。」 VK開発者のTimofey Chaptykov がプレゼンテーションを行った HolyJS JavaScript会議を見越して、いくつかの質問をしました。
-VKでは正確に何をしていますか？
-主にメッセージセクションを開発しています。 しかし、私たちには小さなチームがあり、各開発者の責任範囲は非常に広いです。 そして、人がここで長く働くほど、それは広くなります。
-VKに住む前に、あなたはノボシビルスクに住んでいました-この仕事のために、引っ越しましたか？ 最近、ノボシビルスクのJava開発者は 、ノボシビルスクに住んでいて、JavaScriptとフロントエンドのある都市には多くの空きがあると言っていましたが、地元のJSコミュニティは発展していますか？
-昨年、私はサンクトペテルブルクを4回訪れました。 ある時点で、移動しやすいと判断しました。 さて、非常に要求の厳しいオーディエンスを抱える最大かつ最も複雑で大規模なプロジェクトの1つに取り組むという申し出を拒否することは困難でした。
ノボシビルスクには、Web開発に欠員のある大規模なIT企業が多くあります。Yandex、2GIS、JetBrains、SberTech、Tinkoff.ruです。 ノボシビルスクには、複雑でスケーラブルなフロントエンドを実行できる人がいると思います。 いくつかの地元の会議や会議があり、年に一度ロシアで最大のCodeFest IT会議が開催されます。
-VKの月間視聴者はほぼ1億人です。 このようなトラフィックは、開発全般、特にJS /フロントエンドにどのように影響しますか？
-現在、少数のユーザーに対してすべての変更が最初にリリースされます。 これらのユーザーに対して、個別の統計を収集します。 リリースが負荷に影響を与えるかどうかを評価するのに役立ちます。
時にはこれで十分ではありません。 リリースがパフォーマンスに影響を与え、負荷がかかった状態で動作する可能性があると想定した場合、一部の機能は夜間のみ展開します。 モスクワ時間の夜、負荷は低くなります。グラフに異常がある場合は、ピーク負荷が発生してサービス障害のリスクがある前に、変更をロールバックするか、修正プログラムをリリースします。
私たちの負荷の下では、静的を更新するための簡単なアプローチを買う余裕はありません。 すべてのスクリプトを1つのファイルに結合し、デプロイごとに更新する余裕はありません。 すべてのユーザーが同時にファイルにアクセスすると、負荷に耐えることが難しくなります。 1億人のユーザーが1つの追加リクエストを行うと、悲惨な結果につながる可能性があります。 したがって、静的をバージョン管理し、動的にロードし（ページはそれと互換性のある静的のバージョンをロードします）、サイトのセクションと機能に従って小さな断片に分割します。
直接変更することはできません。 データベースが数十億のレコードで移行されている間、数日間サイトをオフにすることはできません。
1か月あたり1億人のアクティブユーザーがいる場合、確率論はあなたに反して働き始めます。 実験の数は、不可能な出来事が毎日のルーチンになるほどです。 バグが100万回に1回再生される場合、これはこのバグが毎日何回も再生されることを意味します。 最も驚くべきシナリオでさえ、詳細に取り組む必要があります。
フロントエンドは、VKontakteを使用するケースが他のサイトとは非常に異なる場合があるという事実の影響を受けます。 たとえば、メッセージタブの有効期間はほぼ無限である場合があります。つまり、タブを開いて数か月間有効です。 これにより、メモリ消費についてより多く考えるようになります。
大量のコードから厳しいパフォーマンス要件が発生する場合があります。 たとえば、アセンブリは非常に些細な主流ではなく組織化されなければなりませんでした。
私たちは、ほとんどの開発者がクライアントを含むデータ構造について考える必要がある場合が多いと思います。 私たちのキッチンでは、新しいライブラリや方法論よりもアルゴリズムやデータ構造についての話をよく耳にします。
サイトでは、外部依存関係をほとんど使用しません。 技術的には、クライアントの各セクションは個別のJSアプリケーションです。 共通のリソースには、コード分割と静的バージョン管理のためのシステム、多言語対応、DOMを操作するためのユーティリティ、サーバー要求、小さな共有ストレージ、および再利用可能なユーザーインターフェイスソリューションがあります。
-Node.jsがあまり知られていないニッチソリューションだった昔、VK開発者のOleg Illarionov がロシアで人気を博しました。 VKでNode.jsを使用していますか？
-ほとんどの場合、客観的な理由から、Node.jsをバックエンドで使用することはできません。ボリュームでは遅すぎます。 したがって、業界全体と同様に、Node.jsを使用してフロントエンドを構築します。 そこで、Gulp、Webpack、Babelという従来のツールセットを使用します。
-以前、VKontakteは独自のKPHP開発をオープンソースでレイアウトしました-JSの場合、ソーシャルネットワークには、理論的にはオープンソースになる可能性のある重要な内部「バイク」がありますか？
-本番環境では、既製のソリューションはほとんどありません。 package.jsonでは、メインリポジトリで宣言されている依存関係は4つだけです。 そのうちの2つは親友、2つはmp3でサウンドを録音およびエンコードするためのライブラリです。
多くの重要な内部自転車があります。 しかし、多くの場合、当社のソリューションは高度に専門化されており、「大量」開発部門では需要がありません。 たとえば、KPHPを取り巻くインフラストラクチャにはかなり高いしきい値があり、その使用には特定の制限があります。 そして、その実装から大きな利益を感じることができるプロジェクトはそれほど多くありません。
それにもかかわらず、私はフロントエンドエリアにもっとオープンソースソフトウェアがあると期待しています。
「JSの世界は、現代のフロントエンドでは、「こんにちは、世界には360 MBの依存関係が必要です」という観点から批判されることがよくあります。」 そして、VKで働いているとき、これは不便をもたらしますか、それとも他の人と比べてそのような大規模なプロジェクトで取るに足らない要因ですか？
-まあ、これは間違いなく私たちが解決しなければならない主な問題ではありません=）node_modulesには140 MBの依存関係があります。 私の意見では、最も深刻な技術的課題の1つは、技術的負債の排除と、開発とテストのためのインフラストラクチャの開発です。 私たちの現実では、新しい機能の開発のペースを落とすことなくこれを行わなければなりません。 そして、当社のすべての製品に関する数十人の開発者の同じチーム。
-HolyJSに関するあなたのレポートは、「光の速度で反応する：非常に普通のサーバーレンダリングではありません」と呼ばれます。 また、ReactはFacebookで作成されたため、Reactを使用できなくなりましたか？ :)
-レポートに来て、そこで最終的な解決策はReact =に基づいていないことを伝えます
Reactは、特定のライブラリの名前としてではなく、アプローチの用語として考えます。 Reactについて言えば、通常は仮想DOM、宣言型レンダリング、コンポーネントアプローチ、JSXを意味します。
ほとんどの場合、Reactは、同じ原則を使用する別のライブラリによって最小限の労力で置き換えることができます。 また、選択したソリューションが特定の状況下で高速であることを示すいくつかのベンチマークを見つけます。 =）
Reactで慣れ親しんでいるすべての基本機能を提供する小さな4KライブラリであるPreactが好きです。
React自体は現在VKontakte Webサイトでは使用されていませんが、いくつかのプロジェクトで使用されています。 たとえば、 VK MessengerはReactで記述されたElectronデスクトップアプリケーションです。
-ありがとう。 最後に、通知カウンターに関する皮肉なツイートのために明確にしたいと思います。これが専門的に出会わない人にとってこれが難しいタスクである理由を簡単に説明できますか？
-新しい通知のカウンターは、膨大な数のシステムの作業の結果として表示される1つの数字です。 通常、これらは複雑で複雑なマルチレベルシステムであり、キャッシング、非同期タスクの実行、キュー、計算は膨大な数のサーバーで実行されます。 その結果、これらのシステムのいずれかの部分に障害が発生すると、ユーザーがカウンターで誤った値を見ることになります。
皮肉なことに、ITのシステムの複雑さが、携帯電話の一部のアプリケーションの壊れた赤いカウンターに常に注意を向けている。