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
Short Introduction for Kysely
Search
YUMOTO Michitaka
November 20, 2024
Technology
1
170
Short Introduction for Kysely
Remix Tokyo × Cloudflare Meetup Lighting Talks
https://lu.ma/wv9xzam7
YUMOTO Michitaka
November 20, 2024
Tweet
Share
More Decks by YUMOTO Michitaka
See All by YUMOTO Michitaka
Dive Into Single Fetch
gothedistance
1
180
クラフトマンシップ(職人魂)を湾岸MIDNIGHTから学ぼう / Learn Craftsmanship from Wangan Midnight
gothedistance
0
250
プロ野球をデータモデリングしてみたら沼だった件 / Baseball ERD Modeling to be obsessed
gothedistance
2
760
フロントエンド開発スタイルの変遷と、私がFlutterにハマったわけ
gothedistance
8
12k
ITプロジェクトのはじめ方 / How to work around software project
gothedistance
27
150k
私がITプランナーを志すようになった理由、そして、目指していること / bpstudy142_why_i_wanna_be_a_it_plannner
gothedistance
1
860
ITプランナーの必要性を小一時間問い詰めたい / Why We need IT-Planner.
gothedistance
0
13k
IT企画をちゃんとやりたい#01 ガイダンス資料 / IT Planning do well_01
gothedistance
0
6.5k
bpstudy_127
gothedistance
0
520
Other Decks in Technology
See All in Technology
Backlog ユーザー棚卸しRTA、多分これが一番早いと思います
__allllllllez__
1
140
MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の取り組みについて / Modernize the Development Process and Visualize Development Productivity at MUIT
muit
1
15k
Operating Operator
shhnjk
1
540
LangSmith×Webhook連携で実現するプロンプトドリブンCI/CD
sergicalsix
1
210
生成AI時代 文字コードを学ぶ意義を見出せるか?
hrsued
1
810
20250707-AI活用の個人差を埋めるチームづくり
shnjtk
4
3.7k
自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025
yoshikiiida
1
15k
Claude Code に プロジェクト管理やらせたみた
unson
6
2.9k
開発生産性を測る前にやるべきこと - 組織改善の実践 / Before Measuring Dev Productivity
kaonavi
6
1.9k
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
330
20250705 Headlamp: 專注可擴展性的 Kubernetes 用戶界面
pichuang
0
250
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
7
5.2k
Featured
See All Featured
Fireside Chat
paigeccino
37
3.5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Making the Leap to Tech Lead
cromwellryan
134
9.4k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Become a Pro
speakerdeck
PRO
29
5.4k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Designing Experiences People Love
moore
142
24k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Transcript
Kysely ポータブルなTypeScript のクエリビルダ Remix Meetup #2 2024.09.17 @gothedistance Quality Start,inc
Agenda TypeScript とORM Kysely とは Kysely のPros/Cons Quality Start,inc 2
自己紹介 YUMOTO Michitaka 1979 年生まれ、松坂世代 https://x.com/gothedistance Flutter/Remix/Python を主に使っています。 野球が好きで、東京ヤクルトスワローズのファン Quality
Start,inc 3
ORM に疲れた時期が個人的にあった Remix に出会うまではPython を使うことが多く、SQLAlchemy を使った。 SQLAlchemy は重厚長大なORM で、モデル定義もガッツリ、DB とのやり取
りも独自のモデル設計。情報量がとにかく多い。 Remix を書き始めて、自分は 「コンパイルできるSQL 」 が欲しかっただけ なのでは・・・と天啓があった。 ORM のコードの書き方への習熟があっても最後は発行しているSQL のレビ ューになるし、ORM ではなくクエリビルダを使ってみようかな! というわけで、Kysely を使ってみた。 kysely-d1 を使えばCloudFlare D1 が 使える! Quality Start,inc 4
Kysely こんな感じでSQL を組み立ててくれるライブラリ。 selectFrom, innerJoin, where, select などを発行する時に、型推論が効いて いるので自動的にカラムやテーブル名の補完が走ります。 const
result = await db .selectFrom('person') .innerJoin('pet', 'pet.owner_id', 'person.id') .select(['person.id', 'pet.name as pet_name']) .execute() Quality Start,inc 5
Kysely のスキーマ定義(TypeScript の型定義) Prisma のような独自DSL ではなく、TS の型定義でDB スキーマを表現。 ORM で必ずあるリレーション定義がありません!
クエリビルダなんで! 文字数のようなカラムの付帯情報もありません! クエリビルダな(ry export type Pet = { id: Generated<number>; owner_id: Generated<int>; name: Generated<string>; created: Timestamp | null; modified: Timestamp | null; }; Quality Start,inc 6
Kysely の嬉しみ SQL の表現力を最大限にかせる!これが一番! Prisma のようなORM は、リレーション/ スキーマ定義をテコにデータの CRUD を単純化するために、SQL
の表現力を殺している。 Prisma はDB 関数,CTE,EXISTS,CASE, サブクエリなどが使えず、 queryRaw や TypedSQL で対応できるが、SQL の表現力を活かす方法に振り切ってる Kysely には勝てない。 Prisma の場合は1つの関数実行でN 個のクエリが吐かれる事が多く、個人 的に違和感がある。 ORM の設定や仕様に追従/ 習熟して得られるメリットが薄いなら、クエリ ビルダもアリよりのアリです。 Quality Start,inc 7
Kysely に求めてはあかんもの ネストされたデータの戻り値。 order:{detail: [ {item:}]} みたいな。 Kysely は一次元配列しか返しません。 SQL
の発行によってネストしたオブ ジェクトは得られないと同じ。JOIN 先のカラム名が同じ場合は上書きされ る。カラムの選択が必須になると思っていい。 マイグレーションは正直Prisma のほうが楽。モデル定義を持っているから ね。 スキーマのモデルに拡張メソッドを生やすとか、クエリ発行前にHook する イベント仕込むとか、そういうのも持ってないです。ActiveRecord 風なコ ードを書くのは難しい。 ORM との距離のとり方について誰か僕と話そう!! Quality Start,inc 8