jsconf proposal
memo
DCI
構成
yasaichi さんの話まとめ
tara pj での技術選定とその背景
(yasaichi さんのトークで取り上げられていた) 課題が実際どう起きているか、分析と今後の改善手法
一般的に
0 Prisma とは
"Next-generation Node.js and TypeScript ORM"
Prisma の開発フロー
Prisma Schema を記述する
以下の2つが自動生成される
DBへのマイグレーションのコード (Prisma Migrate)
DBへのクエリビルダーのコード (Prisma Client)
Rails ユーザー向け情報: ridgepole (cookpad) と同じ開発フロー
Prisma の特徴
開発体験が非常に良い
1
Ruby on Rails (特に Active Record) の開発生産性の高さを評価している
開発初期: いわゆる Rails way による、開発の手数や考える量の最小化
開発中期以降: 高機能な Active Record により、ドメインロジックをモデル以下に記述できる
Prisma の評価
Prisma はテーブルデータゲートウェイである
Prisma を採用すると、トランザクションスクリプトが増えがちになる
結果、長期でみた開発生産性が低下する
Prisma 側の動き
議論できるポイント
Active Record をベースにしたドメインモデル分割は、開発生産性に寄与するか
Rails ActiveRecord 文脈でよく語られる "Fat Model" 問題
脱線するので詳細は省く
一つの解決策として Service class がよく使われる
複数のモデル(テーブル)をまたいだ Write 系の処理を担う
CQS
トランザクションスクリプトは、開発生産性を低下させるか
肥大化したトランザクションスクリプトは、開発生産性を低下させる
リファクタリングも難しくなる
一方で、初手から最適なドメインモデル分割ができるとは限らない
適切なタイミングでドメインモデルへの分割を考慮していくことは可能か?
テーブルデータゲートウェイとドメインモデルの組み合わせを実践するのは難しいのか
理論的にはできる
手数が増える
つまり上とほぼ同じ問題
仮説: 以下の手法を組み合わせることで、Prisma を利用しても開発生産性を保つことができるのではないか
CQS の利用
適切なタイミングでのドメインモデリング
2 スタディサプリの新規開発で Prisma を採用した理由
新規開発
(LP)
前段の意思決定
(飛ばす?)
コンテンツサービスの話
Architecture Decision Records: tara-content に Node.js, TypeScript, PostgreSQL, Prisma を採用する
3 技術的負債への対応
content サービスのコードは、肥大化したトランザクションスクリプトにより、開発生産性が低下していないのか?
コードベース
Read と Write に大きく分けられる
Read 側
Write 側
大きく3段階の処理に分かれる
processContents ... コンテンツデータの Git Repository から全てのデータを処理し、1枚の Plain JS Object にまとめる
deleteAllContents ...
insertContents ...
つくりなおし
Prisma
GraphQL + Prisma を利用した技術選定事例
kw: 開発生産性
Prisma を利用したアーキテクチャ考察