Introducing the server-side configuration of laravel+vue front-end and back-end separation

Preface

Separation of front-end and back-end has always been an unavoidable topic in laravel learning. In the early stage, we can quickly build a back-end management system that does not require too much front-end code by using laravel's excellent framework (such as laravel-admin, dcat-admin). But in the later stage, as the scale of the project increases, we also need services such as middle office (which can be simply understood as a user-oriented management backend), front-end website and other services. If we still use the above framework, it may seem inadequate. And in actual development, we will encounter such problems:

• The company has front-end and back-end engineers. The front-end engineers use vue to develop, and as phpers, we use laravel to develop. Then the problem arises. We cannot let front-end engineers also use laravel-mix and develop under the laravel framework. This is very unfriendly.
  

• The original model has a high degree of coupling and is very difficult to maintain and expand. Therefore, reducing the coupling between modules is quite beneficial for subsequent maintenance and expansion. helpful.
  

Clear concept

At this time, we will all think ofSeparation of front and rear ends.
So what is front-end and back-end separation? We will not discuss the specific definition today. If you are interested, you can check out these articles: What exactly is front-end and back-end separation? , Reflections on the practice of front-end and back-end separation
After understanding the basic concepts and ideas, we should start doing things. But before you start, you have to think about whether the current project is suitable for front-end and back-end separation? What kind of projects are suitable for front-end and back-end separation? Because if the project is not suitable, then the separation of front-end and back-end will undoubtedly increase the workload. For example, if it is just a pure back-end management system development, coupled with interface access, the number of project visits is not large, then a model like laravel-admin can completely competent. There will be a misunderstanding here, that is, the front-end code and the back-end code are developed separately, which means the front-end and back-end are separated (this seems to be a bit contradictory to what is said above). The so-called separation of front-end and back-end is not only for decoupling, but also to facilitate subsequent maintenance and expansion. In essence, the front-end project and the back-end project are two projects and need to be deployed independently. Two different projects, two different code bases, different developers. Front-end and back-end engineers need to agree on interactive interfaces to achieve parallel development. After development, independent deployment is required. The front-end calls the back-end restful api through http requests. The front-end only needs to focus on the style of the page and the parsing & rendering of dynamic data, while the back-end focuses on specific business logic
(Source: Why should the front-end and back-end be separated? What are the benefits and disadvantages of front-end and back-end separation?). So assuming that our front-end and back-end local development has been completed, we need to put it into the online environment for testing, so how do we go to the server for deployment and configuration?
Related tutorial recommendations: "

"

StartFor example, the project we completed is like this :

vue
, the back-end uses laravel jwt dingo to build the API interface, and uses laravel-admin as the back-end management system. According to the traditional method of configuring the backend, only the background management system is configured. After we install lnmp
with one click, configure nginx and point the root directly to the public directory of the project, or simply use Pagoda Panel, it will be fine in a few minutes. For us programmers who speak martial arts, this is called "click to stop". The backend can be used directly with the domain name /admin. But now that we have vue, we need to use the main domain name shop.test for front-end use. We will say Teacher You, Teacher Niu, Teacher Liu, you don’t follow martial ethics, and Teacher You says sorry, I will use it. So there are two ways to achieve the effect:

Try

1. Deploy separately and use different domain namesThe front-end domain name is: vue.shop.test

The interface domain name is shop.test/api
I only need to go to the root directory of nginx in the front-end project Just point to the target folder, for example:

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;#根目录    ...}

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

Back-end project configuration cross-domain:

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';}

Save and access the front-end: vue.shop .test, can be accessed normally.

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;
    }
    ...}

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

总结

优点

1.前后端开发人员各司其职，各自部署，相互不干涉，提高开发效率。
2.能够实现解耦，使得业务更加清晰，减少业务复杂程度。

缺点

1.增加开发、部署难度；
2.提高了对接和沟通成本；
3.不是所有的项目都适合前后端分离，需要框架设计者、开发者自己去判断

The above is the detailed content of Introducing the server-side configuration of laravel+vue front-end and back-end separation. For more information, please follow other related articles on the PHP Chinese website!