Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GraphQLのBFFをJVMで書く理由を模索してみた_LT用
Search
iwaseshi
August 06, 2022
0
68
GraphQLのBFFをJVMで書く理由を模索してみた_LT用
iwaseshi
August 06, 2022
Tweet
Share
More Decks by iwaseshi
See All by iwaseshi
ソフトウェアを作る際に意識してほしい責務と依存性
iwaseshi
5
16k
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
A Tale of Four Properties
chriscoyier
158
23k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Into the Great Unknown - MozCon
thekraken
36
1.7k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Producing Creativity
orderedlist
PRO
344
40k
Java REST API Framework Comparison - PWX 2021
mraible
29
8.5k
Transcript
1 GraphQLのBFFをJVMで書く理由を模索してみた
2 API開発において技術選定されることが年々減ってきている...気がする。 - バックエンド技術のモダン化に取り残されている。 - 新規のプロダクト作りだとGo、Python、Node.jsがバックエンドとして選択されることが多い。 (*1) - コンテナ技術との相性が悪い。 -
GraalVMでネイティブビルドこそできるが、 JVMのAPI開発でベターなSpringがクソ重い。 → どうにか覇権を取り返せないか?! (*1)https://to-a.org/news/2022/05/12/7631/ より上位企業の選定技術より 模索のモチベーション なんか最近バックエンド界隈でJVM系言語の肩身狭くね?
3 QraphQLを利用したBFFの導入事例が増えてきた。 - 主にGo、Node.jsで実装されることが多い。 - バックエンドがGoで実装されているなら素直にGoで良さそうだから。 - Node.jsはフロントエンドの技術スタックをそのまま持ち越せる。 → モダンなアーキテクチャを前提とした新規開発で覇権を取りかえしにいくのは、 ちょっと現実味がなさそう...
機会となりうるもの API提供以外でのバックエンド界隈での動き
4 Springベースのものは勿論、Strutsやseaser…etで動いているシステムの保守は続いている。 - 既存システムを技術スタックをそのままにモダナイズする動きは国内でもめずらしくない。 - SpringMV → Front - Bak構成へのアーキテクチャ分割とか
→ すでに描画用のデータフェッチや加工に関するロジックがJavaで書かれている! 新規開発以外でなら...? 稼働中のシステムでいうとJVM系技術の使用したシステムの母数は圧倒的
5 新規開発以外でなら...? 稼働中のシステムでいうとJVM系技術の使用したシステムの母数は圧倒的 SpringMV Front (SPA) BFF (QraphQL) Bak (Spring)
AS IS TO BE ← ここに既存ロジックが活かせる。
6 - 迅速なオートスケール - ログ統合/監視 - 複雑なエラーハンドリング → この辺のエコシステムさえ整っていれば全然いけそう。 Q :
BFFに求められる技術要件を満たせるか? BFFが採用されるマイクロサービスアーキテクチャにおける技術観点を参考に評価する。
7 - 迅速なオートスケール - quarkus-smallrye-graphqlを使用すれば、Sptingライクな開発者体験を位事しつつ、 Nativeビルドによるイメージの軽量化等の恩恵が受けられる。 - ログ統合/監視 - 複雑なエラーハンドリング
- 横断処理の記述になるそうていのため、もともと得意な Aspet系の処理が活きてくる。 → なんだよ、いけそうじゃねえか。 A : BFFに求められる技術要件を満たせられる! BFFが採用されるマイクロサービスアーキテクチャにおける技術観点を参考に評価する。
8 - SPA化やAPI公開のようなユースケースへの対応は全然可能。 - SI系の業界とかだと遭遇機会多そう。 - ぶっちゃけ脱Springすればコンテナ技術も活かせる。 総括 既にJVMで動いているシステムでならモダナイズの波に乗ってまだまだ戦えるぞ