node.js - FeatherJS 認証のニーズの評価

Question

同僚と私はチャット アプリケーション (ReactJS <-> NodeJS) を構築したいと考えており、そのために最適なフレームワークを探していました。FeathersJS は、間違いなく最も安定した機能豊富な socket.io ラッパーのようです。

ただし、アプリケーションをスケールアップできるようにするため、このチャット機能をメイン ノード バックエンドとは別のノード プロセスに分割することにしました。

ただし、チャット機能には引き続き認証と承認が必要であり、2 つのサービスの認証が重複することは避けたいと考えています。したがって、解決策として、メインノードのバックエンドにセッ​​ション Cookie を照会して、チャットサービスを使用させる前にユーザーを認証します。

FeathersJS は長期的なソケット接続を確立しますか?それとも、送受信されるすべてのメッセージに対してソケット接続を確立しますか? 最初のケースでは、アーキテクチャを続行できますが、2 番目のケースでは、メインのバックエンドで高い負荷が発生するため、レビューする必要があります。

ありがとう！

Answer 1

サービスを分割するにはいくつかの方法があり、それぞれに利点と欠点があります。Feathers にとって一般的に重要なことの 1 つは、JSON Web トークンだけでセッションが存在しないことです。JWT はステートレスであり、同じシークレットを共有する任意のサーバーで読み取ることができるため、中央のセッション ストアは必要ありません。私が考えることができる2つの主なオプションは次のとおりです。

1. 承認を処理し、接続されているすべてのクライアントを管理するメイン アプリケーションを用意しますが、データベースと対話するサービスを用意する代わりに、内部ネットワーク内の個別のシンプルな API サーバーに接続します。これはセットアップが簡単で、利点は、内部 API サーバーが非常にシンプルであり、認証をまったく必要としないことです (メイン アプリケーションはすべてを実行でき、認証されたユーザーの制限に従ってクエリを実行するため)。欠点は、メイン アプリケーションが依然としてボトルネックであることです (ただし、基本的に内部 API へのプロキシとして機能するため、負荷が減少します)。

2. すべてのクライアントは、JWT を使用して必要なすべての API サーバーに接続します。JWT は、別個の認証 (またはユーザー) API によって作成されます。これは、よりスケーラブルなソリューションです。唯一のボトルネックは、共通のユーザー サービスから最新のユーザー情報を取得することです (必ずしも必要ではない場合もあります)。欠点は、クライアント側での管理がより複雑であり、すべてのサーバーで認証 (少なくとも JWT の場合) を構成する必要があることです。ただし、JWT はステートレスであるため、共有セッションは必要ありません。