ウェブサイトのアーキテクチャはノーバックエンド ソリューションを採用

ウェブサイトのアーキテクチャにはnobackendソリューションを採用しています
現在のアプリケーション開発モデルはバックエンド構築に重点を置きすぎているため、Brothers in Arms の創設者である Li Chao は、バックエンド開発の簡素化に長年取り組んできました。 UX にもっと注意を払う現在の環境 ——バックエンドはなく、PHP トレーニングフロントエンド開発が優先されます。
つまり、Web、ios、androidは単なるプレゼンテーション層であり、永続化の操作はまとめてAPIに任せられています。
現時点ではテンプレートのレンダリングを無視します。これをフロントエンドに置くことができます。
現在苦労しているのは、Webセッションとアプリトークンの問題です。
この API はトークンを通じて検証されるだけでなく、Web リクエストが行われたときにユーザー セッションも行います。
ユーザーセッションがある場合、トークンを検証する必要はありません。
このアプローチには何か制限やデメリットはありますか?
バックエンドphp..


返信内容:
もちろんそれは可能ですし、私は成功例をたくさん持っていますし、業界にもたくさんの事例があるはずですが、中には欺瞞的なものもあれば、あるがままに見えるものもあるが、実際はそうではありません。
そうは言っても、上級アーキテクトがいるかどうかは、あなたが本当にお金に余裕があるのであれば、このアーキテクチャの実現可能性を証明するために .NET を使用しても構わないと思います。 (PHP は好きではありません、ごめんなさい)
もしあなたがトークンとセッションの問題で本当に悩んでいるとしたら、それはあなたがこの構造を扱える能力がないか、プレイしたことがなくてどっちなのか分からないからです。実現可能かどうかの答えは「はい」です。 あなたが話しているノーバックエンドとは、PHPやJSPなどのテクノロジーを使用したくない従来のアーキテクチャを指し、その種のアーキテクチャは、セッションに大量のユーザーのビジネスステータスを配置し、サーバー側でロジックを記述することになると理解しています。ページを更新するか、バックエンド サービスを操作します (データベースの更新など)。
私の個人的な経験に関する限り、ページの更新とユーザーの現在のステータスをフロントエンドに配置できます。バックエンド API はステートレスなサービスのセットです。これは実際には非常に一般的なアーキテクチャです。
（問題の説明からわかるように）より厄介な部分はセキュリティの側面です。
ネイティブ クライアントの場合は、ネイティブ APP の方が安全であると考えられるため、oauth 暗黙的付与タイプ、つまりトークンがクライアントに直接配置されることを検討できます。
ウェブの場合、トークンをクライアントに直接置くのはより危険ですが、従来の方法（oauth認可コードグラントタイプを含む）ではセッションにトークンを置く必要があります。
実はこの問題を解決する方法があります。しかし、最初に自問したほうがよいでしょう。本当にセッションレスになりたいのですか? 実際、システム アーキテクチャ全体に関する限り、セッションを完全に削除するのは一般に困難です。ただ、プログラミングのビジョンでセッションを使用しないだけです。 。合理的な使用には何の問題もありません。原理主義に関与しないでください。トークンのみがセッションに配置されている場合、サーバーがクラッシュした場合、アプリケーションがそれを適切に処理し、フロントエンドのビジネス ステータスを維持できると仮定すると、それはユーザーに再度ログインして前のページに戻るように要求するだけです。続ける。たとえば、オンライン モールでは、ユーザーがショッピング カートに商品を入れてバックエンドがクラッシュしても、再度ログインするだけで買い物の記録が残り、操作を続行できます。これは大まかな説明であり、具体的な詳細はビジネスのニーズに応じて決定されますが、私の言いたいことは理解できるはずです。 この記事「Lift, State, and Scaling」は、言語に関係なく読むことができます。考えられるのは、フロントエンドで多くのことを実行するための成熟したツールがないため、多くのホイールを自分で構築する必要がある可能性があり、最終的にはビジネス www.itxdl.cn の速度が低下することになります。 簡単に言えば、
1. バックエンドはRest APIを提供し、ログイン認証用の/verifyを提供し、その後の操作には認証情報が必要です
2. フロントエンドは ember/angular を通じて Web アプリにされ、残りの API を消費するために ajax を使用します。実際には、Cookie は使用せず、毎回ログインするだけです。なぜなら、あなたはすでに Web アプリだからです。
3. セキュリティが必要な場合は、https にアクセスしてください。Cookie を回避できるのであれば、js API を直接使用することは回避できると思います。認証の問題は解決するのが難しく、秘密はブラウザにダウンロードできません。暗黙的な認証のみを使用できますが、ほとんどのサービスではどちらもサポートされていません。 。 。 これまでに行われたバックエンド ソリューションはありませんか?私の記憶ではかなりの数のケースがあります。
バックエンドがないということは、API実装もバックエンドのような技術ではないでしょうか？今から開発するのに基本的には難しいことはありません。 質問者の問題は、サーバートークンとWebセッションの違いを理解していないことかもしれません。実際、大丈夫です。インターフェイス サーバーとの通信はトークンである必要があり、Web 側のセッションは、最初にサーバーのアクセス許可を確認した後、Web 側で生成される必要があります。


プロセスを見てみましょう、
例としてのユーザーログイン
1. ユーザーがログインし、認証情報をAPIサーバーに送信します
2.サーバーはOKを検証し、検証に合格したことを示すトークンを返します
3. Web側でログインセッションを作成し、現在のログイン状態で取得したトークンを記録します
4.ログイン後、アプリページにジャンプします
上記の後、ユーザーは自分のクーポン情報を見てください
1.ログイン時にWebセッションに保存されたトークンとユーザー名、その他の情報を取得し、クーポンインターフェイスを呼び出します
2.クーポン情報に戻る
このプロセスでサーバーは 2 つのことを行いました
1. トークンの正当性（存在、有効期限、ソースなど）を検証します
2. 合法であれば、サービスを呼び出すとクーポン情報が返されますが、そうでない場合はエラーが報告されます。
ここで、セッションはWeb側のプレゼンテーション層によって使用され、トークンはインターフェイスサーバーのセッションであることがわかります。レベルを明確に区別すると明らかです。
注: www.itxdl.cn Web サイトには、noBackend モードを使用して開発を開始するのに役立つ一連のバックエンド ソリューションがリストされています。