Header Ads Widget

Ticker

6/recent/ticker-posts

Arquitectura GraphQL sin servidor con Graphcool

 


Hoy en día, el desarrollo de nuevas aplicaciones se inclina hacia los microservicios y los enfoques sin servidor . Con este cambio de paradigma, las debilidades de los enfoques API RESTful tradicionales comenzaron a mostrarse. GraphQL se desarrolló en respuesta a los problemas de una API REST típica, pero requiere una buena cantidad de configuración para que se ejecute en el servidor. Según Nikolas Burk , desarrollador de pila completa, Graphcool reúne los conceptos de GraphQL y sin servidor, lo que permite la creación simple de backends de aplicaciones.

Este artículo explorará por qué GraphQL es una excelente alternativa a REST, cómo funcionan las funciones sin servidor en la actualidad y cómo se usa Graphcool para el desarrollo de backend. Lea todo el camino hasta el final para ver una demostración práctica y algo de código Graphcool.

Vea la presentación de Nikolas Burk sobre Graphcool ( diapositivas aquí ):

GraphQL: el mejor REST

GraphQL es un estándar de API de código abierto, creado por Facebook y lanzado en 2015. La QL al final del nombre significa "Lenguaje de consulta", pero a pesar de un error común, GraphQL no tiene nada que ver con las bases de datos. Más bien, es un lenguaje de consulta para API . Esencialmente, ofrece a los usuarios un método declarativo para interactuar con los datos, lo que facilita a los clientes obtener los datos que necesitan y que las API evolucionen con el tiempo.

Para obtener una introducción a GraphQL, lea: 5 beneficios potenciales de la integración de GraphQL

La aplicación de blogs

Con REST típico, la adquisición de datos para completar una aplicación simple puede conducir fácilmente a una recuperación excesiva. Reutilizado de la diapositiva de Nikolas Burk .

Para transmitir plenamente los beneficios de GraphQL , Burk utiliza un ejemplo práctico. Presenta una aplicación de blogs de estilo medio, que se centra en la pantalla de perfil de un usuario determinado. En este perfil, se representa parte del contenido estándar: el nombre de usuario, sus 3 últimas publicaciones y sus 3 seguidores más recientes.

La representación de esta pantalla de perfil con una API REST típica requiere una cantidad decente de código. Cada porción de datos requiere una llamada API separada y trae consigo una selección predeterminada de datos. Obtener el nombre de usuario, por ejemplo, podría devolver una carga útil JSON que contiene el nombre de usuario, su nombre completo, su dirección de correo electrónico y su fecha de registro, cuando todo lo que se necesita es el nombre de usuario. Entre las múltiples llamadas a la API y los diversos bits de datos no deseados, las ineficiencias de una API REST tradicional son claras.

GraphQL adopta un enfoque diferente. En lugar de tener varios puntos finales, hay un único punto final que acepta y devuelve una estructura de datos flexible. La consulta especifica exactamente qué datos se necesitan del servidor. GraphQL luego trabaja en el backend para devolver exactamente la información solicitada en la estructura prescrita. Una sola llamada a la API como la que se muestra a continuación devolverá todos los datos necesarios, una bendición para el rendimiento de la aplicación y los planes de datos móviles.

query {
User(id: "er3tg439frjw") {
Name
posts {
 Title
 }
 followers(last:3) {
 Name
 }
}
}

El esquema GraphQL

El esquema es el núcleo de GraphQL. Schema cumple el importante propósito de definir la API. Establece los diferentes tipos de datos y los diversos métodos de interacción con la API para cualquier aplicación CRUD determinada. Como dice Burk, "Schema realmente define la funcionalidad de su API y, por lo tanto, es el contrato para la comunicación cliente-servidor".

En términos prácticos, el esquema está escrito en lenguaje de definición de esquema (SDL). El esquema está organizado por tipos y campos (en lugar de puntos finales como una API REST), lo que permite un acceso flexible a los datos a través de un único punto final. Hay 3 tipos de raíz en SDL que definen el acceso a la API: consulta, mutación y suscripción. La consulta lee datos, mutaciones cambia los datos y la suscripción permite al cliente monitorear los datos en busca de cambios, disparando eventos predeterminados en el cambio.

Sin servidor: monolitos frente a microservicios

La importancia de GraphQL es más clara si se comprende el estilo monolítico de desarrollo de software frente a los microservicios. Los monolitos gozaron de una popularidad histórica, pero los microservicios se adaptan mejor al nuevo estilo de desarrollo de software. Junto con GraphQL, los microservicios ofrecen muchas ventajas a los desarrolladores.

Muy relacionado: ¿Debería comenzar con un monolito o microservicios?

Diseño de software Monolith

Las arquitecturas monolíticas tienen una larga historia en el desarrollo de software y lo llevaron a donde está hoy. Francamente, funcionaron bien durante mucho tiempo. Tienen muchas ventajas, como una estructura de equipo simple, lo que significa menos gastos de comunicación. La seguridad de tipo global también está garantizada cuando todos los componentes de la aplicación se construyen juntos en un sistema, y ​​los datos se comprenden universalmente.

Por otro lado, los monolitos tienen una serie de debilidades exacerbadas por el ritmo del desarrollo de software ágil. Debido a que son tan independientes, las pruebas unitarias son una pesadilla y la escalabilidad es difícil. Los ciclos de implementación tienden a ser largos gracias a todas las interdependencias, lo que hace imposible la integración continua. Esto hace que sea difícil responder a las necesidades del cliente de manera oportuna, lo que resulta en un estancamiento.

Microservicios

Los microservicios surgieron como una solución estructural a los problemas de la arquitectura monolítica y se utilizan ampliamente en la actualidad. Ofrecen muchas ventajas, que abordan directamente las debilidades de los monolitos. Los microservicios son fáciles de probar, porque los ingenieros solo necesitan escribir pruebas unitarias para componentes pequeños e independientes. La integración y la implementación continuas son muy sencillas, gracias a la capacidad de implementar solo un microservicio a la vez.

Si bien los microservicios lograron resolver muchos problemas existentes, trajeron consigo nuevos desafíos propios. La comunicación y la organización son exponencialmente más difíciles con diferentes equipos que manejan cada microservicio. Orquestar la interacción de los servicios es otro desafío que señala Burk. Si bien existen marcos para ayudar, es algo con lo que los equipos deben lidiar con regularidad. También hay que considerar los datos y el estado de varios componentes. Preguntas como dónde está la base de datos, quién puede acceder a ella y cómo se mantienen los datos sincronizados desafían regularmente a los equipos de ingeniería.

Arquitectura impulsada por eventos

Uno de los principales desafíos en el diseño de microservicios es cómo se comunican los diferentes microservicios. Este desafío es lo que generó la arquitectura impulsada por eventos, que "realmente es una muy buena idea y una idea ampliamente aceptada de cómo debería hacerlo", según Burk.

La arquitectura impulsada por eventos especifica lo que sucede cuando dos microservicios necesitan comunicarse. Esta comunicación se realiza a través de un sistema PubSub . Un microservicio se suscribe a otro microservicio, escuchando la ocurrencia de un evento en particular. Cuando ocurre cualquier evento, se notifica al microservicio suscriptor y puede ejecutar cualquier funcionalidad deseada.

Consulte también: 5 protocolos para arquitecturas de API basadas en eventos

Funciones sin servidor: el futuro de la tecnología sin servidor

Burk señala que las funciones como servicio (FaaS) son el siguiente paso natural en la evolución de las aplicaciones sin servidor. En lugar de continuar implementando servicios como servidores web completos, los ingenieros están comenzando a implementar funciones individuales. Estas funciones manejan una pequeña parte de la funcionalidad y son completamente autónomas.

Producir estos FaaS es sencillo. Se crea un archivo fuente que contiene solo una función. Luego, esta función se implementa e integra en el sistema. Cuando es necesario, la función se invoca a través de un webhook HTTP, al igual que un servidor tradicional, pero no se requiere configuración de servidor. Hay muchos servicios disponibles para ayudar en la implementación de FaaS, incluidos AWS Lambda, Microsoft Azure y Google Cloud Functions. Estos servicios hacen un montón de trabajo pesado, cosas como resistencia y escalabilidad, lo que deja tiempo para centrarse en la creación de funciones reales.

Presentación del marco Graphcool

Graphcool es un marco relativamente nuevo que proporciona un backend GraphQL sin servidor. "Está abstrayendo efectivamente su base de datos y generando automáticamente una API CRUD para usted", dice Burk. Esto significa que ya no hay que lidiar con SQL, consultas de bases de datos o esquemas de bases de datos. El modelo de datos se define con SDL y todo está automatizado desde allí. En pocas palabras, podría ser más fácil comenzar a usar GraphQL cuando tiene Graphcool para manejar el backend.

Otra ventaja de utilizar Graphcool es el núcleo impulsado por eventos, que se utiliza para implementar la lógica empresarial. Esta arquitectura de eventos utiliza un patrón de resolución, por lo que es ideal para el software moderno sin servidor. Graphcool también proporciona un sistema de tipos global que se determina automáticamente mediante el esquema GraphQL. Con este sistema, la comunicación entre componentes es más segura y sencilla, lo que aporta una ventaja de la arquitectura monolítica.

Uso de Graphcool para crear backends de GraphQL sin servidor

Graphcool facilita el uso de funciones sin servidor. Estas funciones sin servidor se aprovechan a través de tres tipos de funciones:

  • Los enganches permiten al cliente realizar una validación y transformación de datos sincrónicos. Los ganchos son como consultas y mutaciones GraphQL generadas automáticamente.
  • Las suscripciones brindan la capacidad de activar eventos asincrónicos.
  • Los resolutores son métodos que amplían el marco Graphcool con consultas y mutaciones GraphQL personalizadas.

Con estos tipos de funciones, el backend de Graphcool puede manejar muchas cosas. El equipo de Graphcool ha producido bloques de construcción para una gran cantidad de funciones de backend estándar, como crear usuarios, suscripciones y establecer permisos. Estos se pueden copiar en una configuración de Graphcool existente, ajustar para la aplicación y ponerlos a trabajar. Para comprender completamente cómo Graphcool podría funcionar con diferentes sistemas, Burk explora algunos ejemplos prácticos.

Evento de suscripción - La teoría

Tome un sistema que necesita enviar un correo electrónico de bienvenida a los nuevos usuarios. El primer paso es enviar una consulta de suscripción al sistema de eventos. Esta consulta permite al sistema monitorear constantemente y esperar cualquier evento relacionado con el tipo de Persona. La consulta puede tomar una forma similar a esta, especificando el tipo de consulta (suscripción) y el tipo a monitorear (Persona):

subscription {
    Person {
   	 node {
   		 name
   		 email
   	 }
    }
}

En este punto, el sistema está monitoreando activamente cualquier evento de persona. En algún momento, la aplicación cliente creará una nueva persona usando algún código GraphQL para declarar el tipo de consulta (mutación), el nombre de la mutación (createPerson), los datos proporcionados por el usuario (nombre y correo electrónico) y los datos a retorno (id).

mutation {
createPerson( name: "Nikolas" email: "nikolas@graph.cool" ){ id } }

Cuando el servidor recibe esta mutación, esto hace que el sistema de eventos se active en esa consulta de suscripción. Una carga útil que contiene los datos solicitados se envía de vuelta al servidor.

"data": {
"Message": { "node": { "name": "Nikolas", "email": "nikolas@graph.cool" } } }

Esta carga útil activa la función especificada en la consulta de suscripción original. La función luego ejecuta el código requerido para realizar el envío real del correo electrónico, en el idioma preferido del desarrollador de la API.

Evento de suscripción: implementación en Graphcool

Ese es el evento de suscripción en teoría, pero ¿cómo se construye realmente con Graphcool? Para empezar, requiere una estructura de archivos similar a esta:

├── graphcool.yml
├── types.graphql ├── src │ ├── welcomeEmail.graphql │ ├── welcomeEmail.js

El types.graphqlarchivo se usa exactamente para lo que su nombre implica: declarar los diferentes tipos de datos dentro del esquema de la aplicación. En este ejemplo, solo se necesita un tipo, el tipo Persona. Como nota, el! Indica que se requiere un campo. El campo de correo electrónico no es obligatorio para crear una nueva persona.

type Person {
id: ID! @isUnique createdAt: DateTime! updatedAt: DateTime! name: String! email: String }

Además del archivo de tipos, el único otro archivo requerido es graphcool.yml . Este archivo YAML es el archivo de configuración Graphcool. Importa el archivo de tipos, configura varias funciones, maneja los permisos de la aplicación y más. Un archivo muy básico será suficiente para poner en marcha la demostración:

# Type Definitions
types: ./types.graphql '' # Permission Rules permissions: # for simplicity, open access - operation: "*" '' # TODO: Function Definitions # functions:

En este punto, se puede utilizar el backend de Graphcool. Para implementar y generar una API CRUD automatizada, se necesita Graphcool CLI . Primero, instale las herramientas a través de NPM :

npm install -g graphcool

Luego, simplemente navegue hasta el directorio de la aplicación en la terminal e implemente el proyecto:

graphcool deploy

Este comando hace un par de cosas. Genera la API CRUD para esta aplicación. Luego, implementa el servicio en un clúster de Docker local, con el tipo de Persona accesible a través de API. Para experimentar con la API tal como existe actualmente, el patio de recreo Graphcool está disponible. Es una caja de arena, similar a herramientas como Postman, donde la API se puede utilizar para consultar y mutar datos de aplicaciones en un formato interactivo. Para obtener la URL del perfil de la aplicación, use el comando:

graphcool info

Tome la URL de Simple API Endpoint y ábrala en un navegador. Esto abre el campo de juego interactivo, donde se puede explorar la API. Por ejemplo, para ver todas las personas en la base de datos de la aplicación, use una consulta como esta y presione el botón de reproducción.

{
allPersons { id name } }

Esta consulta devolvería una carga útil de datos que contienen el ID de usuario y el nombre de todas las Personas creadas en esta aplicación. Por supuesto, todavía no se crean usuarios, lo que se indica mediante la matriz vacía que devuelve actualmente. Para agregar una persona, abra una nueva pestaña en el patio de juegos para redactar una consulta de mutación. Al ejecutar esta consulta, se agregará una nueva persona a la aplicación con el nombre especificado:

mutation {
createPerson(name: "Sarah") { id } }

Después de ejecutar esta consulta, ejecutar la consulta allPersons nuevamente devolverá una matriz que contiene la Persona con el nombre Sarah. La gran parte de Graphcool es que toda esta funcionalidad se crea automáticamente al implementar la configuración básica y el archivo de tipos.

En la API Graphcool, se sigue una convención de nomenclatura estándar. Cada tipo creado tiene puntos finales CRUD generados automáticamente. El tipo Person, por ejemplo, tiene los siguientes puntos finales de API: crear (createPerson), leer (allPersons), actualizar (updatePerson) y eliminar (deletePerson).

En este punto, es necesario configurar la funcionalidad de la aplicación deseada para enviar un correo electrónico a todas las personas nuevas cuando se crea su cuenta.

El código para enviar realmente el correo electrónico está compuesto en welcomeEmail.js, que exporta una única función. Esta función acepta un argumento, que contiene los datos del evento de Graphcool. Dentro de la función, se puede acceder a los datos enviados (por ejemplo, el nombre de usuario y la dirección de correo electrónico) a través de event.data.Person.node.fieldNameEn realidad, el envío del correo electrónico se puede realizar a través de cualquier método preferido, como un servicio de correo electrónico transaccional como Mailgun .

module.exports = event => {
    // access the user information
    const name = event.data.Person.node.name;
    const email = event.data.Person.node.email;
''
    // place code here to send the email via the preferred method
}

A continuación, se debe declarar el esquema de suscripción. Esto se hace en el welcomeEmail.graphqlarchivo. Esta declaración es bastante sencilla, declara el tipo de consulta (suscripción) y especifica el tipo de esquema a monitorear (Persona). El objeto de nodo contiene los campos que deben pasarse a través de los datos del evento.

subscription {
Person(filter: { mutation_in: [CREATED] }) { node { name email } } }

Un elemento a destacar es el atributo de filtro en la declaración de tipo de persona. Este filtro especifica que la suscripción solo debe activarse cuando se crea una nueva persona. De forma predeterminada, una suscripción supervisará las modificaciones de cualquier Persona, ya sea que se esté creando, actualizando o eliminando.

El paso final es declarar la función en el archivo de configuración Graphcool, graphcool.ymlLas funciones obtienen su propia sección del archivo de configuración y, dentro de la declaración, se especifican el código del controlador, el esquema de consulta y el tipo de función.

functions:
    welcomeEmail:
   	 handler:
   		 code:
   			 src: ./src/welcomeEmail.js
   	 type: subscription
   	 query: ./src/welcomeEmail.graphql

Una vez que esto está configurado, el proceso es como antes. El código se compila y la API se genera ejecutando el graphcool deploycomando. Desde allí, navega hacia el patio de recreo nuevamente. La ejecución de la consulta createPerson, especificando el nombre Y la dirección de correo electrónico, activará esta función de suscripción y enviará el correo electrónico.

mutation {
createPerson(name: "Sarah", email: "sarah@gmail.com") { id } }

Graphcool tiene usos mucho más allá del alcance de esta demostración. Puede envolver las API REST existentes para crear un único punto de entrada para todos los servicios del cliente, incluso si no es posible el acceso directo a la base de datos. La funcionalidad prefabricada está disponible para ayudar con la creación de usuarios, flujos de inicio de sesión y validación de datos. Estas son solo algunas de las cosas posibles con Graphcool. Para configurar un backend GraphQL rápido, fácil y sin servidor, Graphcool es un marco que vale la pena considerar.

Diapositivas

Creación de backends de GraphQL sin servidor desde Nikolas Burk

Publicar un comentario

0 Comentarios