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
GatewayパターンとSchema駆動開発
Search
andoshin11
May 07, 2019
Technology
7
1.5k
GatewayパターンとSchema駆動開発
andoshin11
May 07, 2019
Tweet
Share
More Decks by andoshin11
See All by andoshin11
カーナベルにおけるProtobuf二次利用例
andoshin11
0
140
Envoy External AuthZとgRPC Extensionを利用した「頑張らない」Microservices認証認可基盤
andoshin11
0
750
カーナベル株式会社2024年2月 エンジニアイベント資料
andoshin11
0
390
Private Cloudを支える最高のユーザーガイド運用技術
andoshin11
0
300
TS CompilerがVueを喋れても良いじゃないか
andoshin11
0
750
ain't giving up type-safe Express
andoshin11
2
450
Type Safe "Everything"
andoshin11
0
260
Hack your Nuxt router!
andoshin11
0
1.3k
Catch up Nuxt.js 2019.02
andoshin11
0
2.1k
Other Decks in Technology
See All in Technology
英語は話せません!それでも海外チームと信頼関係を作るため、対話を重ねた2ヶ月間のまなび
niioka_97
0
130
業務効率化をさらに加速させる、ノーコードツールとStep Functionsのハイブリッド化
smt7174
2
130
「れきちず」のこれまでとこれから - 誰にでもわかりやすい歴史地図を目指して / FOSS4G 2025 Japan
hjmkth
1
270
大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜
maimyyym
6
4.1k
自動テストのコストと向き合ってみた
qa
0
220
社内お問い合わせBotの仕組みと学び
nish01
1
560
Git in Team
kawaguti
PRO
3
350
How to achieve interoperable digital identity across Asian countries
fujie
0
140
【Kaigi on Rails 事後勉強会LT】MeはどうしてGirlsに? 私とRubyを繋いだRail(s)
joyfrommasara
0
230
AIツールでどこまでデザインを忠実に実装できるのか
oikon48
6
3.2k
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
1
310
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
5
710
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
65
7.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
900
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
860
For a Future-Friendly Web
brad_frost
180
9.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
189
55k
Transcript
Gatewayパターンと Schema駆動開発 2019.5.7 @andoshin11
Who am I? Shin Ando (Andy) @andoshin11 - Frontend Developer
/ Architect - Freelance Vue / Nuxt / React / Flutter / Go / Ruby etc... 2
話すこと 3 • アーキテクチャの話 • Universal Schemaの話 • TypeScriptの話
話さないこと 4 • Vue.jsの話 • Nuxt.jsの話 • ドメイン設計の話 • 具体的な実装の話
(サンプルは紹介予定)
5 本LTの内容は中規模以上 のSPAを想定しています
6 「描画」を司るデータ管理の変遷 SPA以前 • Rails, Symfony等のフルスタックフレームワークで描画も担っていた時代 • 各Modelから抽出したデータをFatなControllerに集約して描画層へ伝達 • Dirtyなデータ整形ロジックはバックエンドレイヤーで隠蔽するのが一般的
7 「描画」を司るデータ管理の変遷 SPA以前 → SPA黎明期 • フロントエンドとバックエンドの分離。 HTTPを介した疎なデータ伝達 • サーバーサイド
→ バックエンドドメインのREST APIを公開 • クライアントサイド → APIレスポンスをそのままメモリ上に保存し、描画に利用 描画(Presentation)のたびにクライアントサイドでDirtyなデータ整形処理が必要になる → ページ単位のStoreやPresenter(Getters)が量産される結果に
8 「描画」を司るデータ管理の変遷 SPA以前 → SPA黎明期 → SPA成熟期(Now!) • クライアントデータストアの設計手法が成熟 •
(中規模以上のSPAにおいては)エンドユーザーに対するデータの入出力に特化したクラ イアントドメインの定義が不可欠に • APIレスポンスをStoreに保存する前のドメイン変換レイヤーが求められるようになる
9 (番外編)バックエンドドメインとの乖離 バックエンドのドメイン設計におけるクライテリア • DBの特性 → Relation Hints, Indexability, etc…
• 言語の特性 → Value ObjectやEntityの扱いやすさ • FWおよびORMの特性 → Model Layerの扱い、DBとの結合度合い等
10 (番外編)バックエンドドメインとの乖離 バックエンドのドメイン設計におけるクライテリア • DBの特性 → Relation Hints, Indexability, etc…
• 言語の特性 → Value ObjectやEntityの扱いやすさ • FWおよびORMの特性 → Model Layerの扱い、DBとの結合度合い等 モノリシックなアプリケーションでも上記の制約が発生するのに加えて、マイクロ サービス環境ではさらに個々のドメインが疎になる
11 (番外編)バックエンドドメインとの乖離 バックエンドのドメイン設計におけるクライテリア • DBの特性 → Relation Hints, Indexability, etc…
• 言語の特性 → Value ObjectやEntityの扱いやすさ • FWおよびORMの特性 → Model Layerの扱い、DBとの結合度合い等 モノリシックなアプリケーションでも上記の制約が発生するのに加えて、マイクロ サービス環境ではさらに個々のドメインが疎になる バックエンドドメインをクライアントドメインに そのまま転写するのは厳しくなる一方
12 Translator、作りましょう ※ バックエンドのSchemaを受け取ってクライアントドメイ ンに変換する関数(逆も然り)
13 Translatorを挟むのはどこでもOK • BFF • API Clientのmiddleware • API ClientをラップするClient-Side
Gateway • etc...
14 バックエンドSchemaはどこから?
15 Universal Schema(Swagger)を利用
16 YAMLから型定義を自動生成 作った → openapi-ts-gen
17 Schemasの型定義
18
19
20 現在のワークフロー 1. Swaggerファイルを更新 (バックエンド/フロントエンド共同でメンテ) 2. 型定義をPrivate Registryに公開 3. フロントエンド開発用のStub
Serverを更新(シンプルなExpress Server) 4. GatewayのRequest / Response translatorsを更新 → APIの実装ではなくInterfaceについて逐次合意を取ることで高速な開発が可能に → APIの仕様変更はTypeScriptの型エラーとして検知可能。壊れにくい仕組みづくり
21 サンプルコード • https://github.com/andoshin11/sample-petstore-api • https://github.com/andoshin11/sample-nuxt-pet-store