Skip to main content

フロントエンドとAPIサーバの分離

はじめに​

JHipsterは「フルスタック」開発ツールであり、その目標はフロントエンドコード（Angular/React）とバックエンドコード（Spring Boot）で効率的に作業できるようにすることです。

ただし、フロントエンド・コードとバックエンド・コードを分離することは一般的な要件です。これは通常、これらのコードが異なるチームによって開発され、異なるライフサイクルを持つためです。

注意 これはデフォルトのJHipsterの作業方法ではありません。複雑ではなく、うまく機能しますが、高度なトピックです。JHipsterを使い始める場合は、私たちの標準的な作業方法を使用することから始めることをお勧めします。

フロントエンド・アプリケーションまたはバックエンド・アプリケーションのみを生成​

JHipsterバックエンドまたはJHipsterフロントエンドアプリケーションのみを生成するように選択できます。生成時には、アプリケーション生成ドキュメントに記載されているフラグを選択するだけです。

  • jhipster --skip-clientはバックエンドアプリケーションのみを生成します（これは通常JHipsterマイクロサービスがそうなります）
  • jhipster --skip-server [options]はフロントエンドアプリケーションのみを生成します（例：jhipster --skip-server --db=sql --auth=jwt）

これは、マイクロサービス（いずれにしてもフロントエンドがない）やゲートウェイ（Spring Cloud Gatewayサービスが有効になっているモノリス）ではあまり意味がないため、モノリスでのみうまく機能するはずです。

ディレクトリのレイアウト​

JHipsterは、標準のMavenディレクトリ・レイアウトを使用します。バックエンドで作業する場合は、Maven標準ディレクトリ・レイアウト・ドキュメントを参照できます。

フロントエンドで作業する場合は、次の2つのディレクトリを知っておく必要があります。

  • src/main/webappは、クライアントアプリケーションが開発される場所です
  • target/classes/staticは、クライアントアプリケーションがパッケージ化される場所です

フロントエンドとバックエンドで別々のチームが作業している場合は、2つのソリューションがあります。

  • 両方のチームが同じプロジェクトで作業します。ディレクトリが分離されているので、チーム間の競合はあまりありません。さらにクリーンにするために、両方のチームが別々のブランチで作業もできます。
  • フロントエンドコードを特定のGitプロジェクトに格納し、Gitサブモジュールとしてメインのバックエンドプロジェクトにインポートできます。これには、クライアントサイドのビルドスクリプトを移動する必要があります。

HTTPリクエストのルーティングとキャッシング​

フロントエンドとバックエンドが分離されると、問題はHTTPリクエストの処理方法になります。

  • すべてのAPI呼び出しは/apiプレフィックスを使用します。Angularを使用している場合、webpack.common.js設定で定義された特定のSERVER_API_URL定数もあり、このプレフィックスを強化できます。例えば、"http://api.jhipster.tech:8081/"をバックエンドAPIサーバとして使用できます（これを行う場合は、以下のCORSに関するドキュメントをお読みください）。
  • /index.htmlは、ブラウザまたはサーバによってキャッシュされるべきではありません。
  • （フロントエンドの）静的アセットである/app（クライアント側アプリケーションを含む）および/content（画像やCSSなどの静的コンテンツを含む）を提供する/の呼び出しは、これらのアセットがハッシュ化されるため、プロダクション環境でキャッシュされるべきです。
  • /i18nへの呼び出しはキャッシュできますが、ファイル自体はハッシュされず、URLクエリ文字列が使用されます。
  • 存在しないルートへのコールは、リクエストをindex.htmlに転送する必要があります。これは通常、ClientForwardControllerを介してバックエンドで処理されます。クライアントを個別にデプロイする場合、これを設定する必要があります。いくつかの例については、AngularまたはReactのドキュメントを参照してください。

BrowserSyncの使用

devモードでは、JHipsterはフロントエンドアプリケーションのホットリロードにBrowserSyncを使用します。BrowserSyncには、/apiからバックエンドサーバ（デフォルトではhttp://127.0.0.1:8080）にリクエストをルーティングするプロキシ（ここにドキュメントがあります）があります。

これはdevモードでのみ動作しますが、フロントエンドから異なるAPIサーバにアクセスするための非常に強力な方法です。

CORSの使用​

CORS (Cross-origin request sharing)を使用すると、プロキシを設定せずに、同じフロントエンドを使用して異なるバックエンドサーバにアクセスできます。

これは使いやすいソリューションですが、本番環境では安全性が低くなる可能性があります。

JHipsterは、すぐに利用できるCORS構成を提供します。

  • CORSは、JHipster共通アプリケーションプロパティで定義されているように、JHipster.corsプロパティを使用して構成できます。
  • モノリスとゲートウェイでは、devモードでデフォルトで有効になっています。マイクロサービスでは、ゲートウェイを介してアクセスすることになっているため、デフォルトでは無効になっています。
  • セキュリティ上の理由から、prodモードではデフォルトでオフになっています。

NGinxの使用​

フロントエンドコードとバックエンドコードを分離するもう1つの解決策は、プロキシサーバを使用することです。これは本番環境では非常に一般的であり、一部のチームは開発でもこの手法を使用しています。

この設定は特定のユースケースに応じて変更されるため、これをジェネレータで自動化はできません。実際に動作する設定を次に示します。

src/main/docker/nginx.ymlでDocker構成ファイルを作成します。

version: '2'
services:
  nginx:
    image: nginx:1.15-alpine
    volumes:
    - ./../../../target/static:/usr/share/nginx/html
    - ./nginx/site.conf:/etc/nginx/conf.d/default.conf
    ports:
    - "8000:80"

このDockerイメージは、target/staticから静的アセットを読み取るNGinxサーバを設定します。これは、JHipsterフロントエンドアプリケーションがデフォルトで生成される場所です。プロダクション環境では、このための特定のフォルダがあると思われます。

また、./nginx/site.confファイルも読み込みます。これはNGinx固有の設定ファイルです。

lambdaの設定​

以下にsite.confの例を示します。

server {
    listen 80;
    index index.html;
    server_name localhost;
    error_log  /var/log/nginx/error.log;

    root /usr/share/nginx/html;

    location /api {
        proxy_pass http://api.jhipster.tech:8081/api;
    }
    location /management {
        proxy_pass http://api.jhipster.tech:8081/management;
    }
    location /swagger-resources {
        proxy_pass http://api.jhipster.tech:8081/swagger-resources;
    }        
    location /v2 {
        proxy_pass http://api.jhipster.tech:8081/v2;
    }
    location /auth {
        proxy_pass http://api.jhipster.tech:8081/auth;
    }

    location / {
        try_files $uri $uri/ /index.html;
    }
}

この設定は、次のことを意味します。

  • NGinxはポート80で動作します。
  • フォルダ/usr/share/nginx/htmlの静的アセットを読み込みます。
  • これは/apiからhttp://api.jhipster.tech:8081/apiへのプロキシとして動作します。
  • 処理されない要求はすべてindex.htmlに転送されます。

この構成は、特定のニーズに応じて調整する必要がありますが、ほとんどのアプリケーションにとって十分な出発点となるはずです。