Su Vercel invii email tramite una HTTP API, non SMTP. Vercel esegue il tuo codice in funzioni serverless ed edge, e quei runtime sono costruiti attorno alla gestione di richieste HTTP di breve durata, non a socket TCP mantenuti aperti. L'Edge runtime in particolare non ha il modulo Node net, quindi una libreria SMTP non può nemmeno aprire una connessione. Una richiesta HTTPS a una API email si adatta perfettamente al modello. Ecco la configurazione Next.js.
Perché SMTP non funziona bene su Vercel?
Le funzioni serverless sono progettate per avviarsi rapidamente, gestire una richiesta e terminare. Mantenere aperta una connessione SMTP (con il suo handshake a più passaggi) va contro questo principio, e la funzione può essere congelata o terminata durante la conversazione. L'Edge runtime è ancora più restrittivo: esegue un ambiente web-standard senza i moduli di rete di Node, quindi librerie come Nodemailer che dipendono da net e tls non funzioneranno affatto. Inviare tramite HTTPS aggira entrambi i problemi, perché fetch è esattamente ciò per cui questi runtime sono costruiti.
Come si invia un'email da un Route Handler Next.js?
Crea un Route Handler in app/api/send/route.ts. Legge la chiave API da una variabile d'ambiente e chiama la API email. Usando l'Bird Node SDK:
// app/api/send/route.ts
import { BirdClient } from "@messagebird/sdk";
export const runtime = "nodejs";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
export async function POST(request: Request) {
const { to } = await request.json();
const { data, error } = await bird.email
.send({
from: "you@yourdomain.com",
to: [to ?? "delivered@bird.dev"],
subject: "Hello from Node",
html: "<p>It works.</p>",
})
.safe();
if (error) {
return Response.json({ error: error.message }, { status: 502 });
}
return Response.json({ id: data.id });
}
Imposta BIRD_API_KEY nelle variabili d'ambiente del progetto Vercel, così è disponibile a runtime e non viene mai committata. L'indirizzo sandbox delivered@bird.dev accetta sempre la posta, il che rende facile verificare il primo deploy.
Edge runtime o Node runtime?
La riga export const runtime sceglie quale runtime esegue il tuo handler. Poiché SDK e fetch funzionano in entrambi, puoi scegliere in base alle tue altre esigenze:
| Node runtime | Edge runtime | |
|---|---|---|
| Predefinito | Sì | Su richiesta |
API Node (net, fs) | Disponibili | Non disponibili |
| Cold start | Più lento | Più veloce |
| Librerie SMTP | Funzionano, ma inaffidabili su serverless | Non funzionano |
HTTP email API (fetch) | Funziona | Funziona |
Se chiami solo una HTTP API, l'Edge runtime ti offre cold start più veloci. Se dipendi da un pacchetto solo-Node in un'altra parte dell'handler, resta su Node. In entrambi i casi l'invio dell'email è la stessa chiamata basata su fetch.
Inviare con Bird
L'handler sopra usa già lo snippet canonico. La struttura è la stessa ovunque esegui JavaScript:
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
const { data, error } = await bird.email
.send({
from: "you@yourdomain.com",
to: ["delivered@bird.dev"],
subject: "Hello from Node",
html: "<p>It works.</p>",
})
.safe();
Se costruisci i corpi delle email come componenti, React Email li renderizza nell'HTML che questa chiamata si aspetta. Per una visione più ampia di dove collocare il codice email, vedi inviare email con JavaScript.
FAQ
Posso usare Nodemailer su Vercel?
Sul Node runtime si carica, ma mantenere aperta una connessione SMTP è inaffidabile su funzioni serverless di breve durata. Sull'Edge runtime non può funzionare, perché non c'è il modulo Node net. Una HTTP API evita entrambi i problemi.
Dove salvo la mia chiave API su Vercel?
Nelle variabili d'ambiente del progetto, impostate nella dashboard di Vercel o tramite CLI. L'handler la legge con process.env, così resta sul server e fuori dal repository.
Edge o Node runtime per inviare email?
Entrambi funzionano per una chiamata HTTP API. Edge ha cold start più veloci; Node è necessario se l'handler usa anche pacchetti solo-Node.
Vercel e una HTTP email API sono una combinazione naturale. La panoramica del prodotto email e la guida all'invio di email coprono il resto.
Il traffico di picco e il recupero degli arretrati determinano la capacità di invio di cui la tua applicazione ha bisogno da un servizio di email transazionali.