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
64
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
How to Ace a Technical Interview
jacobian
276
23k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
KATA
mclloyd
29
14k
Designing for humans not robots
tammielis
250
25k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
4 Signs Your Business is Dying
shpigford
182
22k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
Facilitating Awesome Meetings
lara
52
6.2k
YesSQL, Process and Tooling at Scale
rocio
172
14k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.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で動いているシステムでならモダナイズの波に乗ってまだまだ戦えるぞ