昨年12月、iknow.travelプロジェクトでこの市場に参入し、航空券とコンテンツリソースの販売を組み合わせることに賭けましたが、3か月後（2月）にプロジェクトをゼロから書き直すことを決定し、チケット部分も撤回しませんでした。その時点でテストします。
プロジェクト開発戦略の観点からこれが行われた理由については、近い将来別の投稿を掲載します。 次に、 航空券+コンテンツの最初のリリースから旅行デザイナーまでの途中で解決しなければならなかったタスクと使用されたテクノロジーについて説明します （新しいバージョンの開発には3か月かかりました）。
何だった
何になった
何をした
最初に、私たちは目標を設定しました：単一ページのアプリケーションのスタイルでサイトを作りながら、検索エンジンに対してサイトを完全にオープンにしておくことです。 1ページのサイトではSEOが困難です。 このような場合のGoogleは、いわゆるハッシュフラグメントを推奨しています。 一番下の行はこれです：すべてのリンクは「＃！」で始まり、ロボットは「＃！」のみを置き換えます 「？_escaped_fragment = "に、リクエストを作成し、静的HTMLに応答して待機します。 そしてそれは動作します。 古き良き方法を好んだ。 サイトの大部分はHTMLでアクセスできます。これにより、検索エンジンは通常の静的サイトと同じようにページを見ることができます（ただし、妥協はありません）。 確かに、 GooglebotはすでにAJAXを理解しているという噂がありますが、どういうわけか私たちはそれらを信頼するつもりはありません。 また、通常のブラウザーでは、HTML5 PushState（IE 9を除くすべての最新ブラウザーでサポートされています）で作業し、HTML5 PushStateが利用できない場合はハッシュURLへの自動移行を行います。 そして、あなたはどうしますか？
次に、スタックの選択
タスクの言語を選択するのが慣例です。 サーバーフロントエンドの場合、node.jsが最良の選択でした。 このかなり人気のあるプラットフォームにより、コードとパターンをクライアントとサーバー間で分割できました。 JavaScriptは優れた関数型言語です。 しかし、純粋なJSは構文上の砂糖がなく、サポートが面倒なので疲れるので、CoffeeScriptを使用します。
バックボーン
私たちのクライアントはバックボーンに基づいて書かれています。 バックボーン-対話型アプリケーション用のJSフレームワーク。 すべてが4つの概念に基づいて構築されています。
- モデル
- 表示する
- 収集
- ルーター
バックボーンでのそれらの解釈は、一般に受け入れられているものとは異なります。 まず、モデルはベースから分離されます。 REST CRUD APIへのバインディングが含まれていますが、 HTML5 LocalStorage WebSockets へのアダプターがあります。 第二に、Viewは通常はまったくビューではなく、通常の意味でのコントローラーです。 用語は純粋に主観的な問題であり、Backboneの著者は直接述べています。 1つのアプローチを選択し、順守することは非常に重要です。 何て言うの？
ちなみに、Backboneから始めるには、これを確認することをお勧めします（Habrに翻訳させていただきます-必要に応じて書いてください）。
モンゴッド
クライアントを構築するテクノロジースタックの選択と並行して、データストレージ用のDBMSを選択するという問題に直面しました。
サブジェクトエリアは私たちにとって新しいものだったので、一度設計したモデルはプロジェクトの開発や開発に合わせて変更する必要がないほど十分に優れているという事実に頼るべきではないことは明らかでした。 NoSQLでは、より高速なクエリ実行速度、複雑なデータのより便利でシンプルなストレージ、および柔軟性が得られることが期待されていました。 基本スキームを繰り返し変更するという理解は、リレーショナルデータベースがプロジェクトのテクノロジースタックに存在する可能性を完全に無効にしました。
NoSQL DBMSのいくつかのバリアントの分析に基づいて、MongoDBを選択しました。これは、幅広い機能と高速の優れた組み合わせのためです。 特に、配列にインデックスを付けるMongoDBの機能、便利なシャーディングとレプリケーション、優れたドキュメントに魅了されました。 MongoDBは、このDBMSと多くの成功したプロジェクトでのそのアプリケーションへの優れたサポートを支持します（完全なリストは、ディズニー、クレイグリスト、フォースクエアなどの巨人です）。
当初、ドキュメント指向のDBMSの特性を考慮してデータストレージスキームを設計しましたが、クエリの実行時間とデータベースサイズの両方を削減するために、データベーススキームを繰り返し変更する必要がありました。 たとえば、投稿の高速フィルタリングを保証するために大きな多次元インデックスをサポートする必要に直面しましたが、クエリ実行速度を最大にするためにデータストレージスキームを最適化しようとすると、インデックスとデータ自体のサイズが指数関数的に増加し、その結果、 RAM要件のため、このようなベースを維持できます。 その結果、インデックスとデータのサイズを過度に大きくすることなく、すべてのクエリの高速実行を保証するかなり美しいソリューションを発見しました。 ただし、現時点では速度とリソース消費の観点で許容可能な指標が達成されているという事実にもかかわらず、プロジェクトの成長に伴い、現在のソリューションを複数回修正する必要があることを理解しています。
結果
最後に何が起こったのか、どのように機能するのかを確認したい場合は、テストのために更新されたプロジェクトをここに投稿しました 。
古いサイトで航空券にアクセスするには（誰かがそこに乗りたい場合）、コードi3n7wt0a8elを使用します。
投稿をどこかに正しく投げたら、どこにいるのか教えてください。 フィードバックを事前に感謝します。 多くの点で、（ホリデーシーズンに間に合うように）すばやく直感的に移動する必要がありました。 同様のシステムが初めて構築されました。 ご質問にお答えします。