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
47
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
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
A better future with KSS
kneath
231
16k
Building Applications with DynamoDB
mza
88
5.7k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.7k
How GitHub (no longer) Works
holman
305
140k
Atom: Resistance is Futile
akmur
260
25k
A Modern Web Designer's Workflow
chriscoyier
689
190k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
358
22k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
188
16k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
660
120k
Building Flexible Design Systems
yeseniaperezcruz
320
37k
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で動いているシステムでならモダナイズの波に乗ってまだまだ戦えるぞ