Drizzle@1.00β の RQ2 で作る GraphQL API
Drizzle Relational Queries version 2🔗
Drizzle@1.00β によって、Drizzle ORM の Relational Queries (RQ) が version 2 へとアップデートされました。
これは、SQL を直接的に扱うことを重視してきた Drizzle が、開発者体験 (DX) を向上させるために高レベルな抽象化を取り入れた重要な進化です。
この記事では、公式ドキュメントおよび Prisma が提唱する「ORM Convergence(ORM の収束)」という観点から、RQ v2 の変更点とその背景を解説します。
背景:ORM Convergence(ORM の収束)🔗
Prisma のブログ記事 The ORM Convergence では、「異なる哲学から始まった ORM であっても、プロダクションレベルの課題に直面すると、似たような解決策(機能・API)に収束していく」 という興味深い現象が指摘されています。
- Prisma: スキーマ駆動で、直感的なオブジェクトベースの API からスタート。
- Drizzle: "If you know SQL, you know Drizzle" を掲げ、SQL に近い操作性を重視してスタート。
しかし、アプリケーションが複雑化し、リレーションを含むデータを効率的に取得する必要が出てくると、生の SQL や単純なクエリビルダだけでは記述が冗長になりがちです。
Drizzle RQ v2 は、Prisma が開拓した 「オブジェクトベースのクエリ構文(Include や Select のようなパターン)」 を採用することで、複雑なデータ取得を宣言的かつ直感的に記述できるようにしました。
これは Drizzle が「SQL ファースト」を捨てたわけではなく、「SQL の制御力」と「モダンな DX」のいいとこ取り を目指した結果と言えます。
v1 から v2 への主な変更点🔗
Drizzle の公式ドキュメント に基づき、具体的な変更点を見ていきます。
1. リレーション定義の一元化と構文変更🔗
v1 ではテーブル定義の直後にリレーションを記述していましたが、v2 では relations 関数を使ってより整理された形で定義できるようになりました。また、パラメータ名が直感的に変更されています。
変更点:
- パラメータ名:
fields/referencesがfrom/toに変更されました。視覚的に「どこからどこへ」結合するかが分かりやすくなっています。 - Many-to-Many の簡素化: 中間テーブルを意識せずに記述できる
throughオプションが導入されました。
1// v2 でのリレーション定義例2import { relations } from "drizzle-orm";34export const usersRelations = relations(users, ({ many }) => ({5 posts: many(posts),6}));78export const postsRelations = relations(posts, ({ one }) => ({9 author: one(users, {10 fields: [posts.authorId],11 references: [users.id],12 }),13}));
2. クエリ構文のオブジェクト化🔗
これが最大の変化です。v1 ではコールバック関数を多用していましたが、v2 では Prisma ライクなオブジェクト形式で where, orderBy, with (リレーション取得) を記述できます。
v1 のスタイル (Callback ベース):
1const result = await db._query.users.findMany({2 where: (users, { eq }) => eq(users.id, 1),3 with: {4 posts: true,5 },6});
v2 のスタイル (Object ベース):
1const result = await db.query.users.findMany({2 where: {3 id: 1,4 },5 with: {6 posts: {7 limit: 10,8 orderBy: { createdAt: "desc" }, // オブジェクト内で完結9 },10 },11});
v2 では、ネストしたリレーションに対しても limit や offset、フィルタリングを直感的に適用できるようになっています。
3. Many-to-Many の大幅な改善🔗
v1 では Many-to-Many リレーションを扱う際に、中間テーブルを手動で結合したりマップしたりする必要がありましたが、v2 では through を使うことで、直接関連エンティティを取得・フィルタリングできるようになりました。
4. その他🔗
- 必須リレーション:
optional: falseを指定することで、TypeScript の型レベルでリレーションが存在することを保証できるようになりました。 - マイグレーション: 既存の v1 コードも動作するように後方互換性が考慮されていますが、新しい機能を使うには v2 構文への移行が推奨されます。
Pothos と Drizzle Plugin🔗
Drizzle RQ v2 の進化は、GraphQL サーバー構築においても大きなメリットをもたらします。とくに TypeScript 製の Code-first GraphQL スキーマビルダーである Pothos との組み合わせが強力です。
Pothos とは?🔗
Pothos は、型安全性と開発者体験(DX)を最優先に設計された TypeScript 向けの GraphQL スキーマビルダーです。
自動生成に頼らず、TypeScript の強力な型推論を活用してコードベースでスキーマを定義していくスタイルが特徴で、Prisma との親和性が高いことでも知られています。
@pothos/plugin-drizzle🔗
Pothos には公式の Drizzle プラグイン が用意されており、Drizzle RQ v2 の機能をフル活用して GraphQL API を効率的に構築できます。
主な特徴は以下の通りです:
- Drizzle スキーマからの型定義: Drizzle のテーブル定義を元に GraphQL の Object Type を簡単に定義できます。型情報は自動的に推論されるため、手動で型を書く手間が省けます。
- クエリの最適化 (N+1 問題の解決): GraphQL クエリで要求されたフィールドやリレーションだけをデータベースから取得するように、Drizzle のクエリを自動的に構築します。これは Drizzle RQ の
with構文などを活用して行われ、過剰なデータ取得を防ぎます。 - Relay スタイルのサポート: Relay 準拠の Connection や Global ID (Node インターフェイス) を簡単に実装できるヘルパーが提供されています。
実装イメージ🔗
プラグインを利用すると、以下のように Drizzle のスキーマ定義を直接参照して GraphQL の型を定義できます。
1import { builder } from "./builder";2import { users } from "./db/schema";34// Drizzle のテーブル定義 (users) から GraphQL Object Type を作成5builder.drizzleObject("users", {6 fields: (t) => ({7 id: t.exposeID("id"),8 name: t.exposeString("name"),9 // リレーションも簡単に定義可能10 posts: t.relation("posts", {11 // 必要な引数やソート順なども指定可能12 args: {13 limit: t.arg.int(),14 },15 query: (args, context) => ({16 limit: args.limit ?? 10,17 orderBy: { createdAt: "desc" },18 }),19 }),20 }),21});
このように、Drizzle RQ v2 の表現力と Pothos の型安全性を組み合わせることで、非常に効率的かつ堅牢な GraphQL API 開発が可能になります。
GraphQL API の自動構築🔗
さらに開発を加速させるツールとして、pothos-drizzle-generator というライブラリを作成しました。
これは、Drizzle のスキーマ定義を読み取り、Pothos の GraphQL スキーマ定義コードを自動生成する ライブラリです。
手動で builder.drizzleObject を個別に定義していく手間を大幅に削減できます。
主な機能🔗
- 全テーブルの自動型定義: Drizzle スキーマに含まれるすべてのテーブルに対して、GraphQL Object Type を自動生成します。
- リレーションの自動解決:
relationsで定義されたリレーションも自動的に GraphQL フィールドとして追加されます。 - CRUD オペレーションの生成: 設定によっては、基本的な Query や Mutation (CRUD) も自動生成可能です。
使用イメージ🔗
Pothos のビルダー初期化時にプラグインとして追加するだけで利用できます。
1import SchemaBuilder from "@pothos/core";2import DrizzlePlugin from "@pothos/plugin-drizzle";3import { PothosDrizzleGeneratorPlugin } from "pothos-drizzle-generator";4import { db } from "./db";5import * as schema from "./db/schema";67const builder = new SchemaBuilder({8 plugins: [DrizzlePlugin, PothosDrizzleGeneratorPlugin],9 drizzle: {10 client: db,11 schema: schema,12 },13 pothosDrizzleGenerator: {14 //...カスタマイズオプション15 },16});1718// これだけでGraphQLのスキーマが自動構築される19export const schema = builder.toSchema();
このように、Drizzle RQ v2 でデータベーススキーマとリレーションをしっかり定義しておけば、GraphQL API の大部分を自動で構築できる環境を構築できます。
「まずは自動生成でベースを作り、必要な部分だけ Pothos で手動拡張する」というハイブリッドな開発が行えます。
具体的な実装サンプル🔗
実際のプロジェクトでの構成イメージを掴むために、SoraKumo001/pothos-drizzle-generator-sample を参考に、具体的な実装方法を見てみましょう。
このサンプルは、Hono, Drizzle ORM, Pothos, そして pothos-drizzle-generator を組み合わせ、セキュアで型安全な GraphQL API を構築する実践的な例です。動作の確認は Apollo Explorer で行います。

1. プロジェクト構成🔗
主要なファイル構成は以下のようになっています。Drizzle の定義と Pothos の設定が明確に分かれています。この分離により、データベースのスキーマ変更が API 定義に与える影響を管理しやすくなります。
1src/2├── db/3│ ├── schema.ts # Drizzle テーブル定義 (データ構造)4│ └── relations.ts # Drizzle リレーション定義 (テーブル間の関係)5├── builder.ts # Pothos ビルダー設定 (プラグイン設定とセキュリティ定義)6├── context.ts # コンテキスト定義 (ユーザー情報など)7└── index.ts # Hono サーバーのエントリーポイント
2. Drizzle スキーマとリレーションの定義🔗
データモデルの定義は Drizzle ORM の中核です。v2 構文を用いて、テーブルとリレーションを定義します。
ER 図
まず、作成するデータモデルの全体像を把握しましょう。ユーザーが記事を投稿し、その記事に複数のカテゴリを付与できる一般的なブログシステムの構成です。
erDiagram
User ||--o{ Post : "author"
Post ||--o{ PostToCategory : "categories"
Category ||--o{ PostToCategory : "posts"
User {
uuid id PK
text email UK
text name
Role_array roles "Enum: ADMIN, USER"
timestamp createdAt
timestamp updatedAt
}
Post {
uuid id PK
boolean published
text title
text content
uuid authorId FK
timestamp createdAt
timestamp updatedAt
timestamp publishedAt
}
Category {
uuid id PK
text name
timestamp createdAt
timestamp updatedAt
}
PostToCategory {
uuid postId FK "PK"
uuid categoryId FK "PK"
}
テーブル定義 (src/db/schema.ts)
Drizzle ORM を使用してテーブル定義を行います。ここでは PostgreSQL を想定していますが、Drizzle は他のデータベースもサポートしています。pgTable を使用してテーブルの構造を定義し、各カラムの型や制約(notNull, default, primaryKey など)を設定します。
1// src/db/schema.ts2import {3 pgTable,4 uuid,5 text,6 boolean,7 timestamp,8 pgEnum,9 primaryKey,10} from "drizzle-orm/pg-core";1112// ユーザーロールを定義するEnum13export const roleEnum = pgEnum("Role", ["ADMIN", "USER"]);1415// 'User'テーブル16export const users = pgTable("User", {17 id: uuid().defaultRandom().primaryKey(),18 email: text().notNull().unique(),19 name: text().notNull().default("User"),20 roles: roleEnum().array().default(["USER"]).notNull(),21 createdAt: timestamp({ withTimezone: true }).defaultNow().notNull(),22 updatedAt: timestamp({ withTimezone: true }).defaultNow().notNull(),23});2425// 'Post'テーブル26export const posts = pgTable("Post", {27 id: uuid().defaultRandom().primaryKey(),28 published: boolean().notNull().default(false),29 title: text().notNull().default("New Post"),30 content: text().notNull().default(""),31 authorId: uuid().references(() => users.id, { onDelete: "cascade" }), // 外部キー32 createdAt: timestamp({ withTimezone: true }).defaultNow().notNull(),33 updatedAt: timestamp({ withTimezone: true }).defaultNow().notNull(),34 publishedAt: timestamp({ withTimezone: true }).defaultNow().notNull(),35});3637// 'Category'テーブル38export const categories = pgTable("Category", {39 id: uuid().defaultRandom().primaryKey(),40 name: text().notNull(),41 createdAt: timestamp({ withTimezone: true }).defaultNow().notNull(),42 updatedAt: timestamp({ withTimezone: true }).defaultNow().notNull(),43});4445// 'PostToCategory' 中間テーブル (多対多)46export const postsToCategories = pgTable(47 "PostToCategory",48 {49 postId: uuid()50 .notNull()51 .references(() => posts.id, { onDelete: "cascade" }),52 categoryId: uuid()53 .notNull()54 .references(() => categories.id, { onDelete: "cascade" }),55 },56 (t) => [primaryKey({ columns: [t.postId, t.categoryId] })] // 複合主キー57);
リレーション定義 (src/db/relations.ts)
Drizzle RQ v2 の重要な機能であるリレーション定義です。relations 関数を使い、テーブル間の関係性を一元管理します。これにより、GraphQL クエリでネストされたデータを取得する際(例: posts と一緒に author を取得)、Drizzle が適切な JOIN クエリを生成できるようになります。
1// src/db/relations.ts2import { defineRelations } from "drizzle-orm";3import * as schema from "./schema.js";45export const relations = defineRelations(schema, (r) => ({6 // Userは複数のPostを持つ (One-to-Many)7 users: {8 posts: r.many.posts({9 from: r.users.id,10 to: r.posts.authorId,11 }),12 },13 // Postは一人のUser(author)と複数のCategoryを持つ14 posts: {15 author: r.one.users({16 from: r.posts.authorId,17 to: r.users.id,18 }),19 categories: r.many.categories({20 from: r.posts.id.through(r.postsToCategories.postId),21 to: r.categories.id.through(r.postsToCategories.categoryId),22 }),23 },24 // Categoryは複数のPostを持つ25 categories: {26 posts: r.many.posts(),27 },28 // 中間テーブルのリレーション定義29 postsToCategories: {30 post: r.one.posts({31 from: r.postsToCategories.postId,32 to: r.posts.id,33 }),34 category: r.one.categories({35 from: r.postsToCategories.categoryId,36 to: r.categories.id,37 }),38 },39}));
3. Generator の設定とセキュリティ制御🔗
src/builder.ts では、Pothos のスキーマビルダーを初期化し、PothosDrizzleGeneratorPlugin を設定します。
このプラグインの真価は、単に API を自動生成するだけでなく、「誰が」「どのデータに」アクセスできるか というセキュリティルール(Authorization)をコードベースで柔軟に定義できる点にあります。
1// src/builder.ts2const builder = new SchemaBuilder<PothosTypes>({3 plugins: [DrizzlePlugin, PothosDrizzleGeneratorPlugin],4 pothosDrizzleGenerator: {5 // 1. グローバルな実行制御6 // 未認証ユーザーによる Mutation (書き込み操作) を全面的に禁止します。7 // これにより、個別のリゾルバで認証チェックを行う手間が省けます。8 executable: ({ operation, ctx }) => {9 if (operation === "mutation" && !ctx.user) return false;10 return true;11 },1213 // 2. 行レベルセキュリティ (RLS) のようなフィルタリング14 // クエリやミューテーションの実行時に、自動的に WHERE 句を追加してアクセス制御を行います。15 where: ({ ctx, operation }) => {16 // Query: 公開済みの記事、または自分が作成した記事のみを取得可能にします。17 // 下書き記事が他人の目に触れるのを防ぎます。18 if (operation === "query") {19 return {20 OR: [{ authorId: ctx.user?.id }, { published: true }],21 };22 }23 // Mutation: 自分の記事のみを操作(更新・削除)可能にします。24 if (operation === "mutation") {25 return { authorId: ctx.user?.id };26 }27 },2829 // 3. データ挿入時の自動入力30 // 新規作成時、クライアントからの入力を待たずに、サーバー側で値を強制的にセットします。31 // ここでは、記事作成時に authorId にログインユーザーの ID を自動セットしています。32 inputData: ({ ctx }) => {33 return { authorId: ctx.user?.id };34 },35 },36});
4. Hono サーバーとの統合🔗
src/index.ts で Hono サーバーを立ち上げ、GraphQL エンドポイントを作成します。
Hono のミドルウェア機能を利用して JWT 認証を行い、その結果(ユーザー情報)を GraphQL のコンテキスト(ctx)に注入します。これにより、先ほどの builder.ts 内で ctx.user を利用できるようになります。
1// src/index.ts2const app = new Hono();34// 認証ミドルウェア:5// リクエストヘッダーやCookieからトークンを取得し、検証します。6// 検証に成功すれば、ユーザー情報をコンテキストにセットします。7app.use(async (c, next) => {8 const token = getCookie(c, "auth-token");9 const user = await verifyToken(token); // 擬似コード: 実際にはJWT検証ロジックが入ります10 c.set("user", user);11 await next();12});1314// GraphQL エンドポイント15// 生成されたスキーマを用いてGraphQLリクエストを処理します。16app.post("/", (c) => {17 return graphqlServer({ schema })(c);18});1920// 開発用: ブラウザで開くと Apollo Explorer が起動21// 開発中はブラウザから手軽にクエリを試すことができます。22app.get("/", (c) => {23 return c.html(explorer({ endpointUrl: "/" }));24});
5. 生成される API の利用例🔗
pothos-drizzle-generatorにより、定義したモデル(users, posts, categories)に基づいて、以下の GraphQL 操作が自動的に生成されます。開発者はリゾルバをひとつひとつ手書きする必要はありません。
-
クエリ (Read):
findMany*: 複数件のレコードを取得します。(例:findManyUsers)findFirst*: 条件に一致する最初の 1 件を取得します。(例:findFirstPost)count*: 条件に一致するレコード数を取得します。(例:countPosts)
-
ミューテーション (Create/Update/Delete):
create*: 新しいレコードを作成します。(例:createPost)update*: 既存のレコードを更新します。(例:updatePost)delete*: レコードを削除します。(例:deletePost)
-
強力なフィルタリング:
クエリでは、AND,OR,NOT,eq,ne,gt,gte,lt,lte,like,inなど、SQL に匹敵する柔軟なフィルタ条件が利用可能です。
このセットアップにより、以下のような高度な GraphQL 操作がすぐに利用可能になります。
クエリ例: 公開記事の取得🔗
まずはデータを取得するクエリの例です。
ここでは、「公開されている記事(published: true)」を「作成日時の降順(orderBy: { createdAt: Desc })」で取得しています。
同時に、その記事の「著者名(author { name })」もリレーション経由で取得しています。
1query {2 findManyPost(3 where: { published: { eq: true } }4 orderBy: { createdAt: Desc }5 ) {6 id7 title8 createdAt9 author {10 name11 }12 }13}
生成された SQL
このクエリに対して生成される SQL は以下のようになります。
重要な点は、LEFT JOIN LATERAL を使用して、記事データと著者データを 1 回のクエリで効率的に取得している ことです。
これにより、GraphQL でよくある「N+1 問題(親データの数だけ子データの取得クエリが走ってしまう問題)」を回避し、高いパフォーマンスを実現しています。
1SELECT2 "d0"."id" AS "id",3 "d0"."title" AS "title",4 "d0"."createdAt" AS "createdAt",5 "author"."r" AS "author"6FROM7 "Post" AS "d0"8 LEFT JOIN LATERAL (9 SELECT10 row_to_json("t".*) "r"11 FROM12 (13 SELECT14 "d1"."name" AS "name"15 FROM16 "User" AS "d1"17 WHERE18 "d0"."authorId" = "d1"."id"19 LIMIT20 1 /*$1*/21 ) AS "t"22 ) AS "author" ON TRUE23WHERE24 (25 "d0"."published" = true /*$2*/26 AND "d0"."published" = true /*$3*/27 )28ORDER BY29 "d0"."createdAt" DESC;
ミューテーション例: 記事の作成🔗
次はデータを新規作成するミューテーションです。
入力パラメータ (input) には title, content, published だけを指定しています。
テーブル定義では authorId が必須ですが、builder.ts で設定した inputData により、サーバー側でログイン中のユーザー ID が自動的に挿入されます。
1mutation {2 createOnePost(3 input: {4 title: "Pothos と Drizzle の連携"5 content: "コンテンツ"6 published: true7 }8 ) {9 id10 author {11 name12 }13 }14}
動作 1: サインインしていない場合
builder.ts の executable 設定により、未認証ユーザー(ctx.user が存在しない場合)の Mutation はブロックされます。
そのため、以下のような「No permission」エラーが返ります。これにより、個別に権限チェックを書かなくてもセキュアな API が保たれます。
1{2 "errors": [3 {4 "message": "No permission",5 "locations": [6 {7 "line": 2,8 "column": 39 }10 ],11 "path": ["createOnePost"]12 }13 ]14}
動作 2: サインインしている場合
認証済みであれば、トランザクション内で INSERT が実行されます。
INSERT 文の VALUES を見ると、4 番目のパラメータとしてユーザー ID (ab2f7431-...) が自動的にセットされていることがわかります。
1BEGIN;2--3INSERT INTO4 "Post" ("id", "published", "title", "content", "authorId", "createdAt", "updatedAt", "publishedAt")5VALUES6 (7 DEFAULT,8 true /*$1*/,9 'Pothos と Drizzle の連携' /*$2*/,10 'コンテンツ' /*$3*/,11 'ab2f7431-0e7a-4ebf-9ef0-728a4e5a8f59' /*$4*/,12 DEFAULT,13 DEFAULT,14 DEFAULT15 )16RETURNING17 "id";18--19COMMIT;20--21-- 続けて、レスポンスに必要なデータを取得するSELECTが走ります22SELECT23 "d0"."id" AS "id",24 "author"."r" AS "author"25FROM26 "Post" AS "d0"27...
ミューテーション例: 記事の更新 (ManyToMany リレーションの操作)🔗
Drizzle RQ v2 の強力な点は、中間テーブル(PostToCategory)を意識せずに、多対多のリレーションを直感的に更新できることです。
以下の例では、categories フィールドに対して set を使い、その記事に関連付けたいカテゴリの ID リストを渡しています。
1mutation {2 updatePost(3 where: { id: { eq: "4493c608-fa6c-4cc4-9346-9f41bbc48bd4" } }4 input: {5 title: "更新されたタイトル"6 categories: {7 set: [8 { id: "663f796b-7ec0-4cda-8484-af8fe4197463" }9 { id: "7d503606-1c2b-479d-a0e6-597d46836e3c" }10 ]11 }12 }13 ) {14 id15 title16 updatedAt17 categories {18 name19 }20 }21}
生成される SQL
この操作ひとつで、以下の処理がトランザクション内で自動的に行われます。
Postテーブル自体の更新 (UPDATE "Post" ...)- 古いカテゴリ関連付けの削除 (
DELETE FROM "PostToCategory" ...) - 新しいカテゴリ関連付けの挿入 (
INSERT INTO "PostToCategory" ...)
これらを手動で実装するのは非常に手間がかかりますが、自動生成された API ならクライアントから直感的なパラメータを送るだけで完結します。
1BEGIN;2-- 1. 記事本体の更新3UPDATE "Post"4SET5 "title" = '更新されたタイトル' /*$1*/,6 "authorId" = 'ab2f7431-0e7a-4ebf-9ef0-728a4e5a8f59' /*$2*/7WHERE ...8RETURNING ...;9-- 2. 古い関連の削除10DELETE FROM "PostToCategory"11WHERE12 "PostToCategory"."postId" = '4493c608-fa6c-4cc4-9346-9f41bbc48bd4' /*$1*/;13-- 3. 新しい関連の挿入14INSERT INTO15 "PostToCategory" ("postId", "categoryId")16VALUES17 ('4493c608-fa6c-4cc4-9346-9f41bbc48bd4' /*$1*/, '663f796b-7ec0-4cda-8484-af8fe4197463' /*$2*/),18 ('4493c608-fa6c-4cc4-9346-9f41bbc48bd4' /*$3*/, '7d503606-1c2b-479d-a0e6-597d46836e3c' /*$4*/);19--20COMMIT;21...
ミューテーション例: 記事の削除🔗
記事の削除もシンプルです。削除したい記事の ID を where 条件で指定します。
ここでも builder.ts の where 設定(自分の記事しか操作できない)が効いているため、他人の記事を勝手に削除することはできません。
1mutation {2 deletePost(where: { id: { eq: "uuid-of-the-post" } }) {3 id4 }5}
認証フローの確認🔗
最後に、このサンプルで実装されている認証フローを確認するためのミューテーションです。
サインイン
メールアドレスを送信してサインインします(サンプルなのでパスワードレスです)。
成功すると、サーバーは Set-Cookie ヘッダーを使って HTTP-only Cookie に JWT トークンを保存します。これにより、以降のすべてのリクエストで自動的に認証情報が送信されるようになります。
1mutation {2 signIn(email: "redolent_osie@msn.com") {3 id4 email5 name6 roles7 }8}
現在のユーザー情報の取得 (Me)
現在サインインしているユーザー自身の情報を取得します。
Cookie が正しく送信され、サーバー側で JWT が検証されているかを確認するのに便利です。
1mutation {2 me {3 id4 email5 roles6 }7}
サインアウト
サインアウトして、ブラウザの Cookie をクリアします。
1mutation {2 signOut3}
まとめ🔗
このように、pothos-drizzle-generator を使用することで、Drizzle ORM で定義したスキーマから、実用的でセキュアな GraphQL API を瞬時に構築できます。
- 型安全性: TypeScript による完全な型補完。
- 高パフォーマンス: Drizzle RQ v2 による最適化された SQL 生成。
- 高い生産性: CRUD やリレーション操作の自動生成による工数削減。
- 柔軟なセキュリティ: コードベースで定義できる詳細なアクセス制御。
Drizzle の正式版リリースとともに、このスタックはさらに強力な選択肢となるでしょう。