みんなのお気に入りのREST、STATEless、CRUD、CGI、FastСGI、MVCから旧石器時代の技術に戻る

「ドグマの死によって初めて科学が始まります。」
//ガリレオ・ガリレイ

「私は奴隷をvy望し始めました。 彼らは事前にすべてを知っています。 彼らには強い信念があります。」
//ユージン・シュワルツの劇に基づいたマーク・ザカロフの映画「キル・ザ・ドラゴン」

数年と1日が過ぎたので、新しいプロジェクトを始めた人から聞いたり読んだりすることはありません。 「REST APIとMVCのサーバーエンジンを使って送信してください 。 」 最初は、これらの単語には1つのソースがあり、すべてのストアに配信される本や、検索エンジンの最上部のどこかに開発者をゾンビ化する記事があると考えました。 彼らがRESTとMVCによって理解していることを彼らから見つけたなら、あなたは心に傷つけられます。 MVCですべてが明確になっています。これについては長い間書きましたが、何も変わっていません。悪化しているだけです。GoogleImagesに「mvc」と入力するだけの価値があります。 RESTについては、彼らは次のように答えます：まあ、ブラウザのGUIとモバイルアプリケーションからサーバーメソッドを呼び出す必要があります：たとえば、 setUserCity（userId、cityId）またはcalculateMatrix（data）またはstartVideoConverter（options、source、destination）重い負荷とRESTアーキテクチャがすべてを解決します。 次に、まだ正しい信仰で燃えていて、戦いに熱心で、この世界で何が起こっているかを正確に知っていた人々のために、すでに目が丸くなっている質問をします。 これで、私たちがあなたと一緒にいる震源地で、 用語の大惨事を検討することができます。

MVCに関する質問

最初の質問： 「MVCとは？」の図を描いてください。 私が得るもの：

MVPにとっては、このような理解とスキームでも十分であり、疑うこともありません。

2番目の質問：ユーザーインターフェイス用に設計されたこのパターンをサーバーにどのように適用できますか？
ここにすべての可能な答えをリストすることはできません。 しかし、正しいものは非常にまれであり、このようなものです：MVCサーバーでは、ユーザーインターフェイスがサーバーに完全に実装されている場合にのみ可能です。 ブラウザコードはありません。インターフェイスはサーバー上で生成され、ブラウザは単にそれを表示します。

3番目の質問： MVCとRESTをどのように組み合わせましたか？
私は抵抗することはできません、私は一般的なオプションを公開します：

• まあ、私たちはMVCをRESTを使用して実装しています
• まあ、MVCを使用してRESTを実装しました

これについてコメントすることはできません。 用語の大惨事を扱っていることは完全に明らかですが、それについては後で詳しく説明します。

RESTに関する質問

最初の質問：まあ、私の親愛なる人、これらのsetUserCity、calculateMatrix、startVideoConverterをRESTに実装するにはどうすればよいですか？
私の答え：RESTのポイントは、ファイルごとに固有のURLを持ち、GET、PUT、POST、DELETEというHTTPメソッドのみがこのファイルで生成できることです。 したがって、これらすべてのsetUserCityをHTTP POST / user / idに置き換えて、シリアル化されたユーザー全体をそこに送信してください。 または、別のオプションとして、ユーザーパラメータごとに個別のURLが必要です。 明らかに、HTTPメソッドを介して呼び出されるCRUDメソッド（作成、読み取り、更新、削除）は、データベース内のファイルまたはオブジェクトを操作するのに十分です。 たとえば、フォームとフォームを入力するには、それらをテーブルに保存し、さらに削除して編集します。 しかし、最新のアプリケーションをこのような原始的な課題に減らすことはできません。 そして、ほとんどの場合、開発者はRESTによってその正反対-RPC （リモートプロシージャの呼び出し）、CRUDだけでなく必要な数のメソッドを作成できる場合、および1つのURLがどのユーザーに応じて完全に異なる回答を提供できるかを理解します彼は、どのようなパラメーターで、どのような順序で呼ばれました。 これはまったくRESTではありません。たとえば、Habrはhttp://habrahabr.ru/tracker/で私たちそれぞれに異なるリストを提供しており、これはGoogle、Facebook、Githubなどのどこにでもあります。 したがって、誤解を招くRESTワードを削除し、APIを実行すれば完了です。

2番目の質問：わかりました、あなたにとってRESTとは何ですか？
ここでの意見の範囲はMVCほど広範ではありませんが、 用語の大惨事はこれです：上記で示したように、RESTはRESTとしてまったく理解されていませんが、RESTに関する独断的な文献を研究し、RESTをサポートするフレームワークを探して、その結果、RPCとRESTのハイブリッドが登場します。 そして最悪なことに、これはすべて無意識に起こります。

3番目の質問： RESTがどの程度正確に負荷を軽減するかを説明できますか？
私の答え：それはSTATElessですが 、それは何を意味し、なぜサーバー上の状態を放棄する必要があるのか​​-以下で説明します。

STATElessの意味は何ですか

スケーリングする場合、 最新の Webサーバーはリクエストごとに個別のプロセスを生成します。 これらのプロセスがSTATElessである場合、システムが1台のサーバーで実行されているか、100台のサーバーで実行されているかに違いはありません。 各プロセスはCGIプロトコルを介してリクエストデータを受信し、メモリを割り当て、その中にデータ構造を展開し、必要に応じてデータベース接続を作成し、ファイルを読み取り、外部モジュールを呼び出す必要があります。 その後、プロセスはその論理を実現し、この経済はすべて消滅します。 このようなプロシージャはHTTPリクエストの実行を遅らせるため、常に実行されるプロセスを提供し、作成、メモリのプライマリ割り当て、プロセスの解放と終了にかかる時間を節約するFastGIがあります。 FastCGIでは、データベース接続やその他の記述子を再利用することもできます。 ただし、各HTTPリクエストの処理に必要なメモリ構造はまだ長続きせず、消滅して作成され、同時にデータベースおよびファイルと外部モジュールのクエリが繰り返し実行されます。 ただし、この場合、次のHTTP要求がどのプロセスに該当するかは不明であるため、STATElessの原則に従う必要があります。 また、異なる要求は異なるアプリケーションサイトに関連付けることができ、1つのアプリケーションでさえ、異なるセッションを参照したり、非常に異なるデータ構造のメモリへの展開を提供したりできます。

旧石器時代後期のプログラマーに幸福が訪れた

私のプログラミングの世界観が発展していた頃（1997-2002）、主流は3層アプリケーションアーキテクチャ （ウィンドウクライアント、アプリケーションサーバー、DBMS）でした。 また、クライアントはRPCを介してアプリケーションサーバーとやり取りしました。 すべてがSTATEfulでしたが、多くのマシンでアプリケーションサーバーのスケーリングを必要とするようなタスクはありませんでした。 そのため、2002年から2012年まで長年にわたって、RESTとSTATElessに耐え、負荷の高いシステム向けの本格的なSTATEfulプログラミングとRPCを夢見てきました。 現在、ほとんどの言語とプラットフォームにNode.js、PythonのTwisted、Ruby Event Machineなどの独自のイベントループソリューションがある場合、私は完全に幸せな人のように感じ、STATElessが必要な理由や「 REST APIおよびMVCのサーバーエンジンを使用して、それを動かしてみましょう 。 」

状態のある負荷の高いアプリケーションサーバーを作成することが可能になったため、プロセスの寿命が長くなり、すべてのデータ構造をメモリに残し、データベース接続、キャッシュ、タイマーを残し、メモリに複雑なモデルを展開して、1か月間そこに置くことができます。 また、このモデルを使用すると、クライアント部分はAPIを介して対話できます。 そして今、少し算術です。ユーザー状態が32Kbで、16GBのメモリがあると想像してください。これは524288（50万人以上）ユーザーに十分です。

解決すべき唯一のことは、1つのセッションに関連するすべてのリクエストを同じプロセスに送信する方法です。 つまり、セッションをサーバーとプロセスに「固定」する必要があります（プロセスは多くのサーバーのいずれかに存在できます）。 このために、 IPスティッキング （ip-sticky）およびcookie（cookie-sticky）を実装するハードウェアおよびソフトウェアバランサーがあります。 もちろん、各プロセスは、そのような識別子を持たないすべてのリクエストに、その識別子が付いたCookieでマークする必要があります。 識別子がある場合はスティッキングが機能し、ない場合はラウンドロビンまたはより複雑なバランシングアルゴリズムが機能します。

そして、MVCではまだ完了していません

MVCは全員に、モデル、ビュー、コントローラーを分離すること、そしてそれが必要な場所と必要でない場所を考えずに教えることを教えました。 しかし、各コンポーネントに関する共通の理解はまだ確立されていません。 モデルにパラメーターのみを残し、メソッドはコントローラーに転送されますが、一部のモデルではデータベースから自分自身を保存および復元する方法を知っていますが、他の人はこのアプローチの猛烈な反対者であり、データベースにアクセスするために別のデータアクセスレイヤーを割り当てます。 いずれにせよ、 用語的な災害に対して何かをする必要があります。

科学および技術で使用するのが慣習であるため、 「モデル」という言葉を使用することを提案します。つまり、実際のシステムおよび/またはプロセスの簡略化された表現です 。 モデルにはパラメータとメソッドが含まれることがあります。 ただし、これらのメソッドは定義に適合する必要があります。 たとえば、CRUDメソッドは実際のオブジェクトのモデルの一部にすることはできません。実際のオブジェクトはそれ自体を作成または削除できないためです。 CRUDはモデルの一部ではなく、ストレージレイヤーAPIの一部であり、描画メソッドはグラフィックスレイヤーAPIの一部です。 モデルは、そのストレージ、ネットワーク上の伝送プロトコル、ブラウザのレンダリング機能などについて何も知らないはずです。 モデルのメソッドの良い例は次のとおりです。SteppingMotor.setSpeed（x）モデルが物理デバイスドライバーである場合、または物理デバイスのモデル化に使用される場合。 別の良い例は、Equation.calculateRoots（）のような数学モデルです。 3番目の例は情報モデルです。たとえば、Patient.assignBed（bedId）です。

「ビュー」と「コントローラー」という言葉は可能な限り避けられますが、それは、個々の開発者の頭の中では、完全に予測不可能で奇妙な意味を持つことができるからです。 代わりに、「テンプレート」、「コントロール」（または「ユーザーインターフェイスコントロール」）、「リクエストルーター」などのより具体的な概念を使用することをお勧めします。

旧石器時代後期のアプリケーション開発のヒント

イベント指向のソリューションのうち、私は個人的にNode.jsを使用していますが、これらは普遍的なものにできると思います。
1. RPCおよびSTATEfulの原則に従ってクライアントとサーバー（ブラウザーアプリケーションとネットワークAPI）を分離し、セッションをプロセスに接着します。
2. RAMを使用し、絶えずデータベースにアクセスしないでください。 STATEfulは、高速ループアプリケーションを作成する絶好の機会です。これは、イベントループフレームワークが非ブロッキングI / Oを必要とするからではなく、メモリを正しく使用するためです。 I / O操作のほとんどはクエリ処理中に行う必要さえありません。読み取りはプロアクティブかつ並列に行うことができ、書き込みは遅延します。 STATEfulプロセスで長く幸せな人生を送るアプリケーションのメモリにデータを展開し、ハッシュ、オブジェクト、アレイを構築します。
3.異なるプロセス間で、ZeroMQ（および他のMQ）、TCP、HTTP、IPC、およびその他のあらゆるものを介して対話します。 したがって、さまざまなプロセスのデータは、それがどのような種類のデータであるかに応じて、メモリ内で複製（共有データの場合はキャッシュ）するか、「スティッキー」セッションに分割するか、プロセス間通信を通じて相互に同期できます。

おわりに

毎回デザインパターンを再考します。 他の人の決定を彼らの権威のためだけに取らないでください。彼らは悪いことではないかもしれませんが、あなたの場合はそうではありません。 意思決定は可能であり必要ですが、完全な消化と理解が必要です。
プロジェクトを開始する前に必ず同僚と用語を確認し、パブリックドメインで辞書が作成されるまでそれを調整してください。 私たちの時代に蓄積された概念の混乱により、たとえ同じ言葉を使っていても、あなたが同じことについて話していると確信することは不可能です。

UPD：以下のコメントは、 用語災害の最良の証拠です。 RESTとMVCが何であるかだけでなく、 ステートレスとステートフルが何であるかについても、一般的な理解はありません。 さらに興味深いことに、一般に「条件」が何であるかについての一般的な理解はありません。 誰かがこれをプロセスの状態 （そのメモリ）、誰かがすべてのサーバーの状態（その状態が別のプロセスに存在する可能性がある）、誰かがシステム全体の状態 （そしてデータベースに保存されたファイルとデータも状態と見なすことができる）として理解しています。 そのような状況では、甘やかされた汚い古い用語を捨てる方が良いです 。その意味は、新しい用語に同意して導入するという希望はまったくありませんが、すでに厳密な辞書定義を作成しています 。 そうでなければ、話すことはまったくありません。1語だけを話す対話を構築することは不可能ですが、まったく異なる概念についてです。