laravel+vue 프런트엔드와 백엔드 분리의 서버측 구성 소개-Laravel-php.cn

엔드의 앞면과 뒷면의 분리는 항상 라라벨이 다룰 수 없는 주제였습니다. 초기 단계에서는 laravel의 우수한 프레임워크(laravel-admin, dcat-admin 등)를 사용하여 프런트엔드 코드가 많이 필요하지 않은 백엔드 관리 시스템을 빠르게 구축할 수 있습니다. 그러나 이후 단계에서는 프로젝트 규모가 커지면서 미들 오피스(단순히 사용자 중심 관리 백엔드로 이해될 수 있음), 프런트 엔드 웹 사이트 및 기타 서비스와 같은 서비스도 필요합니다. 프레임워크 위에서는 부적절해 보일 수 있습니다. 그리고 실제 개발에서는 다음과 같은 문제에 직면하게 됩니다.

회사에는 프론트엔드 및 백엔드 엔지니어가 있으며, 프론트엔드 엔지니어는 vue를 사용하여 개발하고, phper로서 우리는 laravel을 사용하여 개발합니다. 그러면 문제가 발생합니다. 프론트 엔드 엔지니어가 laravel-mix를 사용하고 laravel 프레임워크에서 개발하도록 할 수는 없습니다.

원래 모델은 결합도가 높아 유지 및 확장이 상당히 어렵습니다. 따라서 모듈 간의 결합을 줄이는 것이 후속 유지 관리 및 확장에 매우 도움이 됩니다.

그렇다면 이쯤 되면 다들 앞뒤 분리를 생각하게 되겠죠.

그렇다면 프론트엔드와 백엔드 분리란 무엇일까요? 오늘은 구체적인 정의에 대해 논의하지 않겠습니다. 관심이 있으시면 다음 기사를 확인해 보세요. 프론트엔드와 백엔드 분리란 정확히 무엇입니까? , 프론트엔드와 백엔드 분리 실천에 대한 고찰

기본 개념과 아이디어를 이해한 후 작업을 시작해야 합니다. 하지만 시작하기 전에 현재 프로젝트가 프런트엔드와 백엔드 분리에 적합한지 생각해 볼 필요가 있나요? 프런트엔드와 백엔드 분리에 적합한 프로젝트는 무엇인가요? 프로젝트가 적합하지 않다면 프런트엔드와 백엔드를 분리하면 의심할 여지 없이 작업량이 증가하기 때문입니다. 예를 들어 순수한 백엔드 관리 시스템 개발과 인터페이스 액세스, 프로젝트 수만 있다면 말이죠. 방문 횟수가 크지 않으면 laravel-admin과 같은 모델이 완벽하게 작동합니다. 여기서 오해가 있을 수 있습니다. 즉, 프론트엔드 코드와 백엔드 코드가 별도로 개발된다는 것입니다. 이는 프론트엔드와 백엔드가 분리되어 있다는 의미입니다(이것은 약간 모순되는 것 같습니다) 위에). 소위 프런트엔드와 백엔드 분리는 분리를 위한 것뿐만 아니라 후속 유지 관리 및 확장을 용이하게 하기 위한 것입니다.
프론트엔드 프로젝트와 백엔드 프로젝트는 두 개의 프로젝트이며 독립적으로 배포해야 합니다. 두 개의 서로 다른 프로젝트, 두 개의 서로 다른 코드 베이스, 서로 다른 개발자. 병렬 개발을 위해서는 프런트엔드와 백엔드 엔지니어가 대화형 인터페이스에 동의해야 합니다. 개발 후에는 프런트엔드에서 http 요청을 통해 백엔드 Restful API를 호출해야 합니다. 프론트엔드는 페이지 스타일과 동적 데이터의 구문 분석 및 렌더링에만 집중하면 되는 반면, 백엔드는 특정 비즈니스 로직에 중점을 둡니다
(출처: 프론트엔드와 백엔드를 분리해야 하는 이유는 무엇입니까? 프런트엔드와 백엔드 분리의 장점과 단점은 무엇입니까?) 그럼 프론트엔드와 백엔드 로컬 개발이 완료됐다고 가정하고, 온라인 환경에 올려서 테스트해야 하는데, 배포와 구성을 위해 서버로 어떻게 가야 할까요?
추천 튜토리얼: "laravel tutorial"

Start

예를 들어, 우리가 완성한 프로젝트는 다음과 같습니다:

프론트 엔드는 `vue`를 사용하고 백엔드는 laravel+jwt +dingo는 API 인터페이스를 구축하고 `laravel-admin`을 백엔드 관리 시스템으로 사용했습니다. 백엔드를 구성하는 전통적인 방법에 따르면 백그라운드 관리 시스템만 구성됩니다. 한 번의 클릭으로 `lnmp`를 설치한 후 루트가 프로젝트의 공개 디렉터리를 직접 가리키도록 nginx를 구성하거나, `Pagoda Panel` 코드>를 사용하면 몇 분 안에 준비됩니다. 윤리적인 프로그래머에게는 이를 "중지하려면 클릭"

이라고 합니다. 백엔드는 도메인 이름 +/admin을 사용하여 직접 사용할 수 있습니다.

하지만 이제 Vue가 있으므로 프런트엔드 사용을 위해 메인 도메인 이름 shop.test를 사용해야 합니다. 선생님, Niu 선생님, Liu 선생님은 무도덕을 따르지 않으시고 죄송하다고 말씀드립니다. , 나는 그것을 사용할 것이다.
따라서 효과를 얻는 방법에는 두 가지가 있습니다. vue，后端使用laravel+jwt+dingo构建了api接口，以及使用了laravel-admin作为后端管理系统。
按照传统配置后端的方法，只配置后台管理系统，我们一键安装lnmp后，nginx配置一下，root直接指向项目的public目录，或者干脆用宝塔面板
Try

1. 별도로 배포하고 다른 도메인 이름을 사용하세요.

프런트 엔드 도메인 이름은 vue.shop.test

백엔드 도메인입니다. 이름은 shop.test/ admin인터페이스 도메인 이름은 shop.test/api프런트 엔드 프로젝트의 nginx 아래에 있는 대상 폴더에 대한 루트 디렉터리를 가리키기만 하면 됩니다. 예:

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

로그인 후 복사

백엔드 프로젝트 구성 크로스 도메인:

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

로그인 후 복사

프론트 엔드: vue.shop.test를 저장하고 액세스합니다. 정상적으로 액세스할 수 있습니다.

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 速度杠杠的。