Arquitectura y contratos del frontend
Biblioteca creada y mantenida con agentes de IA. Las personas son responsables de la revisión y publicación.
Propuesta · requiere revisión humana · r2
Elegir el renderizado para cada interacción
La generación estática encaja con contenido público que se puede recompilar. El renderizado en servidor puede ayudar a la actualización inicial o al descubrimiento, mientras que el renderizado en cliente encaja con la interacción sostenida. Las rutas híbridas pueden combinar estos enfoques. Este es el marco de decisión original de la biblioteca: mide el recorrido relevante e inspecciona el comportamiento actual del framework elegido antes de adoptarlo.
Registra quién controla la caché, el coste de hidratación y JavaScript y los límites de autenticación y despliegue. No coloques la respuesta privada de un usuario renderizada en servidor en una caché compartida con otra identidad. Los microfrontends pueden facilitar responsabilidades independientes, pero añaden costes de enrutamiento, dependencias y coherencia de diseño; no son la forma predeterminada de dividir componentes.
Dar un único propietario a cada estado
Distingue entre estado del servidor, estado de URL y navegación, estado local de interacción y preferencias duraderas. Decide qué estado sobrevive a una recarga o al uso sin conexión y cómo se invalida después de cerrar sesión o cambiar permisos. Organiza las funcionalidades en torno a interfaces explícitas y componentes básicos accesibles compartidos. Copiar los mismos datos del servidor en varios almacenes crea trabajo de conciliación en lugar de resiliencia.
Para cada interacción respaldada por una API, define:
| Contrato | Ejemplo de evidencia de aceptación |
|---|---|
| Autorización | Las solicitudes directas a la API fallan cuando el usuario carece de permiso, aunque se omita la interfaz |
| Forma de la respuesta | Los clientes antiguos y nuevos manejan los campos, errores, paginación y unidades documentados |
| Carga y cancelación | Salir de la página detiene trabajo innecesario o ignora de forma segura un resultado tardío |
| Cambio optimista | El rechazo restaura o concilia el estado visible sin perder la entrada del usuario |
| Sin conexión y conflictos | Una edición en cola tiene una identidad estable y una regla de conflicto explícita al reconectar |
| Privacidad | El cierre de sesión y la revocación de acceso borran o invalidan los datos privados relevantes en caché |
El servidor es responsable de la validación y la autorización de confianza. Los botones ocultos y los esquemas del cliente mejoran la usabilidad, pero no pueden imponer control de acceso. Mantén los secretos del backend fuera de los paquetes del navegador, los mapas de código fuente y los índices generados. El código del navegador y las salidas de modelos o herramientas son datos no confiables en el límite del servidor.
Probar el recorrido observable
Durante la implementación, prueba las reglas de dominio por separado de los detalles de renderizado. Ante cambios de API, ejecuta pruebas de compatibilidad de consumidores. Antes de publicar, ejercita los recorridos clave como usuario de caja negra: teclado y orden del foco, nombres accesibles, contraste, ventana estrecha, estados de carga, vacío y error, acceso denegado y solicitudes interrumpidas. Combina comprobaciones automatizadas de accesibilidad con revisión de tareas mediante teclado y tecnologías de asistencia cuando corresponda; superar un comprobador automático no demuestra conformidad completa.
Usa pruebas de rendimiento con condiciones representativas de dispositivo y red y carga sostenida de API; mide navegación, latencia de interacción, recursos transferidos y errores. Confirma que el frontend no multiplique las llamadas al backend durante reintentos, sondeos o reconexiones. Prueba los límites de autenticación y caché mediante el plan de pruebas de seguridad.
Evolucionar deliberadamente
Un backend para un frontend concreto puede ser útil cuando ese cliente necesita agregación o un límite más fuerte en servidor. Explica la mejora y quién será responsable del despliegue adicional. Cambia de framework o introduce microfrontends solo cuando restricciones medidas justifiquen la migración, incluidos los costes de accesibilidad, compatibilidad y soporte de dependencias. Conserva un plan de publicación e invalidación de caché para que los recursos antiguos del navegador sigan siendo compatibles con la API desplegada.
Aquí WebMCP es una mejora progresiva. La lectura y búsqueda ordinarias deben funcionar sin él; los navegadores compatibles siguen necesitando pruebas de permisos, cancelación y navegación. La exposición experimental de herramientas no debe conceder acceso que el usuario no tenga ya.
Decisiones relacionadas
Arquitectura · Estrategia de pruebas · Pruebas de rendimiento · Pruebas de seguridad · Integraciones
Evidencia primaria
wcag · owasp · webmcp · wcag-keyboard · wcag-focus-order · wcag-focus-visible · wcag-contrast · azure-cqrs