投稿者：セバスチャン・ダシュナー
オリジナル：
https :
//blog.sebastian-daschner.com/entries/stop_saying_heavyweight （2016年4月9日）
翻訳：セミヨン・ソルダテンコ
エンタープライズJavaアプリケーションを開発する場合、Java EEまたは他の「軽量」フレームワークを使用するかどうかを選択する必要があります。 しかし、企業フレームワークを軽量化するものは何ですか？
開発者として、主に開発プロセスに注意を払う必要があります。 私たちの時間は貴重で（そして高価です）、オーバーヘッドに費やす時間が少ないほど良いです。
ビルド時間
この時間は、主にアプリケーションをコンパイル、デプロイ、およびテストする時間で構成されます-ローカルまたは特別な環境で。 完全な円の時間をできる限り短くするために、コンパイルは数秒を超えないようにしてください。 はい秒。
Java EEの使用には、開発者がAPIに基づいて開発できる標準（基本的にはインターフェイスと注釈のみ）に依存できるという大きな利点がありますが、フレームワークの実際の実装はアプリケーションに含まれません。 実際、Java EE依存関係はアプリケーションサーバーによって「提供」されます。つまり、コンパイルにのみ必要であり、インストールパッケージには含まれていません。 これには、基本的にwarファイルが空のままであるという副作用があります-アプリケーションのクラスファイルのみが含まれます。 そして、他のすべてはJava EE実装によって提供される必要があります。
細くてミニマルである限り、つまりサードパーティの依存関係ではなく、Java EE API（7）のみを使用することを意味します-ビジネスケースに本当に必要がない限り、数秒でコンパイル時間を達成できます。 遅いアセンブリの主な理由は、遅い（統合）テストまたは大規模なインストールパッケージのいずれかであり、それに応じて多くのコピーが必要です。
インストールパッケージサイズ
典型的な単純なJava EE warファイルは、小さな（まあ、ご存知のように）フレームワークの実装を提供する場合、50メガバイト以上のサイズと比較して、数百キロバイトのサイズです。
アプリケーションサーバーとアプリケーションを考慮すると、Java EEの場合の結果は大きくなります。 しかし、一般的に、ビルドするたびにキロバイトが作成されるため、開発プロセスは高速になります。 通常、アプリケーションサーバーは開発マシンまたは他の環境に既にインストールされており、可動部分は小さいままです。 その結果、開発者のマシンと継続的インテグレーションサーバーの両方で、ビルドと展開の時間が短縮されます。 また、インストールパッケージを集中リポジトリ（NexusまたはMavenセントラルなど）に配置すると、時間とトラフィックの両方を節約できます。
展開時間
最新のすべてのJava EE 7アプリケーションサーバー（Wildfly、TomEE、Glassfish / Payara、WLPなど）は、アプリケーションの展開に非常に短い時間を示しています。 モジュラーシステム（OSGiなど）の一部として、必要なコンポーネントのみをダウンロードし、数秒でアプリケーションを実行できます。
Tomcat上で実行される別のフレームワーク（Springなど）と比較すると、同じマシンで測定した場合、これまでに測定した最短の展開時間は少なくとも15秒（単純な「Hello World」アプリケーションの場合）でした。
シックJAR /コンテナ統合
マイクロサービスの新しい世界では、開発されたアプリケーションとフレームワークの実装の両方を含む独立したjarの形式でアプリケーションを提供するのが一般的です。 Java EEでは、Wildfly SwarmやTomEE Embeddedなどのテクノロジーを使用してこれを実現できます。
ただし、前述のとおり、インストールパッケージをそれほど大きくすることはお勧めしません。 このアプローチの最大の問題はビルド時間です。AからBに毎回多くのものをコピーする必要があるためです。また、Dockerなどのコンテナーを使用してデプロイする場合、アプリケーションがサーバーに付属するのかサーバーに含まれるのかは重要ではなくなりますコンテナ。
コンテナにインストール済みのアプリケーションサーバーが既に含まれている場合は、ビルド時間（コンテナ）を大幅に節約できます。 この場合、ベースイメージは変更されず、（数百キロバイトのみの）アプリケーションを追加するだけです-これはほとんど時間なしで実現されます。
メモリ消費
古いJ2EEの時代から、「重い」アプリケーションサーバーは起動するとすぐに大量のメモリを消費するという神話があります。 Adam Bienは、最新のJava EEアプリケーションサーバーの実際のメモリオーバーヘッドを示す興味深い
ビデオを投稿しました。
おわりに
私の観点から、エンタープライズアプリケーション向けの最も「軽量な」ソリューションの1つは次のとおりです。
- サーバーが提供するAPIのみを使用するJava EE 7およびJava 8
- ビジネスロジックと最小限の構成（JAX-RSリソースやJPAなど）のみを含む小さなwarファイル
- コンテナが組み込まれたテストフレームワークなしの高速ユニットテスト（単純なJUnitのみ）
- アプリケーションを除く、必要なすべてのコンポーネントを含む基本イメージのコンテナに基づく展開
- コミットごとにコンテナにアプリケーションをデプロイする継続的デリバリーに基づくビルドプロセス
- コンテナにデプロイされたアプリケーションの自動システムテスト（統合テストを必要とせずにアプリケーションの高品質を確認します。同時に、開発者も迅速な応答を受け取ります）
翻訳者から：
- エンタープライズアプリケーション-エンタープライズアプリケーション
- フレームワーク-フレームワーク
- インストールパッケージ-展開アーティファクト
- ビジネスケース-ビジネスユースケース
Semyon Soldatenko、CC-BY-NC-SA 4.0
「ヘビー級」と言うのをやめるの翻訳、セバスチャン・ダシュナー、CC BY-NC-SA 4.0