Arquitectura · Entrega estática + runtime explícito
WordPress estático con runtime dinámico en AWS
Mantenga la entrega pública de páginas WordPress en S3 y CloudFront y asigne a cada función interactiva su propio runtime del navegador al servicio, sin devolver todo el sitio a PHP y MySQL.
CMS WordPress ↓ Static Publisher S3 + CloudFront ├→ Gatey → Amazon Cognito ├→ Flow → backend de workflows ├→ AI-Kit → backend configurado de IA/conocimiento ├→ rutas protegidas → acceso firmado └→ acciones de aplicación → API protegidas
Límite de ejecución
Clasifique el runtime por función, no por sitio
«Estático» describe cómo se entrega la página. No obliga a eliminar el inicio de sesión, los formularios, los debates, la IA ni las acciones de aplicación. Cada capacidad puede cruzar un límite de ejecución independiente solo cuando el visitante la utiliza.
Solicitud de página pública → CloudFront → HTML/recursos estáticos Inicio de sesión → navegador → Cognito Ruta estática protegida → identidad → acceso firmado → CloudFront Formulario / borrador / debate → navegador → backend Flow IA / DocSearch → navegador → modo local o backend configurado Escritura de aplicación → navegador → API autorizada
Límite de confianza La visibilidad en el frontend no es autorización. La identidad, el acceso a archivos protegidos, la validación de formularios, el acceso a IA y las escrituras de API deben ser aplicados por el servicio responsable.
Plano de control y plano de ejecución
Esta matriz separa la propiedad editorial de la responsabilidad de ejecución. Muestra qué permanece en WordPress y qué pasa al navegador o a servicios AWS cuando la entrega pública es estática.
| Responsabilidad | Papel de WordPress | Papel de AWS/runtime | Por qué importa |
|---|---|---|---|
| Contenido y diseño | Los editores crean páginas en Gutenberg y publican CPT | La entrega estática sirve el resultado renderizado | El flujo editorial sigue siendo conocido y el tráfico público evita PHP. |
| Interfaz de autenticación | La página contiene un bloque, shortcode o widget de Gatey | Cognito gestiona acceso, MFA, SSO y tokens | El acceso sobrevive a la exportación porque se ejecuta en el navegador contra Cognito. |
| Contenido protegido | WordPress define dónde viven las secciones protegidas | Las cookies firmadas de CloudFront aplican el acceso a objetos | Las páginas privadas estáticas no requieren sesiones de WordPress. |
| Formularios y workflows | El diseño y la intención del workflow se editan en WordPress | El backend valida, almacena, enruta y activa acciones | Los envíos escalan por separado de la entrega de páginas. |
| Funciones de IA | Bloques, chatbot, fuentes de KB y ajustes viven en WP Admin | Llamadas a modelos, RAG, salvaguardas y registros se ejecutan en el backend | La inteligencia de contenido es una capacidad gobernada, no un proxy PHP. |
| Funciones de aplicación | WordPress renderiza botones, contenedores e interfaz según cuenta | API Gateway y Lambda aplican autorización y escriben estado | El frontend sigue estático y la aplicación interactiva. |
Límite de ejecución de Flow tras la plantilla de backend
La tabla se centra en Flow. Separa rutas de visitantes, administrativas y ejecución asíncrona para mostrar por qué cada responsabilidad queda fuera de la solicitud de página WordPress.
| Superficie | Rutas de ejemplo | Responsabilidad | Por qué fuera de PHP |
|---|---|---|---|
| Formularios frontend | /frontend/forms/{formId}/submit, /drafts, /upload-url | Validar entradas, aceptar borradores y referencias, y activar el procesamiento posterior. | El navegador envía desde una página estática; el backend controla validación, abusos y durabilidad. |
| Operaciones administrativas | /admin/forms, /admin/submissions, /admin/templates, /admin/workflows, /admin/webhook-endpoints | Configurar definiciones, plantillas y workflows por rutas protegidas. | Las escrituras pueden exigir Cognito/IAM, ámbitos y restricciones IP independientemente de la entrega. |
| Ejecución de workflows | Dispatchers de EventBridge para envíos, estados, correo y webhooks | Procesar de forma asíncrona y registrar eventos sin mantener abierta la solicitud. | Los formularios se convierten en workflows fiables, no en un POST síncrono frágil. |
Mapa de superficies de ejecución
Use esta matriz como lista de seguridad y operaciones. Relaciona cada superficie con su autenticación típica, riesgo principal y límite recomendado.
| Superficie | Autenticación típica | Componente WP Suite | Riesgo principal | Límite recomendado |
|---|---|---|---|---|
| Vista anónima | Ninguna | Salida de Static Publisher | Páginas, listados o recursos obsoletos | Base verificada, propiedad del manifiesto, invalidación CloudFront y comprobación del destino. |
| Interfaz de acceso/perfil | Cliente público Cognito | Bloques Gatey Authenticator y Account Attribute | URL de callback o supuestos de token incorrectos | Cognito App Client, dominio de callback y manejo de tokens. |
| Ruta estática protegida | Cognito antes de emitir cookie | Flujo Static Site Guardian | Ámbito, caducidad y rotación | Cookies firmadas de CloudFront y servicio firmante. |
| Llamada pública de formulario o IA | NONE + reCAPTCHA/WAF o Cognito | Rutas AI-Kit y endpoints Flow | Abuso y coste de modelos/envíos | Límites, validación, reCAPTCHA, WAF y cuotas. |
| Llamada de API de miembro | JWT de Cognito o IAM | Acceso API protegido por Gatey | Confundir visibilidad con autorización | Autorizador API Gateway, ámbitos o firmas IAM. |
| Operación administrativa | IAM o ámbitos Cognito administrativos | Rutas administrativas AI-Kit, operaciones KB | Exponer operaciones privilegiadas | Ruta /admin separada, autenticación estricta y lista IP. |
Diseño de API y caché
La separación de runtime también cambia las reglas de entrega. Esta tabla convierte la arquitectura en decisiones de caché, separación de API, CORS, estado y gestión visible de errores.
| Área | Buen patrón | Mal patrón | Por qué importa |
|---|---|---|---|
| Caché de HTML estático | Caché duradera con invalidación determinista tras publicar | Caché breve en todo porque un componente es dinámico | Un widget dinámico no debe devolver toda la página al servidor. |
| Rutas de API | Superficies /frontend y /admin separadas con autenticación y limitación distintas | Un endpoint genérico para todo | Widgets públicos y operaciones privilegiadas tienen riesgos diferentes. |
| CORS | Permitir dominios estáticos y entornos exactos | CORS comodín con solicitudes con credenciales | Los sitios estáticos suelen tener varios hostnames; CORS debe ser deliberado. |
| Widgets con estado | Guardar estado en Cognito, DynamoDB, objetos S3 temporales o backend específico | Suponer que existe sesión WordPress tras exportar | La página exportada no tiene sesión PHP en solicitudes públicas. |
| Gestión de errores | Mostrar estados accionables de autenticación, reintento o no disponibilidad | Fallo silencioso cuando se bloquea una API | El frontend es el límite visible para el usuario. |
Ruta de implementación
Separe primero la entrega y añada solo los runtimes necesarios
La arquitectura es más fácil de operar cuando cada requisito dinámico tiene un responsable y una ruta de fallo explícitos.
- Mantener WordPress como fuente editorial — Cree y revise páginas en WordPress y publique después resultados almacenables en caché mediante Static Publisher en S3 y CloudFront.
- Asignar las funciones interactivas a sus límites de servicio — Use Cognito para identidad, Flow para estado de formularios y workflows, AI-Kit para rutas de IA locales o configuradas, acceso firmado para contenido estático protegido y API dedicadas para escrituras.
- Proteger cada runtime de forma independiente — Aplique autorización, validación, CORS, WAF, limitación o controles de abuso adecuados en cada límite de servicio, sin depender de una sesión de WordPress ni de estado oculto del frontend.
- Probar producción como aplicación de navegador — Verifique recursos exportados, URL de callback, CORS, estados autenticados y anónimos, fallos de API y accesos caducados desde el dominio de producción.
Cuándo esta arquitectura ofrece el límite adecuado
Buena opción
Sitios mayoritariamente cacheables con funciones activas seleccionadas
- El sitio público es principalmente contenido, pero necesita acceso, formularios, debates, IA o recursos protegidos.
- Desea conservar WordPress como CMS conocido sin incluir PHP y MySQL en cada solicitud pública.
- Las distintas funciones de ejecución requieren límites diferentes de seguridad, escalado o propiedad.
Elegir otro modelo
Otro runtime puede ser más sencillo cuando
- La mayoría de las páginas requieren personalización del lado del servidor antes de renderizarse.
- Una aplicación frontend separada ya es un requisito, por lo que la arquitectura headless es intencional.
- WordPress dinámico tradicional ya resuelve bien la carga y separar servicios no añade un límite operativo útil.
Guías de problemas
Adónde ir desde la arquitectura
¿Cómo hago WordPress estático sin perder funciones dinámicas?
Empiece por Haga WordPress estático sin perder funciones dinámicas. Asigna acceso, formularios, debates, valoraciones, IA y contenido protegido a runtimes explícitos.
¿Cómo conservo WordPress para editar sin exponerlo públicamente?
Consulte Conserve WordPress para editar sin exponerlo públicamente para la separación entre origen editorial y entrega pública; después use esta arquitectura para decidir qué runtimes siguen activos.
¿Cómo funcionan los formularios largos y los workflows de revisión tras publicar estáticamente?
Consulte Permita guardar un formulario largo y continuarlo más tarde, Sustituya las aprobaciones por correo y hojas de cálculo por un workflow y Cree un workflow de revisión con formularios, debate y valoraciones para las rutas de Flow.
¿Cómo funcionan el inicio de sesión y el contenido protegido sin sesiones PHP?
Consulte Añada inicio de sesión a WordPress estático sin recuperar las sesiones PHP para la identidad Cognito y WordPress estático seguro con cookies firmadas de CloudFront para el mecanismo de entrega.
Empiece por el problema del comprador
Elija el límite de ejecución según la función que necesita conservar
Use primero las guías de problemas para identificar la interacción necesaria y vuelva después a la arquitectura para definir implementación y confianza.