Présentation de la configuration côté serveur de la séparation front-end et back-end laravel+vue-Laravel-php.cn

Présentation de la configuration côté serveur de la séparation front-end et back-end laravel+vue

藏色散人

Libérer： 2021-06-27 09:14:44

avant

4314 Les gens l'ont consulté

Avant-propos

La séparation du front-end et du back-end a toujours été un sujet que Laravel ne peut pas apprendre. Au début, nous pouvons rapidement créer un système de gestion back-end qui ne nécessite pas trop de code front-end en utilisant l'excellent framework de laravel (tel que laravel-admin, dcat-admin). Mais à un stade ultérieur, à mesure que l'ampleur du projet augmente, nous avons également besoin de services tels que le middle office (qui peut être simplement compris comme un backend de gestion orienté utilisateur), un site Web frontal et d'autres services si nous utilisons toujours le. cadre ci-dessus, cela peut sembler inadéquat. Et dans le développement réel, nous rencontrerons de tels problèmes :

L'entreprise a des ingénieurs front-end et back-end. Les ingénieurs front-end utilisent vue pour développer, et en tant que phpers, nous. utiliser Laravel pour développer. Ensuite, le problème se pose. Nous ne pouvons pas laisser les ingénieurs front-end utiliser également Laravel-mix et développer sous le framework Laravel.
Le modèle original a un degré élevé de couplage et est très difficile à maintenir et à développer. Par conséquent, réduire le couplage entre les modules est très utile pour la maintenance et l'expansion ultérieures. .

Concept clair

Puis à ce moment-là, nous penserons tous à

séparation des extrémités avant et arrière. Alors, qu'est-ce que la séparation front-end et back-end ? Nous ne discuterons pas de la définition spécifique aujourd'hui. Si vous êtes intéressé, vous pouvez consulter ces articles : Qu'est-ce que la séparation front-end et back-end exactement ? , Réflexions sur la pratique de la séparation front-end et back-end
Après avoir compris les concepts et les idées de base, nous devrions commencer à faire les choses. Mais avant de commencer, vous devez réfléchir à
Le projet actuel est-il adapté à la séparation front-end et back-end ? Quels types de projets conviennent à la séparation front-end et back-end ? Parce que si le projet ne convient pas, alors la séparation du front-end et du back-end augmentera sans aucun doute la charge de travail. Par exemple, s'il s'agit simplement du développement d'un système de gestion back-end pur, couplé à un accès à l'interface, le nombre. des visites de projet n'est pas important, alors un modèle tel que laravel-admin peut être tout à fait compétent. Il y aura un malentendu ici, c'est-à-dire que le code front-end et le code back-end sont développés séparément, ce qui signifie que le front-end et le back-end sont séparés (cela semble un peu contradictoire avec ce que est dit plus haut). La soi-disant séparation du front-end et du back-end ne sert pas seulement au découplage, mais aussi à faciliter la maintenance et l'expansion ultérieures. Il s'agit essentiellement de :
Le projet front-end et le projet back-end sont deux projets et. doivent être déployés de manière indépendante. Deux projets différents, deux bases de code différentes, des développeurs différents. Les ingénieurs front-end et back-end doivent se mettre d'accord sur des interfaces interactives pour réaliser un développement parallèle. Après le développement, un déploiement indépendant est requis. Le front-end appelle l'API restful du back-end via des requêtes http. Le front-end doit uniquement se concentrer sur le style de la page ainsi que sur l'analyse et le rendu des données dynamiques, tandis que le back-end se concentre sur une logique métier spécifique (Source : Pourquoi le front-end et le back-end devraient-ils être séparés ? Quels sont les avantages et les inconvénients de la séparation front-end et back-end ?). Donc, en supposant que notre développement local front-end et back-end soit terminé, nous devons le mettre dans l'environnement en ligne pour le tester. Alors, comment pouvons-nous accéder au serveur pour le déploiement et la configuration ?

Recommandations de didacticiel associées : "

tutoriel laravel"

Démarrer

Par exemple, le projet que nous avons terminé est comme ceci :

Le front-end utilise
, le back-end utilise vue pour construire l'interface API et laravel+jwt+dingo est utilisé comme système de gestion back-end. laravel-adminSelon la méthode traditionnelle de configuration du backend, configurez uniquement le système de gestion en arrière-plan. Après avoir installé
en un clic, configurez nginx pour que la racine pointe directement vers le répertoire public du projet, ou utilisez simplement lnmp. Ce sera prêt dans quelques minutes . Pour nous, programmeurs qui parlons arts martiaux, cela s'appelle 宝塔面板 "cliquez jusqu'à ce que ça se termine" . Le backend peut être utilisé directement avec le nom de domaine +/admin. Mais maintenant que nous avons Vue, nous devons utiliser le nom de domaine principal shop.test pour une utilisation frontale. Nous dirons Teacher You, Teacher Niu, Teacher Liu, vous ne suivez pas l'éthique martiale et Teacher You. dit désolé, je vais l'utiliser.
Il existe donc deux façons d'obtenir cet effet :

Essayez

1. Déployez séparément et utilisez des noms de domaine différents.

Le nom de domaine front-end est : vue.shop.test

Le nom de domaine back-end est shop.test/admin
Le nom de domaine de l'interface est shop.test/api
J'ai juste besoin pour aller dans le répertoire racine de nginx dans le projet front-end Pointez simplement sur le dossier cible, par exemple :

server{
    listen 80;
    server_name vue.shop.test;#域名
    index index.php index.html index.htm default.php default.htm default.html;
    root /www/wwwroot/vue.shop.test/dist;#根目录    ...}

Copier après la connexion

Proxy inverse vers l'adresse de l'interface :

#意思就是只要含有"api"的请求，都转发到接口地址去请求
location /api    {
        add_header 'Access-Control-Allow-Origin' '*';
        proxy_pass http://shop.test/api;
    }

Copier après la connexion

Configuration du projet backend inter-domaines :

location / {  
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
    add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';}

Copier après la connexion

Enregistrez et accédez au front end : vue.shop .test, accessible normalement.

2、分别部署，采用相同域名、不同端口

这个就相对简单很多，不需要第二个域名，效率也高的多。
例如，我的后端项目位于/www/wwwroot/test_adimin，前端项目是/www/wwwroot/test_vue，我们只需要在nginx配置里再配置监听另外一个端口就可以：

server{
    listen 80;
    server_name shop.test;
    index index.php index.html index.htm default.php default.htm default.html;
    root /www/wwwroot/test_adimin/public;
    ...}server{
    listen 8080;
    server_name shop.test:8080;
    index index.php index.html index.htm default.php default.htm default.html;
    root /www/wwwroot/test_vue/dist;
    location / {
        try_files $uri $uri/ @router;#需要指向下面的@router否则会出现vue的路由在nginx中刷新出现404
        index  index.html index.htm;
        # try_files $uri $uri/ /index.html;
    }
    #这里要写，不然会报：
    #We’re sorry but XXX doesn’t work properly without JavaScript enabled
    #网上说的把history改为hash就可以，那个不行，不适用于现在的情况。
    location /api    {
        add_header 'Access-Control-Allow-Origin' '*';
        proxy_pass http://shop.test/api;
    }
    ...}

Copier après la connexion

配置成功保存，访问shop.test:8080 速度杠杠的。