Jhipster Development和訳

はじめに(注意点）

全体的にかなり意訳です。
自分の理解用に作っています。他の方の参考に少しでもなれば。

Profiles

原文:https://www.jhipster.tech/profiles/

JHipsterは２つのSpringProfileを使用します。

• dev ・・・開発環境用
• prod ・・・本番環境用

これらのprofileには２つの異なる構成がある:

• Maven/Gradle profileはビルドのタイミングで使用する。 例えば./mvnw -Pprod packageまたは./gradlew bootWar -Pprodは本番環境用にパッケージングする
• Spring Profileは実行に利用されます。いくつかのSpring Beanはprofileによって動作が異なります。

Spring ProfileはMaven/Gradleにより設定される。それによりMaven/GradleとSpring間でもそれが一貫性を持って設定されます。prod profileは、Maven/GradleとSpringとで同時に利用できます。
注意: Spring ProfileはJHipSter application propertiesで利用されるのでcommon application properties documentation.
にも目を通してください。

By default, JHipster will use the dev profile

Maven/Gradleを使用せずにApplicationクラスを実行した場合
Mavenを使っており、MavenWrapperを実行（./mvnw）またはmvnを使用した場合
Gradleを使っており、GradleWrapperを実行（./gradlew）またはgradleを使用した場合

Angular2を使用しており、devprofileでwebpackのコンパイルした内容に置き換えたい場合は以下のようにwebpackパラメータを追加してください
./mvnw -Pdev,webpack or ./gradlew -Pdev -Pwebpack

In production, JHipster has to run with the prod profile

Spring profiles switches

Common application properties

Common ports

Separating the front-end and the API server

Introduction

Generating only a front-end or a back-end application

Directory layout

JhipsterはMavenの標準ディレクトリ構造を採用しています。
バックエンドの作業をするときはこちらMavenの標準レイアウトを参考に。
フロントエンドで作業する場合は、２つのディレクトリがあることを理解する必要があります

• src/main/webapp は開発中のフロントエンドアプリケーションを配置する場所
• target/wwwはビルドされパッケージングされたアプリケーションが配置される場所

もし、フロントエンドとバックエンドが別々のチームで作業する場合２つの解決策があります。

• ディレクトリが分かれているので両方のチームが同じプロジェクトで作業可能。役割をはっきりさせるために、両チームは別々のbranchで作業できる。
• フロントエンドを別のgitプロジェクトし、バックエンドプロジェクトにgitサブモジュールとしてインポートする。クライアント側のビルドスクリプトを移動する必要あるが、シンプルにリファクタリングができる。

HTTP requests routing and caching

フロントエンドとバックエンドを分離させた場合HTTPリクエストをどうハンドリングするかが課題となります。

• 全てのAPIは/apiプレフィックスを付けてリクエストされる。これはangularを使う場合だと、webpack.common.jsの設定でSERVER_API_URLで既に定義することにより自動で付与される。例えば、http://api.jhipster.tech:8081/のようにバックエンドAPIサーバーのURLとすることができます。(apiをドメイン部に付与するつもりであれば、まずはCORSのドキュメントを読んでから検討してください。)
• /をコールした場合はブラウザにキャッシュする必要のない静的コンテンツが提供される
• /app(クライアントサイドアプリケーション）と/content(cssや画像などの静的コンテンツ) をコールした場合、本番環境ではキャッシュすべきこれらのコンテンツはハッシュ化され、提供される

Using BrowserSync

Jhipsterではdevモードの場合フロントエンドアプリケーションのhot-reloadのためにBrowserSyncを使う。
BrowserSyncはプロキシ機能(ドキュメント)があり、
バックエンドへの/apiへのリクエストをルーティングしてくれる（デフォルトの設定はhttp://127.0.0.1:8080)

これはdevモードだけの機能だが、フロントエンドから別のAPIサーバーにリクエストを送る際に非常に有用です。

Using CORS

CORS([https://wikipedia.org/wiki/Cross-origin_resource_sharing]) はproxyなしで
フロントエンドから別のバックエンドサーバにアクセスを許可するものです。
これはとても簡単ではあるが、本番環境では安全性が低くなる可能性があります。

JHipsterはCORSがすぐに使えるようにする設定がある

• CORSはapplication.ymlにjhipster.corsの名で定義される(参考)
• これはデフォルトではモノリシックとゲートウェイアプリケーションの場合、devモード時に有効になり、ゲートウェイを通してアクセスするマイクロサービスでは無効になる
• セキュリティ上の理由からこれはprodモードでは無効になる

Using NGinx

フロントエンドとバックエンドのコードを分けるための別の案としてプロキシサーバーを使います。
これは本番環境ではとてもよく使う手法で、一部のチームはこのテクニックを開発でも使用しています。
この設定方法は特定のユースケースに応じて変わるため、Jhipsterのgeneratorでは自動生成できません。
以下にdocker-composeファイルでの設定方法を示します。src/main/docker/nginx.ymlとして作成してください

nginx.yml

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

このDockerイメージはtarget/wwwからJHipsterがデフォルトの設定で生成するフロントエンドアプリケーションの静的コンテンツを読み込みます。
また、Nginxの設定ファイル./nginx/site.confも読み込みます。
以下にサンプルを示します。

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

    location / {
        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 /v2 {
       proxy_pass http://api.jhipster.tech:8081/v2;
    }
    location /swagger-ui {
        proxy_pass http://api.jhipster.tech:8081/swagger-ui;
    }
    location /swagger-resources {
        proxy_pass http://api.jhipster.tech:8081/swagger-resources;
    }
}

上記設定の意味は

• Nginxをポート80で動作
• 静的assetのフォルダを/usr/share/nginx/htmlに指定
• /apiをhttp://api.jhipster.tech:8081/apiへリクエストするプロキシサーバー設定

この設定は必要に応じて変える必要はあるものの、多くのアプリケーションのスタート時はこれで十分でしょう。

Managing server errors

Using Angular

Tooling

AngularはJavascriptの代わりにTypeScriptを使用しています。
その結果として、効率的に作業するためには特定のツールが必要です。
我々のAngular2アプリケーション開発フローを以下に示します。好みによってnpmをyarnに読み替えてください。

1. アプリケーションの新規作成時におけるファイルの自動生成のタイミングの最後にnpm installタスクが実行される
2. npm installが完了したらpackage.jsonのpostInstallが実行される。このタスクの中でwebpack:buildがトリガーされる
3. この段階でコンパイルされたすべてのファイルがwwwフォルダ内のtargetまたはbuildフォルダに生成されており、ここをビルドツール(MavenまたはGradle)が参照しています
4. ./mvnwまたは./gradlewでアプリケーションサーバを起動することによりlocalhost:8080で上記ステップでコンパイルされたクライアントサイドのコンテンツを配信できるようになる
5. 別のターミナルを開き、npm startまたはyarn startを実行することにより、BrowserSyncのWebpack dev-serverが起動する これにより自動的にTypeScriptコードをコンパイルし、ブラウザをリロードしてくれる

もしnpm startまたはyarn start実行をせずにクライアントサイドのコードを変更してしまった場合、コンパイルはされず、変更も反映されません
その場合は手動でnpm run webpack:buildを実行するか、npm startまたはyarn startを実行して何か変更を行ってください。

またmavenやgradleにwebpackプロファイルを設定することでwebpack:devタスクを実行することもできます
例）./mvnw -Pdev,webpack or ./gradlew -Pdev -Pwebpack
これはgradleやmavenのcleanタスクを実行した後に特に役立ちます。

他の実行可能なnpm/yarnコマンドもpackage.jsonの中のscriptsセクションに記載されています。

• ブラウザ上でコードを動作させるために、我々はAngular Auguryをお薦めします。これによりルーティングやコードのデバックが簡単になります。

Project Structure

JHipsterのクライアントコードはsrc/main/webapp配下にあります。
構成はJohn Papa Angular 2 style guideに従っています
もし我々のアプリケーション構成、ファイル名、TypeScriptルールに質問等があれば、まずはガイドを読んでみてください。

このガイドはAngularチームに支持され、全てのAngularプロジェクトが使うべきベストプラクティスです
AngularのルーティングではURLを一貫性を保つためにダッシュケースの命名規則を使用します。
entityを生成する際、ルーティングURLとREST APIエンドポイントURLはこの規則にしたがって生成され、
entity名は必要に応じて自動的に複数形にされます

以下がプロジェクトのメインの構成です。

webapp
├── app                               - Your application
│   ├── account                       - User account management UI
│   ├── admin                         - Administration UI
│   ├── blocks                        - Common building blocks like configuration and interceptors
│   ├── entities                      - Generated entities (more information below)
│   ├── home                          - Home page
│   ├── layouts                       - Common page layouts like navigation bar and error pages
│   ├── shared                        - Common services like authentication and internationalization
│   ├── app.main.ts                   - Main application class
│   ├── app.module.ts                 - Application modules configuration
│   ├── app.route.ts                  - Main application router
├── content                           - Static content
│   ├── css                           - CSS stylesheets
│   ├── images                        - Images
├── i18n                              - Translation files
├── scss                              - Sass style sheet files will be here if you choose the option
├── swagger-ui                        - Swagger UI front-end
├── 404.html                          - 404 page
├── favicon.ico                       - Fav icon
├── index.html                        - Index page
├── robots.txt                        - Configuration for bots and Web crawlers

entity sub-generatorを使用し、新しいFoo entityを生成した場合の
結果(src/main/webapp配下)が以下です。

webapp
├── app
│   ├── entities
│       ├── foo                                    - CRUD front-end for the Foo entity
│           ├── foo.component.html                 - HTML view for the list page
│           ├── foo.component.ts                   - Controller for the list page
│           ├── foo.model.ts                       - Model representing the Foo entity
│           ├── foo.module.ts                      - Angular module for the Foo entity
│           ├── foo.route.ts                       - Angular Router configuration
│           ├── foo.service.ts                     - Service which access the Foo REST resource
│           ├── foo-delete-dialog.component.html   - HTML view for deleting a Foo
│           ├── foo-delete-dialog.component.ts     - Controller for deleting a Foo
│           ├── foo-detail.component.html          - HTML view for displaying a Foo
│           ├── foo-detail.component.ts            - Controller or displaying a Foo
│           ├── foo-dialog.component.html          - HTML view for editing a Foo
│           ├── foo-dialog.component.ts            - Controller for editing a Foo
│           ├── foo-popup.service.ts               - Service for handling the create/update dialog pop-up
│           ├── index.ts                           - Barrel for exporting everything
├── i18n                                           - Translation files
│   ├── en                                         - English translations
│   │   ├── foo.json                               - English translation of Foo name, fields, ...
│   ├── fr                                         - French translations
│   │   ├── foo.json                               - French translation of Foo name, fields, ...

Authorizations

JHipsterはAngular routerを用いてクライアントアプリケーションの各コンポーネントを構成しています。
各stateについて、必要な権限がstateのデータにリストされ、リストが空の場合は誰でもアクセス可能であることを意味します。
権限はサーバーサイドのAuthoritiesConstants.javaでも定義され、クライアントとサーバーサイドのロジックは同じでなければなりません
以下の例では、'session' stateが ROLE_USER権限をもつユーザーのみアクセス可能となるように設計されたコードです

export const sessionsRoute: Route = {
    path: 'sessions',
    component: SessionsComponent,
    data: {
        authorities: ['ROLE_USER'],
        pageTitle: 'global.menu.account.sessions'
    },
    canActivate: [UserRouteAccessService]
};

これらの権限がルーターに定義されると、２つの引数のタイプに基づき、jhiHasAnyAuthorityディレクティブを使用することができます。

• string単体の場合、引数の権限を持ったユーザーにのみHTMLコンポーネントが表示される
• string配列の場合、配列に定義された権限の内、一つでももっているユーザーにのみHTMLコンポーネントが表示される

例えば、以下のテキストはROLE_ADMINを持ったユーザーにのみ表示されます

<h1 *jhiHasAnyAuthority="'ROLE_ADMIN'">Hello, admin user</h1>

また、以下の例ではROLE_ADMINまたはROKE_USER権限を持ったユーザーにのみ表示されます。

<h1 *jhiHasAnyAuthority="['ROLE_ADMIN', 'ROLE_USER']">Hello, dear user</h1>

注意：これらのディレクティブはクライアントサイドでHTMLの表示、非表示を切り替えるだけです。
サーバーサイドでもコードをセキュアに保つ必要があります。

The ng-jhipster library

ng-jhipsterはOSSで誰でも利用可能です (https://github.com/jhipster/ng-jhipster)
ng-jhipsterには下記のようなAngular2用の共通componentやutilが含まれています。

• Validation directives
• Internationalization components
• Commonly-used pipes like capitalization, ordering and word truncation
• Base64, date and pagination handling services
• A notification system (see below)

Notification System

Jhipsterではサーバーサイドからクライアントサイドへイベントを送信し、生成されたアプリケーション全体で使用できる国際化対応された独自の通知システムを使用します。(JhiAlertComponsentとJhiAlertErrorComponent)
デフォルトではHTTP responseでエラーを検知した際にエラーメッセージを表示するのに使用されている
通知やアラートを表示するためには、AlertServiceをcontroller, directive, serviceにInjectした後に以下のようにsuccess, info, warning, またはerrorを指定してください。タイムアウトのデフォルト値は5秒で、これは設定可能です。

this.alerts.push(
    this.alertService.addAlert(
        {
            type: 'danger',
            msg: 'you should not have pressed this button!',
            timeout: 5000,
            toast: false,
            scoped: true
        },
        this.alerts
    )
);

Using Angular CLI

注意：AngularCLIとJHipsterへ並行して使うことができ、それぞれが独自の設定ファイルを持っています。JHipsterはデフォルトでアプリケーションをデプロイする際やCI-CDサブジェネレーターを使用する際に自分の設定ファイルを使用しています。

Angular CLIは開発用のツールでありscaffoldやangularアプリケーションのメンテナンスを行います。
JHipsterはAngularCLIの設定ファイルを生成します。そのため、AngularCLIのワークフローはJhipster内で動作します。
この統合は、アプリケーションのルートフォルダにangular.jsonファイルを生成し、その依存関係をpackage.jsonファイルに追加することによって行われます。

Usage

ng help

Building

JHipsterには独自のスクリプトが含まれているため、フロントエンドのビルドにng buildは使用しないでください。
詳細は下記ページを参照
Using JHipster in development
Using JHipster in production

Generating Components, Directives, Pipes and Services

ng generate (またはng g) でAngularコンポーネントを生成することができます。

ng generate component my-new-component
ng g component my-new-component # using the alias

# Components support relative path generation
# Go to src/app/feature/ and run
ng g component new-cmp
# your component will be generated in src/app/feature/new-cmp
# but if you were to run
ng g component ../newer-cmp
# your component will be generated in src/app/newer-cmp

Scaffold	Usage
Component	ng g component my-new-component
Directive	ng g directive my-new-directive
Pipe	ng g pipe my-new-pipe
Service	ng g service my-new-service
Class	ng g class my-new-class
Guard	ng g guard my-new-guard
Interface	ng g interface my-new-interface
Enum	ng g enum my-new-enum
Module	ng g module my-module

Test

JHipsterアプリケーションの一貫性を保つため、テストの実行はnpmコマンドを介してのみ実行可能です。

npm test

i18n

JHipsterはng2-translateを翻訳目的に使用しています。Angular CLI の国際化はデフォルトのAngular i18nサポートに基づいており、JHipsterとは互換性がありません。

Running the Server

Angular CLIを使用してアプリケーションを開発したい場合は、専用のコマンドを使用してサーバーを直接実行できます

ng serve

上記コマンドを実行することによって、Angularアプリケーションをコンパイルし、http://localhost:4200でアクセス可能になります。
しかし、あなたのバックエンドはデフォルトではそこから利用できません。
ローカルバックエンドサーバーを使うにはそこからさらに

ng serve --proxy-conf proxy.conf.json

これでAPIにアクセス可能になるでしょう

Conclusion

Angular CLIについてもっと知りたい場合は https://cli.angular.io/を参照してください

Using React (with Redux)

Customizing Bootstrap 4

※開発者向けTips: 変更の即時フィードバックを得るためにnpm startまたはyarn startの実行を忘れないようにしてください
JHipsterアプリケーションの見た目をカスタマイズする
最も簡単な方法は、src/main/webapp/content/css/global.cssのCSSスタイルを上書きすることです。
(sassオプションを選択した場合は、src/main/webapp/content/scss/global.scss)

あなたがあなた自身のscssファイルでBootstrapをPartialで使いたいならば、
scssファイルの始めに以下のようにインポートしてください。
例）border-radius mixinを使う場合

@import "node_modules/bootstrap/scss/variables";
@import "node_modules/bootstrap/scss/mixins/border-radius";

必ずメインのSassファイルではなくPartialのみをインポートするようにしてください、
さもなくば、重複したCSSを生成し、結果的に問題を引き起こすかもしれません。
color,border-radius等のdefaultのBootstrap設定を変更する場合やPartialファイルのpropertyの値を追加したい場合は
src/main/webapp/content/scss/_bootstrap-variable.scssを編集します。
Bootstrapに定義されている全ての値(_variables.scss)はこのファイルで上書きすることができます。

Using TLS and HTTP/2 in development