Crea servicios independientes de back-end que determinadas aplicaciones de front-end o interfaces puedan usar. Este patrón es útil cuando desea evitar personalizar un único back-end para varias interfaces. Sam Newman describió por primera vez este patrón.
Contexto y problema
Inicialmente se puede destinar una aplicación a una interfaz de usuario web de escritorio. Normalmente, un servicio back-end se desarrolla en paralelo y proporciona las características necesarias para esa interfaz de usuario. A medida que crece la base de usuarios de la aplicación, se desarrolla una aplicación móvil que debe interactuar con el mismo back-end. El servicio back-end se convierte en un back-end de uso general que atiende los requisitos de la interfaz tanto de escritorio como móvil.
Pero las funcionalidades de un dispositivo móvil difieren significativamente de las de un explorador de escritorio, en términos de tamaño de pantalla, rendimiento y limitaciones de pantalla. En consecuencia, los requisitos para un back-end de aplicación móvil difieren de los de la interfaz de usuario web de escritorio.
Estas diferencias dan lugar a requisitos contrapuestos para el back-end. El back-end requiere cambios significativos y regulares para atender tanto la interfaz de usuario web de escritorio como la aplicación móvil. A menudo, hay equipos independientes de la interfaz que funcionan en cada front-end y hacen que el back-end se convierta un cuello de botella en el proceso de desarrollo. Los requisitos de actualización conflictivos y la necesidad de mantener el servicio en funcionamiento para ambos front-ends pueden suponer dedicar un gran esfuerzo a un único recurso que se puede implementar.
Como la actividad de desarrollo se centra en el servicio back-end, se puede crear un equipo independiente para administrar y mantener el back-end. En última instancia, esto produce una desconexión entre los equipos de desarrollo de la interfaz y del back-end, lo que supone una carga para el equipo del back-end a la hora de equilibrar los requisitos contrapuestos de los diferentes equipos de la interfaz de usuario. Cuando un equipo de la interfaz requiere cambios en el back-end, esos cambios se deben validar con otros equipos de la interfaz antes de que se pueden integrar en el back-end.
Solución
Cree un back-end por interfaz de usuario. Ajuste el comportamiento y el rendimiento de cada back-end para que se adapte mejor a las necesidades del entorno de front-end, sin preocuparse de que pueda afectar a otras experiencias de front-end.
Como cada back-end es específico de una interfaz, se puede optimizar para esa interfaz. En consecuencia, será más pequeño, menos complejo y es probable que más rápido que un back-end genérico que intenta satisfacer los requisitos de todas las interfaces. Cada equipo de la interfaz tiene autonomía para controlar su propio back-end y no se apoya en un equipo de desarrollo de back-end centralizado. Esto proporciona flexibilidad al equipo de la interfaz en la selección del lenguaje, el ritmo de lanzamiento, la priorización de la carga de trabajo y la integración de características en el back-end.
Para más información, consulte Pattern: Backends For Frontends (Patrón: servidores back-end para servidores front-end).
Problemas y consideraciones
- Tenga en cuenta cuántos servidores back-end va a implementar.
- Si distintas interfaces (por ejemplo, clientes móviles) van a hacer las mismas solicitudes, calcule si es necesario implementar un back-end para cada interfaz o si será suficiente con un back-end único.
- Es muy probable que se produzca una duplicación de código en los servicios al implementar este patrón.
- Los servicios back-end centrados en front-end solo deben contener una lógica y un comportamientos específicos del cliente. La lógica de negocios general y otras características globales deben administrarse en otra parte de la aplicación.
- Piense en cómo puede reflejarse este patrón en las responsabilidades de un equipo de desarrollo.
- Tenga en cuenta el tiempo que se tardará en implementar este patrón. ¿Incurrirá el esfuerzo de creación de los nuevos backend en una deuda técnica, mientras continúa apoyando el back-end genérico existente?
Cuándo usar este patrón
Use este patrón en los siguientes supuestos:
- Un servicio back-end de uso general o compartido debe mantenerse con una sobrecarga de desarrollo importante.
- Desea optimizar el back-end para los requisitos de interfaces de cliente específicas.
- Las personalizaciones se realizan en un back-end de uso general para dar cabida a varias interfaces.
- Un lenguaje de programación es más adecuado para el back-end de una interfaz de usuario específica, pero no para todas las interfaces de usuario.
Este patrón puede no ser adecuado:
- Cuando las interfaces realizan las mismas solicitudes o similares al back-end.
- Cuando se usa solo una interfaz para interactuar con el back-end.
Diseño de cargas de trabajo
El arquitecto debe evaluar cómo se puede usar el patrón Back-Ends for Front-End en el diseño de su carga de trabajo para abordar los objetivos y principios tratados en los pilares del Marco de la Well-Architected de Azure. Por ejemplo:
| Fundamento | Cómo apoya este patrón los objetivos de los pilares |
|---|---|
| Las decisiones de diseño de la fiabilidad ayudan a que la carga de trabajo sea resistente a los errores y a garantizar que se recupere a un estado de pleno funcionamiento después de que se produzca un error. | Disponer de servicios separados que sean exclusivos de una interfaz de front-end específica contiene fallos de funcionamiento, de modo que la disponibilidad de un cliente podría no afectar a la disponibilidad de acceso de otro cliente. Además, al tratar a los distintos clientes de forma diferente, puede priorizar los esfuerzos de fiabilidad en función de los patrones de acceso previstos de los clientes. - RE:02 Flujos críticos - RE:07 Conservación automática |
| Las decisiones de diseño de seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo. | Debido a la separación de servicios introducida en este patrón, la seguridad y la autorización en la capa de servicios que soporta un cliente se pueden adaptar a la funcionalidad requerida por ese cliente, lo que podría reducir el área expuesta de una API y el movimiento lateral entre distintos back-end que podrían exponer diferentes funcionalidades. - SE:04 Segmentación - SE:08 Recursos de protección |
| La eficiencia del rendimiento ayuda a que la carga de trabajo satisfaga eficazmente las demandas mediante optimizaciones en el escalado, los datos y el código. | La separación del back-end permite optimizar de formas que no serían posibles con una capa de servicios compartida. Al gestionar los distintos clientes de forma diferente, puede optimizar el rendimiento en función de las limitaciones y funcionalidades de cada cliente. - PE:02 Planeamiento de capacidad - PE:09 Flujos críticos |
Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.