회사에는 프론트엔드 및 백엔드 엔지니어가 있으며, 프론트엔드 엔지니어는 vue를 사용하여 개발하고, phper로서 우리는 laravel을 사용하여 개발합니다. 그러면 문제가 발생합니다. 프론트 엔드 엔지니어가 laravel-mix를 사용하고 laravel 프레임워크에서 개발하도록 할 수는 없습니다.
원래 모델은 결합도가 높아 유지 및 확장이 상당히 어렵습니다. 따라서 모듈 간의 결합을 줄이는 것이 후속 유지 관리 및 확장에 매우 도움이 됩니다.
기본 개념과 아이디어를 이해한 후 작업을 시작해야 합니다. 하지만 시작하기 전에 현재 프로젝트가 프런트엔드와 백엔드 분리에 적합한지 생각해 볼 필요가 있나요? 프런트엔드와 백엔드 분리에 적합한 프로젝트는 무엇인가요? 프로젝트가 적합하지 않다면 프런트엔드와 백엔드를 분리하면 의심할 여지 없이 작업량이 증가하기 때문입니다. 예를 들어 순수한 백엔드 관리 시스템 개발과 인터페이스 액세스, 프로젝트 수만 있다면 말이죠. 방문 횟수가 크지 않으면 laravel-admin과 같은 모델이 완벽하게 작동합니다. 여기서 오해가 있을 수 있습니다. 즉, 프론트엔드 코드와 백엔드 코드가 별도로 개발된다는 것입니다. 이는 프론트엔드와 백엔드가 분리되어 있다는 의미입니다(이것은 약간 모순되는 것 같습니다) 위에). 소위 프런트엔드와 백엔드 분리는 분리를 위한 것뿐만 아니라 후속 유지 관리 및 확장을 용이하게 하기 위한 것입니다.
프론트엔드 프로젝트와 백엔드 프로젝트는 두 개의 프로젝트이며 독립적으로 배포해야 합니다. 두 개의 서로 다른 프로젝트, 두 개의 서로 다른 코드 베이스, 서로 다른 개발자. 병렬 개발을 위해서는 프런트엔드와 백엔드 엔지니어가 대화형 인터페이스에 동의해야 합니다. 개발 후에는 프런트엔드에서 http 요청을 통해 백엔드 Restful API를 호출해야 합니다. 프론트엔드는 페이지 스타일과 동적 데이터의 구문 분석 및 렌더링에만 집중하면 되는 반면, 백엔드는 특정 비즈니스 로직에 중점을 둡니다
(출처: 프론트엔드와 백엔드를 분리해야 하는 이유는 무엇입니까? 프런트엔드와 백엔드 분리의 장점과 단점은 무엇입니까?) 그럼 프론트엔드와 백엔드 로컬 개발이 완료됐다고 가정하고, 온라인 환경에 올려서 테스트해야 하는데, 배포와 구성을 위해 서버로 어떻게 가야 할까요?
추천 튜토리얼: "laravel tutorial"
vue
를 사용하고 백엔드는 laravel+jwt +dingo는 API 인터페이스를 구축하고 laravel-admin
을 백엔드 관리 시스템으로 사용했습니다. 백엔드를 구성하는 전통적인 방법에 따르면 백그라운드 관리 시스템만 구성됩니다. 한 번의 클릭으로 lnmp
를 설치한 후 루트가 프로젝트의 공개 디렉터리를 직접 가리키도록 nginx를 구성하거나, Pagoda Panel
코드>를 사용하면 몇 분 안에 준비됩니다. 윤리적인 프로그래머에게는 이를 "중지하려면 클릭"하지만 이제 Vue가 있으므로 프런트엔드 사용을 위해 메인 도메인 이름 shop.test를 사용해야 합니다. 선생님, Niu 선생님, Liu 선생님은 무도덕을 따르지 않으시고 죄송하다고 말씀드립니다. , 나는 그것을 사용할 것이다.
따라서 효과를 얻는 방법에는 두 가지가 있습니다. vue
,后端使用laravel+jwt+dingo
构建了api接口,以及使用了laravel-admin
作为后端管理系统。
按照传统配置后端的方法,只配置后台管理系统,我们一键安装lnmp
后,nginx配置一下,root直接指向项目的public目录,或者干脆用宝塔面板
Try
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를 저장하고 액세스합니다. 정상적으로 액세스할 수 있습니다.
这个就相对简单很多,不需要第二个域名,效率也高的多。
例如,我的后端项目位于/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.不是所有的项目都适合前后端分离,需要框架设计者、开发者自己去判断
위 내용은 laravel+vue 프런트엔드와 백엔드 분리의 서버측 구성 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!