8
API Gateway
Ciclo 4a:
Desarrollo de aplicaciones web
Objetivo de Aprendizaje
Identificar las principales características de un API Gateway, dentro de
una arquitectura de Microservicios.
API Gateway
Componente Web
El API Gateway es el componente encargado de recibir y
responder las solicitudes del Componente Web. Por esta GraphQL
razón, es necesario que el API Gateway se comunique con API Gateway
el Componente Web y con los microservicios que le
REST
proveen las funcionalidades de la aplicación. Para realizar
MsAutenticación MsCuentas
la conexión con los microservicios se utilizarán los
conectores de tipo REST, y para la conexión con el
componente web se utilizará un conector de tipo GraphQL, UsuariosDB CuentasDB
el cual se introducirá posteriormente.
GraphQL: Definición
GraphQL es un entorno de ejecución para la consulta y
Cliente GraphQL
manipulación de datos para APIs, que cuenta con su propio
lenguaje de consulta. GraphQL es una alternativa a la
exposición de datos por medio de REST, que ofrece algunas
Servidor GraphQL ventajas como, la consulta únicamente de los datos que el
cliente requiere, la descripción completa de los datos de la
API, y la fácil evolución de las APIs sobre el tiempo.
API REST API REST API REST
GraphQL: Apollo Server
Para la implementación en una API de tipo GraphQL, se
debe utilizar un servidor que haga uso del entorno de
ejecución de GraphQL, con el fin de recibir y responder
peticiones. Existen múltiples servidores para cada lenguaje
de programación. Por ejemplo, para JavaScript existen:
Apollo Server, [Link], Express GraphQL, entre otros. En
el caso de estudio, el API Gateway se desarrollará en
JavaScript, y se hará uso de Apollo Server, dada su
versatilidad.
[Imagen] GraphQL & Apollo. (s. f.). [PNG]. Medium. [Link]
GraphQL: Peticiones
Para realizar consultas y modificaciones sobre los datos del API Gateway, existen 2 tipos de peticiones:
Queries y Mutations. Las Queries sirven para solicitar información, como una operación GET en REST,
mientras que las Mutations sirven para cambiar los datos, como las operaciones POST, PUT y DELETE en
REST.
[Imagen] Queries. (s. f.). [PNG]. ApolloGraphQL. [Link]
Apollo Server: Estructura
Para lograr que un API Gateway pueda llevar a cabo la
orquestación de funcionalidades entre microservicios,
Apollo Server plantea una estructura compuesta por 3
pilares principales:
• DataSources: encargados de establecer la comu-
nicación con los microservicios.
• TypeDefs: encargados definir las operaciones y los
datos que se manejarán. DataSources Resolvers TypeDefs
• Resolvers: encargados de procesar las operaciones.
Apollo Server: DataSource
Una de la principales tareas de un API Gateway es realizar
peticiones a distintos microservicios con el fin de consumir
sus servicios, dado que estos poseen una API REST la
comunicación se realizará a través de peticiones HTTP.
Apollo Server plantea el concepto de DataSource, el cual es
una abstracción de una fuente de datos y servicios (como
un microservicio). Para comunicarse con los Data Source Microservicio
microservicios, solamente se deberán definir algunos
elementos y Apollo Server se encargará del proceso.
Apollo Server: TypeDefs
Una de las ventajas de la interfaz de GraphQL, es la
robustez de su esquema de datos y peticiones, GraphQL
define de manera clara y concisa las peticiones (Queries y
Mutations) que se pueden realizar al API Gateway, así
como los datos de entrada yde salida de estas.
El proceso de definición de las peticiones y los datos se
realiza en los TypeDefs. Un TypeDef es un objeto
compuestos por los encabezados de las Queries y
Mutations , y los datos usados en las peticiones.
[imagen] Schema Apollo Server. (s. f.). [Ilustración]. [Link]
Apollo Server: TypeDefs
Los tipos de datos aceptados como entradas y salidas de las
operaciones pueden ser escalares como Int, Float, String o Boolean.
Sin embargo, también se aceptan objetos construidos a partir de
escalares u otros objetos. TypeDef también soporta el concepto de
arreglos, para esto usa los corchetes cuadrados, el tipo [objetoA]
representa un arreglo de objetoA.
Para indicar si un dato u objeto es obligatorio u opcional, se usa el
indicador !, este representa obligatoriedad.
Apollo Server: Resolvers
Cada una de las peticiones que llegan al API Gateway
contienen una operación, ya sea una Query o una
Mutation, cada una de estas operaciones debe tener
un mecanismo que permite procesarla. A este
mecanismo, Apollo Server lo llama Resolver. En la
práctica, un resolver es una función que procesa una
operación.
Schema Apollo Server. (s. f.). [Ilustración]. [Link]
Apollo Server: Context
Una herramienta que no forma parte de los pilares de
Apollo Server, pero que resulta útil en muchos escenarios,
son los Context. Context
Un context es un preprocesamiento realizado sobre una
petición, es decir dota a la petición de un contexto
adicional. En la práctica, un context es una función que Petición Resolver
recibe como parámetro una petición y realiza operaciones
sobre esta, la función es ejecutada justo al momento que la
petición llega al API Gateway.
[imagen] Service. (s. f.). [Icon]. [Link]
Apollo Server: Context
Los context son útiles cuando se quiere expandir o revisar
la información que contiene una petición. Algunos usos
comunes son la autenticación, donde un context revisa si
una petición esta autorizada para ejecutarse o no.
Otro caso de uso es cuando la petición contiene un
identificador y el API Gateway requiere información
adicional de ese identificador, proveniente de recursos
externos.
[imagen] Autenticación. (s. f.). [Icon]. [Link]
![Apollo Server: TypeDefs
[imagen] Schema Apollo Server. (s. f.). [Ilustración]. https://miro.medium.com/max/1400/1*O8mWd4Hq4_3](/p?url=https%3A%2F%2Fscreenshots.scribd.com%2FScribd%2F252_100_85%2F141%2F621452649%2F9.jpeg&__src=https%3A%2F%2Fes.scribd.com%2Fdocument%2F621452649%2F06-Graphql-API-Gateway&__type=image)
