Netflix es conocido por su arquitectura de microservicios poco acoplada y altamente escalable.  Los servicios independientes permiten evolucionar a diferentes ritmos y escalar de forma independiente. Sin embargo, agregan complejidad para casos de uso que abarcan múltiples servicios. En lugar de exponer cientos de microservicios a los desarrolladores de UI, Netflix ofrece una capa de agregación de API unificada en el borde.

A los desarrolladores de UI les encanta la simplicidad de trabajar con una API conceptual para un dominio grande. A los desarrolladores de back-end les encanta el desacoplamiento y la resistencia que ofrece la capa de API. Pero a medida que nuestro negocio ha ido creciendo, nuestra capacidad para innovar rápidamente se ha acercado a una asíntota (En geometría, línea recta que, prolongada indefinidamente, se acerca progresivamente a una curva sin llegar nunca a encontrarla). A medida que aumentamos el número de desarrolladores y aumentamos la complejidad de nuestro dominio, desarrollar la capa de agregación de API se ha vuelto cada vez más difícil.

Para abordar este problema creciente, hemos desarrollado una plataforma GraphQL federada para potenciar la capa API. Esto resuelve muchos de los desafíos de consistencia y velocidad de desarrollo con compensaciones mínimas en dimensiones como escalabilidad y operatividad. Hemos implementado con éxito este enfoque para el ecosistema de estudio de Netflix y estamos explorando patrones y adaptaciones que podrían funcionar en otros dominios. Compartimos nuestra historia para inspirar a otros y fomentar conversaciones sobre la aplicabilidad en otros lugares.

Estudio de caso: Studio Edge

Introducción al ecosistema de Studio

Netflix está produciendo contenido original a un ritmo acelerado. Desde el momento en que se presenta un programa de televisión o una película hasta que está disponible en Netflix, suceden muchas cosas detrás de escena. Esto incluye, entre otros, búsqueda de talentos y casting, negociaciones de acuerdos y contratos, producción y postproducción, efectos visuales y animaciones, subtitulado y doblaje, y mucho más. Studio Engineering está creando cientos de aplicaciones y herramientas que impulsan estos flujos de trabajo.

API de Studio

Mirando hacia atrás unos años, uno de los dolores en el API Studio fue la creciente complejidad de los datos y sus relaciones. Los flujos de trabajo que se muestran arriba están intrínsecamente conectados, pero los datos y sus relaciones eran dispares y existían en miles de microservicios. Los equipos de producto resolvieron esto con dos patrones arquitectónicos.

1) Capas de agregación de un solo uso: debido al acoplamiento flexible, observamos que muchos equipos dedicaron un esfuerzo considerable a la creación de códigos de obtención de datos duplicados y capas de agregación para respaldar las necesidades de sus productos. Esto fue realizado por equipos de UI a través de BFF (Backend For Frontend) o por un equipo de backend en un servicio de nivel medio.

2) Vistas materializadas para datos de otros equipos: algunos equipos utilizaron un patrón de construcción de una vista materializada de los datos de otro servicio para sus necesidades específicas del sistema. Las vistas materializadas tuvieron beneficios de rendimiento, pero la coherencia de los datos se retrasó en diversos grados. Esto no era aceptable para los flujos de trabajo más importantes de Studio. Los datos inconsistentes en diferentes aplicaciones de Studio fueron el principal problema de soporte en Studio Engineering en 2018.

API de gráficos: para abordar mejor las necesidades subyacentes, nuestro equipo comenzó a crear una API de gráficos seleccionada llamada “API de Studio”. Su objetivo era proporcionar una abstracción unificada además de los datos y las relaciones. Studio API utilizó GraphQL como su tecnología API subyacente y creó un apalancamiento significativo para acceder a los datos compartidos principales. Los consumidores de la API de Studio pudieron explorar el gráfico y crear nuevas funciones más rápidamente. También observamos menos casos de inconsistencia de datos en diferentes aplicaciones de IU, ya que cada campo en GraphQL se resuelve en una sola pieza de código de obtención de datos.

Cuellos de botella de la API Studio

El One Graph expuesto por Studio API fue un éxito rotundo; A los equipos de productos les encantó la reutilización y el acceso fácil y coherente a los datos. Pero surgieron nuevos cuellos de botella a medida que aumentaba el número de consumidores y la cantidad de datos en el gráfico.

Primero, el equipo de la API Studio se desconectó de la experiencia del dominio y de las necesidades del producto, lo que afectó negativamente la salud del esquema. En segundo lugar, la conexión de nuevos elementos desde un back-end a la API gráfica fue manual y fue en contra de la rápida evolución prometida por una arquitectura de microservicios. Finalmente, fue difícil para un equipo pequeño manejar la creciente carga operativa y de soporte para el gráfico en expansión.

Sabíamos que tenía que haber una mejor manera: unificada pero desacoplada, curada pero en rápido movimiento.

Volviendo a los principios básicos

Para abordar estos cuellos de botella, nos apoyamos en nuestra rica historia de microservicios y rompiendo monolitos (en referencia a arquitecturas monolíticas). Todavía queríamos mantener el esquema GraphQL unificado de la API Studio, pero descentralizar la implementación de los resolutores a sus respectivos equipos de dominio.

Mientras estábamos haciendo una lluvia de ideas sobre la nueva arquitectura a principios de 2019, Apollo lanzó la Especificación de Federación GraphQL . Esto prometía los beneficios de un esquema unificado con propiedad e implementación distribuidas. Realizamos una implementación de prueba de la especificación con resultados prometedores y nos acercamos para colaborar con Apollo en el futuro de GraphQL Federation. Nuestra arquitectura de próxima generación, “Studio Edge”, surgió con la federación como elemento crítico.

Introducción a la federación GraphQL

El objetivo de GraphQL Federation es doble: proporcionar una API unificada para los consumidores y, al mismo tiempo, brindar a los desarrolladores de backend flexibilidad y aislamiento del servicio. Para lograr esto, es necesario crear y anotar esquemas para indicar cómo se distribuye la propiedad. Veamos un ejemplo con tres entidades centrales:

1. Película : en Netflix hacemos títulos (programas, películas, cortometrajes, etc.). Para simplificar, supongamos que cada título es un objeto Movie .
2. Producción : cada película está asociada a una producción de estudio. Un objeto de producción rastrea todo lo necesario para hacer una película, incluida la ubicación de la filmación, los proveedores y más.
3. Talento : las personas que trabajan en una película son el talento, incluidos actores, directores, etc.

Estos tres dominios pertenecen a tres equipos de ingeniería independientes responsables de sus propias fuentes de datos, lógica empresarial y microservicios correspondientes. En una implementación no federada, tendríamos este esquema simple y Resolvers de propiedad e implementados por el equipo de la API Studio. GraphQL Framework tomaría las consultas de los clientes y organizaría las llamadas a los resolutores en un recorrido de amplitud primero.

Para realizar la transición a una arquitectura federada, debemos transferir la propiedad de estos resolutores a sus respectivos dominios sin sacrificar el esquema unificado. Para lograr esto, necesitamos extender el tipo de película a través de los límites del servicio GraphQL:

Esta capacidad de extender un tipo de película a través de los límites del servicio GraphQL convierte a la película en un tipo federado . La resolución de un campo determinado requiere la delegación por una capa de puerta de enlace hasta los servicios del dominio propietario.

Arquitectura de Studio Edge

Usando la capacidad de federar un tipo, visualizamos la siguiente arquitectura:

Componentes arquitectónicos clave

Domain Graph Service (DGS) es un servicio GraphQL independiente que cumple con las especificaciones. Los desarrolladores definen su propio esquema GraphQL federado en un DGS. Un DGS es propiedad y está operado por un equipo de dominio responsable de esa subsección de la API. Un desarrollador de DGS tiene la libertad de decidir si desea convertir su microservicio existente en un DGS o poner en marcha un nuevo servicio.

Schema Registry es un componente con estado que almacena todos los esquemas y cambios de esquema para cada DGS. Expone las API de CRUD para esquemas, que utilizan las herramientas de desarrollo y las canalizaciones de CI / CD. Es responsable de la validación del esquema, tanto para los esquemas DGS individuales como para el esquema combinado. Por último, el registro compone el esquema unificado y lo proporciona a la puerta de enlace.

GraphQL Gateway es el principal responsable de atender las consultas GraphQL a los consumidores. Toma una consulta de un cliente, la divide en subconsultas más pequeñas (un plan de consulta) y ejecuta ese plan enviando llamadas a los DGS descendentes apropiados.

Detalles de implementacion

Hay 3 componentes principales de lógica empresarial que impulsan la federación GraphQL.

Composición del esquema

La composición es la fase que toma todos los esquemas DGS federados y los agrega en un solo esquema unificado. Gateway expone este esquema compuesto a los consumidores del gráfico.

Siempre que un DGS envía un esquema nuevo, el Registro de esquemas valida que:

1. El nuevo esquema es un esquema GraphQL válido
2. El nuevo esquema se compone a la perfección con el resto de los esquemas de DGS para crear un esquema compuesto válido
3. El nuevo esquema es compatible con versiones anteriores

Si se cumplen todas las condiciones anteriores, el esquema se registra en el Registro de esquemas.

Planificación y ejecución de consultas

La configuración de la federación consta de todos los esquemas DGS individuales y el esquema compuesto. Gateway usa la configuración de federación y la consulta del cliente para generar un plan de consulta. El plan de consulta divide la consulta del cliente en subconsultas más pequeñas que luego se envían a los DGS descendentes para su ejecución, junto con un orden de ejecución que incluye lo que se debe hacer en secuencia en lugar de ejecutar en paralelo.

Creamos una consulta simple a partir del esquema mencionado anteriormente y veamos cómo se vería el plan de consulta.

Para esta consulta, la puerta de enlace sabe qué campos son propiedad de qué DGS según la configuración de federación. Con esa información, divide la consulta del cliente en tres consultas separadas para tres DGS. La primera consulta se envía a Movie DGS ya que las películas de campo raíz son propiedad de ese DGS. Esto da como resultado la recuperación de los campos movieId y title de las primeras 10 películas en el conjunto de datos. Luego, utilizando los movieId‘s que obtuvo de la solicitud anterior, la puerta de enlace ejecuta dos solicitudes paralelas a Production DGS y Talent DGS para buscar la producción y los actores para esas 10 películas. Una vez completada, las respuestas a la subconsulta se fusionan y la respuesta de datos combinados se devuelve al llamante.

Fantástico!

Una nota sobre el rendimiento: la planificación y ejecución de consultas agrega una sobrecarga de ~ 10 ms en el peor de los casos . Esto incluye el cálculo para crear el plan de consulta, así como la deserialización de las respuestas DGS y la serialización de la respuesta de la puerta de enlace fusionada.

Resolución de entidad

Ahora quizás se esté preguntando, ¿cómo funcionan realmente las subconsultas paralelas a Producción y Talent DGS? Eso no es algo que admita la DGS. Esta es la última pieza del rompecabezas.

Volvamos a nuestra película de tipo federado . Para que la puerta de enlace se una a la película sin problemas en todos los DGS, todos los DGS que definen y amplían la película deben estar de acuerdo en uno o más campos que definen la clave principal (por ejemplo, movieId) . Para que esto funcione, Apollo introdujo la directiva @key en las especificaciones de la federación. En segundo lugar, los DGS deben implementar un solucionador para un campo de consulta genérico , _entities. La consulta _entities devuelve un tipo de unión de todos los tipos federados en ese DGS. La puerta de enlace usa la consulta _entities para buscar Movie por movieId.

Echemos un vistazo a cómo se ve realmente el plan de consulta:

El objeto de representación consta de movieId y se genera a partir de la respuesta de la primera solicitud a Movie DGS. Como solicitamos las primeras 10 películas, tendríamos 10 objetos de representación para enviar a Producción y Talent DGS.

Esto es similar a la identificación de objetos de Relay con algunas diferencias. _Entity es un tipo de unión, mientras que Relay’s Node es una interfaz. Además, con @key, hay soporte para nombres y tipos de clave variable, así como claves compuestas, mientras que en Relay, la identificación es un solo campo de identificación opaco.

Combinados, estos son los ingredientes que impulsan el núcleo de una arquitectura de API federada.

El viaje, resumido

Nuestra arquitectura Studio Ecosystem ha evolucionado en distintas fases, todas ellas motivadas por reducir el tiempo entre la idea y la implementación, mejorar la experiencia del desarrollador y agilizar las operaciones. Las fases arquitectónicas se ven así:

Manténganse al tanto

Durante el año pasado, implementamos los componentes de la arquitectura de API federada en nuestro Studio Edge. Llegar aquí requirió una iteración rápida, muchas colaboraciones multifuncionales, algunos pivotes e inversión continua. Estamos en vivo con 70 DGS y cientos de desarrolladores que contribuyen y utilizan la arquitectura de Studio Edge. En nuestra próxima publicación de Netflix Tech Blog, compartiremos lo que aprendimos a lo largo del camino, incluidas las preocupaciones transversales necesarias para construir una solución integral.

Queremos agradecer a toda la comunidad de código abierto GraphQL por todas las generosas contribuciones y por allanar el camino hacia la promesa de GraphQL. Si desea ser parte de la resolución de problemas complejos e interesantes como este a escala de Netflix, consulte nuestra página de trabajos o comuníquese con nosotros directamente.

Por Tejas Shikhare

Créditos adicionales: Stephen Spalding , Jennifer Shin , Philip Fisher-Ogden , Robert Reta , Antoine Boyer , Bruce Wang , David Simmer

Traducción al español: Juan José González Faúndez

Fuente: https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2

Please follow and like us: