GraphQLのBFFをJVMで書く理由を模索してみた_LT用

1. 1 GraphQLのBFFをJVMで書く理由を模索してみた
2. 2 API開発において技術選定されることが年々減ってきている...気がする。 - バックエンド技術のモダン化に取り残されている。 - 新規のプロダクト作りだとGo、Python、Node.jsがバックエンドとして選択されることが多い。 (*1) - コンテナ技術との相性が悪い。 - GraalVMでネイティブビルドこそできるが、 JVMのAPI開発でベターなSpringがクソ重い。 　→　どうにか覇権を取り返せないか?! (*1)https://to-a.org/news/2022/05/12/7631/ より上位企業の選定技術より 模索のモチベーション なんか最近バックエンド界隈でJVM系言語の肩身狭くね？
3. 3 QraphQLを利用したBFFの導入事例が増えてきた。 - 主にGo、Node.jsで実装されることが多い。 - バックエンドがGoで実装されているなら素直にGoで良さそうだから。 - Node.jsはフロントエンドの技術スタックをそのまま持ち越せる。 　→　モダンなアーキテクチャを前提とした新規開発で覇権を取りかえしにいくのは、 ちょっと現実味がなさそう... 機会となりうるもの API提供以外でのバックエンド界隈での動き
4. 4 Springベースのものは勿論、Strutsやseaser…etで動いているシステムの保守は続いている。 - 既存システムを技術スタックをそのままにモダナイズする動きは国内でもめずらしくない。 - SpringMV → Front - Bak構成へのアーキテクチャ分割とか 　→　すでに描画用のデータフェッチや加工に関するロジックがJavaで書かれている！ 新規開発以外でなら...? 稼働中のシステムでいうとJVM系技術の使用したシステムの母数は圧倒的
5. 5 新規開発以外でなら...? 稼働中のシステムでいうとJVM系技術の使用したシステムの母数は圧倒的 SpringMV Front (SPA) BFF (QraphQL) Bak (Spring) AS IS TO BE ←　ここに既存ロジックが活かせる。
6. 6 - 迅速なオートスケール - ログ統合/監視 - 複雑なエラーハンドリング 　→　この辺のエコシステムさえ整っていれば全然いけそう。 Q : BFFに求められる技術要件を満たせるか? BFFが採用されるマイクロサービスアーキテクチャにおける技術観点を参考に評価する。
7. 7 - 迅速なオートスケール - quarkus-smallrye-graphqlを使用すれば、Sptingライクな開発者体験を位事しつつ、 Nativeビルドによるイメージの軽量化等の恩恵が受けられる。 - ログ統合/監視 - 複雑なエラーハンドリング - 横断処理の記述になるそうていのため、もともと得意な Aspet系の処理が活きてくる。 　 →　なんだよ、いけそうじゃねえか。 A : BFFに求められる技術要件を満たせられる！ BFFが採用されるマイクロサービスアーキテクチャにおける技術観点を参考に評価する。
8. 8 - SPA化やAPI公開のようなユースケースへの対応は全然可能。 - SI系の業界とかだと遭遇機会多そう。 - ぶっちゃけ脱Springすればコンテナ技術も活かせる。 総括 既にJVMで動いているシステムでならモダナイズの波に乗ってまだまだ戦えるぞ