El estilo de la arquitectura microservicios se compone de pequeños servicios que se comunican unos con otros usualmente con mecanismos ligeros de comunicación, siendo el más típico HTTP/REST. Sin embargo no es el único mecanismo ni mucho menos el ideal para todos los escenarios. En esta entrada hablaremos de otros 6 estilos de comunicación existentes, cada uno con sus ventajas y desventajas. Al concluir esta lectura conocerás nuevos estilos y aprenderás a seleccionar el mas adecuado para cada situación.

En todos los casos no son estrictamente estilos de comunicación en sí o patrones.

SOAP

SOAP (Simple Object Access Protocol) es un protocolo de comunicación estándar utilizado en servicios web para intercambiar información estructurada en entornos distribuidos. Basado en XML, SOAP define reglas para la creación de mensajes que pueden ser consumidos por aplicaciones en diferentes plataformas. Utiliza HTTP o SMTP para el transporte de mensajes, proporcionando un enfoque robusto y ampliamente adoptado para la interoperabilidad entre sistemas heterogéneos. SOAP se centra en la definición clara de operaciones y tipos de datos, facilitando la comunicación entre servicios y clientes a través de una interfaz bien definida.

SOAP es ampliamente usado en aplicaciones empresariales y del sector bancario, conviene conocerlo, cuando vayamos a integrarnos a sistemas legados o a migrarlos necesitaremos conocer este estilo.

Ventajas

• Es un estándar bien definido
• Ampliamente adoptado
• Neutro
• Estructurado
• Fuerte seguridad (ws-security)

Desventajas

• Alto overhead por el tamaño de los documentos XML
• Esta siendo reemplazado por nuevas formas de comunicación.
• Curva de aprendizaje alta.

Restful

Representational State Transfer, es un estilo arquitectónico para el diseño de servicios web que se centra en la simplicidad, escalabilidad y la utilización eficiente de los protocolos de la web. En un servicio web RESTful, los recursos (datos o servicios) son identificados por URLs y se accede a ellos y se manipulan mediante los métodos estándar HTTP, como GET, POST, PUT, DELETE, PATCH y HEAD. La arquitectura REST utiliza los principios de estado y representación, donde cada recurso tiene una representación que puede ser transferida o modificada. Los formatos comunes de representación incluyen JSON o XML.

REST tiene un enfoque ligero y fácil de aprender, lo que facilita la implementación y consumo. Es especialmente adecuado para servicios web que priorizan la simplicidad y la eficiencia. RESTful es ampliamente utilizado en el desarrollo web, aplicaciones móviles y servicios en la nube debido a su flexibilidad y capacidad para funcionar bien en entornos distribuidos. A diferencia de SOAP, RESTful no requiere un esquema predeterminado y se basa en estándares web existentes, como HTTP, lo que lo convierte en una opción popular para la creación de API web.

Ventajas

• Simple de entender.
• Representación múltiple. 
• Neutro.
• Estructurado.
• Flexible

Desventajas

• Seguridad.
• Puede volverse lento cuando el volumen de datos a transmitir aumenta.
• Limitado para operaciones de consultas complejas.

GraphQL

Es un lenguaje de consulta para APIs que permite a los clientes solicitar solo los datos que necesitan. Proporciona una forma eficiente de obtener información específica, evitando la transferencia de datos innecesarios. GraphQL facilita la integración entre el frontend y el backend, ya que los clientes definen la estructura de la respuesta, mejorando la flexibilidad y rendimiento en comparación con algunos enfoques tradicionales de APIs RESTful.

Ventajas

• Permite la ejecución de solicitudes personalizadas, con ello podremos pedir a la API solo los campos que necesitamos.
• Bajo overhead en la red.
• Descubrimiento del esquema.

Desventajas

• Seguridad.
• Curva de aprendizaje.
• Difícil de usar cache por la variabilidad y dificultad de poder definir claves efectivas.
• Falta de estándares.

gRPC

gRPC (gRPC Remote Procedure Call) es un marco de trabajo de código abierto desarrollado por Google que facilita la comunicación entre servicios distribuidos. Utiliza el protocolo binario (ceros y unos) Protocol Buffers para serializar datos, lo que resulta en una transferencia de información eficiente. gRPC permite llamadas a procedimientos remotos (RPC) entre aplicaciones cliente y servidor, utilizando una variedad de lenguajes de programación. Proporciona una comunicación bidireccional eficiente y admite características avanzadas como streaming bidireccional (esto es fundamental, nos permite optimizar mucho la comunicación) y control de versiones integrado. Su multiplexación permite manejar múltiples solicitudes y respuestas simultáneamente en una única conexión. gRPC es utilizado en entornos de microservicios para la comunicación interna ofreciendo rendimiento, flexibilidad y generación automática de código para facilitar el desarrollo.

Linkedin reemplazó JSON por gRPC con protobuf en su arquitectura y logro reducir hasta en un 60% la latencia de su comunicación interna.

Ventajas

• Tipado fuerte.
• Alto rendimiento en la comunicación.
• Multiplexado de streams (facilita reusar un mismo canal).
• Herramientas existentes de generación de código.

Desventajas

• Curva de aprendizaje.
• Falta de soporte en todos los navegadores, por lo que se usa solo para comunicaciones internas.
• Observabilidad compleja debido a ser binario.

Websockets

WebSocket es una tecnología de comunicación bidireccional y en tiempo real entre un navegador web y un servidor. A diferencia de las solicitudes HTTP tradicionales, que son unidireccionales, WebSockets permiten que tanto el cliente como el servidor envíen mensajes activamente en cualquier momento durante la conexión. Esto mejora la eficiencia y la capacidad de respuesta, siendo útil para aplicaciones que requieren actualizaciones instantáneas como por ejemplo un chat o notificar hacia el navegador el estado de las acciones en la bolsa.

En la comunicación usando webSockets se inicia una conexión a través de un protocolo HTTP y luego se actualizan a una conexión independiente y bidireccional. Mantienen una conexión persistente, lo que significa que la comunicación puede ocurrir sin la necesidad de abrir y cerrar repetidamente nuevas conexiones. Este sistema reduce la latencia.

Ventajas

• Bidireccional.
• Tiempo real, baja latencia.
• Bajo overhead en la comunicación.

Desventajas

• Complejo de implementar.
• Problemas de soporte de dispositivos como firewalls.
• Complejo de escalar.

SSE

SSE (Server-Sent Events) es una tecnología web que permite la transmisión unidireccional de datos desde el servidor al navegador. Utiliza conexiones HTTP para enviar eventos en tiempo real, facilitando actualizaciones automáticas y notificaciones push sin la necesidad de solicitudes adicionales del cliente.

Ventajas

• El servidor puede pasar mensajes al cliente.
• Fácil de implementar.
• Compatibilidad.

Desventajas

• Unidireccional limitado.
• Limitado a transferir datos en texto plano.

Publicador/suscriptor

El modelo de publicador/suscriptor, o patrón Pub/Sub, es un diseño de comunicación donde los componentes, llamados suscriptores, se registran para recibir eventos de un publicador. Cuando el publicador emite un evento, todos los suscriptores registrados lo reciben.

Esto permite un alto desacoplamiento entre componentes, ya que los suscriptores no necesitan conocer directamente a los publicadores. El modelo es utilizado para mejorar la escalabilidad en los microservicios, donde la comunicación entre componentes debe ser eficiente y flexible.

Ventajas

• Desacoplamiento.
• Escalabilidad.
• Permite implementar el mecanismo fire & forget (mandar el mensaje y desentenderse de la respuesta o de lo que suceda con el mismo).

Desventajas

• Posible pérdida de mensajes.
• Difícil lidiar con el orden y la garantía de entrega.
• Puede generarse contrapresión pues los consumidores pudieran no dar abasto para consumir los mensajes publicados.

¿Qué es mejor SOAP, REST, gRPC, Websockets, SSE o Pub/Sub?

Bueno, como no puede ser otra forma en la programación, no exista A mejor que B, solo existen tecnologías adecuadas para diversos casos de uso, solo debemos tenerlas todas en nuestra caja de herramientas como desarrolladores y usar cada una cuando tenga lugar.

Como única recomendación de este artículo te quiero dejar que mientras sea posible y el caso de uso lo permita uses eventos para comunicar microservicios, el desacoplamiento favorece la escalabilidad y resiliencia, dos elementos muy deseados en los sistemas de software modernos.

Si te ha servido este artículo únete a nuestra newsletter y al canal de Youtube.