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
73
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
RailsConf 2023
tenderlove
30
1.2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.6k
Gamification - CAS2011
davidbonilla
81
5.4k
Making Projects Easy
brettharned
117
6.3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
20k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
810
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
What's in a price? How to price your products and services
michaelherold
246
12k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
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で動いているシステムでならモダナイズの波に乗ってまだまだ戦えるぞ