Más allá de REST - Pruebas de contrato en la era de gRPC, Kafka y GraphQL

OK, bueno, gracias a todos por venir a mi charla sobre Más allá de REST, pruebas de testing en la era de gRPC, Kafka y GraphQL. Mi nombre es Matt Fellowes. Soy Gerente de Producto Principal en SmartBear. Fui cofundador de Pactflow, que se unió a la familia SmartBear en abril de este año. Y soy un mantenedor principal de PACT, que es un marco de pruebas de contrato impulsado por el consumidor, uno de código abierto. Y el tema, o el curso, hasta gran parte de la charla de hoy.

Antes de trabajar en Pactflow, fui consultor. Soy un consultor en recuperación, y tuve la suerte de trabajar en algunas de las organizaciones más grandes y conocidas de Australia y sus sistemas distribuidos, y realmente los vi evolucionar a lo largo de mi career. Ha habido, por supuesto, una gran cantidad de cambios tecnológicos desde los días en que SOAP, que era la tecnología predominante cuando me uní a la industria, hasta los años. Y en mi career relativamente corta, he trabajado desde ese punto de partida de SOA, SOAP hasta REST y microservicios, el auge de la nube pública y el IOT, el event sourcing, la estructura de eventos, las canalizaciones de datos modernas y, por supuesto, las arquitecturas sin servidor. Y descubrí que en muchas de estas situaciones y contextos, las pruebas de contrato eran aún muy relevantes y a menudo buscaba introducir pruebas de contrato en lugares donde había beneficios en el desplazamiento hacia la izquierda, avanzar más rápido y resolver esos problemas en sí mismos. Pero, por supuesto, durante esas implementaciones o a menudo, yo sería el destinatario de algún comentario sarcástico, generalmente de otra consultoría competidora, que tenía el siguiente argumento en forma de shape. Si simplemente usáramos la tecnología en blanco, entonces no necesitaríamos pruebas de contrato. Pero ¿es cierto? Bueno, hoy vamos a examinar esa afirmación. Vamos a hacer la pregunta ¿REST es realmente el problema? ¿Y podríamos ahorrarnos la molestia de tener que pensar en las pruebas de contrato, ejecutar pruebas utilizando una tecnología superior para la comunicación de API? Vamos a aprender brevemente qué son las pruebas de contrato, por qué existen y el problema que resuelven. Y vamos a ver, ya sabes, si la historia se repite o si estas nuevas tecnologías y tendencias arquitectónicas realmente resuelven el problema. Específicamente, vamos a ver algunas clases de tecnologías. Vamos a ver especificaciones como OAS y ASIN KPI hasta cierto punto, GraphQL y también IDL y cosas como Protobufs y Avroans, Rift. Por supuesto, hay otros, pero estos son, con mucho, las alternativas más comunes que me sugieren mis interlocutores consultores. Los veremos desde una perspectiva general de pruebas de contrato, pero por supuesto utilizaremos PACT, que obviamente es una herramienta en la que trabajo, como una implementación concreta para ayudarnos a comprender y cómo funciona en la práctica. Y espero que veas que, ya sabes, si bien PACT ha evolucionado para satisfacer algunas de estas necesidades, también veremos que el problema y la solución son mucho más generales que cualquier tecnología o lenguaje específico que hayamos discutido hoy.

Permítanos hablar rápidamente o comprender por qué existen las pruebas de contrato y el contexto en el que operan. Creo que comenzar con una cita de un cliente es una buena manera de ambientar la escena, solo para ayudarnos, ya sabes, a sentir el problema. Esta es una cita de un prospecto de PACT flow que busca ayuda y, por el bien del argumento y para proteger al inocente, llamémoslo Bill. Y Bill es líder de una organización de pruebas para más de 40 equipos en una institución bancaria muy grande. Y aquí puedes ver que básicamente describe cómo trabaja en este entorno grande con un entorno de pruebas altamente volátil, lo que lo hace desafiante, y está tratando de descubrir cómo puede usar pruebas de contrato para probar todas las cosas que tiene. Tiene servicios RESTful, GraphQL, Kafka, sistemas de terceros, todas estas cosas, ¿verdad? Lo que puedes deducir de esto es que trabaja en este entorno caótico, es complejo y está buscando formas de llevar algo de proceso y control a esa situación. Ahora, si suena algo parecido a su empresa o arquitectura, no está solo. La investigación del estado de calidad de SmartBear, así como el informe de API de Postman, realmente respaldan esto. Y podemos ver que, en primer lugar, los microservicios internos se están convirtiendo en un enfoque masivo para los equipos.

Aquí puedes ver que el 61% dijo que verán el mayor crecimiento para los microservicios. Pero en realidad, detrás de escena, leerás que en realidad hay servicios internos que hacen que los datos estén disponibles internamente para otros equipos para crear más valor, lo cual es realmente interesante. Pero también puedes ver que la mayoría de las empresas operan en un entorno de múltiples protocolos, alrededor del 81% o así, y casi el 60% tiene tres o más protocolos.

Ahora, por supuesto, aunque los microservicios no son nuevos y se han aprendido muchas lecciones, hay estos problemas que estamos empezando a ver, ya sabes, realmente una década después de que hayamos adoptado esta nueva forma de hacer las cosas. En el informe, o en ambos informes, podemos ver que el 50% de las personas afirmaron que la experiencia o las habilidades eran una barrera para implementar los microservicios, y el 35% afirmó que la complejidad de los sistemas, este es el segundo problema, se está convirtiendo en un problema. Y los obstáculos están relacionados con la velocidad de entrega, o la velocidad de entrega esperada, en comparación con el tiempo real para probar y construir cosas, lo cual es realmente contradictorio. Y lo que encontré más interesante de todo es que las organizaciones maduras son las que sienten el dolor. Y entonces piensas, ¿por qué es contraintuitivo? Si son maduros, probablemente tengan todas estas prácticas y tecnología y demás para lidiar con ello, pero creo que las razones son bien comprendidas.

La primera razón, o una de esas razones, es cómo probamos los microservicios hoy en día. La mayoría de las empresas confían en pruebas y sistemas distribuidos utilizando una forma de pruebas de integración de extremo a extremo. Esto implica básicamente tomar todas tus aplicaciones y desplegarlas en un gran entorno compartido y luego ejecutar una serie de pruebas en todo el sistema, en todas las capas de tu sistema, ¿verdad? Y luego, si eso funciona, puedes implementar. Ahora, esto puede darte un alto grado de confianza. Si pasan, tienden a ser bastante lentas, y también tienden a ser muy inestables y difíciles de depurar. Y debido a todo esto, te brindan retroalimentación mucho más adelante en el ciclo de vida, ¿verdad? Porque has tenido que implementarlos antes de poder obtener esa retroalimentación. También significa que son muy difíciles de implementar. Probablemente no puedas implementar cosas de forma independiente y probablemente tengas un monolito distribuido en lugar de un conjunto coherente de componentes cooperativos que trabajan hacia un objetivo único en mente.

Esto crea un problema cuando comienzas a escalar el tamaño de tu ecosistema, tanto las personas como el software. A medida que haces esto, al agregar nuevos componentes y personas al sistema, ves esta respuesta no lineal a cosas como el costo, la complejidad, el tiempo o el número de entornos, el tiempo de construcción, el costo asociado con el cambio y el tiempo de inactividad del desarrollador. Pero si miras con mucho cuidado, te darás cuenta de que realmente comienzas a sentir el dolor un poco más adelante. Ese punto de inflexión no está al principio, así que entras al sistema pensando que es fácil de usar, pero luego, a medida que escalas, eventualmente llegas a este punto de inflexión donde se vuelve realmente doloroso. Y así no es de extrañar que Bill esté pasando un mal momento. Esto explica un poco lo que está sucediendo allí.

De acuerdo, ¿cuál es la solución? Bueno, una de las soluciones es utilizar cosas como las pruebas de contrato. Las pruebas de contrato pueden ayudar al reducir muchas de las pruebas de extremo a extremo y reemplazarlas por una forma de probar las comunicaciones de tu API, que es a menudo lo que las pruebas de extremo a extremo buscan hacer. Las pruebas de contrato son una técnica para garantizar que dos sistemas puedan comunicarse. Y examinamos esos puntos de integración y lo hacemos simulando las dependencias. Entonces, si eres un consumidor de la API, simulas el proveedor y reproduces esas simulaciones contra él más tarde en la vida real contra el proveedor real. Y si esas simulaciones han sido validadas, tenemos confianza en que estos dos sistemas pueden comunicarse. Y el beneficio de esta forma de trabajar es que es mucho más fácil de entender. Solo estás probando un punto de integración a la vez.

No necesitas entornos de prueba dedicados, puedes ejecutarlo en tu máquina de desarrollo. Esto te brinda una retroalimentación rápida y confiable que es fácil de depurar. Estas pruebas se escalan de forma lineal y podemos implementar los servicios de forma independiente. Y, por supuesto, podemos rastrear esto a lo largo del tiempo, lo que nos da la capacidad de evolucionarlos. Hablamos de esto en la Cumbre TestJS anterior. Vuelve y mira ese video si quieres conocer el resto de los detalles de esa charla.

Ok, con suerte ahora tenemos una idea del problema con el que estamos tratando y cómo las pruebas de contrato podrían ayudar con eso. Ahora volvamos al argumento original de mi consultor, Interlocutor, y hagamos la pregunta, ¿es REST realmente el problema? ¿Y podríamos ahorrarnos todos los problemas usando algo diferente? Comencemos con OpenAPI y su contraparte, JSON schema. Pero también puedes pensar en esto aplicando a cosas como AsyncAPI y SOAP y otras especificaciones. En cierta medida, GraphQL también entra en esta mezcla. No tenemos tiempo para hablar específicamente de GraphQL hoy.

Entonces, ¿cómo pretende resolver un problema? Bueno, lo primero es que las especificaciones contienen todos los elementos necesarios para que los humanos y puedan comunicar lo que puede hacer una API. Y utiliza cosas como JSON schema para decirnos cuál es la estructura de los datos entrantes y cómo debería ser la forma de la respuesta. O lo que también puede ser. Y luego podemos generar clientes y servidores de API a partir de eso OAS.

Entonces sabemos que no vamos a romper ningún cambio. ¿Verdad? Entonces, si podemos generar un código de cliente a partir del OAS, ¿no estamos siempre garantizados de tener un sistema funcional? Bueno, por supuesto que la respuesta es no. De lo contrario, no estaríamos aquí. Y si eres lo suficientemente mayor como para recordar SOAP, recordarás que también teníamos todas estas cosas en características. Una especificación clara, un esquema claro y generación de clientes y generación de esquemas y servicios. Pero no resolvió el problema. Y REST obviamente tiene algunos principios de redundancia mejorados incorporados en el diseño de él. Ya sabes, la ley de Postel y la extensibilidad. Pero en realidad no es suficiente.

Y si estás mirando aquí, si miras esta cita, esto es del sitio web de JSON schema. Básicamente dice que si vas a hacer este tipo de pruebas con JSON schema para validar tu solicitud, necesitarás dos tipos de validaciones. Uno es una herramienta estructural, a nivel de esquema, que es lo que JSON schema puede hacer. Y otro a nivel semántico. Y eso debe hacerse en código, probablemente. Así que JSON schema aún no puede hacer eso. Incluso te lo dice.

Entonces, el aforismo de que una API no es incompatible con una especificación comienza a resumir cómo pienso acerca de y cómo pensamos acerca de las API abiertas. Lo que quiero decir con eso es que el esquema es en realidad abstracto. Y por lo tanto, es muy difícil decir que una API realmente implementa una especificación porque una especificación es en realidad abstracta y no exactamente clara. Ejemplos. Entonces, campos opcionales y nulos. En documentos de OpenAPI suficientemente avanzados, verás el uso de campos opcionales y nulos pero no sabrás en qué situaciones esos campos estarán o no presentes. Entonces, en algunos casos, muchos de esos campos resultaron ser opcionales. Y ahora es realmente difícil entender qué datos estarán disponibles en qué momento. Pero ciertos consumidores pueden necesitar esa información. Combina esto con puntos finales polimórficos.

Entonces, estos son puntos finales que pueden aceptar entradas de diferentes formas y salidas de diferentes formas. Ahora se vuelve muy difícil decir para cada recurso en su documento, qué entrada corresponderá a qué salida y bajo qué condiciones. En el caso de SOAP, en realidad teníamos Schemetron para ayudarnos con esto. Tenía esta capa adicional de protección que se podía colocar encima de él, pero necesitaba XSLT para hacerlo, que utilizaba funciones para lograrlo. Por supuesto, también perdemos de vista el área de servicio de la API. Entonces, si estamos utilizando SDK generados por el cliente, bueno, no sabemos qué está haciendo nuestro consumidor, así que tenemos que asumir que están utilizando toda la interfaz. Lo que significa que necesitamos un mecanismo de evolución diferente. El estándar aquí va a ser la versionización, de la cual hablaremos en un momento.

Por último, pero no menos importante, los SDK de cliente pueden modificarse y utilizarse de formas inesperadas. Estaba hablando con uno de nuestros ingenieros de soluciones en Europa que trabaja con algunos de los clientes más grandes de Smagger y Smagger Hub en el mundo. Mencionó que básicamente el 90% de todos los clientes que utilizan CodeGen realmente modifican el código generado cuando el sistema operativo cambia después de esa generación inicial. Esa oportunidad de desviación definitivamente sigue presente.

Por supuesto, toquemos brevemente el tema de la versionización. La versionización es la práctica más común aquí, pero es dolorosa. No queremos hacerlo si podemos evitarlo. Los equipos necesitan construir otra versión del software, mantenerlo, probarlo, lanzarlo. Ahora tenemos múltiples versiones que debemos mantener, por lo que tenemos más código para mantener, por supuesto. El costo de mantener el código suele ser mucho mayor a lo largo del ciclo de vida que construirlo. Suponiendo que no sabemos qué están utilizando nuestros consumidores, la funcionalidad siempre se mantiene a través de esas versiones porque tenemos que asumir que la necesitan y la quieren. Y luego necesitamos llevar a los consumidores eventualmente a esas nuevas versiones, lo que nos requiere nuevamente monitorear, coordinar y comunicar a las personas sobre esas versiones. Realmente, este es el costo y si podemos evitar esta sobrecarga, deberíamos hacerlo.

Entonces hablemos sobre la segunda clase de problemas aquí. Vamos a hablar sobre los lenguajes de definición de interfaz. Estamos hablando de cosas como Protobufs, Avro y Thrift, y debo decir que de todos ellos, Protobufs es el comentario más común que me han hecho, diciendo que podríamos simplemente usar Protobufs y no necesitaríamos pruebas de contrato porque tiene una evolución de esquemas incorporada desde el principio. De hecho, es tan bueno que puedes avanzar y retroceder en el tiempo. Puedes usar clientes antiguos con servidores más nuevos y clientes más nuevos con servidores más antiguos y todos pueden comunicarse mágicamente. Y, por supuesto, también admite la generación de código. Por lo tanto, podemos crear servidores y clientes a partir de esas definiciones. Entonces, si eso es cierto, ¿por qué Protobufs y gRPC son la característica más solicitada en nuestra hoja de ruta de código abierto? Bueno, la respuesta aquí es que las ideas verdes sin color duermen furiosamente. ¿Qué estoy diciendo aquí? Obviamente, esta es una afirmación absurda. En realidad, proviene de un hombre llamado Noam Chomsky, quien escribió sobre esto en la década de 1950 en su tesis sobre el lenguaje. Y estaba hablando sobre lo que está haciendo aquí es sobre la sintaxis y la semántica, que la conformidad sintáctica no significa que sea comprensible semánticamente. La gramática y la sintaxis son diferentes. No hay significado aquí. Entonces, lo que estamos tratando de decir es que, aunque podamos comunicarnos entre nosotros, aún debemos entender mejor lo que estamos diciendo.

Veamos un ejemplo aquí. Supongamos que tenemos una cola de Kafka, un tema donde publicamos pedidos que se están completando en ese tema. Y tenemos un consumidor en ese tema que lee todos los pedidos que llegan y calcula los totales, solo para hacer un informe o algo así, ¿verdad? Entonces, va a encontrar todos estos pedidos, cada vez que llega uno, mira el total, lee el valor total y lo imprime o lo guarda en algún lugar.

Ahora, supongamos que necesitamos cambiar esa estructura de pedido. Tal vez necesitamos dividir el total en diferentes valores. Tal vez solo dividirlo en GST o impuestos o lo que sea, o necesitamos moverlo a algún lugar más en la carga útil, ¿verdad? De cualquier manera, ha cambiado. Y ahora, hemos enviado este nuevo mensaje. Bueno, solo porque el consumidor puede leer el mensaje no significa que no necesitara ese valor total, ¿verdad? Todavía necesita el valor. De lo contrario, no puede hacer su trabajo.

Este problema se manifiesta aún más y se vuelve mucho más difícil cuando se combina con campos opcionales. En la investigación de esta charla, hablé con un equipo que trabajaba con gRPC y Protobufs en una empresa global de procesamiento de pagos. Y fue un error extraño que apareció cuando los comerciantes ocasionalmente no recibían pagos del proveedor. Y después de un análisis y depuración cuidadosos, descubrieron que había este nuevo servicio de comerciantes que se había cambiado ya que una API de configuración tenía un nuevo campo booleano para habilitar el guardado de pagos para un comerciante. Y descubrieron que había un solo cliente que no conocía esta actualización. Y cada vez que enviaba una solicitud al servicio de comerciantes, inadvertidamente deshabilitaba los pagos del comerciante porque el campo predeterminado, por supuesto, iba a ser falso. Así que puedes ver cómo este tipo de error puede ser particularmente malicioso de encontrar y resolver. Y en realidad, es un caso en el que probablemente no quieras la compatibilidad hacia adelante y hacia atrás. Tal vez una explosión de red sería mejor. Y de hecho, para empeorar las cosas, la versión tres de Protobufs elimina por completo los campos requeridos , lo cual se parece mucho a lo que sucedió con SOAP en los viejos tiempos, donde todo era un campo opcional y realmente era una API incomprensible. Así que volviendo a los desafíos con Protobufs, hablamos sobre la semántica y los campos opcionales. Aún necesitamos gestionar cambios disruptivos. Los descriptores de campo y cosas como estas, técnicamente o teóricamente, deberían ser fáciles de gestionar, pero en realidad, en la práctica, es muy fácil refactorizar accidentalmente tu código y cambiar los descriptores de campo. Es posible que debamos considerar cómo gestionamos la seguridad del transporte en el caso de Protobufs, que puede utilizar diferentes tipos de transporte. Es posible que deseemos reducir los tipos. Los Lenguajes de Definición de Interfaz (IDL), muchas de estas tecnologías, de hecho, no tienen sistemas de tipos realmente completos. GraphQL es un buen ejemplo, lo tiene. Pero digamos que quieres almacenar una fecha, una fecha semántica o un formato particular de una fecha, o un SIMVIR, todas estas cosas. Bueno, el lenguaje no tiene esos primitivos incorporados. Necesitas agregarlos encima. Eso es en realidad un desafío.

En realidad, podría ser un problema. Y, por supuesto, si usamos SDK y demás, perderemos visibilidad como antes en el uso real del cliente. Y, por supuesto, si aceptamos estos problemas, ahora necesitamos una nueva forma de coordinar los cambios.

De acuerdo. Espero que hayas comenzado a ver un poco de un tema aquí. Y, obviamente, estas tecnologías nos brindan algunos beneficios que en realidad no resuelven este problema del que hemos estado hablando.

Entonces, volvamos a las lecciones que podemos aprender de todo esto y veamos si podemos entender por qué las pruebas de contrato impulsadas por el consumidor son tan efectivas para ayudarnos. El primer punto que quiero hacer es que su contrato de proveedor no es su API. Es solo una representación de su API. De hecho, cualquier cambio observable en el comportamiento y la API será considerado como un cambio rompedor por ciertos consumidores. Esta observación se conoce como la Ley de Hiram. Pero aunque no podemos hacer que esta ley desaparezca, podemos encontrar formas de reducir la ambigüedad. Y una de esas formas es incorporar la perspectiva del consumidor en la imagen, que es, por supuesto, cómo las pruebas de contrato y PACT pueden ayudarnos.

Usamos grabación y reproducción para probar los ejemplos representativos contra el proveedor real. Esto nos da confianza de que realmente funcionará, porque lo estamos probando. También obtenemos especificaciones mediante ejemplos para esto, porque eso es lo que estamos haciendo. Y eso reduce la ambigüedad. Ahora podemos ver cómo se supone que debe funcionar. Mejora la comprensión de la API. En realidad, podemos viajar en el tiempo en esa evolución del servicio, porque ahora conocemos las versiones de la aplicación y los contratos válidos entre ellas en cualquier momento. Así que podemos avanzar y retroceder en el tiempo. Podemos verificar si esta versión del consumidor puede leer mensajes de este productor y viceversa. Muy interesante. Codificamos esas preocupaciones de transporte en el contrato. Podemos hacer una coincidencia de tipos estrecha en el contrato. Y, por supuesto, porque tenemos todos los contratos, sabemos lo que están haciendo todos nuestros consumidores. Tenemos el área de superficie que nos brinda un mecanismo para evolucionar sin tener que hacer versiones.

Así que espero que puedas ver que las pruebas de contrato proporcionan este intercambio de datos generalizado que funciona en diferentes protocolos, transportes y tipos de contenido. Ya sea que estemos proporcionando APIs Restful a través de HTTP o protobufs a través de gRPC o Kafka, o ejecutando Avro en un sistema de archivos como parte de un pipeline de ETL de datos, el problema que estamos tratando de resolver es realmente el mismo. ¿Podemos comunicar datos entre múltiples versiones de aplicaciones en evolución? Si bien PACT no tiene soporte nativo para todas estas tecnologías de forma predeterminada, se puede ampliar mediante complementos.

Entonces, puedes escribir un complemento en el lenguaje que elijas para admitir cosas como transportes, protocolos o reglas de coincidencia. Y luego puedes distribuirlo a todos los lenguajes que admitan complementos. Hemos agregado ese soporte a PACT-JVM, por lo que Java, Kotlin y demás, PACT-Go, y hemos lanzado recientemente soporte beta para JS. Así que todos ustedes son los primeros en saberlo. Y el primer complemento oficial que creamos fue protobufs, por supuesto.

Aquí tienes un ejemplo de protobuf, o gRPC/protobuf que falla, donde el proveedor no ha coincidido con el tipo de contenido exacto del consumidor. Entonces, ¿cuáles son nuestras conclusiones aquí? La adopción de microservicios internos multiprotocolo se está acelerando. Y la falta de estandarización para el diseño y las pruebas está contribuyendo a los desafíos de los microservicios en general. Aprendimos sobre la Ley de Hiram y la necesidad de reducir la ambigüedad, y cómo, en realidad, nuestra API no es una especificación en sí misma, es solo una vista de la API. Y las pruebas de contrato son un enfoque que puede ayudar a reducir tanto la complejidad de nuestras pruebas como la ambigüedad inherente en esas especificaciones de la API. Y por último, vimos cómo PACT puede envolver todo esto en un flujo de trabajo estandarizado para probar esas comunicaciones de la API en diferentes lenguajes, transportes y protocolos.

Así que, muchas gracias por venir a mi charla. Espero que haya sido interesante y hayas aprendido algo. Si tienes alguna pregunta, no dudes en comunicarte conmigo a través de cualquiera de los canales a continuación y disfruta del resto de la conferencia. Gracias.