Formulario estático: comprobar backend y entrega de correo

Un botón que cambia a «gracias» no demuestra que alguien haya recibido un mensaje. En una web creada con IA, el formulario puede tener diseño y validación visual sin un backend que procese la petición. Antes de comprar o cambiar alojamiento, identifica qué etapa funciona y cuál falta.

Esta guía utiliza Buzón de ensayo, ejemplo original MIT con Node. El repositorio público contiene el código para reproducir las pruebas locales, no una demo backend pública. Su modo normal valida datos ficticios, no envía correo ni guarda contactos.

Cuatro etapas, cuatro evidencias

La validación de formularios de MDN explica por qué las comprobaciones del navegador deben repetirse en servidor. Un cliente puede saltarse la UI. En DevTools, mira URL, método, status y respuesta: un 200 sólo tiene el significado definido por ese endpoint.

Ensayo local sin proveedor

Con una copia del ejemplo, instala Node 22.23.3 desde Node.js y comprueba v22.23.3. Conserva el lockfile y la licencia. No hay dependencias externas ni credenciales.

git clone https://github.com/ocentelles/hostbrid-example-form.git
cd hostbrid-example-form
git checkout e949f6a14258eced69d1a3e47dbb6909b35639cc
node --version
npm ci --ignore-scripts --offline
npm run check
npm test
PORT=8080 npm start

Abre http://127.0.0.1:8080/, usando datos ficticios como demo@example.invalid. Mantén el proceso activo. El servidor escucha sólo en loopback; no es una demo pública HTTPS. Usa ese origen exacto: localhost no se considera equivalente. FORM_ORIGIN configura el origen permitido, pero no DNS, certificados ni acceso público.

Desde otra terminal, ejecuta únicamente contra esta demo local:

curl -fsS http://127.0.0.1:8080/healthz
curl -s -i http://127.0.0.1:8080/api/contact \
  -H 'Origin: http://127.0.0.1:8080' \
  -H 'Content-Type: application/json' \
  --data '{"name":"Persona Demo","email":"demo@example.invalid","message":"Mensaje sintético de ensayo.","website":""}'

Espera 200, accepted:true y delivery:"not-sent". El recibo es una confirmación local de validación, no prueba de transporte de correo. /healthz muestra entrega desactivada y contador efímero; no valida un proveedor ni un buzón.

Prueba el rechazo, no sólo la portada

curl -s -i http://127.0.0.1:8080/api/contact \
  -H 'Origin: https://other.example.invalid' \
  -H 'Content-Type: application/json' \
  --data '{"name":"Persona Demo","email":"demo@example.invalid","message":"Mensaje sintético de ensayo.","website":""}'

Debe devolver 403. También se prueban origen ausente/null, tipo incorrecto 415, JSON/UTF8 inválidos 400, cuerpo mayor de 4096 bytes 413, lectura incompleta 408 y campos inválidos 422. Las rutas no declaradas son 404 y métodos no admitidos 405. Cinco intentos POST por minuto y dirección de socket llevan después a 429; los intentos inválidos también cuentan.

Estas pruebas son locales y sintéticas. No ejecutes el ensayo de carga contra formularios ajenos ni confundas un límite básico con una garantía DDoS. El ejemplo no confía en X-Forwarded-For: detrás de un proxy, varios visitantes podrían compartir dirección. Un servicio público requiere configurar proxy de confianza y límites compartidos.

Qué pueden y qué no pueden hacer los controles

Origin y Fetch Metadata reducen peticiones de otros orígenes del navegador, pero no autentican un bot que falsifica headers. El honeypot exige un campo vacío; es una heurística, no un CAPTCHA. El formato de email no acredita propiedad ni entrega. El limitador vive por proceso y se reinicia con él.

La segunda fase inyecta simulaciones locales (mocks) de verificador y entrega, sólo en modo de test explícito. Comprueba rechazo, fallo y timeout; no verifica una persona ni conecta un proveedor. La clave de idempotencia liga contenido e intento: un reintento concurrente comparte ejecución; contenido distinto o token reutilizado con otra clave devuelve 409. Cachés de claves y hashes y replay duran cinco minutos en memoria: no ofrecen garantía distribuida o duradera. Un timeout no prueba que un proveedor externo haya cancelado un efecto.

Turnstile requiere Siteverify en servidor; mostrar un widget no completa la integración. Este ejemplo no tiene widget ni validación real de tokens. La futura implementación necesitaría secreto sólo servidor y comprobar valores hostname y action esperados, fallos y reutilización de tokens.

Antes de afirmar entrega real

El ejemplo superó 43 pruebas locales y comprobaciones en Chrome a 390 y 1280 px. Eso prueba su contrato local y las simulaciones, no SMTP, Nodemailer, OAuth, push automático, dominio público ni recepción de correo. No hay proveedor elegido o cuenta contratada para este ejemplo.

Un proveedor de envío requiere configuración propia: remitente/destinatario controlados por el operador, clave sólo servidor, dominio verificado cuando corresponda, gestión de errores y reintentos y destino de prueba autorizado. El cliente no debería elegir destinatario o remitente arbitrarios. Resend documenta estados de envío; es una referencia de proveedor, no una integración probada aquí. Revisa eventos, rebotes y destino: aceptación no equivale a presencia en la bandeja de entrada.

Elegir dónde vive el backend

Para una aplicación que necesita Node permanente, valora Projects con plan que incluya servicios y cuota libre. Un VPS puede servir si necesitas controlar el entorno y asumir sistema, red y operación. El ejemplo actual escucha sólo en loopback: adaptación al alojamiento y HTTPS necesitan pruebas aparte. No inferir servicios gratuitos de una cuota estática.

Si aún estás identificando la arquitectura, consulta hosting para una web creada con IA y diagnóstico de un proceso Node. Correo de dominio cubre buzones; contratar un buzón no demuestra un backend transaccional para tu formulario. Decide envío y alojamiento por separado, revisando condiciones y precio actuales.