バックエンドがRailsのSencha Touchでモバイルアプリケーションをプログラミングしています。Sencha に深く入るにつれて、2 つをますます分離していることに気付きました: 基本的に、Rails はモデル ストレージ (データベース) としてのみ機能し、Sencha は JSON を介して必要なものすべてをプルします - 再現ロジックの多くはすでにレールに存在しています。
私の質問は、各アプリケーションに機能を委譲することに関して、あなたは何をアドバイスしますか? Sencha アプリに REST を実装して、ユーザーと関連データを通信し、同じ形式で保存できるようにしました。
これはユーザー セッション管理の正しい方法ですか? レールにもっと力を与えるべきですか？IE : セッションをどこに保存しますか? サーバー上でできますか？セッションストレージ管理として行うべきですか? ローカルストレージ？私は知りません。
アドバイスをいただければ幸いです。ありがとう。
これはあなたの質問に対する具体的な答えではありませんが、あなたが正しい方向に進んでいると思うことを付け加えておきたいと思います。
Web は、レンダリングされたドキュメントの 1 つ (サーバーが完全にすべてを実行し、ブラウザーは本質的に愚かでした) から、ブラウザーとサーバーがより対称的なピアになるものへと移行しています。そして、あなたの課題は、2 つの完全な MVC アプリの同期を維持することに関するものになります。 !
(間違いなく、クライアント側のアプリケーションの豊富さに比べて、サーバーがかなり馬鹿げた世界になるかもしれません。これは、何十年も揺れ続けてきたシッククライアント/シンクライアントの振り子の次のサイクルに過ぎないと思います。 -) )
しかし、モバイルの場合、これは単なる恣意的なコンピューター サイエンスの問題ではありません。モバイル デバイスのネットワーク カバレッジは部分的または散発的である可能性が高いため、アプリケーション設計の最終的なテストは、ユーザーがアプリで作業を継続できるかどうかを判断することです。デバイスはオフラインです (たとえば、トンネルに追い込まれます)。その後、ネットワークが再び利用可能になったら、再同期します。リッチで応答性の高いクライアントが唯一の方法です。
そのシナリオでは、ブラウザにセッションを豊富に保存することは妥当なステップのように思えます。実際、単一のクライアントとサーバーの間でセッション状態を同期させる方が、他のタイプのデータ レコード (複数のクライアントによって同時に操作される可能性がある) よりも簡単です。