Header Ads Widget

Ticker

6/recent/ticker-posts

Microservicios GraphQL (GQLMS) como backend: un caso de estudio de Netflix


La iteración rápida es el objetivo final de muchos desarrolladores. La idea de poder, con muy poca inercia, superar las barreras del desarrollo y la colaboración para entregar un producto completamente nuevo es un sueño hecho realidad. Para muchas situaciones, sin embargo, es menos una cuestión de si se desea un despliegue rápido, y más una cuestión de si es posible o no.


Una excelente tecnología para habilitar esta iteración es GraphQL . GraphQL puede potenciar una agilidad excepcional, pero tiene algunos inconvenientes en algunas situaciones . Hoy, veremos la propuesta de valor general de GraphQL, así como una implementación específica realizada por Netflix. Veremos algunos casos de uso que permite GraphQL y, con suerte, mostraremos algunos de los maravillosos beneficios que puede traer la adopción.


¿Qué es GraphQL?

GraphQL es una especificación de lenguaje de consulta de capa de aplicación diseñada para interpretar una cadena de un servidor o cliente y luego entregar esos datos según la forma y función solicitada por la entidad solicitante. En otras palabras, como explica el sitio web GraphQL, GraphQL le permite "describir sus datos, pedir lo que quiere y obtener resultados predecibles".


Esta maleabilidad de la forma y función de la respuesta tiene sentido, dado que GraphQL se derivó originalmente de Facebook. En ese momento, Facebook se estaba alejando de sus aplicaciones y soluciones HTML5 para encontrar una forma nativa más sólida de mostrar datos y promover la participación de los usuarios. Facebook tenía la importante necesidad adicional de combinar conjuntos de datos de fuentes completamente dispares.


En consecuencia, su solución fue permitir que las solicitudes fueran moldeadas por quien las solicitaba. En lugar de ofrecer un punto de datos y todos sus campos relacionados, GraphQL fue diseñado para permitir que un usuario solicite un elemento específico, en una forma específica, con una salida específica compatible con el caso de uso subyacente para ese usuario final específico. Sin embargo, esta capacidad para cambiar la solicitud fundamental desbloqueó otros beneficios que hicieron de GraphQL una solución potente . Al definir la forma y función específicas y permitir múltiples llamadas en una solicitud singular, GraphQL logró una funcionalidad mucho más eficiente.


Hemos cubierto GraphQL antes con mayor detalle, pero la conclusión principal es que GraphQL es simple, intuitivo y permite la recuperación y agregación precisas de datos. Se pueden extraer varios puntos de datos con una sola consulta. GraphQL permite mutaciones, consultas y suscripciones para establecer conexiones personalizadas con el servidor y los datos solicitados para una amplia gama de resultados.


¿Cómo permite GraphQL una implementación rápida?

El principal beneficio de adoptar GraphQL en un entorno de implementación rápida es la eficiencia en la forma en que maneja la recuperación de datos. Los costos de transferencia de datos se reducen significativamente, tanto para el servidor como para el cliente; dado que esta transferencia se puede restringir solo a lo que el cliente necesita o solicita, las llamadas no se desperdician. El costo de tránsito también se reduce significativamente ya que estas llamadas también se pueden combinar en una sola solicitud GraphQL.


Esto también significa que se puede controlar el tamaño y el método de la solicitud, lo que permite que existan múltiples fuentes de datos y se cotejen, comparen o combinen, lo que finalmente desbloquea muchas posibilidades. Primero, esto hace que el backend sea mucho más estable. Como GraphQL no requiere lenguajes, arquitecturas, etc. específicos para ofrecer su potente solución, el backend se puede construir en piezas que sean más apropiadas para cada componente en lugar de lo que sea más adecuado para el punto final final.


Este desacoplamiento del ciclo de desarrollo de backend y frontend es muy importante, y la capacidad de mezclar y combinar es lo que hace que GraphQL sea tan eficaz para un desarrollo rápido. Considere por un momento lo que se necesita en un entorno de implementación rápida: debe crear rápidamente un prototipo y crear flujos y patrones de solicitud que toquen los recursos de formas para las que esos recursos posiblemente no fueron diseñados inicialmente.


Más importante aún, debe construir con lo que tiene, no con lo que necesita, lo que permite que existan conjuntos de datos dispares como lo hacen actualmente, en lugar de existir de la manera que desearía que existieran. No es necesario crear nuevos sistemas, servidores y servicios para cada pequeña cosa que desee probar e implementar; solo desea poder desarrollar y probar. Esa situación exacta es donde GraphQL brilla más: no necesita hacer nada más que señalar sus recursos, definir lo que desea y mutar una vez que llegue a donde lo envía.


La reducción de los costos de transferencia de datos también ayuda en esta implementación rápida, ya que la creación de prototipos se puede mantener de manera eficiente, dirigida y con un propósito. Esto significa que la resolución de problemas no se realiza dentro del panorama de solicitudes no controladas, sino dentro de la solicitud formada, conocida y limitada. Las fugas y las ineficiencias están expuestas de forma predeterminada, ya que sobresalen como un pulgar dolorido. Donde esas fugas e ineficiencias son más difíciles de encontrar, puede probar rápidamente diferentes tipos y formas de llamadas para encontrar de dónde proviene la falla y qué enfoque específico la está causando.


Uno de los mayores beneficios de adoptar GraphQL en esta mentalidad de desarrollo es la mejora de la comprensión organizacional. La mayoría de las veces, las API descritas con el esquema de gráfico GraphQL dan como resultado una API mejor estructurada, más fácil de entender y con una anotación más completa. Comprender el flujo de datos centrales a través de este sistema y cómo funcionan las partes constituyentes puede conducir a ganancias significativas.


Esto puede parecer un beneficio menor, pero la realidad es que el desarrollo de API tradicional a menudo puede conducir a API que hacen lo que deben hacer con una complejidad adicional invisible que es difícil de codificar. Puede hacer que algo haga su trabajo, pero no tiene nada con qué compararlo en términos de eficiencia. Con GraphQL, puede iterar, desarrollar y probar, y su comprensión más completa dará como resultado una mayor eficiencia y eficacia del sistema subyacente.


Estudio de caso de Netflix

Afortunadamente, hay un excelente ejemplo de dónde se ha aprovechado GraphQL para implementar un backend eficaz para una implementación rápida. Al escribir en el Blog de tecnología de Netflix , Dane Avilla, un ingeniero de software senior, discutió precisamente cómo GraphQL desbloqueó estos beneficios.


Avilla señala que el equipo comenzó con dos teorías centrales en torno a lo que consideraban los "beneficios anunciados de GraphQL". Primero, creían que el uso de GraphQL IDE en forma de GraphiQL les permitiría emparejar la documentación con el esquema, y ​​que esto proporcionaría ergonomía al desarrollador a través de una mayor comprensión del sistema en sí. Dicho respaldo proporcionaría información de componentes que fuera referenciable, iterable e implementable.


Su segunda teoría era que la tipificación fuerte, el soporte al cliente políglota y el agnosticismo de la solución que sustenta las capacidades de transformación de GraphQL permitirían la generación de clientes agnósticos. Esto permitiría la iteración rápida de los clientes que fueran más apropiados para cada situación.


Parte del objetivo declarado del equipo de Netflix era esencialmente crear una experiencia RESTful mejorada. Se refieren a esto como "mejor DESCANSO que DESCANSO" o "DESCANSO ++". La idea simple era agrupar la biblioteca Graphile que sustenta el entorno y agruparla en una imagen base de Docker que permitiera a cualquier equipo extraer la imagen y crear rápidamente un entorno para pruebas e implementación.


En su búsqueda de esta solución, adoptaron algunas soluciones que, aunque específicas para su caso de uso, exponen el potencial de este tipo de sistema. En primer lugar, el equipo de Netflix decidió tomar las tablas de datos en su esquema PostgreSQL y definirlas en otro esquema. Al hacerlo, pudieron:


Crear vistas de base de datos seguras (logradas mediante el aprovechamiento del sistema de concesión explícito predeterminado en el flujo entre el usuario de PostgreSQL y la aplicación web);

Cree tablas de datos que existían independientemente de las vistas de esquema GraphQL expuestas, lo que permite una rápida iteración y mutación en distintos conjuntos de datos;

Sistemas de formato proporcionados a través de las vistas de la base de datos; y

Creó un flujo de datos donde las tablas y vistas se podían cambiar, mutar y transformar "de manera que los cambios en el esquema GraphQL expuesto ocurrieran de forma atómica".

En otras palabras, la solución en cuestión creó un sistema en el que la vista de la base de datos se podía trabajar y transformar de formas nuevas y emocionantes sin afectar los esfuerzos de otros equipos o funciones comerciales centrales.


Esta solución no estuvo exenta de aspectos negativos, por supuesto. El equipo notó que los tipos anidados eran difíciles de describir en Graphile debido a cómo se describen esos tipos. Si bien pudieron solucionar esos problemas, surgieron otras preocupaciones que permanecen en su implementación. El principal de estos es que en el comportamiento predeterminado adoptado, había (y siguen existiendo) preocupaciones sobre el DDOSing a través de llamadas ilimitadas a la base de datos, la falta de una solución sólida de gestión de identidades, etc.


Netflix señala que, si bien estos problemas aún existen, la realidad es que, en su caso de uso, la preocupación es algo silenciada:


“Sin embargo, en el contexto de GQLMS para el desarrollo rápido de aplicaciones internas por parte de equipos pequeños, tener el comportamiento Graphile predeterminado de hacer que todas las columnas estén disponibles para el filtrado permitió al equipo de UI iterar rápidamente a través de una serie de nuevas funciones sin necesidad de involucrar al equipo de backend. . Esto contrasta con otros modelos de desarrollo en los que los equipos de IU y backend acuerdan primero un contrato de API inicial, el equipo de backend implementa la API, el equipo de IU consume la API y luego el contrato de API evoluciona a medida que las necesidades de la IU cambian durante el ciclo de vida del desarrollo ".


Sin embargo, este ejemplo es intenso y quizás no sea apropiado para la mayoría de las organizaciones. La adopción de GraphQL puede permitir un desarrollo y creación de prototipos más rápidos y, como se ve en el caso de Netflix, cuando se lleva al extremo, puede generar experiencias de colaboración rápidas más allá de la flexibilidad de otras soluciones actuales. El equipo de Netflix es plenamente consciente de esto y señala en el blog de tecnología original lo siguiente:


"Dicho esto, la implementación exitosa de una aplicación interna durante 4-6 semanas con requisitos iniciales limitados y un equipo distribuido ad hoc (sin historial previo de colaboración) despertó un gran interés en Netflix Studio. Otros equipos dentro de Netflix son encontrar el enfoque GQLMS de:


1) usar construcciones y utilidades GraphQL estándar para exponer la base de datos como API
2) aprovechar los tipos personalizados de PostgreSQL para crear un esquema GraphQL
3) aumentar la flexibilidad mediante la generación automática de una API grande a partir de una base
de datos 4) y exponer lógica comercial personalizada adicional y tipos de datos junto con los generados por Graphile


para ser una solución viable para herramientas CRUD internas que históricamente habrían utilizado REST. Tener un contenedor Docker estandarizado que aloje Graphile proporciona a los equipos la infraestructura necesaria mediante la cual pueden iterar rápidamente en la creación de prototipos y el rápido desarrollo de aplicaciones de nuevas herramientas para resolver las necesidades cambiantes de un estudio de medios global durante estos tiempos desafiantes ".


Conclusión

GraphQL es una solución poderosa que permite una gran libertad en la implementación y la iteración. Como podemos ver en la historia de Netflix, puede tener sus propios inconvenientes en implementaciones específicas. En consecuencia, si bien GraphQL es una gran tecnología y puede desbloquear un gran potencial, debe usarse en las circunstancias apropiadas con una comprensión de sus limitaciones. Con una comprensión de las limitaciones, así como de las fortalezas, GraphQL puede ser un multiplicador de gran valor.


¿Qué opinas del experimento de Netflix con GraphQL? ¿Hay algún otro experimento similar del que tenga conocimiento que le gustaría que cubramos? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios