パート1
- CoffeeScript
- お客様
* Backbone.js
* HTML5 History API
*口ひげ - プッシュとポーリング
* Socket.ioおよびWebSockets
* AJAXリクエスト
パート2
- サーバー
* node.js
* HAProxy
* Redis
* MongoDB - 好きですか？
サーバー
Node.js
Trelloのサーバー側はNode.jsに基づいています。 更新を即座に配信する必要があることはわかっていました。つまり、[サーバーへの]多くの接続を開いたままにする必要があるため、イベント駆動型の非ブロッキングサーバーが適切な選択肢のように思えました。 Node.jsは、プロトタイプの単一ページアプリケーションを構築するためのすばらしいツールであることが証明されました。 Trelloサーバーのプロトタイプは、実際には単一のNode.jsプロセスのメモリにあるモデルの配列を処理する関数の単純なライブラリであり、クライアントアプリケーションは小さなWebSocketラッパーを使用してこれらの関数を呼び出しました。 私たちにとって、Trelloの使用を開始し、開発が正しい方向に進んでいることを確認する最も早い方法でした。 プロトタイプバージョンを使用して、Trelloおよび他のFog Creek内部プロジェクトの開発を管理しました。
プロトタイプが完成する頃には、Node.jsの十分な経験があり、その機能とパフォーマンスにショックを受けました。 だから私たちは仕事を続け、トレロ・ピノキオを本当の男の子にしたので、彼に与えました：
- 実際のDBおよびスキーマ（ node-mongodb-nativeおよびMongoose ）
- ルートやCookieなどの基本的なWebテクノロジー（ ExpressおよびConnect ）
- 再起動時にダウンタイムのないサーバー上の多くのプロセス[プロセス]（ クラスター ）
- プロセス間通信（パブリッシュ/サブスクライブ）およびRedis （ node_redis ）を介した構造データの共有
Node.jsは優れており、アクティブなコミュニティが新しい有用なライブラリをリリースするたびに改善されています。 最初に使用を余儀なくされる膨大な数の[およびネスト]コールバックは問題のように思えますが、数週間後にはそれに慣れます。 優れた非同期ライブラリ（およびCoffeeScriptが提供するコードの簡潔さ）を使用して、コードの制御を維持します。 他の洗練されたソリューションもありますが、非同期を使用するだけでよく、その動作は完全に理解されています。
HAProxy
HAProxyを使用して、Webサーバー間で負荷を分散します。 ラウンドロビンサーバー間でTCP接続を配布し、Node.jsは他のすべてを残します。 WebSocketを許可し、AJAXリクエストに接続を再利用するのに十分な時間、接続を開いたままにします。
レディス
TrelloはRedisを使用して、サーバープロセス間で交換するときに使用される短期間のデータに使用しますが、ディスクには保存されません。 セッションアクティビティレベルやOpenID一時キーなどのオブジェクトはRedisに保存され、アプリケーションは、このデータが部分的に（または完全に）失われた後に正常に回復するように構築されます。 与えられたキー「allkeys-lru」と少なくとも5倍必要なワーキングセットで[Redis]を実行します。 したがって、Redisは長期間使用されていないデータを自動的に削除し、必要に応じて復元します。
Redisの最も興味深い使用法の1つは、モデルの変更をブラウザーに送り返すときに短いクエリを使用することです。 サーバー上でオブジェクトが変更されると、関連するすべてのWebSocketにJSONメッセージを送信して、クライアントに通知し、関連するモデルの固定長リストにこのメッセージを保存します。このリストに常時追加されたメッセージの数を記録します。 次に、AJAXリクエスト（WebSocket接続ではなく）を使用するクライアントが最後のリクエストの瞬間からサーバーにpingを送信すると、許可を確認する前にサーバー全体の応答を取得できます。ほとんどの場合、1つのRedis値を確認します。 Redisは非常にクレイジーであるため、1つのCPUで大きなパフォーマンス低下を引き起こすことなく、毎秒数千のこのようなチェックを処理できます。
また、Redisはパブリッシュ/サブスクライブサーバーとして機能し、それを使用して、最初のリクエストを行ったサーバープロセスから他のすべてのサーバープロセスにオブジェクトの変更に関するメッセージを配信します。 構成済みのRedisサーバーがあるとすぐに、あらゆる種類の事柄にそれを使用し始めます。
モンゴッド
MongoDBは、ほとんどのデータベースクエリを満たします。 [サーバー] Trelloを非常に高速にしたかったのです。 最もクールでパフォーマンス重視のチームの1つは、隣にあるStackExchangeパートナー企業です。 ある日、主任デベロッパーであるデイビッドと昼食をとりながら、SQLサーバーを使用してデータを保存していますが、実際には多くのデータを非正規化形式で保存して、パフォーマンスを向上させ、必要です。
今日のトレロ。
MongoDBでは、リレーショナルデータベースの機能（つまり、任意のJOIN）を使用することを拒否して、非常に高速な書き込み、ほとんどの場合、高速な読み取り、非正規化データのサポートの向上を実現しました-カードプロパティ[Trello要素]をデータベースの1つのドキュメントに保存できますネストされたドキュメントフィールドをクエリ（およびインデックス）することができます。 急速に成長して以来、読み取り/書き込みに関してかなりの量の違反に耐えることができるパフォーマンスを持つデータベースを所有することは非常に良いことでした。 また、MongoDBは複製、バックアップ、復元が非常に簡単です（ Foursquareの失敗にもかかわらず）。
一貫性のないドキュメントのリポジトリを使用するもう1つの利点は、データベーススキーマの移行にタンバリンを使用することなく、同じデータベースで異なるバージョンのTrelloコードを簡単に使用できることです。 これには、Trelloの新しいバージョンをリリースする際に多くの利点があります。データベースを更新または入力している間、アプリケーションへのアクセスをブロックすることは非常にまれです。
開発の場合、これは非常に優れています-hg bisect（またはgit bisect）を使用してソースとテストリレーショナルデータベースのバグを検索する場合、データベースをテストバージョンにロールバックまたは戻す（または必要なフィールドを持つ新しいデータベースを作成する）追加手順が必要です。 これにより、作業が大幅に遅くなる可能性があります。
好きですか？
一連のテクノロジーが気に入っています。 Joelが述べたように、開発プロセス全体を通して出血しましたが、ツールやコンポーネントに関連する流血なしに、チームが興味深いアプリケーションを作成するのを見たことはありません。 そして、誰もが彼らがフィニッシュラインに来たものを本当に気に入っていると言うことができるわけではありません。 ほとんどのアプリケーションに当てはまるように、本質的に必要なコンポーネントや実装の詳細はありません。 しかし、この多くの優れたオープンソースプロジェクトが開発を加速し、強固で維持されたコードベースを提供し、それによって集中的に前進し、Trelloをより応答性が高く美しいアプリケーションにしたと考えています。 これらのプロジェクトに参加したすべての人のおかげで、プログラマーになるのに最適な時期です。
それは魅力的に聞こえますか？ Trelloをお試しください！ 無料です。
まだ話が足りない？ 最近の議論のために私が作成した Trello プレゼンテーションは次のとおりです。