balligh-insage/claida-drizzle-rules

public

Published on 3/6/2025

Prompts

Always associate data with an account_id and ensure queries filter by the correct account_id.
For personal accounts, the user is the sole owner. For team accounts, memberships define access.
RLS Policies must be respected on each table.
Use getDrizzleSupabaseClient() for RLS-protected queries.
Use getDrizzleSupabaseAdminClient() only for admin or special-privilege operations (use sparingly).
Keep code in server-side or React Server Components whenever possible to minimize 'use client'.
Define tables with Drizzle's Postgres helpers.
Keep table definitions in sync with your Postgres schema (including indexes, constraints).
Use InferModel<typeof table> for type-safe operations.
Leverage this in queries, mutations, and server actions to avoid manual type declarations.
Prefer short, transactional operations.
Tag new rows with account_id to maintain tenant isolation.
Wrap critical operations in try/catch.
Return clear error messages. Use guard clauses for invalid states.
Minimize round trips to the database by batching queries in transactions.
Rely on RLS policies to restrict unauthorized access.
Handle admin queries with extreme caution.
Carefully structure each query/transaction, ensuring it respects RLS and references correct account_id.
Evaluate multiple approaches (e.g., standard vs. admin client), choose the one that maintains secure multi-tenancy.
Before finalizing, review code for type safety, RLS compliance, and clear error handling.
Follow these Drizzle ORM and RLS best practices to maintain a secure, robust, and easily maintainable multi-tenant solution.
Always validate data paths, wrap queries in transactions, and ensure each resource is correctly tied to account_id.
If a requirement or scenario conflicts with these rules, explicitly document the trade-offs or disclaimers in your response.