Skip to main content

API Gateway

Antiguamente teníamos un sistema grande que proporcionaba todo lo necesario, más conocido como Monolito. Todas las solicitudes eran enviadas a él. Hoy en día las cosas han cambiado mucho y dividimos esto en sistemas menores llamados microservicios para que sea más fácil desarrollar, probar, escalar, dividir responsabilidades y gestionar permisos, mejorar la seguridad, etc.

Cada microservicio tiene su propia API y dependiendo de qué endpoint de esta API se utilice, se dará una respuesta.

Resumen sobre APIs​

Las APIs (Application Programming Interfaces) son interfaces que permiten la comunicación entre sistemas, servicios o aplicaciones. Existen diversos tipos de APIs, cada una con características específicas que las hacen adecuadas para diferentes escenarios. Vamos a detallar los principales tipos:

  • REST (Representational State Transfer)

    • Es el estándar más utilizado actualmente. Se basa en recursos representados como URLs, con operaciones realizadas por métodos HTTP (GET, POST, PUT, DELETE).
    • Protocolo HTTP.
    • Utiliza JSON o XML (principalmente JSON actualmente) como formato de datos.
    • Más simple y más utilizado.
    • Fácilmente integrable con navegadores y frontends.
    • Menor rendimiento en comparación con otros protocolos.
    • No mantiene una conexión persistente.
    • Generalmente usados en APIs públicas, integraciones web, aplicaciones móviles.
    • Utiliza un estándar para escribir llamado OpenAPI (Antiguo Swagger). Las definiciones pueden ser escritas en JSON o YAML.

  • gRPC (Google Remote Procedure Call)

    • Protocolo desarrollado por Google que utiliza HTTP/2 para comunicación, con foco en rendimiento. Adopta una arquitectura basada en llamadas de método remoto.
    • Protocolo HTTP/2.
    • Varios formatos pueden ser utilizados. Avro, Protobuf, MessagePack (JSON en formato binario para mejorar el rendimiento). Existen otros, pero son menos utilizados.
    • Alto rendimiento (menor latencia).
    • Soporte a streaming bidireccional.
    • Definición de contratos fuertemente tipados. Por ejemplo, un JSON no define si true debe ser leído como string o booleano.
    • Complejidad mayor en comparación con REST.
    • No es amigable para navegación directa en navegadores.
    • Más usado en microservicios, comunicación entre sistemas de alto rendimiento.

  • GraphQL

    • Lenguaje de consulta para APIs creado por Facebook, que permite al cliente especificar exactamente qué datos necesita.
    • Protocolo HTTP.
    • JSON es el formato de datos utilizado.
    • Permite consultas personalizadas, reduciendo sobrecarga de datos.
    • Ideal para aplicaciones que consumen APIs con múltiples clientes (como web y móvil).
    • Mayor curva de aprendizaje.
    • Posibilidad de consultas excesivamente complejas, impactando el rendimiento.
    • Más utilizado en aplicaciones con frontends dinámicos, proyectos con gran variedad de clientes.

  • SOAP (Simple Object Access Protocol)

    • Un estándar más antiguo que utiliza XML para intercambio de mensajes estructurados. Generalmente se encuentra esto en sistemas legacy.
    • Puede operar sobre los protocolos HTTP, SMTP, TCP.
    • Altamente estandarizado y confiable.
    • Incluye especificaciones robustas para seguridad y transacciones.
    • Muy verboso por usar XML volviéndolo más lento y pesado.
    • Menos flexible que REST o GraphQL.
    • Sistemas legacy, integración en bancos, servicios financieros.

  • WebSocket

    • Permite comunicación bidireccional en tiempo real entre el cliente y el servidor mediante una conexión persistente.
    • Protocolo WebSocket.
    • Texto o binario pueden ser utilizados en los datos.
    • Ideal para aplicaciones en tiempo real.
    • Menor latencia por mantener conexiones abiertas.
    • Más difícil de escalar en comparación con REST.
    • Requiere soporte específico en el servidor.
    • Usado en Chat, juegos, actualizaciones en tiempo real.

Una cosa que debe estar clara antes de comenzar es que API Gateway no es un balanceador de carga.

alt text

Funciones del API Gateway​

Pueden existir microservicios utilizando diferentes tipos de API, ¿y cómo vas a saber dónde están cada uno de tus microservicios?

¿Vas a utilizar un balanceador de carga para agruparlos? ¿Vas a separar por IP? ¿Por subdominio? ¿Vas a usar un service discovery? ¿Cómo vas a hacer la autorización de ellos? ¿Cómo estandarizar esto?

El API Gateway viene a ser el muro, el hub, para todas esas APIs siendo el frente para el mundo interno de tu sistema que puede estar dividido de varias maneras y nadie necesita saber cómo. Con él logramos simplificar un sistema complejo y tener control sobre las solicitudes.

Un API Gateway es muy poderoso y tiene muchas funciones que podemos explorar.

alt text

Con un API Gateway tenemos solo un endpoint y él encaminará (función de enrutamiento), modificando si es necesario (transformación), el mensaje para la API (microservicio) correcta. Funciona como una interfaz sobre interfaces (APIs).

Cuando dije que puede modificar, quiero decir que a veces queremos recibir un mensaje en JSON o YAML por el API Gateway y él cambiará a XML para enviar a un microservicio legacy que aún no ha sido actualizado. De esta forma logramos estandarizar las cosas.

Quien está fuera no sabe ni cuántos microservicios están siendo utilizados, ni conoce la API de esos microservicios, solamente aquello que es expuesto en el API Gateway. Eventualmente piensan que estás trabajando con un único sistema.

Con API Gateway podemos centralizar el proceso de autenticación y autorización en un único punto de entrada evitando que cada microservicio tenga que implementar individualmente. De esta forma podemos garantizar la uniformidad en este estándar de autenticación o incluso cambiar de forma centralizada evitando que sea corregido esto en 300 microservicios.

El uso del API Gateway mejora la seguridad, pues cada lenguaje utilizado en los diferentes microservicios tiene bibliotecas específicas que implementan la autenticación y autorización. Evitando utilizar esas bibliotecas reducimos la posibilidad de ser expuestos a CVEs y delegamos ese problema a la nube.

El API Gateway puede ser configurado para verificar y validar tokens de autenticación (como JWT) antes de permitir el tráfico hacia los microservicios. Esto garantiza que los microservicios nunca tengan que manipular directamente las credenciales o tokens sensibles.

Tiene soporte a varios proveedores de autenticación diferentes lo que simplifica la gestión de autenticación cuando tienes usuarios de diferentes fuentes. Además puede ser utilizado para verificación de autorización basada en RBAC o ABAC permitiendo una gestión más simple y cohesiva de los permisos.

Existen muchas más cosas que podemos hablar sobre un API Gateway, en el aspecto de escalabilidad, flexibilidad, gestión de sesión, etc.

El API Gateway debe ser usado cuando trabajamos con diferentes sistemas, no solamente microservicios, y necesitamos un punto único de entrada. Funciona como un proxy inverso potenciado y cuando tenemos todas las solicitudes entrando por un único lugar también es más fácil monitorear logrando tener una visión macro de todo el flujo de entrada y salida (cantidad de solicitudes, endpoints más accedidos, estrés extra por endpoint, tiempos de respuesta, etc.)

Dos puntos importantes es que el API Gateway también tiene su sistema de caché y versionamiento que pueden ser explorados para facilitar el rendimiento y desarrollo.

Algunos servicios ni siquiera poseen IPs como por ejemplo los serverless (lambda en AWS, function en Azure, etc.) y podemos hacer uso del API Gateway para dar a esas funciones endpoints.

Otra funcionalidad interesante es incorporar un WAF en el API Gateway para protección contra ataques de DDoS pudiendo crear reglas que limiten el acceso a endpoints, por ejemplo definir una cantidad de solicitudes por segundo provenientes de la misma IP. Generalmente esos WAFs también nos ayudan a proteger contra otros tipos de ataque como SQL Injection.

Aún podemos usar el API Gateway para hacer la verificación de los esquemas evitando entregar un request sin los datos necesarios para el próximo servicio mejorando el rendimiento del sistema. De la misma forma podemos hacer el tratamiento de errores y retornar una respuesta consistente caso el backend no responda.

Todavía tenemos la opción de crear un endpoint que encadena llamadas para varios backends y retornamos una respuesta única. Es posible hacer pero poco usual.

Ventajas​

  • Rendimiento
  • Simplificación del sistema y de las integraciones
  • Escalabilidad
  • Seguridad
  • Monitoreo

Desventajas​

  • Punto único de fallo
  • Latencia si no es bien trabajado
  • Esclavización por quedar atrapado en los recursos ofrecidos y precios
  • Costo cuando el tráfico es muy alto
  • Costo de Mantenimiento (Personal) principalmente si es hospedado.
  • Complejidad de configuración

Servicios Disponibles​

Para las Clouds tenemos los servicios ofrecidos:

  • Amazon API Gateway
  • Azure API Management
  • Google Cloud API Gateway
  • Apigee

Self Hosted Más usados:

  • Kong (Open Source)
  • Nginx Plus (Tiene licencia)
  • Express Gateway
  • Tyk

Si no queremos utilizar el API Gateway de la Cloud incluso por cuestión de precio tenemos una excelente opción que es Kong. Realmente es necesario hacer un análisis del costo de esto pues muchas veces la propia llamada para un serverless puede costar más caro que la ejecución de la función.