【反省】バッチの実装を誤って、盛大にご迷惑をおかけしてしまった話
やらかしてしまいました。今回は業務における失敗談をお話しようと思います。 何をやらかしたか バッチの実装を誤った結果多数のユーザーにメールを重複送信してしまい、ユーザーはもちろん社内のカスタマーサクセスチーム、開発チームにもご迷惑をおかけしてしまいました。 技術スタック typescript Prisma Mysql バッチの要件 特定のステータスを持つユーザーに対して、以下の処理を行うバッチです ステータスの更新 ※更新すること次のバッチの対象から外れる その他の処理 ※本題から逸れるので省きます メール送信を行う どんな実装をしたか 流れとしてはこんな感じ バッチの対象ユーザーを取得 ユーザーに対して、updateMany等で一括更新処理 処理が終わったら対象ユーザーにメール送信 export async function sample() { // 対象ユーザーを取得 const t
Prismaの型処理を100倍ほど改善できるかもしれない知識
はじめに もしかしたら多くの開発者が見落としているかもしれないPrismaのちょっとした使い方が TypeScriptコンパイラやIDE等の開発環境に思わぬ悪影響を与えることに気付いたので、 その解決策と実際のプロジェクトでの適用例を紹介します。 問題の発見 手前味噌ですが、冒頭に記載した自作のOSSを使ってTypeScriptのパフォーマンスを測定していたところ、あるプロジェクトでPrisma関連のコードに起因してやたらIDEが重くなることに気づきました。 そこで tsc --noEmit --diagnostics などのデバッグコマンドを使って調べてみると、面白いことが分かったのでそのエッセンスを検証データとともに以下にまとました。 検証環境の構築 パフォーマンスの問題を明確に示すため、30段階のネストしたPrismaスキーマを作成しました。 Tree1からTree30まで、各モデル
Prisma ORM Architecture Shift: Why We Moved from Rust to TypeScript
The Prisma query engine, written in Rust, has always been a core part of Prisma ORM. It was developed for the future, but is no longer compatible with Prisma ORM’s current direction. Read on to learn more about our rewrite from Rust to TypeScript. TL;DR: The Rust-Free ORM is ready for production-use Prisma ORM's core engine has undergone a major shift from the Rust based query engine to a leaner T
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why Prisma ORM Checks Types Faster Than Drizzle
