Edita

Comparteix a través de

Back-end para el patrón de front-end

Azure

Desacoplar los servicios de back-end de las implementaciones de front-end para adaptar experiencias para diferentes interfaces de cliente. Este patrón es útil cuando desea evitar personalizar un back-end que sirva varias interfaces. Este patrón se basa en Pattern: Backends For Frontends descritos por Sam Newman.

Contexto y problema

Considere una aplicación diseñada inicialmente con una interfaz de usuario web de escritorio y un servicio back-end correspondiente. A medida que los requisitos empresariales cambiaron con el tiempo, se agregó una interfaz móvil. Ambas interfaces interactúan con el mismo servicio back-end, pero las funcionalidades de un dispositivo móvil difieren significativamente de un explorador de escritorio, en términos de tamaño de pantalla, rendimiento y limitaciones de visualización.

diagrama de arquitectura que muestra el contexto y el problema del patrón Back-ends for Frontends.

El servicio back-end a menudo se enfrenta a demandas de diferentes front-end, lo que conduce a cambios frecuentes y posibles cuellos de botella en el proceso de desarrollo. Las actualizaciones en conflicto y la necesidad de mantener la compatibilidad dan lugar a un trabajo excesivo en un único recurso implementable.

Tener un equipo independiente que administre el servicio back-end puede crear una desconexión entre los equipos de front-end y back-end, lo que provoca retrasos en obtener consenso y equilibrar los requisitos. Por ejemplo, los cambios solicitados por un equipo de front-end deben validarse con otros equipos de front-end antes de la integración.

Solución

Introduzca una nueva capa que controle solo los requisitos específicos de la interfaz. Esta capa denominada servicio back-for-frontend (BFF) se encuentra entre el cliente de front-end y el servicio back-end. Si la aplicación admite varias interfaces, cree un servicio BFF para cada interfaz. Por ejemplo, si tiene una interfaz web y una aplicación móvil, creará servicios BFF independientes para cada uno.

Este patrón adapta la experiencia de cliente para una interfaz específica, sin afectar a otras interfaces. También ajusta el rendimiento para adaptarse mejor a las necesidades del entorno de front-end. Dado que cada servicio BFF es más pequeño y menos complejo, la aplicación puede experimentar ventajas de optimización en cierto grado.

Los equipos front-end tienen autonomía sobre su propio servicio BFF, lo que permite flexibilidad en la selección de idioma, cadencia de versión, priorización de cargas de trabajo e integración de características sin depender de un equipo de desarrollo de back-end centralizado.

Aunque muchas BFFs se basan en las API REST, las implementaciones de GraphQL se están convirtiendo en una alternativa, lo que elimina la necesidad de la capa BFF porque el mecanismo de consulta no requiere un punto de conexión independiente.

diagrama de arquitectura que muestra los back-end para el patrón de front-end.

Para obtener más información, consulte patrón de : back-end para front-end.

Problemas y consideraciones

  • Evalúe cuál es el número óptimo de servicios para usted, ya que esto tendrá costos asociados. Mantener e implementar más servicios significa un aumento de la sobrecarga operativa. Cada servicio individual tiene su propio ciclo de vida, requisitos de implementación y mantenimiento, y necesidades de seguridad.

  • Revise los objetivos de nivel de servicio (SLO) al agregar un nuevo servicio. Es posible que se produzca una mayor latencia porque los clientes no se ponen en contacto directamente con los servicios y el nuevo servicio introduce un salto de red adicional.

  • Cuando diferentes interfaces realizan las mismas solicitudes, evalúe si las solicitudes se pueden consolidar en un único servicio BFF. Compartir un único servicio BFF entre varias interfaces puede dar lugar a diferentes requisitos para cada cliente, lo que puede complicar el crecimiento y el soporte técnico del servicio BFF.

    La duplicación de código es un resultado probable de este patrón. Evalúe el equilibrio entre la duplicación de código y una experiencia más personalizada para cada cliente.

  • El servicio BFF solo debe controlar la lógica específica del cliente relacionada con una experiencia de usuario específica. Las características transversales, como la supervisión y la autorización, deben abstraerse para mantener la luz del servicio BFF. Las características típicas que pueden aparecer en el servicio BFF se controlan por separado con , limitación de velocidad, enrutamiento, etc.

  • Tenga en cuenta el impacto en el equipo de desarrollo al aprender e implementar este patrón. La creación de nuevos back-end requiere tiempo y esfuerzo, lo que podría incurrir en deuda técnica al tiempo que mantiene el servicio back-end existente.

  • Evalúe si necesita este patrón en absoluto. Por ejemplo, si su organización usa GraphQL con solucionadores específicos del front-end, es posible que BFF no agregue valor a las aplicaciones.

    Otro ejemplo es la aplicación que combina api Gateway con microservicios. Este enfoque puede ser suficiente en algunos casos en los que se recomendaron anteriormente BFF.

Cuándo usar este patrón

Use este patrón en los siguientes supuestos:

  • Un servicio back-end compartido o de uso general debe mantenerse con una sobrecarga de desarrollo significativa.

  • Quiere 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 solo se usa una interfaz para interactuar con el back-end.

Diseño de cargas de trabajo

Un arquitecto debe evaluar cómo se pueden usar los back-ends para front-end en el diseño de su carga de trabajo para abordar los objetivos y principios que se tratan en los pilares de Azure Well-Architected Framework. 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. Tener servicios independientes que son exclusivos de una interfaz de front-end específica contiene un mal funcionamiento, por lo que es posible que la disponibilidad de un cliente no afecte a la disponibilidad del acceso de otro cliente. Además, al tratar varios clientes de forma diferente, puede priorizar los esfuerzos de confiabilidad en función de los patrones de acceso de cliente esperados.

- 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 el nivel de servicio que admite 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.

- de segmentación SE:04
- 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 de back-end le permite optimizar de maneras que podrían no ser posibles con un nivel de servicio compartido. Al controlar clientes individuales de forma diferente, puede optimizar el rendimiento de las restricciones y funcionalidades de un cliente específico.

- PE:02 Planeamiento de capacidad
- flujos críticos de PE:09

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.

Ejemplo

En este ejemplo se muestra un caso de uso para el patrón en el que tiene dos aplicaciones cliente distintas: una aplicación móvil y una aplicación de escritorio. Ambos clientes interactúan con una instancia de Azure API Management (puerta de enlace del plano de datos), que actúa como una capa de abstracción, controlando problemas transversales comunes, como:

  • autorización: garantizar que solo las identidades comprobadas con los tokens de acceso adecuados pueden llamar a recursos protegidos mediante Azure API Management (APIM) con el identificador entra de Microsoft.

  • Supervisión: captura y envío de detalles de solicitud y respuesta con fines de observabilidad a Azure Monitor.

  • de almacenamiento en caché de solicitudes: optimización de solicitudes repetidas al atender las respuestas de la memoria caché mediante características integradas de APIM.

  • enrutamiento & de agregación: dirigir las solicitudes entrantes al back-end adecuado para los servicios de front-end (BFF).

Cada cliente tiene un servicio BFF dedicado que se ejecuta como una función de Azure que actúa como intermediario entre la puerta de enlace y los microservicios subyacentes. Este BFF específico del cliente garantiza una experiencia adaptada para la paginación entre otras funcionalidades. Aunque el dispositivo móvil es más consciente del ancho de banda y el almacenamiento en caché mejora el rendimiento, el escritorio agrega varias páginas en una sola solicitud, optimizando para una experiencia de usuario más completa.

Diagrama que muestra la arquitectura de Azure BFF con Azure API Management que controla los problemas transversales; mobile and desktop fetch data using client-specific BFF Azure Functions( Captura de datos móviles y de escritorio mediante BFF Azure Functions específico del cliente).

Flujo A: Cliente móvil: primera solicitud de página

  1. El cliente móvil envía una solicitud de GET para la página 1, incluido el token de OAuth 2.0 en el encabezado de autorización.
  2. La solicitud alcanza la puerta de enlace de Azure APIM, que la intercepta y:
    1. Comprueba el estado de autorización: APIM implementa defensa en profundidad, por lo que comprueba la validez del token de acceso.
    2. Transmisión de la actividad de solicitud como registros a Azure Monitor: los detalles de la solicitud se registran para la auditoría y la supervisión.
  3. Las directivas se aplican y, a continuación, Azure APIM enruta la solicitud al BFF de Azure Function Mobile.
  4. A continuación, azure Function Mobile BFF interactúa con los microservicios necesarios para capturar una sola página y procesar los datos solicitados para proporcionar una experiencia ligera.
  5. La respuesta se devuelve al cliente.

Flujo B: Cliente móvil: primera solicitud almacenada en caché de páginas

  1. El cliente móvil envía la misma solicitud de GET para la página 1 de nuevo, incluido el token de OAuth 2.0 en el encabezado de autorización.
  2. La puerta de enlace de Azure APIM reconoce que esta solicitud se realizó antes y:
    1. Las directivas se aplican y, después, identifica una respuesta almacenada en caché que coincide con los parámetros de solicitud.
    2. Devuelve la respuesta almacenada en caché inmediatamente, lo que elimina la necesidad de reenviar la solicitud a Azure Function Mobile BFF.

Flujo C: cliente de escritorio: primera solicitud

  1. El cliente de escritorio envía una solicitud de GET por primera vez, incluido el token de OAuth 2.0 en el encabezado de autorización.
  2. La solicitud llega a la puerta de enlace de Azure APIM, donde se tratan problemas transversales similares:
    1. Autorización: la validación de tokens siempre es necesaria.
    2. Transmisión de la actividad de solicitud: los detalles de la solicitud se registran para la observabilidad.
  3. Una vez que se aplicaron todas las directivas, Azure APIM enruta la solicitud al BFF de Azure Function Desktop, que es responsable del procesamiento de aplicaciones con mucha carga de datos. El BFF de escritorio agrega varias solicitudes mediante llamadas de microservicios subyacentes antes de responder al cliente con una respuesta de varias páginas.

Diseño

  • microsoft Entra ID actúa como proveedor de identidades basado en la nube, emitiendo notificaciones de audiencia adaptadas para clientes móviles y de escritorio, que posteriormente se aprovechan para la autorización.

  • azure API Management actúa como proxy entre los clientes y sus BDF agregando un perímetro. Se configura con directivas para validar los tokens web JSON (JWT), rechazando las solicitudes que llegan sin un token o las notificaciones no son válidas para el BFF de destino. Además, transmite todos los registros de actividad a Azure Monitor.

  • azure Monitor funciona como solución de supervisión centralizada, agregando todos los registros de actividad para garantizar una observabilidad completa de un extremo a otro.

  • azure Functions es una solución sin servidor que expone sin problemas la lógica de BFF en varios puntos de conexión, lo que permite el desarrollo simplificado, reduce la sobrecarga de infraestructura y reduce los costos operativos.

Pasos siguientes