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
TypeScriptのバックエンド開発について
Search
mimu
October 21, 2024
Programming
70
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
TypeScriptのバックエンド開発について
mimu
October 21, 2024
More Decks by mimu
See All by mimu
マルチレポだってスキーマ駆動開発がしたい!
mmrakt
0
73
lt.pdf
mmrakt
0
47
npm/Yarn/pnpmゆるふわ解説
mmrakt
0
1.4k
Type Script型パズル(?)超入門
mmrakt
0
100
まだWebpackで消耗してるの?
mmrakt
0
100
Other Decks in Programming
See All in Programming
2年かけて Deno に DOMMatrix を実装した話 / How I implemented DOMMatrix in Deno over two years
petamoriken
0
210
Built Our Own Background Agent at LayerX
layerx
PRO
10
5.4k
仕様駆動開発へのトライを機に チームに適合する手法を模索し続けている話
freee
PRO
0
500
そこに3びきプロダクトがいるじゃろう——生成AI時代における“価値が届かない理由”の構造
kosuket
0
480
楽しそうなつよつよエンジニアと目が死んでる僕/A brilliant engineer having a blast, and dead-eyed me.
3l4l5
2
180
AIが無かった頃の素敵な出会いの話
codmoninc
1
430
freee が目指す データ マネジメント戦略 AI-Ready 時代を支える 攻めのガバナンスとは
freee
PRO
0
360
PostgreSQL 18で考えるUUID主キー
kazuhiro1982
0
470
PHP に部分適用が来るぞ!……ところで何それ?おいしいの? #phpcon / phpcon-2026
shogogg
0
660
複数の Claude Code が"放置"されてしまう問題をCLI ダッシュボードを自作して解決した話
sumihiro3
1
680
PHP Application における Kubernetes 内 gRPC 通信
ganchiku
0
590
生成AI導入の「期待外れ」を乗り越える ー 開発フロー改革が目指す、真の組織変革
starfish719
0
4.4k
Featured
See All Featured
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1.1k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.5k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
440
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
640
The agentic SEO stack - context over prompts
schlessera
0
860
Google's AI Overviews - The New Search
badams
0
1.1k
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
200
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
4.3k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
540
Heart Work Chapter 1 - Part 1
lfama
PRO
8
36k
How Software Deployment tools have changed in the past 20 years
geshan
1
34k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.6k
Transcript
TSのバックエンド開発に ついて
TOC - やってきたこと - 今後の課題 - まとめ
Challenges 1. AWS Lambda を用いた非同期処理実装 2. API 定義からTypeScriptの型生成&パッケージ共 有
Lambdaを用いた 非同期処理① - 「データの整合性をチェックしてExcel出力する機能」の処理が非常に重く、BE APIからのレスポンスでタイムアウトが発生 - FE ➡ BE APIの同期処理から、Lamdbaを用いた非同期処理に移行
- フロント->バックエンドAPIからLambdaをキックし(正確にはSNSを経由)、フ ロントに一旦レスポンスを返す - フロントから手動でポーリングし、LambdaによるExcel生成処理が終了して いればDL用のリンクを返す
Lambdaを用いた非同期処理② - 非同期化するも処理が想定以上に重く、今度は Lambdaがタイムアウト(Max15min) - ワークフロー構築サービスの AWS Step Functionsを用いてLambdaを処理単 位で分割&ボトルネック部分を並列実行させること
で何とかタイムアウトを解消
Lambdaを用いた非同期処理② - 非同期化するも処理が想定以上に重く、今度は Lambdaがタイムアウト(Max15min) - ワークフロー構築サービスの AWS Step Functionsを用いてLambdaを処理単 位で分割&ボトルネック部分を並列実行させること
で何とかタイムアウトを解消 ここまで辿り着くのに 2~3ヶ月費やすも、 ステークホルダーの信頼獲得&メンバーのレベル アップに繋がった(はず)
None
API定義からTSの型生成&パッケージ共有① - 機能開発の流れ - APIスキーマ定義->FEはそれを元にMSWのモックを利用して 開発 - 状況 - FEとBEどちらもTypeScriptを採用しているが、別repo(マルチ
レポジトリ)に別れており、型定義が共有できない問題 - 特にAPI周りのほぼ同じ型定義を自前で書いており、メンテコ ストが肥大化
API定義からTSの型生成&パッケージ共有① - APIのスキーマから型定義を自動で生成させる - Orvalを採用(他はopenapi-typescript、 swagger-typescript-apiなど色々存在) - 型定義をNpmパッケージ化し、GitHub Packagesでプライベート に公開することでFE・BE(その他repo)で利用可能に
- 残課題はあるものの、スキーマ駆動開発の土台は完成
Problems - BE Appのアーキテクチャ再考 - NoSQLのテーブル設計 - スキーマ駆動開発の推進 - CICD
強化 - Lambda は未だ温かみのある手動デプロイ - …etc
Problems - BE Appのアーキテクチャ再考 - NoSQLのテーブル設計 - スキーマ駆動開発の推進 - CICD
強化 - Lambda は未だ温かみのある手動デプロイ - …etc
BE Appのアーキテクチャ再考 - 現状はDDD(ドメイン駆動設計)を意識した(っぽい)アーキテクチャ で設計されているが、色々と柔い - ドメイン層からビジネスルールが漏れまくっていたり、ユースケースが入力 バリデーションからAPIレスポンス整形まで全部担ってしまったり。。。 - アーキテクチャに関する意思決定の証跡が残っていない問題。。
➡ADR活用中!
BE Appのアーキテクチャ再考 NBX主導のFEの大規模リファクタリングの成功に倣って、BEの リファクタも成功させたい! BEの設計について知見のあるエンジニアが少なく。。我こそはと いう方がもしいれば🙏🙏🙏
NoSQL(DynamoDB)のテーブル設計 - DBにDynamoDBを使用しているが、RDBとは思想や設計手法が 大きく異なる - テーブル数は極力少なく、正規化もしない(重複可) - RDBほどSQLの柔軟性がなく、セカンダリインデックスの活用等テクニック が求められる -
ちなみに採用した経緯も正確には不明。。
NoSQL(DynamoDB)のテーブル設計 - 現状はユーザー(とデータ量)も少ないため割とカジュアルに本番 データを入れ替えたり設計変更しているが、今後は事前の入念な 設計が必要になる - 本来スキーマレスではあるものの、テーブル設計の都合にア プリ側が引っ張られて非効率なコードが生まれている状況
Summary - 色々とチャレンジを成功させているものの、問題は山積み。。 - FE領域では既に信頼を獲得しているので、BEやインフラ周 りまで染み出せるとより評価は上がる! - 我々はFEが強みだが、BEもできるぜ!な人がより増えると CLの信頼はきっと上がるはず!