laravel - Problèmes de conception liés à la conception de l'architecture système interne de l'entreprise

Question

L'entreprise compte actuellement environ 500 employés et envisage de mettre en place certains systèmes de gestion.
Le SGRH (qui stocke les informations de base sur les employés et implique également certains processus personnels de base) est déjà en ligne, qui est développé sur la base de Laravel5.2. Je n'en attendais pas autant lors de sa conception initiale, il est donc étroitement couplé entre le front. et l'arrière.
Maintenant, je souhaite l'utiliser comme base pour tous les systèmes. En d'autres termes, si un autre système nécessite une authentification, il récupérera les informations utilisateur du HRMS.

Objectif :

1. Réécrivez le SIRH avec Lumen, fournissez uniquement l'API

2. Tous les systèmes réalisent la séparation front-end et back-end

3. Nous utiliserons l'API Electron pour créer certaines applications de bureau à l'avenir

4. Tous les projets réalisent une intégration durable Dockerisée

Les systèmes qui seront lancés ultérieurement sont :

• MRBS : Système de gestion des réservations de salles de réunion

• SCRM : Système de gestion de la relation client basé sur une plateforme sociale

• BPM : approbation du flux de travail

• TMS : Système de Gestion Interne de la Formation

• AMS : Système de gestion des immobilisations

À ce stade, le service a été Dockerisé. Le framework back-end a été décidé pour utiliser Lumen. Si le front-end et le back-end sont complètement séparés, quels sont les avantages et les avantages. les inconvénients de l'utilisation d'OAuth2.0 et de JWT ?

Answer 1

Laxatif ;
Ma suggestion est de toujours utiliser Laravel ;
Si c'est pour l'interface, alors 5.2 peut utiliser le package Dingo https://github.com/dingo/api;
au lieu d'utiliser Lumen pour refactoriser ;
lumen et laravel sont des frères ;
Mais ; lumen a été dépouillé de nombreuses fonctions et ses ressources sont bien inférieures à celles de laravel ;

Même la mise à niveau de laravel5.2 vers 5.3 est plus raisonnable que le refactoring avec lumen ;
5.3 a déjà un support natif pour le développement des interfaces API
Et c'est évidemment aussi la tendance de développement des mises à niveau ultérieures de laravel ;

Quant à OAuth2.0 ou JWT ;

Il n'y a pas de comparaison entre les deux ;
JWT est un protocole ; OAuth2.0 est un cadre d'autorisation ;
OAuth2.0 est plus standardisé, largement utilisé et plus évolutif

Si vous avez suffisamment de temps, passez plus de temps à apprendre à utiliser OAuth2.0 ;