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
53
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
Debugging Ruby Performance
tmm1
71
11k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
121
18k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
17
8.7k
Art, The Web, and Tiny UX
lynnandtonic
291
20k
Scaling GitHub
holman
458
140k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
129
32k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
How to train your dragon (web standard)
notwaldorf
79
5.5k
The Straight Up "How To Draw Better" Workshop
denniskardys
229
130k
The Invisible Customer
myddelton
117
13k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
Web development in the modern age
philhawksworth
203
10k
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で動いているシステムでならモダナイズの波に乗ってまだまだ戦えるぞ