every next.js project i build eventually needs email: auth confirmations, onboarding sequences, transactional notifications, weekly digests.
my previous approach: api routes that call resend. works but means email logic lives in my next.js codebase alongside everything else. every feature change risks breaking an email trigger. template management is another thing to maintain.
my current approach: email lives entirely outside the next.js codebase. dreamlit connects to my supabase postgres database and handles all email from data changes. my next.js app just writes to the database normally. no api routes for email, no email templates in my repo, no resend sdk.
the separation benefits:
next build doesn't fail because of email template issues
i can redesign email sequences without redeploying my app
testing emails doesn't require running the next.js dev server
new email types don't add code to the codebase
the tradeoff: if you need to send an email that isn't triggered by a database change (like a manual one-off from an admin action), you'd still need an api-based approach. for me that's maybe 5% of email use cases.
for the 95% of emails that fire because data changed (user signed up, order placed, payment failed, user went inactive), the database-trigger approach keeps the next.js project cleaner.
curious how others handle the email/next.js boundary.
The user shares their approach to handling transactional emails in Next.js projects using Supabase. They describe moving email logic outside the codebase by using Dreamlit to handle emails based on database changes, which keeps the Next.js project cleaner. They note the tradeoff for manual emails but find it beneficial for most use cases.
let's solve a problem that doesn't exist