多くの場合、次のような質問に出くわします。「そして、大規模/有名/著名なIT企業の誰が一般に実稼働でNode.jsを使用していますか？」 2012年1月19日に、悪名高いJoel Spolskyによって設立されたFog Creekのブログに「The Trello Tech Stack」という記事が掲載されました。 Habrでは、どういうわけか無視されているのは奇妙です。 したがって、この欠点を修正すると同時に、大規模プロジェクトでNode.jsを使用する例を示すために、この記事を翻訳しました。



記事自体は非常に膨大であるため、2つの部分に分かれています。



パート1

• CoffeeScript
• お客様
  
  * Backbone.js
  
  * HTML5 History API
  
  *口ひげ
• プッシュとポーリング
  
  * Socket.ioおよびWebSockets
  
  * AJAXリクエスト

パート2

• サーバー
  
  * node.js
  
  * HAProxy
  
  * Redis
  
  * MongoDB
• 好きですか？

trello techスタック

Trelloの開発は、TrelloチームのデザイナーであるJustinとBobbyが1週間でまとめたHTMLレイアウトから始まりました。 彼の見た目と感じの良さに驚きました。 ダニエルと私がTrelloのプロトタイプと実用バージョンを開発するプロジェクトに参加した後、サーバーとクライアントを作成しながら元のレイアウトの素晴らしい印象を維持することが本当の課題でした。





Trelloの初期レイアウト。



このレイアウトにより、クライアント側のユーザーインターフェイスを作成し、北上でデータの更新を受信する1ページのWebアプリケーションに至りました。 これは、以前フォグクリークで行った作業とは大きく異なりました。 したがって、技術的な観点から、Trelloの開発は冒険でした。



最初は、[プロジェクト]マネジメントが心配する前に、[アプリケーション]の構造がどれほど興味深く多様であるかを驚かせました。 ジョエルとの最初の会議で問題が解決されました。 「。



でした。 私たちは、より成熟した代替品と比較して驚くべき体験を提供する有望な（そしてしばしば問題の多い）技術を一貫して選択しました。 私たちは約1年間これを行ってきましたが、気に入っています。

CoffeeScript

Trelloの開発は、クライアントサイドとサーバーサイドの両方で純粋なJavaScriptで始まり、5月にコーヒーパス上のいくつかのファイルを実験的に書き換えて気に入ったかどうかを確認するまで、この道を守りました。 私たちは本当に気に入っており、すぐに残りのコードを書き直し、CoffeeScriptで完全に開発を続けました。



CoffeeScriptは、 読みやすい JavaScriptにコンパイルされる言語です。 Trelloの開発を開始した時点ですでに存在していましたが、ソースファイルを直接デバッグするのではなく、コンパイルされたコードをデバッグすることによって生じる複雑さがさらに心配でした。 ただし、これを試してみると、変換は非常に高品質であることが判明したため、Chromeでのデバッグ中に最終コードをソースファイルにレンダリングするのに少し精神的な労力がかかりました。 また、CoffeeScriptを使用したときのコードの簡潔さと読みやすさによるメリットは明らかで、説得力がありました。



JavaScriptはクールな言語です。 よく書かれたCoffeeScriptは、同じセマンティクスを維持しながら、JavaScriptをスムーズにして短縮し、デバッグに重大な問題を持ち込みません。

お客様

• Backbone.js （MVCフレームワーク）
• HTML 5 （履歴API：pushState）
• 口ひげ （テンプレート）

本質的に、TrelloサーバーはHTMLでは機能しません。 実際、彼らは多くのクライアントコードを実行しません。 Trelloページは、サーバーからクライアントアプリケーションを1つの最小化および圧縮されたJSファイル（サードパーティライブラリとコンパイル済みのCoffeeScriptファイルとMustacheテンプレートを含む）としてダウンロードする軽量（2KiB）シンシェルと1つのCSSファイル（ LESSファイルと埋め込み（インライン）画像を含む）。 必要なのは250KiB未満で、AmazonのCloudFront CDNと共有しています。 このようにして、ほとんどのユーザーに低遅延のダウンロードを提供します。 かなり高速な接続（高帯域幅）の場合、ブラウザウィンドウで約0.5秒でアプリケーションのダウンロードと起動が行われます。 キャッシュの恩恵も受けるため、Trelloへの以降のアクセスでは、その部分[ダウンロード]はスキップされます。



同時に、開始ページからAJAXを介したデータのロードを削除し、サーバーへのWebSocket接続を確立しようとしています。

Backbone.js

データを含む応答が到着すると、Backbone.jsが動作を開始します。 Backboneのアイデアは、（View）を使用してサーバーから受信した各モデルを表示することであり、Backboneは次の簡単な方法を提供します。

• ビューによって作成されたHTMLのDOMイベントを追跡し、それらをサーバーと同期するモデルのハンドラーにバインドします。
• モデルの変更を追跡し、変更されたHTMLブロックを表示します。

優雅に！ このアプローチを使用して、通常の、理解可能でサポートされているクライアントアプリケーションを取得します。 特に、クライアント側のモデルキャッシュを構築して、更新を処理し、モデルのクライアント側の再利用を簡素化します。

History.pushState

クライアントアプリケーション全体がブラウザウィンドウに読み込まれたので、ページ間を移動する時間を無駄にしたくありません。 HTML 5 History.pushStateインターフェイスメソッドを使用して、ページ間を移動します。 このようにして、ロケーションバー[ブラウザ要素]に正確で一貫性のあるリンクを提供し、移行時に、単にデータをロードし、Backboneに基づいて適切なコントローラに転送します。

口ひげ

モデルをHTMLで表示するには、Mustache（論理構造を最小限に使用するテンプレート言語）を使用します。 「[substitute_here_your_name]テンプレートの全機能を使用する」ことは良いことのように聞こえますが、実際には、明確なコードを維持するために開発者からの厳しい訓練が必要であることがわかります。 Moustacheの「簡潔さは才能の姉妹」アプローチに非常に満足しています。これにより、テンプレートコードをクライアントロジックと混同して混乱を招くことなく再利用できます。

プッシュとポーリング

リアルタイム更新は新しいものではありませんが、コラボレーションツールを作成する際に重要な部分であるため、Trelloのこの部分に時間を費やしました。

Socket.ioとWebSockets

これをサポートするブラウザーでは、WebSocket接続を使用して、サーバーが他のユーザーが行った変更を対応するチャンネルをリッスンしているブラウザーにプッシュするようにしました。 修正された（*） Socket.ioクライアントおよびサーバーライブラリを使用します。これにより、CPUとメモリの使用量を最小限に抑えながら、各サーバーで何千ものWebSocket接続を開いたままにすることができます。 したがって、観察しているボード[Trello要素]で何らかのアクションが発生すると、このアクションはサーバー上のプロセスに転送され、通常1秒未満の最小遅延でブラウザーに配信されます。



（*）現在、Socket.ioサーバーには、複数のプロセスとRedisストレージを使用する場合に、クライアントとの同時接続を10K以上に拡大する問題があります。 また、クライアントには、同じサーバーへの複数の接続が開かれたり、接続が提供されていることをクライアントが判断できないという問題が発生する可能性があるという問題があります。 プロジェクトに戻って、変更を加える際にいくつかの問題があります（ハック！）。多くの場合、WebSockets（使用する唯一のSocket.ioトランスポート）でのみ動作します。 プロジェクトに戻すために、一般的な使用に適した変更に取り組んでいます。

AJAXリクエスト

複雑ではありませんが、機能します。





建築の初期スケッチ。



ブラウザーがWebSockets（hi、IE）をサポートしていない場合、ユーザーがアクティブな間は数秒ごとに小さなAJAX変更要求を行い、ユーザーがアイドル状態になるときの間隔を10秒に減らします。 サーバーの設定により、HTTPSリクエストを最小限のオーバーヘッドで処理し、TCP接続を開いたままにすることができるため、必要に応じて簡単なリクエストを使用した経験を共有できます。



Socket.ioの低レベルのトランスポートを使用してCometを試しましたが、いずれにしてもそれらはすべて不安定でした。 さらに、CometとWebSocketをアプ​​リケーションの主な機能の基盤として使用するのは危険なようです。 問題に出くわした場合、最も単純で最も確立された技術に戻れるようにしたかったのです。



立ち上げ直後に問題に遭遇しました。 WebSocketサーバーの実装は、 TechCranch効果による突然の大きな負荷の下で奇妙に動作し始めました。アクティビティ中および非アクティビティ中にリクエスト間隔を設定することで、単純なリクエストに戻り、サーバーのパフォーマンスを調整できたことを嬉しく思いました。 これにより、1週間でユーザー数が300から50,000に増えたときにパフォーマンスをスムーズに低下させることができました。今ではWebSocketを使用するようになりましたが、短いリクエストの作業システムがあります。



続行するには...