Arquitectura · Formularios, revisión y ejecución de flujos
Backend de formularios y flujos de trabajo orientado a eventos para WordPress en AWS
Mantenga la creación y colocación de formularios en WordPress, mientras los borradores persistentes, envíos, conversaciones, estados de revisión, notificaciones y acciones posteriores se ejecutan tras un límite explícito de API y eventos.
WordPress / frontend estático
↓
Entorno de Flow
API de frontend
↓
Estado de envío y borrador
├→ cargas
├→ conversación / estado de revisión
└→ eventos del flujo
↓
correo / webhooks / acciones
Límite de ejecución
Un formulario se convierte en flujo de trabajo cuando su estado debe sobrevivir a la petición de página
Los formularios largos, las aprobaciones y los procesos de revisión necesitan estado persistente. Flow separa la experiencia del navegador de la persistencia del backend y de la ejecución posterior, de modo que la página pública puede seguir siendo estática mientras el proceso continúa de forma independiente.
Interfaz de formulario / revisión en WordPress
↓ navegador
API /frontend/*
├→ guardar / cargar / finalizar borrador
├→ enviar registro
├→ contrato de carga
└→ entradas de conversación / valoración
↓
estado persistente + eventos
/admin/* → gestión protegida
↓
despacho del flujo → correo / webhook / acción
Límite de seguridad Las rutas públicas de formularios y las rutas administrativas privilegiadas tienen perfiles de riesgo distintos. Los controles de envíos anónimos, el acceso autenticado de revisores y la configuración administrativa no deben compartir una superficie de autorización amplia.
Qué crea la pila de Flow
El backend de Flow separa API, cómputo, estado, cargas, eventos, seguridad y operaciones. Este inventario muestra qué recursos de AWS cumplen cada función arquitectónica.
| Capa | Recursos de AWS | Función arquitectónica |
|---|---|---|
| Capa de API | API REST regional de API Gateway, dominio personalizado opcional y registros Route53 opcionales | Expone familias separadas de rutas frontend y admin sin vincular la ejecución de formularios al alojamiento de WordPress. |
| Capa de cómputo | Lambda de API de formularios, Lambda de despacho de flujos, Lambda de correo, Lambda de webhooks y Lambda Custom Resource de despliegue | Mantiene como unidades separadas el procesamiento síncrono, los flujos asíncronos, el correo y los webhooks salientes. |
| Capa de estado | Tablas DynamoDB para envíos, eventos, plantillas, definiciones de flujos y formularios, endpoints webhook y mapas de procesos | Guarda definiciones, registros y estado en tablas específicas con TTL/retención, sin usar la base de WordPress como registro de integración. |
| Capa de cargas | Bucket S3 de cargas y bucket de plantillas, con buckets existentes opcionales | Traslada archivos grandes y recursos reutilizables de correo o plantillas al almacenamiento de objetos. |
| Capa de eventos | Reglas EventBridge y eventos como envío creado/actualizado, estado/acción y agente de IA completado/fallido | Convierte el trabajo del formulario en eventos observables que activan flujos sin bloquear al visitante. |
| Capa de seguridad | Autorizador Cognito para rutas admin, modos IAM/NONE opcionales, WAF, reCAPTCHA, listas IP y SSM/KMS para secretos | Aplica protecciones diferentes a los envíos públicos y a las API de gestión privilegiadas. |
| Capa operativa | Grupos de logs CloudWatch, DLQ de SQS, retención configurable y protección GuardDuty opcional | Proporciona logs, superficie de reintentos/fallos y escaneo opcional de cargas. |
API frontend frente a API administrativa
Las dos familias de rutas sirven a llamadores distintos y no deben heredar las mismas suposiciones de confianza. La tabla hace visible la separación antes de configurar comportamiento o permisos.
| Familia de rutas | Ejemplos | Llamador típico | Postura de seguridad |
|---|---|---|---|
| Envío frontend | /frontend/forms/{formId}/submit | Formulario Flow renderizado en una página pública o protegida | Puede funcionar sin autenticación, pero el tráfico anónimo debe usar reCAPTCHA, WAF y límites de frecuencia. |
| Borradores frontend | /frontend/forms/{formId}/drafts, /drafts/load, /drafts/delete, /drafts/{submissionId}/submit | Visitante que guarda, reanuda o finaliza un formulario largo | Las credenciales del borrador y la validación final se separan para que guardar no active los flujos finales. |
| Preparación de carga frontend | /frontend/forms/{formId}/upload-url | Componente que prepara un archivo adjunto grande | Devuelve un contrato de carga S3 prefirmado; la carga no necesita pasar por WordPress. |
| Formularios/envíos admin | /admin/forms, /admin/forms/{formId}/submissions | WP Admin o interfaz de gestión | Debe protegerse con Cognito/IAM y, opcionalmente, lista permitida de IP. |
| Plantillas/flujos/webhooks admin | /admin/templates, /admin/workflows, /admin/webhook-endpoints | Administradores que configuran el comportamiento empresarial | Estas rutas cambian la ejecución y nunca deben tratarse como endpoints públicos. |
Modelo de datos: por qué resultan útiles varias tablas
El backend separa definiciones, registros actuales, historial de eventos y configuración de integraciones porque tienen ciclos de vida distintos. Una única fila genérica no basta para flujos duraderos.
| Familia de tablas | Qué representa | Por qué está separada |
|---|---|---|
| Definiciones de formularios | Estructura y versiones de los formularios usados en el frontend | Un formulario puede cambiar mientras los envíos antiguos deben seguir siendo comprensibles. |
| Envíos | Estado actual, estado borrador/final y datos principales | Es el registro operativo consultado por las vistas administrativas y los pasos del flujo. |
| Eventos de envío | Historial acumulativo: creado, actualizado, cambio de estado y acción invocada | La auditoría y los reintentos no deben sobrescribir el registro actual. |
| Plantillas | Metadatos reutilizables de correo y plantillas | El contenido de correo debe gestionarse independientemente de los envíos. |
| Definiciones de flujos | Reglas, acciones y comportamiento de enrutamiento | La lógica tiene ciclo de vida propio y debe versionarse y gestionarse explícitamente. |
| Endpoints webhook | Destinos de integración salientes y ajustes de firma | Los sistemas externos son dependencias operativas, no simples campos. |
| Mapas de procesos | Correlación en ejecución entre procesos, envíos y acciones | Los flujos complejos necesitan estado de correlación más allá de un registro. |
Controles de seguridad y abuso
Las rutas públicas y las rutas administrativas privilegiadas no deben compartir un modelo de protección. La tabla sitúa los controles de bots, WAF, identidad y secretos en la ejecución de Flow.
| Control | Dónde se aplica | Motivo de diseño |
|---|---|---|
| reCAPTCHA | Endpoints públicos de formularios | Reduce envíos automatizados antes de que generen registros, correos, webhooks o costes de modelos y flujos. |
| Límites de WAF | Prefijos de rutas frontend y admin | Limita de forma distinta el abuso en rutas para visitantes y administradores. |
| Autorizador Cognito admin | Rutas /admin/* | Mantiene formularios, envíos, plantillas, flujos y webhooks tras una identidad real. |
| Secretos SSM/KMS | Secretos de reCAPTCHA y firma de webhooks | Mantiene secretos compartidos fuera de ajustes de WordPress y fuentes de plantillas. |
| Protección GuardDuty | Bucket de cargas cuando está activada | Añade escaneo opcional antes de que el procesamiento posterior confíe en los archivos. |
Parámetros de despliegue que cambian la arquitectura
No son ajustes cosméticos. Cambian autenticación, protección contra abuso, propiedad del almacenamiento, secretos, dominios y operaciones, por lo que deben revisarse como decisiones arquitectónicas.
| Área | Ejemplos | Efecto arquitectónico |
|---|---|---|
| Modos de autenticación | FrontendApiAuthMode, AdminApiAuthMode, AdminCognitoUserPoolId, scopes | Controla si las superficies frontend y admin son públicas o están protegidas por IAM o Cognito. |
| Protección contra abuso | EnableRecaptcha, modo/clave/umbral de reCAPTCHA, EnableWAF, listas IP | Determina cuánto tráfico anónimo alcanza el backend y qué rutas se limitan o permiten. |
| Propiedad del almacenamiento | TemplatesBucketName, PayloadBucketName, prefijos | Permite usar buckets creados o convenciones de almacenamiento existentes. |
| Secretos | EnableKmsForSecrets, secreto de firma webhook y secreto reCAPTCHA | Controla si los secretos se almacenan con una clave KMS dedicada y parámetros SSM. |
| Dominio/DNS | ApiCustomDomainName, ARN de certificado y ajustes Route53 | Mueve la API de una URL execute-api a un dominio propio cuando DNS y certificado están preparados. |
| Operaciones | Retención de datos/logs, memoria/timeout/nivel de log de Lambda | Controla coste, observabilidad y margen de ejecución sin cambiar las páginas WordPress. |
Ruta de implementación
Modele el proceso antes de conectar las acciones
El mismo backend puede admitir formularios simples y procesos más estructurados si los estados de borrador, envío, revisión y acción permanecen explícitos.
- Defina el registro y su ciclo de vida — Decida qué es un borrador, qué se convierte en un registro enviado, qué estados de revisión existen y qué campos o adjuntos deben persistir entre sesiones.
- Separe las operaciones de visitantes y revisores — Mantenga las acciones públicas o autenticadas del frontend en una superficie de ejecución limitada y proteja por separado la gestión administrativa de formularios, envíos y flujos.
- Emita eventos después de cambios de estado persistentes — Active correos, webhooks u otras acciones solo después de aceptar el registro o cambio de estado pertinente, para que los fallos posteriores no borren el envío original.
- Pruebe reintentos y transferencias — Compruebe por separado la reanudación del borrador, el envío final, las decisiones de revisión, los cambios de conversación o valoración, las notificaciones fallidas y los errores de webhooks externos.
Cuándo compensa separar un backend de Flow orientado a eventos
Buen encaje
Formularios que en realidad son procesos empresariales
- Los usuarios deben guardar y reanudar un formulario largo entre sesiones.
- Tras el primer paso, los envíos pasan por flujos de revisión, aprobación, conversación, valoración o estado.
- El frontend público puede ser estático, mientras el estado y las acciones posteriores deben seguir activos y operar de forma independiente.
Manténgalo sencillo
Un recorrido convencional puede bastar cuando
- el formulario es corto y el proceso termina con un envío y una notificación sencilla.
- el sitio es totalmente dinámico y un plugin de formularios existente ya cubre el flujo sin fricción operativa.
- no se necesitan borradores persistentes, estado de revisión en backend, historial de eventos ni acciones externas.
Guías de problemas
Problemas de compradores respaldados por esta arquitectura
¿Cómo sustituyo las aprobaciones por correo y hojas de cálculo por un flujo de WordPress?
Empiece por Sustituya las aprobaciones por correo y hojas de cálculo por un flujo de trabajo de WordPress. Presenta el problema operativo; esta arquitectura explica dónde residen los registros, el estado de revisión y las acciones.
¿Cómo guardan los usuarios un formulario largo de WordPress para continuar después?
Consulte Permita que los usuarios guarden un formulario largo de WordPress y continúen después. El estado persistente del borrador debe estar tras la ejecución del navegador, no dentro de una sola petición PHP.
¿Cómo combino formularios, conversaciones y valoraciones en un único flujo de revisión?
Consulte Cree un flujo de revisión en WordPress con formularios, conversaciones y valoraciones para la revisión, y Añada conversaciones, respuestas y valoraciones a un frontend WordPress estático cuando la colaboración deba seguir activa tras la publicación estática.
¿Puede funcionar con WordPress publicado de forma estática?
Sí. La página puede servirse desde alojamiento estático mientras Flow llama al backend configurado desde el navegador. Haga WordPress estático sin perder funciones dinámicas explica el modelo más amplio de página estática más ejecución dinámica.
Empiece por el problema del flujo
Saque el proceso de las bandejas de entrada antes de añadir más automatización
Elija primero el problema del comprador —aprobación, guardar y reanudar o revisión estructurada— y use después esta arquitectura para definir los límites de persistencia, autorización y eventos.