laravel - 企業の内部システムアーキテクチャ設計に関する設計上の問題

Question

同社は現在約500人の従業員を抱えており、いくつかの管理システムの導入を検討しています。
HRMS (基本的な従業員情報を保存し、いくつかの基本的な人事プロセスも含む) はすでにオンラインになっています。これは、Laravel5.2 に基づいて開発されており、当初の設計時にはそれほど期待していなかったので、フロントとの間で緊密に結合されています。そしてバックエンド。
今度は、これをすべてのシステムの基礎として使用したいと思います。つまり、他のシステムが認証を必要とする場合、HRMS からユーザー情報を取得します。

目標:

1. Lumen で HRMS を書き換え、API のみを提供

2. すべてのシステムでフロントエンドとバックエンドの分離を実現

3. 将来的には Electron API を使用していくつかのデスクトップ アプリケーションを作成する予定です

4. すべてのプロジェクトが Docker 化された持続可能な統合を実現します

今後リリースされるシステムは次のとおりです:

• MRBS: 会議室予約管理システム

• SCRM: ソーシャルプラットフォームに基づく顧客関係管理システム

• BPM: ワークフローの承認

• TMS: 社内トレーニング管理システム

• AMS: 固定資産管理システム

現時点では、サービスは Docker 化されており、バックエンド フレームワークは Lumen を使用することが決定されています。フロントエンドとバックエンドが完全に分離されている場合、その利点は何ですか。 OAuth2.0 と JWT を使用することの短所は何ですか?

Answer 1

下剤;
私の提案は、引き続きlaravelを使用することです;
それがインターフェイス用である場合、5.2はリファクタリングにlumenを使用する代わりに、dingoパッケージhttps://github.com/dingo/apiを使用できます;
lumenとlaravel は兄弟です;
しかし、lumen は多くの機能を取り除き、そのリソースは laravel よりもはるかに少なくなっています。
laravel5.2 を 5.3 にアップグレードすることも、lumen を使用してリファクタリングするよりも合理的です。

5.3 には API インターフェイスの開発がすでにネイティブでサポートされています

これは明らかに、その後の laravel アップグレードの開発傾向です。
OAuth2.0 と JWT については、両者の間に比較はありません。
JWT は承認フレームワークです。

OAuth2.0 はより標準化され、広く使用されており、より拡張性があります

十分な時間があれば、OAuth2.0 の使用方法を学ぶことにもっと時間を費やしてください。