Hola Habr!
El
libro de Alex Banks y Eva Porsello, que le dimos a la traducción hace un par de días, le servirá como una breve digresión al lenguaje de consulta GraphQL. El libro de los mismos autores sobre
React y Redux se convirtió en un verdadero éxito de ventas (estamos esperando la quinta edición de la imprenta). Por cierto, gracias a todos los que nos señalaron inexactitudes en el código y los términos;) hicimos el libro sobre tecnología obsoleta tan rápidamente demasiado rápido.
El autor del artículo de hoy, Robin Viruch, también está trabajando en un libro sobre GraphQL y bibliotecas para este lenguaje, y en el artículo de hoy explica brevemente las ventajas y características de GraphQL como una alternativa a REST
Cuando se trata de solicitudes de red entre aplicaciones de cliente y servidor, REST se elige con mayor frecuencia como un puente entre los mundos de cliente y servidor. En REST, todo se desarrolla alrededor de la idea de "necesitamos recursos accesibles por URL". Puede leer un recurso usando una
HTTP GET , crear un recurso usando una
HTTP POST y actualizarlo y eliminarlo usando
HTTP PUT solicitudes
HTTP PUT y
DELETE . Estas operaciones se llaman CRUD (Crear, Leer, Actualizar, Eliminar). El recurso puede ser cualquier contenido recibido de autores, usuarios o tomado de artículos. Cuando se usa REST, el formato de transferencia de datos no está codificado, pero a menudo se usa JSON para este propósito. Al final, REST permite la comunicación entre aplicaciones a través del protocolo HTTP normal utilizando URL y métodos HTTP.
Aunque REST siguió siendo un estándar de facto durante bastante tiempo, en los últimos años otra tecnología desarrollada por Facebook ha ganado popularidad: se llama GraphQL. Este artículo, una introducción a GraphQL, habla sobre los pros y los contras de este lenguaje de consulta.
¿Qué es GraphQL?Antes de sumergirnos en la discusión de las fortalezas y debilidades de GraphQL, primero respondamos la siguiente pregunta: ¿qué es GraphQL? GraphQL es un
lenguaje de consulta gratuito creado por Facebook en 2012. Incluso antes de enviar el producto a código abierto, el lenguaje ya se usaba en Facebook como tecnología interna para trabajar con aplicaciones móviles. ¿Por qué con las aplicaciones móviles? GraphQL fue desarrollado como una alternativa a la arquitectura REST típica. Permite que el cliente solo solicite los datos deseados, ni más ni menos. El cliente es responsable de todo, es decir, usted. En este caso, surgen dificultades en la arquitectura REST, ya que es la interfaz de la base de datos la que determina qué información estará disponible para cada recurso en cada URL. El muestreo de datos no se solicita en la parte del cliente. Por lo tanto, el frontend en cualquier caso debe solicitar toda la información sobre el recurso, incluso si solo necesita una parte de estos datos. Este problema se llama "re-muestreo". En el peor de los casos, la aplicación cliente tiene que leer no solo uno, sino muchos recursos, para acceder a los cuales es necesario realizar muchas solicitudes de red. Esto lleva no solo a volver a muestrear, sino también a solicitudes similares a avalanchas a través de la red. Sin embargo, al tener un lenguaje de consulta como GraphQL, utilizado no solo en el servidor, sino también en el lado del cliente, el cliente decide qué datos necesita, y para esto solo envía una solicitud al servidor. Cuando Facebook desarrolló aplicaciones móviles usando el lenguaje GraphQL, fue posible reducir drásticamente la carga de la red, ya que muchos menos datos comenzaron a transmitirse a través de ella.
Facebook publicó la especificación GraphQL y su implementación de referencia en JavaScript para acceso gratuito. Desde entonces, esta especificación se ha implementado en muchos otros lenguajes de programación importantes. Además, el ecosistema que se ha desarrollado alrededor de GraphQL crece no solo horizontalmente, extendiéndose a otros lenguajes de programación, sino también verticalmente (las bibliotecas se construyen sobre GraphQL, por ejemplo, Apollo, Relay).
GraphQL proporciona los siguientes tipos de operaciones: solicitud (lectura), cambio (escritura) o suscripción (lectura continua). Cualquiera de estas operaciones es solo una cadena que debe ensamblarse de acuerdo con la especificación del lenguaje de consulta GraphQL. Una vez que dicha operación GraphQL llega a la aplicación de la base de datos desde la aplicación cliente, se puede interpretar en comparación con todo el esquema GraphQL ubicado en el back-end y se resuelve para la aplicación cliente utilizando los datos disponibles. GraphQL funciona igualmente bien con cualquier capa de red (que a menudo se organiza a través de HTTP), así como con cualquier formato de carga útil (a menudo JSON). También está completamente "no preocupado" por la arquitectura de la aplicación (que en la mayoría de los casos consiste en la parte del cliente y la interfaz de la base de datos). Es solo un lenguaje de consulta.
Como puede ver, la consulta ya se aplica a muchos recursos (autor, artículo), que se llaman campos en GraphQL, y solo a un conjunto específico de campos anidados para estos campos (nombre, urlSlug para el artículo), aunque se pueden proporcionar otros datos en el esquema de datos GraphQL. Información (por ejemplo, para un artículo: una descripción, fecha de lanzamiento). Mientras que en una arquitectura REST necesitaríamos al menos dos consultas en cascada para recuperar el autor y los artículos de este autor, GraphQL resuelve este problema en una sola consulta. Además, la consulta selecciona solo los campos necesarios, y no toda la entidad.
Esta es la esencia de GraphQL. En el caso de que la aplicación del servidor proporcione el esquema GraphQL en el que define todos los datos disponibles con su jerarquía y tipos, la aplicación cliente solo solicita los datos que necesita.
Beneficios de GraphQLLos siguientes son los principales beneficios de usar GraphQL en una aplicación.
Muestreo de datos declarativosComo puede ver, GraphQL utiliza el muestreo de datos declarativos en sus consultas. El cliente selecciona los datos, sus entidades y todos los campos entre los cuales hay varias relaciones, y para todo esto se aplica una sola solicitud. El cliente decide qué campos son necesarios para esta IU. A menudo, casi se puede hablar sobre el muestreo de datos orientado a la interfaz de usuario. Por ejemplo, así es como Airbnb usa GraphQL. Un motor de búsqueda de Airbnb a menudo proporciona resultados para hogares, impresiones y otras categorías específicas de un área temática determinada. Para extraer todos los datos de una vez, se ejecuta una consulta GraphQL, recogiendo solo la información que definitivamente se necesita en una IU particular. Al final, GraphQL tiene una división de responsabilidad muy bien organizada: el cliente conoce los requisitos de datos, el servidor conoce la estructura de datos y cómo resolver los datos de una fuente existente (ya sea una base de datos, microservicio, API de terceros).
Sin re-muestreo cuando se trabaja con GraphQLCuando se trabaja con GraphQL, no hay re-selección. Mientras que es probable que un cliente móvil alcance una nueva búsqueda utilizando la misma API que un cliente web con una REST-API. Y cuando se trabaja con GraphQL, el cliente móvil y el cliente web pueden elegir diferentes grupos de campos por sí mismos, utilizando la misma API GraphQL. En consecuencia, el cliente móvil puede seleccionar menos información, ya que es posible que no se necesite información innecesaria en la pantalla pequeña (a diferencia del monitor grande desde el que se ve la versión web de la aplicación). GraphQL minimiza la cantidad de datos transmitidos a través de la red, seleccionándolos selectivamente y guiándose en este caso principalmente por las necesidades de la aplicación cliente.
GraphQL para React, Angular, Node, etc.GraphQL es una solución prometedora no solo para los desarrolladores de React. Sea Facebook quien triunfó GraphQL, y en el lado del cliente, Facebook usa React, de hecho, este lenguaje no está vinculado a ninguna solución para el front-end o el back-end. La implementación de referencia de GraphQL está escrita en JavaScript, por lo que GraphQL se puede combinar con Angular, Vue, Express, Hapi, Koa y otras bibliotecas de JavaScript en las partes cliente y servidor. Además, esto se aplica no solo al ecosistema de JavaScript. GraphQL imita REST en un aspecto, por lo que se ha vuelto popular: la interfaz GraphQL es independiente del lenguaje de programación (lenguaje de consulta) utilizado para comunicar dos objetos (por ejemplo, cliente y servidor). Por lo tanto, su especificación se puede reproducir en cualquier lenguaje de programación.
¿Quién usa GraphQL?Facebook ha estado usando GraphQL desde 2012, antes de que este lenguaje se convirtiera en código abierto. Facebook es la fuerza impulsora responsable del desarrollo de la especificación GraphQL y su implementación de referencia en JavaScript. Entonces, trabajando con GraphQL, ya estás parado sobre los hombros de gigantes. Sin embargo, otras compañías conocidas usan este lenguaje en sus aplicaciones. Invierten en el ecosistema GraphQL, porque las aplicaciones modernas tienen una gran necesidad de dicho lenguaje. Por lo tanto, contará con el apoyo no solo de Facebook, sino también de las siguientes empresas:
Cuando Facebook desarrolló GraphQL y lo puso a disposición del público, otras compañías de aplicaciones móviles también enfrentaron problemas similares. Así es como Netflix creó el proyecto Falcor, que puede considerarse una alternativa a GraphQL. Lo que una vez más confirma que para las aplicaciones modernas necesita exactamente soluciones como GraphQL y Falcor.
La única fuente de verdadEn las aplicaciones GraphQL, existe la verdad última: este es el esquema GraphQL. Es ella, la fuente central, que describe todos los datos disponibles. Mientras que el esquema GraphQL generalmente se define en el lado del servidor, los clientes pueden leer (consultar) y escribir (modificar) datos basados en este esquema. Por lo tanto, la aplicación del servidor, en esencia, proporciona la información exhaustiva disponible en el servidor, y el lado del cliente solo pregunta qué se requiere al formular consultas en GraphQL, o cambia pequeños fragmentos de información utilizando los cambios en GraphQL.
GraphQL sigue las tendencias actualesGraphQL sigue las tendencias actuales en el desarrollo de aplicaciones. Solo puede tener una aplicación en el servidor, pero a menudo sucede que muchos clientes diferentes usan este servidor (cliente web, dispositivo móvil, relojes inteligentes ...) y todos dependen de los datos almacenados en la aplicación de servidor. Por lo tanto, GraphQL puede ayudar no solo a hacer amigos de "ambos mundos", sino también a satisfacer los requisitos de cada cliente (relacionado, por ejemplo, usando la red, relaciones de datos anidados, seleccionando solo los datos requeridos) sin la necesidad de crear una API dedicada para cada tipo de cliente.
Por otro lado, en el servidor podemos esperar no solo una interfaz interna, sino un grupo de microservicios, cada uno de los cuales proporciona su propia funcionalidad específica. Es para tal caso que el esquema GraphQL es ideal, cuya estructura es tal que en dicho esquema GraphQL es posible agregar todo tipo de funcionalidades.
Cómo se cose el esquema GraphQLGracias a la costura, puede armar un esquema de muchos otros. ¿Cuándo puedo entrar en esta situación? Digamos que su backend se implementa utilizando una arquitectura de microservicio. Cada microservicio procesa la lógica empresarial y los datos relacionados con un área temática específica. Por lo tanto, cada microservicio puede definir su propio esquema GraphQL. Después de eso, deberá coserlos juntos para ensamblar uno de todos los esquemas, a los que accederá la aplicación cliente. Al final, cada microservicio puede tener su propio terminal GraphQL, y una puerta de enlace API GraphQL consolidará todos los esquemas en uno global para proporcionarlo a las aplicaciones del cliente.
Introspección GraphQLLa introspección de GraphQL es la capacidad de extraer un esquema GraphQL con la API GraphQL. Dado que el esquema contiene toda la información sobre todos los datos disponibles a través de GraphQL API, se puede utilizar con gran éxito para la generación automática de documentación de API. Sin embargo, el asunto no se limita a documentar la API; La introspección también se puede utilizar para simular un esquema GraphQL en una aplicación cliente (con fines de prueba) o para recuperar esquemas de múltiples microservicios y luego unirlos.
GraphQL fuertemente tipadoGraphQL es un lenguaje de consulta altamente tipado escrito en el lenguaje de definición de esquema expresivo (SDL) para GraphQL. Este lenguaje tiene las mismas ventajas que cualquier lenguaje de programación fuertemente tipado. Es menos propenso a errores, se puede validar en el momento de la compilación y se puede contar con él para la integración con las funciones de IDE / editor admitidas, como el autocompletado y el soporte de entrada.
Versioning GraphQLGraphQL no tiene esas versiones de API a las que estamos acostumbrados en REST. En REST, es normal ofrecer varias versiones de la misma API (por ejemplo, api.domain.com/v1/, api.domain.com/v2/), ya que los recursos o su estructura pueden cambiar con el tiempo. En GraphQL, puede traducir las API en otras no recomendadas a nivel de campo. Por lo tanto, el cliente recibe una advertencia cuando accede a un campo no recomendado. Después de un tiempo, el campo no recomendado se puede excluir del esquema, luego no lo usarán más clientes. Por lo tanto, la API GraphQL se puede desarrollar sin necesidad de versiones.
Creciente ecosistema GraphQLEl ecosistema GraphQL está creciendo. No se trata solo de integraciones con editores e IDEs relacionados con la naturaleza fuertemente tipada de GraphQL; para GraphQL como tal, hay nuevas aplicaciones completas. Por ejemplo, puede recuperar Postman, que se usaba cuando trabajaba con la API REST, y ahora con el mismo propósito, pero con la API GraphQL, GraphiQL o GraphQL Playground. También hay varias bibliotecas para usted, por ejemplo, Gatsby.js, un generador de sitio web estático para React que usa GraphQL. Por ejemplo, Gatsby.js le permite escribir un motor de blog que llena su blog con contenido durante la compilación a través de la API GraphQL. Por lo tanto, también tendrá CMS sin una parte del cliente (por ejemplo, GraphCMS) que proporcione contenido (para un blog) a través de GraphQL. API Sin embargo, no solo se están desarrollando componentes tecnológicos en esta área. A medida que los hongos crecen después de la lluvia, las conferencias, mitaps y comunidades dedicadas a GraphQL también son fáciles de encontrar en sus boletines y podcasts.
Si cambio a GraphQL, ¿voy con todo incluido?Al agregar GraphQL a la pila tecnológica existente, nosotros, por supuesto, no lo hacemos todo. Al migrar de una aplicación de fondo monolítica a una arquitectura de microservicio, lo más importante es sustituir la API GraphQL por nuevos microservicios. De hecho, es precisamente en presencia de muchos microservicios que usted y su equipo pueden implementar de forma segura la puerta de enlace GraphQL, uniendo esquemas y consolidándolos en un esquema global. Pero la puerta de enlace API se puede usar no solo con microservicios, sino también con una aplicación REST monolítica. Así es como puede combinar todas sus API en una puerta de enlace y migrar a GraphQL paso a paso.
Desventajas de GraphQLA continuación, discutimos algunas de las desventajas asociadas con el uso de GraphQL.
GraphQL Query ComplexityA veces GraphQL se usa incorrectamente, trato de reemplazarlo con una base de datos del lado del servidor. No, eso no servirá. GraphQL es solo un lenguaje de consulta. Cuando en el lado del servidor, la solicitud debe resolverse con datos, generalmente hay una implementación independiente de GraphQL que proporciona acceso a la base de datos. GraphQL es indiferente en este caso. Además, GraphQL no elimina los cuellos de botella en el rendimiento cuando necesita abordar muchos campos (autores, artículos, comentarios) en una consulta. Independientemente de la arquitectura en la que se realizó la solicitud: RESTful o GraphQL, aún debe extraer varios campos de la fuente.
Por lo tanto, tendremos un problema si el cliente envía un montón de solicitudes inmediatamente al conjunto de campos anidados. A menudo, los desarrolladores del lado del cliente no saben cuántas consultas de bases de datos diferentes deben procesarse en la aplicación del servidor si comienzan las llamadas de datos masivos. Es para tales casos que se necesita un mecanismo (por ejemplo, profundidad máxima de consulta, ponderar la complejidad de las consultas, evitar la recursividad, consultas constantes) para evitar el flujo de consultas demasiado caras del cliente.
Límite de velocidad en GraphQLOtro problema es la limitación de velocidad. Mientras que en REST es relativamente simple decir "no se permiten más que tantas consultas por día", es difícil formular dicha instrucción para operaciones individuales de GraphQL, ya que no solo hay operaciones "costosas" y "no costosas", sino también muchas gradaciones intermedias. Es para tales casos que las empresas que
proporcionan API públicas de GraphQL ofrecen sus propios cálculos de límite de velocidad , a menudo reducidos a los valores máximos mencionados anteriormente de profundidad de consulta y ponderación de la complejidad de la consulta.
Almacenamiento en caché de GraphQLAl trabajar con GraphQL, implementar una caché simplificada es mucho más complicado que en REST. Cuando trabajamos con REST, accedemos a los recursos por URL y, por lo tanto, podemos organizar el almacenamiento en caché a nivel de recursos, ya que la URL del recurso puede servir como su identificador. En GraphQL, esto es complicado porque todas las consultas pueden ser diferentes, aunque todos operen en el mismo objeto. En una solicitud, puede solicitar el nombre del autor, y en la siguiente, no solo el nombre del autor, sino también su dirección de correo electrónico. Es para tales casos que necesitará una memoria caché más filigrana a nivel de campo, y no es tan simple implementarlo. Sin embargo, la mayoría de las bibliotecas creadas sobre GraphQL ofrecen tales mecanismos de almacenamiento en caché desde el primer momento.
¿Por qué no descansar?GraphQL – REST, . REST – GraphQL, REST?
REST URL , . «», id, , id. GraphQL , . , , , GraphQL , .
, REST. Airbnb. , . REST-, REST- . , , GraphQL API, GraphQL, (, ), (., ).
, GraphQL ; , , , . GraphQL – Facebook , -.
, , REST – . , GraphQL. , GraphQL, - .