Yandex.Money Node.jsスクールの立ち上げの前夜に、このプラットフォームがフロントエンドで定着した理由についてもう少しお話ししたいと思います。

数年前、Yandex.Moneyで、フロントエンドサーバーレイヤーのプラットフォームの変更が急増していました。既存のプラットフォームの変更は社内の独自開発であり、サポートと沈下が不十分であるため次第に消えていきました。 実行時の遅い作業と、APIが機能するXSLTの開発の欠如とともに、多くの制限のあるこの「ブラックボックス」が置き換えられるようになりました。

「フロントエンド」とは、ブラウザで実行されるコードだけでなく、データ収集とHTML生成のためのサーバー層も意味します。 既存のロジックの適切な代替はNode.jsでした。

Node.jsを選ぶ理由

Node.jsは、従来のスレッドベースの並列化モデルの代わりに、イベント指向システムの原則を使用します。「接続ごとに1つのスレッド」アプローチと比較して、コードはよりシンプルで高速です。 Node.jsは、その広範なNPMリポジトリ、印象的な開発者コミュニティ、クライアント、サーバー、およびツールの開発にJavaScriptを使用する機能のおかげで人気を博しました。 一般的に、私たちのチームはこれらすべての利点を気に入っていたため、選択は明白でした。

Yandex.MoneyフロントエンドはクライアントとNode.jsの組み合わせであるため、ユーザーが直接やり取りする、または到達できるすべてのものは、フロントエンド開発者の視野で見ることができます。 同時に、「厚い」ビジネスロジックは、Node.jsアプリケーションにパブリックHTTPベースのAPIを提供する個別のバックエンドコンポーネントに存在します。 バックエンドはページとフロントエンドコンポーネントの本質については何も知りませんが、ユーザーエンティティ、支払い、設定などを操作します。

新しいテクノロジーへの移行の追加ボーナスのうち、開発者を再トレーニングする必要はなく、ツールコードをサポートできるのは1人だけではありません。

フロントエンドでの新しいフレームワークの定着方法

支払いシステムの特徴は、Node.jsが最初に開発された負荷だけです：複雑な同期計算なしで、多くのI / O操作（着信要求とバックエンドへのアクセス）と1クロックサイクルでのわずかな作業です。 結果は、操作が長時間ブロックされることのない「ライブ」イベントサイクルです。

Node.jsアプリケーションでユーザーリクエストを処理するロジックを検討してください。

1. Node.js上のHTTPサーバーは、ユーザーからの着信要求をリッスンします。

   
   
   
   
   
   
   

2. また、リクエストからのデータも処理します。Cookieの解析、投稿リクエストの本文の解析、リクエストに関する情報の記録など。

   
   
   
   
   
   
   

3. さらに、URLはその処理ロジックにリダイレクトされます。

   
   
   
   
   
   
   

   1. そのプロセスで、ページに必要なデータが要求され、それらの集約とその後のビジネスロジックの実行が行われます。

      
      
      
      
      
      
      
   2. サーバーは、収集されたデータからHTMLをレンダリングするか、クライアントへの別の適切な応答（たとえば、json、バイナリファイル、リダイレクト）を生成します。
   
   
   
4. Node.jsサーバーは一般的な応答ヘッダーを設定し、応答をクライアントに送信します。

リクエスト処理のロジック全体を実装するには、一般的なNode.jsフレームワークであるExpressを使用します。 また、内部アプリケーションにはKoa 2が使用されます 。これにより、 Async Functionsを使用してリクエスト処理のフロー全体を記述できます。これは、JavaScriptでの非同期コードの記述を大幅に簡素化する新しいJavaScript機能です。

さらに、Koa 2はNode.js 8がLTSになったときに外部アプリケーションに表示される可能性が高いため、実稼働サーバーにインストールできます。 V8エンジンが新しいTurboFanコンパイラーで使用されるのは8番目のバージョンであり、これにより非同期機能が最適化され、実稼働で使用できるようになります。

V8開発者Benedikt Meurerによる記事の翻訳から、V8と新しい最適化コンパイラーについて詳しく知ることができます。

js、css、picturesなどの静的ファイルはNode.jsサーバーに配布されません。これにはNginxなどのより適切なWebサーバーがあります。 さらに、Nginxはより柔軟なキャッシュ管理を提供します。 したがって、実稼働環境では、Node.jsアプリケーションの前に特別なWebサーバーを配置することをお勧めします。

Node.jsはアプリケーションのJavaScriptコードをシングルスレッド方式で実行しますが、特にコアが多数ある場合、1つのスレッドですべてのユーザーリクエストをプロダクションで処理するプロセスを開始するのは無謀です。 したがって、クラスタリングを使用します。つまり、メインマスタープロセスから個々のNode.jsプロセス（ワーカー）のプール全体を生成します。

メトリックスとグラフィックス

他のすべてのサービスと同様に、フロントエンドは監視に接続されており、その主要なインジケータはすべてチームの多数のダッシュボードにリアルタイムで表示されます。 チャートを見るのは、リリース日やハードウェア構成などで特に魅力的です。

GraphiteとPrometheusはメトリックの収集に最適で、 Grafanaは収集されたすべての視覚的な表示を担当します。

チームはオフィス内でぶらぶらしていて、チームはそのメトリックに関心のあるグラフを表示しています。

フロントエンドシステムの主要なインジケーターのダイナミクス。

フロントエンドチームには独自のダッシュボードもあります。次のグラフがリアルタイムで表示されます。

• すべてのページのHTMLレンダリング時間。

  
  
  
  
  
  
  

• 着信リクエストの数。

  
  
  
  
  
  
  

• 着信リクエストの処理時間。

  
  
  
  
  
  
  

• 応答内の5xxおよび4xxステータスコードの数。

  
  
  
  
  
  
  

• すべてのコールのバックエンドへの発信リクエストの実行時間。

  
  
  
  
  
  
  
• バックエンドへの失敗した発信リクエストの数。

なぜこのすべてが独立したテレビなのか？ まず、メールを常に見て通知に従うわけではありませんが、ここではすべてが目の前にあり、ラップトップの電源を入れる必要さえありません。 第二に、朝、昨日の仕事の結果に「固執」することができます。

私たちは何に直面していますか

サーバーレイヤーのプラットフォームとしてNode.jsを選択したことは、多くの利点に加えて、開発者にとってある程度の頭痛の種でした。

たとえば、私たちのような大規模なアプリケーションでは、テストやドキュメントが十分に網羅されていても、各更新は簡単ではありません。開発者が自分自身を満足させるか、製品を改善したいという欲求だけでなく、JavaScript開発の現実の世界からも常に変化の過程にあります。

Node.jsはJavaScriptのC ++コードのバインディングと組み合わせて使用​​しますが、既存のインフラストラクチャのために拒否することはできません。 Node.jsをアップグレードするたびに、移行ガイドの更新という標準的な困難だけでなく、Node.jsの次のバージョンであるlibxml、libxslt、および内部C ++ライブラリをサポートするためのバインダーの更新も発生します。

一般に、バインダーへの依存は追加のサポートオーバーヘッドをもたらすため、それらを回避する方が良いです。たとえば、内部バインダーを別のHTTPサービスに転送しようとします。

別の話はNode.jsの非同期性であり、それでも「調理」できる必要があります。 たとえば、ある時点で、ExpressとKoaのすべてのロジックコードはエラートラップでラップされ、インターセプトする必要がありますが、ビジネスロジックエラーが原因で作業中のワーカーがクラッシュして再起動することが時々ありました。 つまり、ルートのハンドラーに記述されたビジネスロジックは、Node.jsプロセス全体を停止するべきではありませんが、とにかくそれを行いました。

状況の分析により、奇妙な特徴が明らかになりました。 コールバック関数がprocess.nextTickに渡されると、エラーキャッチコードを含む現在のサイクルの残りのコードが実行された後、非同期サイクルの現在のサイクルで開始されます。 そのような関数の内部で例外が発生した場合、process.nextTickは「次のメジャー」ではなく、現在のメジャーの終わりであるため、キャッチできませんでした。

ES2015にはまだ微妙な点があります。すべてのクライアントコードはBabelのトランスピレーションを通過するため、ES2015標準だけでなく、言語のあらゆる革新を使用できます。 しかし、Node.jsにはそのような優れたサポートがなく、多くの機能が欠けています。また、Babelを介してサーバーコードを実行することは、コードのサポートとビルドにおいて大きな頭痛の種です。 したがって、JavaScriptコードを記述するときは、このコードが実行される環境を常に念頭に置いて、リンタールールを別々に構成する必要があります。

使用するモジュールを選択する「洗練された」プロセスは、難易度の高い快適なチェリーと考えることができます。 もちろん、特定の応用分野のリーダーは認められていますが、その中でも、特定のケースごとにより適切なリーダーを合理的に探すことができます。 はい、ロジックのレビューの数は増えましたが、Node.jsとNPMは、オープンモジュールの選択肢が豊富であり、テクノロジに適合せず、便利なものを使用できるため、優れています。

共有してみませんか

もちろん、最新のテクノロジーへの移行の過程で困難に直面し、バンプを埋めましたが、これはすべて、クライアントとサーバーの単一言語だけで終わらない貴重な経験と利点をもたらしました。

このすべてをゼロから蓄積するのは長くて非生産的であるため、私たちのチームはNode.js開発スクールを立ち上げ、経験を共有することにしました 。 トレーニングは2017年9月18日に開始され、参加申請書は現在提出できます。

トレーニング中に、次のトピックを扱います。

• Webサーバー：作業の種類と原則。

  
  
  
  
  
  
  

• Node.jsでのデバッグとロギング。

  
  
  
  
  
  
  

• テンプレートエンジンとHTMLのサーバー側レンダリング。

  
  
  
  
  
  
  

• Node.jsでのテスト：単体テスト、統合テスト。

  
  
  
  
  
  
  

• Node.jsでデータベースを操作します。

  
  
  
  
  
  
  
• Node.jsのスレッド。

実際、リストはより長く、学校のページで見ることができます 。 しかし、塩は実際に行われます-13のレッスンで、一緒に銀行カードを管理するための電子財布のサーバーアプリケーションを開発します。

サインアップして、Yandex.Moneyサービス全体の開発者の1人のように感じてください。