はじめに
Happy Holidays!
今年はとあるプラットフォームチームで大規模サービス1をパブリッククラウドに移行するため、気の遠くなる一連の改修、設計、テストをしていました。クラウドネイティブに進むためクラウドネイティブの真逆な地獄の日々を送っていましたが、ある程度本番リリースがある程度できて一安心な冬を過ごしています。2
その一環でJSPはこれ以上使わなくていいかなあと思ったので、年末のまとめにアドベントカレンダーに参加することにしました。
お断り
この記事はJSPが最早Webサービスの現場にフィット3しない部分が多いという、実務の話です。JSP自体のアーキテクチャを否定する意向がないことを踏まえてお読みください。
この記事ではJenkins自体も否定はしていません。個人的には安定性や互換性もしっかりしており評価はできますが、Webサービス開発ではGitHub ActionなどのCI/CDツールが使いやすいと考えています。
JSPの代替案の説明をしていますが、モダンフロントエンド開発の詳細には触れません。
Webセキュリティに関わる部分は実装依存で発生することもあるので触れません。
サーバレスは作者が利用していないので触れませんが、JSPは使えない、はず。
キャッシュとCDNの話も割愛します。4
この話で想定している現場の状況
- WebサービスをJavaエンジニアとUI/UXデザイナーで作っています
- バックエンドはJava 8以上で、フレームワークはSpringです
- 開発時期の問題で、管理画面と一般ユーザ向けフロントのUIは全般的にJSPです
- フロントエンドのコーディングはデザイナーがします。デザイナーは仮説検証や他社との協業を多数こなすため、エンジニアとは開発ライフサイクルが独立しており、UIの開発とデプロイをエンジニアに依存せず行う必要があります
- デザイナーはサーバサイドのテンプレートエンジンとモダンフロントエンド技術に詳しいです。CSSはモジュール化して管理する習慣があり、プログラミングもできます
- JavaのアプリケーションサーバはTomcatで、デプロイはエンジニアもデザイナーもJenkinsでデプロイできるようにしてあります
- ソースコードはGitHubで管理され、Pull Requestベースで開発しています5
- エンジニア、デザイナーともに新卒入社も多く、JSPやJavaに詳しい人はエンジニア以外あまりいません
- JavaエンジニアもモダンOSSやJavaの仕様にはあまり詳しくないです
不便な理由
taglibの仕様書の場所がわかりにくい
- 今使っているのがJakarta EEなのかJava EEなのか
- 今利用しているアプリケーションサーバは何
etc踏まえてエンジニアが公式ドキュメントを探すところから必要かもしれません。英語で技術文書が読める方にはSpecへのリンクを紹介しても良いかもしれませんが、エンジニアでさえも公式ドキュメント探しが大変かもしれません。
コーディング方法と規約の整備が必要
デザイナーさんにJSPのコーディング方法を説明するため、最終的にはtaglibの使い方をWikiなどに独自にまとめておく必要がありました。
カスタムtaglibの仕様書がわかりにくい
よく使うコンポーネントをカスタムtaglibとして実装し、デザイナーさんがエンジニアに依存せず自力でコーディングできるようにすることがあります。その場合、デザイナーさん達と仕様書を共有するのにjavadocだと不便です。
- データ呼び出しに必要なパラメータは何？型は？
- 画面表示に使えるパラメータは何？
- コーディング後の画面表示はどうなるの？
といった関心がJavaエンジニア以外に伝えにくいからです。javadocでMarkdownを使えなくはないですが、結局はJavaエンジニア以外にtaglib仕様の共有はとにかく不便です。
コーディングした結果を確認するまでに時間がかかる
JSPにコーディング後、デザインを確認するためにはアプリケーションサーバの起動やソースコードのデプロイが必要です。
組み込みTomcatであればmainメソッドを呼び出せば起動でき手間は少ないかもしれません。
一方、組み込みではないTomcatを利用している場合起動までの手順は煩雑で、エディタにも制約が出てきます。
メンバーの習熟が課題
ローカル開発環境でeclipse WTPを使うことになり、エディタがPleiades All in One Eclipse一択になるかもしれません。2023年の新卒はeclipseを知らないこともあります。本質でない教育と開発環境構築の手順化がコストです。環境のセットアップまでに時間がかかります。
ゲーム業界経験者でなければJenkinsを知らないこともあり、新しく参加したメンバーには、そもそもJenkinsは何か、から説明をはじめてJenkinsデプロイを教えることにもなりかねません。
SEOアンフレンドリーなHTMLになりがち
実装次第ですが、JSPのコーディングで可読性を考慮すると、階層が崩れたSEOアンフレンドリーなHTMLになりがちです。
社内の管理画面などSEOの考慮が不要な場合は問題ありませんが、SEOが大事なサービスでは一大事です。
モジュール化されたJavaScriptが使いにくい
JSファイルは、フッタ下部に書くか、ヘッダに書くか悩みがちです。
scriptタグの記載順の問題でエラーが発生した場合、どの部分で発生しているかトラブルシューティングも手間です。
CSS管理が静的ファイル一本になりがち
サーバのresourceディレクトリにCSSファイルを配置し、JSP内ではHTMLで参照しがちです。
<link rel="stylesheet" type="text/css" th:href="@{/css/example.css}" href="../../../css/example.css"/>
慣れないメンバーにはCSSの配置先がわかりにくく、リンク切れしないためにhttps:// からフルパス指定して本番でリンク切れを起こしたりしがちです。
デプロイが遅くなりがち＋デプロイ時短のためインフラが限定されがち
誤字脱字を修正したいなど、JSPだけを即座にデプロイしたい場合があります。この場合にwarをビルドしてデプロイし、アプリケーションの再起動をかけるとダウンタイムも一瞬発生しますし、デプロイ時間もかかります。
そこでrsyncしてJSPだけコピーし再起動を不要にする運用を取ることがあるのですが、コンテナが使いにくくどうしてもインフラがVMに限られがちです。
テストフレームワークが使いにくい
JSPのテストはアプリケーションサーバを起動し、マニュアルで動作確認するのみになりがちです。JSPのユニットテストはしなくなります。一時期JSPのテストフレームワークのようなものがあった記憶がありますが、浸透しないので忘れました。
ではどうするか
JSPではなくフロントエンドフレームワークを使いましょう
React/Next, Vue/Nuxtなどお好みでどうぞ。
- TypeScriptで型がつけられます
- JavaScriptはモジュール化されています
- eslintやprettierなどが整備されており、CI/CDに組み込んで規約を理解し守れます
- 仕様書はStorybookで管理すると、コンポーネントの仕様、画面表示の状態の確認やテストもできます
- CSS管理にTailwindやstyled-componentsなど選択肢があります
- SSRすればSEOも対策しやすいですし、SEO対策のためインデントに悩むことはありません
- テストフレームワークがあります
- ローカル開発環境にeclipseが不要です
- 動作環境をVM以外から選択できます
- CI/CDの選択肢が広がります
- デプロイにJenkinsは不要です
- インフラもVMに限らず利用できます
- rsyncは不要です
どうしてもJavaの技術スタックを使いたい場合
Thymeleaf
作者は過去、UI/UXデザイナーのチーフから、Thymeleaf独自のプリフィクスをHTMLコーディング時につけたくないので使いたくないと意見をいただいて見送ったことがありました。導入できるかは現場次第です。
HTMLマークアップするメンバーと合意できれば、Thymeleafも良いと思います。
日本語ドキュメンテーションもあり、情報も充実しています。
他にもテンプレートエンジンがある
お好みでどうぞ。
Vaadinというものもある
作者個人はHillaの頃から試していました。
- デザイナーとコーディングを分業できるか
- VaadinがSpring Bootのバージョンアップに追従できるか(しているか？)
気になっていますが、慣れれば便利かもしれません。
それでもJSPがいい
最後まで読んでいただきありがとうございます。ここまで色々説明しましたが、それでもJSPを使おうと思うならご自由にどうぞ。