SOA, GraphQL y gRPC

La arquitectura orientada a servicios, SOA por sus siglas en inglés, es una manera de diseñar el software que persigue un objetivo por encima de todos: aprovechar dos veces lo que ya está construido. Para lograrlo publica cada funcionalidad como un servicio con su propio interfaz, y hace que esos servicios dialoguen por la red en un lenguaje que todos comparten. Lo que antes eran módulos encerrados dentro de una aplicación pasan a ser piezas que cualquier otra aplicación de la organización puede invocar.

SOA no es una tecnología, es una forma de organizar el sistema, y sus principios están recogidos en el manifiesto SOA. Se puede implementar con servicios SOAP, que es lo tradicional, o con servicios REST.

• Cada servicio ofrece una funcionalidad de negocio completa y con sentido por sí sola.
• El interfaz publicado es lo único que ve quien lo llama: la implementación interna puede cambiar sin avisar.
• Los servicios se combinan para formar procesos mayores, en vez de reprogramar lo mismo en cada aplicación.
• La comunicación se apoya en estándares abiertos, para que la tecnología de cada servicio no condicione a los demás.

La palabra que resume SOA es reutilización: publicar una vez lo que hace la organización y consumirlo desde donde haga falta, en vez de reimplementarlo en cada sistema.

Cuando una organización tiene decenas de servicios, conectarlos todos con todos se vuelve inmanejable. El ESB (Enterprise Service Bus, bus de servicio empresarial) es el modelo de arquitectura que resuelve eso: gestiona la comunicación entre los servicios web actuando como una capa intermedia, un middleware al que se conectan todos los sistemas de la empresa en vez de conectarse entre sí.

El resultado es que cada sistema habla solo con el bus, y el bus se encarga de encaminar cada mensaje a su destinatario. Es la pieza de integración típica de una arquitectura SOA.

Un ESB no añade funcionalidad de negocio: no hace nada que la empresa no hiciera ya. Lo que aporta es que las integraciones dejen de ser una maraña de conexiones punto a punto.

GraphQL lo desarrolló Facebook y ataca una limitación concreta de REST: es el servidor quien decide qué campos lleva cada respuesta, así que el cliente casi siempre recibe más datos de los que necesita, o menos y tiene que encadenar varias llamadas. En GraphQL se describen los datos disponibles en el servidor y es el cliente quien especifica en la propia petición qué quiere recibir.

De ahí que trabaje con un único punto de acceso: no hay una dirección por recurso, sino una sola a la que se le manda la consulta. Existen bibliotecas para montar el servidor y para consumirlo desde el cliente en los lenguajes habituales.

En el esquema de un servicio GraphQL las operaciones se declaran repartidas en dos grupos, y la separación es explícita. Bajo query van las consultas, es decir, todo lo que se puede preguntar al servicio sin tocar nada. Bajo mutation van las que sí modifican datos: crear, cambiar o borrar.

query {
  alumno(id: 482) {
    nombre
    intentos(tema: "servicios-web") {
      fecha
      aciertos
    }
  }
}

mutation {
  registrarIntento(alumno: 482, tema: "servicios-web", aciertos: 47) {
    id
    fecha
  }
}

En la consulta de arriba el cliente ha pedido el nombre del alumno y, de sus intentos, solo la fecha y los aciertos. No recibirá nada más, aunque el servidor tenga veinte campos más de cada intento. Esa es la diferencia práctica con REST, donde el formato de la respuesta lo fija el servidor.

La equivalencia mental que ayuda: query hace lo que un GET de REST y mutation lo que hacen POST, PUT y DELETE juntos, pero todo por el mismo punto de acceso.

gRPC lo desarrolló Google y recupera el estilo de la llamada a procedimiento remoto, pero sobre tecnología moderna. Como CORBA en su día, usa un lenguaje de definición de interfaces para declarar el contrato; ese lenguaje es Protocol Buffers, conocido como Protobuf, que sirve a la vez para definir las operaciones y los mensajes y para serializarlos.

La diferencia que lo define frente a REST es el formato: los mensajes viajan en binario, no en texto, y sobre HTTP/2. Eso lo hace mucho más eficiente en ancho de banda y en tiempo de proceso, a cambio de perder legibilidad y de no poder invocarse cómodamente desde un navegador. Por eso su terreno natural son las llamadas internas entre servicios: Kubernetes se entiende por gRPC con los contenedores que administra, a través del interfaz normalizado CRI.