![見出し画像](/_next/image?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Fonepair-production.appspot.com%2Fo%2Fshorts%252FcoverImages%252Fcfc65952-97e8-45f0-8649-15dbd9ca4881.png%3Falt%3Dmedia%26token%3D4cbd1ad3-d3be-41de-9d1f-eb4435966f91&w=3840&q=75)
こんにちは!
toridori広報担当です。
今回は弊社バックエンドエンジニアのテックブログの一部をご紹介いたします!
ーーーー
はじめに
今回はタイトルの通りTypeScriptのモダンなORMであるDrizzle ORMをこれから使ってみようとしている人や概要だけでも知っておきたいという人向けに、導入して使ってみるところまでを書いた記事になります。
実施背景と達成したいこと
業務改善システムの新規開発にてRemix × DrizzleORMを使っていこうということになり実装をはじめました。しかしDrizzleORMに関する情報はprismaなどに比べるとあまり多くはなく、これから取り組む方向けに参考情報を増やしていこうと思い、記事を書くことにしました。
実装の際、少しでも参考になることを願っています!
RemixとDrizzleORMの簡単な紹介
- Remixとは
- ReactをベースとしたフルスタックWebフレームワーク
- 従来のWeb標準を活用した、シンプルで効率的なデータローディングとフォーム処理に焦点を当てている
- Drizzle ORMとは
- TypeScriptを前提としたORMで、型安全なクエリを記述できる
- 軽量で高速なORM
- マイグレーション機能も提供している
- 複数のデータベースをサポートしている
🤔 フォルダ構成を考えてみた
drizzleのドキュメントを見ていけば何の設定を書けばいいかは見えてくるけど、フォルダ構成はドキュメントを読み自身のプロジェクトに落とし込む必要があるため、最初に置き場を考えました。
やったこと
drizzleのドキュメントを参考にし、今回Remixプロジェクトに対し以下のようにディレクトリ構成を用意しました。
良い点と微妙な点、他のORMとの比較
- 良かった点
- SQLライクにクエリがかけるのがシンプルで直感的に書けると感じました。Docsに書かれている「If you know SQL - you know Drizzle.」という言葉通りだと感じました。
- 学習コストが低いこと
- 設定が楽なこと
- 多くのデータベースと互換性があること
- 微妙な点
- マイグレーション戦略が複雑になること
- seedの仕組みが標準で備わっていないこと
- 参考文献が多いとは言えないこと
- Drizzle ORMと他のORMの比較
- よく使われるORMとしてTypeORMやprismaがあると思います。これらと比較するとDrizzleは軽量、セットアップが楽、シンプルな記述で書けるというメリットがあります。TypeORMなどは大規模プロジェクトに使われることも多いようですが、Drizzleは比較的小〜中規模で使われることが多い傾向にあるようです。
🤯 困ったこと
マイグレーションファイルの衝突で事故多発しそう
チーム開発でブランチを分けて、異なるブランチでマイグレーションファイルの生成&実行をした場合、「_journal.json」を適切に書き直す必要があることに気づきました。
_journal.jsonは以下のようになっており、適用したmigrationファイルの適用順序が記されています。
具体的に言うとdevelopブランチから切ったfeature/aブランチとfeature/bブランチがあり、先にfeature/aブランチがdevelopにマージされた際のfeature/bブランチでのコンフリクト解消作業が必要となります。
これはめんどくさいことになりそうだと。
同様の課題がないか調べたところ、以下のdiscussionが見つかりました。
https://github.com/drizzle-team/drizzle-orm/discussions/1104
merge CIでmigrationファイルを作成(して適用)するのがシンプルな方法、とあります。
なるほど、たしかに?
ローカル開発とリリース用で分類するという作戦は良さそう。
ただローカル環境と本番環境とは別に、ステージング環境があると話が厄介になるなと。
結論、以下の戦略で取り組むのが現状の最適解かと考えました。具体的コードは未実装なので書けませんが戦略の概要だけ共有できればと思っています。(機会があれば詳細を追記します)
- ローカル、開発環境、本番環境ごとに、マイグレーション関連のディレクトリを分ける
- 分類したディレクトリに対応するように設定ファイル(drizzle.config.ts)を変更する
- ローカルのディレクトリ分はgit管理下から外す(ignoreに記載する)
- CIを開発環境用、本番環境用に作成する
seedデータ投入の仕組みは...ない?
調べたところ、DrizzleORMにはseedデータ投入の仕組みはないようでした。独自にデータ投入用のフローを作る必要がありそうです。
https://zenn.dev/steg/articles/77204b889814d1
上記の記事を参考に、考えた仕組みは以下の通りです。
- drizzleORMのクエリを使って、データ投入を行うファイルを作成する
- docker起動時にコマンドでファイル実行する
たとえば以下のようにseedファイルを生成して、package.jsonにコマンド記述、Dockerfile.devにコマンド追加をします。
※データ適当ですみません
onDuplicateKeyUpdate は、MySQLの「INSERT ... ON DUPLICATE KEY UPDATE Statement」を使っており、データが既に存在していたら更新をしないようにするためのSQL生成をしています。
https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html
まとめ
TypeScriptを使った開発が多くなっている今、DrizzleはTypeScriptを前提としたORMなのでプロジェクトに導入しやすい。シンプルで軽量で、SQLがわかっていれば学習コストも低く、新規開発をする際に選択肢として上がってきて良さそうなORMだと感じています。
ただ比較的新しいORMであるため、参考情報が少なかったりエコシステムが不十分であったりする部分もあるので、他のORMとメリットデメリットを比較検討してみることをおすすめします。
DrizzleORMは軽量で高速なパフォーマンス、TypeScript前提であるため堅安全性がある、導入しやすくてシンプルなORMです。
個人開発などでも使いやすいと思うのでぜひ使ってみてください!
以上、長文をここまで読んでくださりありがとうございました。
ーーーー
今回はテックブログから一部抜粋しておりますので、気になった方は
是非こちら(https://zenn.dev/toridori/articles/9c41d1fd7f6a85)をご確認ください!
みなさまからのご応募、お待ちしております😌✨
📝開発部に興味がある方へ
(https://toridori.notion.site/toridori-7e9c804bcfc249d6a932cdb99b83e1f6)