Post Top Ad

Your Ad Spot

domingo, 26 de enero de 2020

Creación de FullStack, API GraphQL sin servidor en la nube

GraphQL , un poderoso lenguaje de consulta para API, ha sido apreciado por sus capacidades de integración de datos. GraphQL permite a los desarrolladores extraer datos pertinentes de sus API sin agregar pelusa. A su vez, las aplicaciones pueden controlar con precisión qué datos obtienen. Mientras que las configuraciones RESTful tradicionales dependen de las solicitudes del servidor, GraphQL asume el control de la recuperación de datos. Ese control granular es sumamente beneficioso tanto para los desarrolladores como para los usuarios finales. Esto mantiene las aplicaciones con rendimiento, estables y escalables a medida que crecen las bases de datos.
William Lyon , un desarrollador de software en Neo4j , regularmente ayuda a los desarrolladores a construir aplicaciones GraphQL fullstack. Con el uso adecuado de herramientas y visualización de datos, esta vía de desarrollo es muy prometedora para aplicaciones exigentes. Empresas como Facebook, GitHub, Pinterest e Intuit incorporan GraphQL en toda la plataforma. Por el contrario, incluso los equipos pequeños pueden aprovechar el lenguaje para crear API capaces. Durante su presentación en nuestra Cumbre API de Austin de 2019 , William describió cómo los desarrolladores pueden hacer exactamente eso.
Vea a William Lyon de Neo4j presente en la Cumbre API de Austin de 2019:

Descripción general de GraphQL y herramientas de desarrollo

Lyon comienza con un breve resumen de herramientas de desarrollo útiles para la implementación de GraphQL API. Estos servicios incluyen GraphQL , React , Apollo y Neo4j Database . Cada uno juega un papel clave en el proceso de construcción. Juntos, forman un solo marco GraphQL llamado GRANDstack . Para comenzar, proporcionemos una descripción general de Neo4j : la capa de datos para este proyecto:
Neo4j utiliza gráficos para modelos de datos, en lugar de tablas o documentos. La plataforma también utiliza Cypher , que Lyon compara con SQL especializado para GraphQL. Como se muestra arriba, Cypher se basa en gran medida en la coincidencia de patrones dentro de su lógica. Las bases de datos de gráficos junto con Neo4j son útiles para las siguientes aplicaciones:
  • Gráficos de conocimiento
  • Recomendaciones personalizadas
  • Gestión de datos maestros
  • Gestión de redes y TI.
  • Detección de fraude
  • Analítica
  • Gestión de identidad y acceso.
  • Privacidad y cumplimiento
  • Logística y enrutamiento
  • Búsqueda basada en gráficos
Ya podemos observar cierta superposición con los casos de uso de REST, aunque GraphQL se acerca a estos fines utilizando diferentes medios. La gestión de redes y TI tiene su lugar dentro de ambas metodologías. Un paralelo interesante radica en la identidad y el control de acceso. A menudo pensamos en cosas como el Control de acceso basado en roles (RBAC) , que hemos mencionado en un artículo sobre las mejores prácticas de REST API. Estos servicios son ubicuos independientemente del enfoque de creación de API, lo que otorga a GraphQL un inmenso potencial empresarial.

Los fundamentos de GraphQL

Pero, ¿cómo se comprende el idioma? GraphQL utiliza definiciones de tipo que definen colecciones de estructuras de datos. Estas agrupaciones se denominan esquemas. Aquellos con experiencia en SQL deberían encontrarlos familiares. Para los fines de nuestra API GraphQL, estos comprenden el lenguaje de definición de esquema (SDL) . Desde aquí, evaluamos los diversos datos y campos disponibles. Estos formarán las especificaciones para nuestra API GraphQL. El cliente puede usar esos esquemas para construir consultas, los bloques de construcción de GraphQL, que forman sus llamadas API. Los resultados de esas consultas coincidirán con los campos que solicite el cliente.
GraphQL es único porque interpreta los datos de su aplicación como un gráfico, como sugiere su homónimo. Los consumidores y los clientes deben interpretar los datos de esta manera fundamental. Cada nodo de datos está interconectado de alguna manera. Esas relaciones hacen posible un proceso llamado introspección . Esto permite a los desarrolladores consultar esquemas y ver cómo están conectados los tipos y campos. La información de esas consultas ayuda a formar la documentación de nuestras API. Herramientas como GraphiQL y GraphQL Playground nos permiten visualizar estas estructuras tipográficas , dando mayor claridad a la documentación.
¿Cuáles son los componentes individuales de una consulta GraphQL? La API tiene puntos de entrada, que comienzan con un nombre de operación y argumentos asociados. Estos argumentos forman instrucciones para la API, que especifican la parte de la base de datos a la que queremos acceder. Digamos que queremos recuperar datos de una película específica, de una base de datos de diferentes películas. Para nuestro argumento, especificaríamos el título de esta película. Una vez que hemos determinado e ingresado eso, agregamos tipos para nuestra consulta. Esos tipos de datos colectivos forman el conjunto de selección.
Los tipos en este conjunto de selección determinan los puntos de datos específicos que devolverá nuestra API. Como se ve en la figura anterior, al consultar en la base de datos “River Runs Through It, A” se devolverá el título, los dos primeros actores enumerados y sus nombres. También podemos agregar parámetros para géneros, directores o cualquier otro tipo de datos relacionados con la película. Convenientemente, nuestra API no recuperará ninguna información que no solicitemos explícitamente. Esta es la belleza de GraphQL. Podemos mantener nuestras consultas eficientes y limpias, sin acumular llamadas API extrañas. También alivia la necesidad de construir numerosas estructuras elaboradas como lo haríamos en REST.
Los datos se devuelven en formato JSON , utilizando solo los campos que solicitamos. Dicho esto, Lyon enfatiza que GraphQL es un lenguaje de consulta API en lugar de un lenguaje de consulta de base de datos. En consecuencia, tenemos relativamente poca expresividad dentro de GraphQL. Por ejemplo, las proyecciones, las agregaciones y las consultas de longitud variable son limitadas.
GraphQL también es independiente de la capa de datos . Podemos usar una API GraphQL para acceder a los datos independientemente de cómo los almacenemos, lo que hace que el lenguaje sea flexible. Una base de datos gráfica no es necesaria. En consecuencia, GraphQL a menudo se basa en datos de múltiples fuentes y los agrupa bajo una sola API.

Ventajas y desventajas de GraphQL

Sabemos que GraphQL es increíble para devolver solo los datos específicos que solicitamos. Mientras que otros tipos de API pueden encontrar problemas con la sobrecarga, una API GraphQL no sufre este mismo destino. Esto mantiene la transmisión de datos al mínimo, preservando el ancho de banda y los recursos. En ese mismo sentido, el control granular nos permite evitar la captación insuficiente. Si escribimos una consulta correctamente, podemos depositar en campos específicos que regresan sin problemas. Podemos representar vistas de aplicaciones y completar solicitudes de datos con un viaje de ida y vuelta a la API, sin obstruir las cosas.
GraphQL también se basa en conjuntos de especificaciones predefinidas. Las API REST son más abiertas en este sentido, introduciendo variación y, a menudo, incertidumbre en el proceso de construcción. Estas ambigüedades pueden generar errores o confusión, especialmente para los desarrolladores más nuevos. Como resultado, GraphQL es más usuario dado su enfoque estructurado para la construcción de API.
Las relaciones de datos se basan en la importancia contextual, según cómo se relacionan los tipos y los campos. Por ejemplo, es fácil mirar una publicación de blog y conectarla a un autor determinado. Abordamos todas las consultas de la misma manera. En REST, vemos los puntos de datos como recursos, que son algo menos cortados y secos. GraphQL se basa en las asociaciones heurísticas y lógicas que ya dibujamos entre los elementos. También podemos construir nuestras consultas en torno a componentes individuales en nuestras aplicaciones.

Desventajas

Sin embargo, ningún sistema es perfecto y tenemos que aclarar algunas de las deficiencias de GraphQL. No es necesario aplicar muchas de las mejores prácticas de REST, separando los dos enfoques. Saltar entre REST y GraphQL puede ser un desafío. Faltan códigos de estado HTTP y, en consecuencia, los códigos de error dan poco contexto. Mientras que los desarrolladores REST pueden proporcionar mensajes de error personalizados para los clientes, las API GraphQL proporcionan una respuesta 200 universal El almacenamiento en caché web no es tan efectivo. Sin embargo, si estamos tratando con una API autenticada, el almacenamiento en caché puede no ser una gran preocupación.
Lyon también aborda preguntas asociadas con la complejidad arbitraria y cómo manejamos esas repercusiones con el cliente. Si el cliente puede producir una consulta que es innecesariamente compleja, ¿cómo podemos mitigar esto? Además, ¿qué implicaciones de rendimiento podría presentar esto?
También hay un n+1problema para las consultas, relacionadas con la búsqueda de listas y la coincidencia de datos. Supongamos que recuperamos varias publicaciones de blog o un grupo de películas. ¿Tendremos que solicitar autores o directores para cada uno de nuestra base de datos? Estos problemas se pueden eludir, aunque lleva un poco de trabajo hacerlo.
Finalmente, la limitación de la tasa y la complejidad aumentan las incertidumbres. Existen soluciones y mejores prácticas que abordan estos problemas, como la limitación de consultas. En estos casos, los clientes solo pueden crear consultas a partir de una lista predeterminada, bloqueando las solicitudes y mitigando los problemas de rendimiento.

API GraphQL: ejemplo y proceso de compilación

Al construir su API por primera vez, usar GraphQL Playground como espacio de trabajo puede ser extremadamente útil. Esto permite realizar pruebas y modificaciones en tiempo real sin generar cambios en su aplicación en vivo. También le permite desarrollar consultas, tipos, campos y contenido estructurado sin riesgo. Para este ejemplo, estamos analizando el propio proyecto de William, un foro de discurso basado en blogs categorizados y publicaciones de usuarios.
Cada consulta está conectada a diferentes tipos y campos relevantes para el foro, como autor, nombre de usuario, nombre de usuario y avatar. Si enviamos una consulta en Playgrounds, podemos ver los resultados de nuestra llamada a la API en el panel de la derecha. Estos retornos se basan en los parámetros que establecemos. En el caso de William, quería recuperar los primeros 10 proyectos de código abierto de la comunidad. Esta consulta también recupera el título, la URL, el nombre del autor y las credenciales de discurso asociadas para ese autor:
Esta información ayuda a representar a los visitantes del foro, representada como información en una página web o aplicación asociada. A medida que la información en la base de datos cambia según corresponda a una consulta determinada, estos renders cambiarán en consecuencia. Esto significa que una simple actualización de la base de datos enviará nuevos datos al usuario, en caso de que esa consulta permanezca activa dentro de la aplicación. Por esta razón, las API GraphQL son buenas para generar contenido dependiente de una base de datos. Esto es cierto tanto para contenido estático como dinámico.

Cómo construir un servicio GraphQL

Podemos construir instancias para recopilar datos de la comunidad, esta vez desde Neo4j. Cuando un miembro de la comunidad publica contenido nuevo basado en Neo4j, esta información se puede analizar y agregar automáticamente a una base de datos. Desde aquí, las consultas pueden acceder a esquemas dentro de la base de datos a través de nuestra API GraphQL. Los tipos de consulta y mutación ayudan a definir estos puntos de entrada de API.
Después de definir estas definiciones de tipo, pasamos a construir resolvers GraphQL. Contienen lógica de búsqueda para nuestras solicitudes GraphQL, que le indican a la API cómo funcionar correctamente:
Estos son importantes para la autenticación, validación o cualquier otro proceso que garantice la recuperación adecuada de datos. También permiten utilizar ORM para una fácil manipulación de objetos. Una vez que solidificamos la funcionalidad de recuperación, podemos dictar cómo se formatean estos datos a su regreso. Las consultas se pueden hacer en formato Cypher. Esto también nos permite manejar devoluciones de errores en caso de que ocurran.
Usando Node.js como red troncal, el servidor Apollo nos permite servir esquemas (definiciones de tipos y resolvers) creando una conexión de base de datos. Las definiciones de tipo y los resolvers se combinan en un formato ejecutable bajo varios esquemas. Una vez que Apollo está activo, podemos comenzar a ejecutar consultas sobre nuestra capa de datos. Así es como hacemos una API GraphQL de manera estándar. Sin embargo, esté atento a la duplicación de esquemas, el mapeo innecesario, el exceso de código repetitivo y los n+1problemas.

Motores GraphQL y GRANDstack Starter

Los motores GraphQL son esencialmente integraciones de bases de datos que simplifican la forma en que trabajamos con GraphQL. Estos son beneficiosos para reducir el tiempo de desarrollo y reducir la curva de aprendizaje asociada con la implementación de API.
Algunos de estos complementos, como PostGraphile y Hasura , nos permiten trabajar con Postgres más fácilmente. AWS AppSync otorga acceso a los recursos de Amazon Web Services . Prisma es una herramienta útil para trabajar con múltiples bases de datos simultáneamente.
Lyons aboga por el motor Neo4j-GraphQL . Su integración viene con algunos objetivos y advertencias, que describiremos aquí:
  • Habilite el primer desarrollo de GraphQL, incluidas las definiciones de tipo y los esquemas
  • Genere Cypher desde GraphQL, al tiempo que garantiza que una consulta represente un solo viaje de ida y vuelta con nuestra API
  • Generar API CRUD basadas en GraphQL
  • Promueva una directiva de esquema Cypher extendiendo la funcionalidad de GraphQL
Estas directivas de esquema de Cypher permiten una lógica personalizada y anotaciones de campo, que se asignan a una consulta de Cypher. El motor viene en versiones de JavaScript y Java, incluido un complemento de base de datos. Las solicitudes son generadas por el cliente, procesadas por el servidor Apollo y luego enviadas a la base de datos Neo4j. Los datos se obtienen y se devuelven al cliente.
GRANDstack Starter hace que estas implementaciones de código sean aún más fáciles para los desarrolladores. Comenzamos con un esquema y definiciones de tipo. Importamos las bibliotecas necesarias e iniciamos una aplicación express, después de lo cual pasamos definiciones de tipo a una makeAugmentedSchemafunción. Esta función proporciona una API CRUD GraphQL mientras agrega filtros y paginación.
A partir de aquí, creamos una conexión con la base de datos. Esto está conectado al servidor Apollo, desde el cual podemos definir varios puntos finales GraphQL. Podemos ejecutar esto y revisar nuestros esquemas, incluidas las mutaciones que puedan estar presentes. Estas mutaciones representan cualquier cambio realizado en la información presente en una base de datos dada.
Si diseñamos nuestros puntos de entrada correctamente, nos permitirá ejecutar cualquier operación CRUD necesaria con relativa facilidad.
Una vez que tengamos todo en funcionamiento, es posible procesar consultas complejas. Podemos escribir en una gran cantidad de tipos y hacer que nuestra API GraphQL busque los datos relevantes. Esto puede incluir información numérica, texto y más. Volver a nuestro código permite hacer coincidir diferentes parámetros, como los usuarios y varias empresas para las que escriben reseñas (por nombrar un ejemplo). Este filtrado nos permite devolver información más relevante para el cliente.

Los beneficios de los motores

Los motores GraphQL son útiles porque nos permiten construir una mayor funcionalidad en nuestras API. Por un lado, podemos lograr esto a través de integraciones declarativas. Esto nos permite definir claramente los procedimientos de obtención de datos al incorporar middleware. Las definiciones de tipo nos permiten definir modelos de bases de datos. Las API GraphQL generadas automáticamente surgen de nuestras definiciones de tipo, que podemos aprovisionar para la recuperación de datos. Como parte de eso, también podemos enriquecer nuestros esquemas para presentar información más detallada a nuestros clientes; estos datos a menudo también tienen más importancia contextual.
También podemos crear resolvers automáticamente mientras reducimos la cantidad de código repetitivo necesario para poner en marcha proyectos. Esto ahorra tiempo y reduce las cosas, dos características de la metodología GraphQL.
Entonces, ¿cómo ayudan estos motores a generar consultas en la base de datos? El resolveInfoargumento de resolución contiene información para el árbol de sintaxis abstracta de consulta GraphQL (AST), los objetos de esquema y los conjuntos de selección, variables y más para crear consultas de bases de datos.

Yendo por la ruta sin servidor

Si buscamos adoptar un enfoque de implementación sin servidor, nos llevan a muchos servicios que brindan una funcionalidad clave. Éstos incluyen:
  • AWS Lambda
  • Funciones de Google Cloud
  • Marco sin servidor
  • Zeit Now
  • Funciones de Netlify
Las herramientas creadas sobre estas funciones proporcionan una experiencia de desarrollador única. Podemos combinar la implementación del código de cliente estático con nuestra API sin servidor utilizando estas opciones, lo que facilita el desarrollo. Hay muchos recursos que describen cómo podemos usar estos servicios.

Consultar GraphQL para el cliente

GRANDstack usa React para lograr esto. Apollo proporciona integraciones de marco front-end, agilizando este proceso. También podemos usar Relay y urql . Los clientes GraphiQL , Playground, fetch y HTTP también están disponibles como alternativas a Apollo. Nuestra elección del cliente HTTP, en caso de que tomemos esa ruta, depende de las características únicas proporcionadas y de cómo se comparan con los objetivos de nuestro proyecto. El almacenamiento en caché y las integraciones son consideraciones cruciales con estas opciones. En el foro de la comunidad Neo4j, utilizan fetchsolicitudes junto con JavaScript para servir contenido y devolver datos al cliente.
La integración de React para Apollo es bastante sencilla. Creamos una nueva instancia y la dirigimos a varios puntos finales GraphQL. Las necesidades de autenticación determinarán los requisitos del encabezado. Esta instancia de Apollo se inyecta en el componente Reaccionar. Esto es similar a la integración de Redux.
Configuración de Apollo Server para integrarse perfectamente con React.
Nuestro <Query>componente puede tomar una consulta GraphQL, o podemos definir nuestros propios fragmentos (conjuntos de selección únicos para nuestras consultas) y combinarlos para reaccionar componentes. Esto promueve la compartimentación del código y facilita la administración a largo plazo. Los hijos de eso definen una respuesta y representan tablas, delineando cómo presentamos los datos devueltos.

Autorización en GraphQL

Afortunadamente, GraphQL ofrece una buena cantidad de opciones. Podemos usar nuestros resolvers para lograr estas tareas, o crear lógica de negocios alrededor de una capa de acceso a datos. Esto permite un control granular sobre qué clientes pueden recuperar qué datos de nuestras bases de datos. El middleware puede proporcionar una capa adicional de seguridad alrededor de nuestros solucionadores. Las directivas de esquema también son útiles. Tome Cypher, por ejemplo. Anotar nuestras definiciones de tipo y crear reglas proporciona protocolos de autorización rápidos.
Las autorizaciones de resolución son fáciles de implementar y rápidas para crear prototipos. Sin embargo, podemos duplicar nuestra lógica si no tenemos cuidado. Las capas de acceso a datos brindan una gran flexibilidad al procesar solicitudes y permiten una única implementación. Sin embargo, surgen preguntas cuando se trata de resolvers generados, especialmente en relación con las herramientas del motor GraphQL. La resolución de envolturas nos permite definir permisos juntos y unificar las reglas de autenticación. Estos permisos deben coincidir con los resolvers, y los resolvers generados pueden hacer que la coincidencia sea más complicada. Las directivas de esquema son declarativas mediante anotaciones y se combinan armoniosamente con los resolvers generados. Esto juega bien con los motores GraphQL. Sin embargo, las reglas de autorización se extienden por todo el esquema GraphQL.

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas