¿Qué es un api gateway?

¿Qué es un api gateway? Es un punto de entrada para gente, tráfico, solicitudes. Si alguna vez han experimentado con microservicios, es posible que haya encontrado el término “API Gateway“.

Si bien no es exclusivo de la arquitectura de microservicios, la popularidad de los API Gateway ha crecido en el tiempo desde su surgimiento. Entonces, ¿qué es exactamente un API Gateway ?

Lo Básico

Los API Gateway son una capa que se encuentra entre el cliente y los servicios en los que se basa. A veces llamados “reverse proxy“, actúan como un único punto de entrada del cliente a sus servicios.

Son el mostrador de recepción en la parte delantera de un edificio de oficinas. Se encargan de enrutar llamadas, detener visitantes inesperados y asegurarse de que los paquetes lleguen al lugar correcto.

Si haz utilizado una API de terceros en el pasado, es posible que se esté comunicando con un API Gateway, que a su vez se comunicó con la API interna del servicio. Como veremos en la parte de beneficios a continuación, esto permite a los proveedores exponer partes de su API al mundo exterior y manejar versiones, seguridad, localización regional y más en un lugar central. Piensa en Google exponiendo su API para calendarios, o Twitter proporcionando versiones de su API externamente.

De los casos de uso para usar un API Gateway, el más común es el enrutamiento. Es algo parecido a esto:

1. Un cliente envía una solicitud a la puerta de enlace.
2. El gateway procesa y envía la solicitud al Servicio.
3. El servicio responde al gateway
4. El gateway procesa la respuesta y la envía al cliente.

El cliente, en este contexto, puede ser muchas cosas. En la implementación original mencionada anteriormente, el cliente era cliente del proveedor de API, pero los API Gateways también pueden exponer APIs internas a sus propios clientes. En muchas aplicaciones web modernas, “el cliente” es una aplicación de página única (SPA), pero también puede ser el backend de una aplicación web, una aplicación móvil nativa o incluso televisores inteligentes, reproductores multimedia y dispositivos IoT. Si, los clientes son los que estan bajo nuestro control o los que son propiedad de nuestros usuarios, el gateway administra y expone la API y los recursos que gestiona.

Los servicios a menudo son servicios internos que controlan su aplicación, como una base de datos o un microservicio. Los gateways también pueden interponerse entre cualquier API de terceros y el cliente de su aplicación. Esto permite a sus clientes acceder a datos de terceros de la misma manera que acceden a sus servicios internos.

En lugar de obligar a los clientes a conocer los detalles de cómo funciona cada API o servicio, la puerta de enlace expone una única API unificada con la que el cliente puede interactuar. La puerta de enlace maneja cosas como el control de acceso, la gestión de llamadas API y la interacción con otros servicios de back-end. Los clientes pueden desarrollarse independientemente de cualquier cambio que pueda ocurrir en el lado de los servicios. Los servicios también pueden intercambiarse dentro y fuera de las necesidades comerciales, siempre que el nuevo servicio se asigne a la interfaz existente. Por ejemplo, si la aplicación utiliza una API de terceros para la autenticación de usuarios y desea cambiar a un servicio interno, los clientes no se verán afectados mientras el nuevo servicio se asigne a la implementación.

Backends Tradicionales vs Backends “Para Frontends”

Hay dos variaciones principales de API Gateways. Tradicional y “backends para frontends”. Ambos tienen el mismo propósito, pero se implementan de manera diferente.

Los API Gateways tradicionales manejan las solicitudes de todos los clientes de la aplicación. Por ejemplo, un gateway para un servicio de transmisión de video manejará todas las solicitudes independientemente de donde provengan: televisores, teléfonos y tabletas, etc…

En muchos casos, servirá una API única para cada tipo de cliente según sus necesidades. Por ejemplo, una interfaz de voz puede no requerir los datos completos que requiere una interfaz web tradicional. La API del cliente resultante será más ágil. GraphQL intenta abordar este mismo problema, pero en cambio les da a los clientes control sobre la mucha o poca información que desean.

La variación de “backends para frontends” establece el mismo gateway de transmisión de datos individuales para cada cliente. En lugar de una puerta de enlace grande que enruta las solicitudes de los clientes, cada puerta de enlace más pequeña interactúa con todos los servicios de fondo necesarios independientemente de las otras puertas de enlace del cliente.

Beneficios clave de una API Gateway

Anteriormente mencioné que el caso de uso principal es el enrutamiento. Este y muchos beneficios se centran en abstraer los detalles de implementación lejos de los propios clientes y mantenerlos en un solo lugar: la puerta de enlace. Las puertas de enlace pueden manejar una variedad de tareas compartidas como:

• Autenticación y autorización: esto puede ser tan simple como garantizar que un usuario tenga acceso a un recurso, o tan complejo como manejar un flujo de autenticación completo.
• Procesamiento y validación de entradas: se pueden validar y procesar cualquier dato que provenga de los clientes antes de enviarlo a un servicio. Esto evita requerir que el cliente maneje la sobrecarga que viene junto con el procesamiento de datos.
• Transformación de respuestas: así como la puerta de enlace puede procesar datos antes de enviarlos a API o microservicios de terceros, también puede transformar respuestas antes de enviarlas al cliente. En nuestro ejemplo anterior, esto puede resultar en determinar qué forma de datos necesita un cliente específico.
• Telemetría: la puerta de enlace actúa como un punto central para administrar todos los registros y la recopilación de indicadores. A medida que todas las solicitudes y respuestas pasan por este punto central, se convierte en un lugar valioso para dejar caer las herramientas de telemetría.
• Ofuscación de servicios: al desacoplar los servicios de los clientes, las puertas de enlace API no solo protegen los servicios de los problemas del cliente, sino que también permiten que los clientes y los servicios existan de forma independiente. Los servicios se pueden cambiar o reemplazar sin afectar directamente al cliente.

Desventajas de los API Gateways

Parece que los API Gateways son una opción fácil basada en los beneficios, pero hay inconvenientes.

Al igual que con cualquier adición a su stack, los API Gateways introducen otra pieza para administrar. Deben ser alojados, escalados y administrados al igual que el resto de su software. Dado que todas las solicitudes y respuestas deben pasar por la puerta de enlace, agregan un punto adicional de falla y aumentan la latencia de cada llamada al agregar algunos “saltos” adicionales en la red.

Debido a su ubicación centralizada, resulta fácil aumentar gradualmente la complejidad dentro de la puerta de enlace hasta que se convierta en una “caja negra” de código. Esto hace que mantener el código sea más difícil.

Este enfoque de “poner todo junto” va en contra de la idea central de usar microservicios para dividir una aplicación en partes más pequeñas y elimina parte de su autonomía.

La mayoría de estos problemas son evitables, pero requiere un poco de trabajo.

Cómo API Gateways se relacionan con un Service Mesh

Las puertas de enlace permiten a los clientes acceder a los servicios, pero ¿qué sucede cuando los servicios necesitan comunicarse entre ellos? Ahí es donde entra en juego el mesh. Una service mesh es una capa centrada en la comunicación de servicio a servicio. Verá la comunicación de puerta de enlace descrita como Norte-Sur (desde los clientes a la puerta de enlace) y la comunicación de malla de servicio descrita como Este-Oeste (entre servicios).

Tradicionalmente tenía sentido usar un service mesh y un API gateway juntas. La puerta de enlace sería el punto de entrada para las solicitudes de su cliente, y luego el service mesh permitiría que sus servicios se confiaran unos a otros antes de pasar las respuestas a través del gateway. Un API gateway popular, Kong, lanzó un service mesh de código abierto para emparejarse con su producto de gateway.

En los últimos años, los service mesh han ampliado su funcionalidad para manejar la comunicación externa. Un mesh popular, Istio, ahora incluye algunas funciones de gateway. Se espera que con el tiempo, muchos productos de service mesh adopten muchas de las características principales de los gateways.

API Gateways Populares

• AWS API Gateway: Situada para manejar todas las interacciones alrededor de las llamadas API, el API Gateway de Amazon maneja las API REST y websocket y funciona muy bien con el resto del ecosistema de AWS.
• Apigee: Ahora parte del ecosistema de productos para desarrolladores de Google, el gateway Apigee incluye muchas herramientas no solo para administrar las API, sino también para crearlas.
• Kong: Mencionado anteriormente, Kong es una alternativa de código abierto que ofrece todas las características principales que hemos mencionado en este artículo.
• Tyk: Otra opción de código abierto, Tyk es una puerta de enlace API popular que ofrece las características principales que esperaría para las API y una arquitectura de microservicios, pero también ofrece un conjunto de herramientas adyacentes que funcionan con sus ofertas de servicios.