Frontend and Client Architecture
Decisiones del cliente y de la presentación
Este mapa navega decisiones arquitectónicas de aplicaciones cliente y capas de presentación: responsabilidades, cambios de estado, producción de representación, composición, entorno y qualities relevantes. Incluye clientes Web y deja espacio para plataformas nativas. No es un catálogo de frameworks ni una guía de React, CSS o técnicas de implementación.
La organización es navegación editorial del Atlas, no una taxonomía universal. Sus dimensiones se combinan: MVC frente a SSR es una comparación inválida porque no responden la misma pregunta; MVVM frente a Micro Frontends tampoco ofrece alternativas equivalentes. Antes de elegir un nombre, precisar qué decisión necesita resolverse y qué conocimiento aporta cada recorrido.
Interacción y responsabilidades de presentación
| Pregunta | Recorrido |
|---|---|
| ¿Cómo distribuyo responsabilidades entre View y coordinación de presentación? | presentation-patterns compara MVC, MVP y MVVM conservando variantes. |
| ¿Cómo interpreto entrada y colaboración entre Model, View y Controller? | model-view-controller distingue historia, GUI y adaptaciones Web. |
| ¿Cómo coordino una View explícitamente o mediante estado observable? | model-view-presenter y model-view-viewmodel permiten contrastar esos mecanismos. |
Presentation Patterns conserva su foco y sus documentos permanecen en su ubicación actual. Este mapa superior no lo reemplaza ni vuelve a definir sus patrones. Una pregunta concreta sobre binding o sincronización conviene llevarla a ese recorrido, en lugar de inferir propiedades por las carpetas de un framework.
Cambio de estado y flujo de información
unidirectional-data-flow pregunta cómo una entrada llega a lógica de transición y produce estado observable y nueva representación. Permite seguir ownership, efectos y resultados sin confundir flujo dirigido con ausencia de ciclos de interacción humana. Flux, Redux y Elm aparecen como realizaciones con términos propios, sin convertirse en la definición del concepto general.
client-state-management pregunta qué estado debe vivir en el cliente, quién lo posee, cuánto dura y cómo se relaciona con datos remotos. Distingue borradores, confirmaciones, valores derivados y copias cacheadas sin imponer un store global. UDF organiza propagación de cambios; State Management conserva ownership, alcance y lifecycle. Ninguna copia cliente adquiere autoridad comercial solo por ser la referencia compartida entre pantallas.
Producción de representación Web
rendering-strategies pregunta dónde y cuándo se produce la representación: browser, servidor por request, generación previa o combinaciones. Separa HTML inicial, activación y actualizaciones posteriores. Su vocabulario es principalmente Web; no describe de forma universal cómo funcionan todos los clientes móviles.
Puede combinarse con patrones de presentación y UDF. Un checkout con HTML inicial de servidor puede activar comportamiento cliente y procesar después intenciones mediante transiciones dirigidas. Esto no decide cuántos servicios existen, quién gobierna los pagos ni qué plataforma debe utilizarse. Las consecuencias requieren workload, contexto y evidencia.
Fronteras y composición frontend
micro-frontends pregunta cómo dividir una experiencia frontend en partes que equipos puedan evolucionar y entregar con mayor independencia. Examina composición, contratos y costos de integración sin exigir múltiples frameworks, repositorios ni un frontend por servicio backend.
backend-for-frontend pregunta cuándo conviene adaptar capacidades backend a las necesidades específicas de una experiencia cliente. Conserva autoridad de negocio en sus capacidades y distingue esa adaptación de gateway, rendering y estado local. Una experiencia con varias Micro Frontends puede utilizar un BFF común; sus fronteras no tienen correspondencia uno a uno.
internal-structure permite recuperar organización interna cuando la pregunta trata dependencias y decisiones protegidas. Un cliente puede utilizar capas, puertos/adaptadores o slices sin que su Presentation Pattern describa todo ese diseño. interfaces ayuda cuando el contrato entre UI y aplicación importa más que una biblioteca particular.
Entorno cliente y conectividad
¿Qué restricciones arquitectónicas aparecen cuando el cliente vive bajo lifecycle, recursos, permisos y distribución controlados por una plataforma móvil? mobile-architecture examina esas condiciones, restauración y versiones instaladas sin definir una arquitectura única de Android o iOS.
¿Cómo decido qué debe seguir siendo útil cuando el cliente pierde conectividad? offline-first delimita capacidades, lecturas, escrituras y confirmación sin exigir que todo funcione desconectado ni que la copia local sea autoridad comercial.
¿Cómo intercambian y reconcilian cambios las copias local y remota cuando pueden haber cambiado por separado, y bajo qué supuestos convergen? synchronization examina progreso, reanudación, conflictos y autoridad. Puede existir sin un requisito Offline First; tampoco toda experiencia offline necesita sincronización compleja.
Elegir CSR no demuestra Offline First. Mostrar datos cacheados tampoco demuestra que una operación haya quedado confirmada por el sistema autoritativo. Mobile Architecture aporta restricciones del entorno, CSM organiza estado cliente y los dos recorridos anteriores conservan preguntas distintas sobre utilidad desconectada y relación entre copias.
Qualities transversales del cliente
¿Cómo observo y controlo cuándo una experiencia Web se vuelve útil, responde y permanece estable en condiciones reales? web-performance conecta resultados relevantes, señales, field/lab y decisiones que mueven trabajo y espera entre browser, red y backend. No equivale a load time, Core Web Vitals ni un score Lighthouse.
¿Cómo diseño una experiencia que personas con distintas discapacidades, tecnologías de asistencia y métodos de entrada puedan utilizar? accessibility conecta semántica, operación, foco, contenido y evaluación sin reducir el resultado a ARIA, conformidad WCAG o checks automáticos.
¿Cómo preparo el software para distintas lenguas, scripts, regiones y convenciones culturales sin rediseñarlo por cada mercado? internationalization conecta texto, dirección, formatos y recursos con datos y contratos. No equivale a traducción ni convierte locale en autoridad sobre moneda o tiempo de negocio.
Estas qualities atraviesan diseño, interacción y mantenimiento. Performance no certifica accesibilidad; una versión localizada puede romper etiquetas, foco o contexto aunque conserve las funciones. La elección de rendering no garantiza ninguna de las tres. Sus recorridos se relacionan sin convertirse en alternativas equivalentes.
testability, operability y portability aportan conocimiento arquitectónico ya existente. Seleccionar un escenario pertinente y evidencia suficiente, en vez de asumir que una transición pura o una página de servidor cubren toda integración. trade-off-analysis permite discutir consecuencias sin asignar puntuaciones universales a clientes o frameworks.
Commerce como recorrido situado
Para checkout, comenzar por responsabilidades de presentación y qué confirma realmente la respuesta. Seguir intención Pay, estado pendiente, efecto remoto y resultado mediante UDF. A la vez, preguntar qué representación llegó inicialmente y qué ejecución hizo falta para interactuar. Son decisiones distintas que deben conservar contratos compatibles.
data-ownership mantiene autoridad de Payments aunque el browser tenga una copia de su estado. communication ayuda a examinar el vínculo remoto; deployment y execution-model conservan otras preguntas del sistema. Ninguna flecha de UI demuestra que un timeout signifique pago fallido o que un nuevo container resuelva el resultado incierto.
architecture-profiles sigue organizando paquetes de decisiones más amplios. Commerce puede utilizar Modular Monolith o Microservices y combinar en sus clientes patrones de presentación, UDF y rendering híbrido. El mapa no reemplaza esos perfiles ni los convierte en implementaciones de frontend.
Cobertura inicial y continuidad
La cobertura V0.3 de esta rama conecta Presentation Patterns con MVC, MVP y MVVM; UDF, Rendering Strategies, Client State Management, Micro Frontends, Backend for Frontend, Mobile Architecture, Offline First, Synchronization, Web Performance, Accessibility e Internationalization. Los temas definidos en el blueprint están materializados; su organización sigue siendo navegación editorial, no una taxonomía universal ni afirmación de que el conocimiento esté terminado. Mantener una fuente canónica por concepto y ampliar conforme haya necesidad, sin anticipar notas de tecnologías ni fragmentar cada mecanismo en otra página.