laravel+vueのフロントエンドとバックエンド分離のサーバー側構成の紹介-Laravel-php.cn

laravel+vueのフロントエンドとバックエンド分離のサーバー側構成の紹介

藏色散人

リリース： 2021-06-27 09:14:44

転載

4315 人が閲覧しました

##序文

#フロントエンドとバックエンドの分離は、Laravel Learningで常に避けられないトピックでした。初期段階では、laravelの優れたフレームワーク（laravel-admin、dcat-adminなど）を使用することで、フロントエンドコードをあまり必要としないバックエンド管理システムを迅速に構築できます。しかし、後の段階ではプロジェクトの規模が大きくなるにつれて、ミドルオフィス（簡単に言うとユーザー指向の管理バックエンドと理解できます）やフロントエンドWebサイトなどのサービスも必要になります。上記のフレームワークでは不十分だと思われるかもしれません。

会社にはフロントエンドエンジニアとバックエンドエンジニアがいますが、フロントエンドエンジニアは vue を使って開発しており、私たちは PHPer として、開発にはlaravelを使用します。そこで問題となるのが、フロントエンドエンジニアにもlaravel-mixを使ってlaravelフレームワークで開発をさせるわけにはいかないということで、非常に不親切です。
元のモデルは結合度が高く、保守や拡張が非常に難しいため、モジュール間の結合を減らすことはその後の保守や拡張に非常に有益です。。

明確なコンセプト

このとき、みんなで考える

フロントエンドとリアエンドの分離。では、フロントエンドとバックエンドの分離とは何でしょうか?今日は具体的な定義については説明しませんが、ご興味がございましたら、次の記事をご覧ください: フロントエンドとバックエンドの分離とは正確には何ですか? , フロントエンドとバックエンドの分離の実践についての反省
基本的な概念と考え方を理解した後、行動を開始する必要があります。しかし、始める前に、現在のプロジェクトがフロントエンドとバックエンドの分離に適しているかどうかを考える必要があります。フロントエンドとバックエンドの分離に適しているのはどのようなプロジェクトですか?
プロジェクトが適切でない場合、フロントエンドとバックエンドの分離は間違いなく作業負荷を増加させるためです。たとえば、それが単なるバックエンド管理システムの開発であり、インターフェースへのアクセスと組み合わせている場合、プロジェクトの訪問数が多くない場合は、laravel-admin のようなモデルが完全に機能します。ここで誤解があるかもしれません。つまり、フロントエンドのコードとバックエンドのコードは別々に開発されるということです。これは、フロントエンドとバックエンドが分離されていることを意味します(これは、内容と少し矛盾しているようです)と上で言われています）。フロントエンドとバックエンドのいわゆる分離は、分離のためだけでなく、その後のメンテナンスや拡張を容易にするためでもあります。本質的に、フロントエンドプロジェクトとバックエンドプロジェクトは 2 つのプロジェクトであり、デプロイする必要があります。独立して。 2 つの異なるプロジェクト、2 つの異なるコードベース、異なる開発者。フロントエンドとバックエンドのエンジニアは、並行開発を実現するために対話型インターフェイスについて合意する必要があります。開発後は、独立したデプロイメントが必要です。フロントエンドは、http リクエストを通じてバックエンドの RESTful API を呼び出します。フロントエンドはページのスタイルと動的データの解析とレンダリングのみに重点を置く必要があり、バックエンドは特定のビジネスロジックに重点を置きます (出典: なぜフロントエンドとバックエンドは同じである必要があるのか)フロントエンドとバックエンドを分離することの利点と欠点は何ですか?)。
フロントエンドとバックエンドのローカル開発が完了したと仮定すると、テストのためにそれをオンライン環境に置く必要があります。では、展開と構成のためにサーバーにどのように移動するのでしょうか? 関連チュートリアルの推奨事項: 「
laravel チュートリアル

」

開始

たとえば、私たちが完了したプロジェクトは次のとおりです。このように: フロントエンドは

vue

を使用し、バックエンドは
laravel jwt dingo を使用して API インターフェイスを構築し、laravel-admin を使用します。バックエンド管理システムとして。 バックエンドを構成する従来の方法によると、バックグラウンド管理システムのみが構成されます。ワンクリックで lnmp をインストールした後、nginx を構成し、ルートをプロジェクトのパブリックディレクトリに直接指定します。または単に
Pagoda パネル を使用すれば、数分で完了します。格闘技を話す私たちプログラマにとって、これは 「クリックして停止」 と呼ばれます。バックエンドは、ドメイン名 /admin で直接使用できます。 しかし、vue ができたので、フロントエンドで使用するメインドメイン名 shop.test を使用する必要があります。You 先生、Niu 先生、Liu 先生、武道倫理に従わない、You 先生と言います。「ごめんなさい、使わせていただきます」と言う。 したがって、効果を実現するには 2 つの方法があります:

試す

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

ログイン後にコピー

バックエンドプロジェクト構成クロス-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';}

ログイン後にコピー

フロントエンド: 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 速度杠杠的。