Hemos descansado lo suficiente, ¿qué sigue?

Hola a todos. Soy Ian Douglas. Soy un defensor de desarrolladores senior en Postman, y gracias por tenerme en TestJS. Voy a hacer una charla hoy comparando las API RESTful, arquitecturas impulsadas por eventos He estado en la industria tecnológica durante mucho tiempo. La mayoría de mis canas provienen de trabajar en más de una docena de startups y de tener dos adolescentes. He pasado más de ocho años en el espacio de defensa , cuatro años de los cuales estuvieron en educación, enseñando a las personas sobre software. Por otro lado, también estoy muy interesado en el entrenamiento de perros, la impresión en 3D, el coaching de career, y realmente me gustan los chistes realmente malos, así que verás algunos de esos en mis diapositivas también.

Así que esta es la rápida agenda que vamos a repasar. Voy a darles algunos antecedentes sobre las normas standards RESTful. Vamos a hablar sobre las APIs impulsadas por eventos como los web hooks y los web sockets, y luego vamos a hablar sobre las APIs de performance de baja latencia como gRPC.

Así que REST fue definido en 2000. Mucha gente que está trabajando en desarrollo de software hoy en día sabe qué son los servicios REST. El término servicios RESTful apareció poco después en unos pocos años, aunque no hay una forma muy fácil de determinar cuándo surgió el término en sí. Sucedió porque a la mayoría de los desarrolladores no les gustaba seguir reglas tan estrictas. Querían cierta flexibilidad en lo que construían. La mayoría de las escuelas hoy en día que están enseñando diseño de API design están enseñando diseño de API design RESTful, o están enseñando consumo de API con APIs RESTful principalmente. Postman en realidad tiene un programa de estudiantes donde trabajamos con escuelas para que los estudiantes usen Postman sobre otros tipos de arquitecturas de API, también. Por muy populares que hayan sido, las APIs RESTful parecen un poco atascadas en el territorio de la versión 1.1 de HTTP y necesitan mantenerse al día con la nueva tecnología. Empresas como Google empezaron a introducir nuevos protocolos como speedy, que fue la base básica para HTTP 2.0. Por ejemplo, en HTTP 1, es un poco como una llamada telefónica donde llamo a alguien y le hago una sola pregunta, obtengo una sola respuesta y luego colgamos el teléfono. La próxima vez que necesite llamar a alguien y obtener más información, tengo que llamar, identificarme, hacer mi pregunta, obtener mi respuesta y colgar. Otro problema con HTTP 1 es que no hay forma de interrumpir a un cliente. Si un cliente se conecta a un servidor y dice, me gustaría subir algunos data, el servidor puede decir okay, y el servidor puede simplemente enviar gigabytes o terabytes de data antes de que el servidor tenga permiso para interrumpir y decir, espera, no puedo procesar todos los data que acabas de enviar. También tenemos un problema en las tecnologías RESTful que llamamos subextracción o sobreextracción, que es donde no tenemos formas eficientes de enviar data. Estamos enviando demasiado data y esperando que nuestros front ends oculten ese data, lo que puede llevar a problemas de security, o no enviamos suficiente data, lo que significa que tengo que hacer más y más de estas conexiones de nuevo. Así que tecnologías como GraphQL aparecieron en la escena, permitiendo al cliente especificar qué campos devolver como parte de la solicitud. Esto podría suceder en REST con parámetros, pero es un poco más difícil de hacer eso y pone un poco más de trabajo en el desarrollador para ser capaz de implementar qué campos enviar de vuelta como parte de un parámetro de consulta, por ejemplo.

Si has estado trabajando con desarrollo de front-end y tecnologías de front-end, probablemente has trabajado con WebSockets o cualquier tipo de característica colaborativa, como un sistema de mensajes de chat o aplicaciones impulsadas por eventos como juegos. Así que, voy a darles una rápida lección sobre WebSockets y WebHooks mientras miramos la arquitectura impulsada por eventos por un momento. La idea de las APIs asíncronas es que están impulsadas por eventos. Hay dos métodos clásicos, WebHooks y WebSockets, como mencioné. Todavía están basados en HTTP, y por lo tanto hacen una conexión, transfieren data, y luego se desconectan. Sin embargo, los WebSockets, a diferencia de las APIs RESTful y los WebHooks, pueden mantener una conexión abierta durante un largo período de tiempo, y cualquiera de los lados puede enviar data de ida y vuelta en cualquier momento. Y por lo tanto permite el procesamiento impulsado por eventos, que cuando algo sucede, puedes transmitirlo a través de una conexión que ya está abierta. Los desarrolladores no necesariamente necesitan pausar y esperar una respuesta antes de continuar trabajando. Así que puedo enviar una solicitud, y luego puedo continuar mi ciclo de eventos, esperando por otra interacción del usuario y esperar a que esa respuesta regrese. Así que, los ciclos de eventos como las promesas y otros mecanismos llamados async y await permiten a los desarrolladores elegir cuándo pausar la ejecución para esperar una respuesta o simplemente procesarla en segundo plano.

Normalmente, vemos los webhooks utilizados en un mecanismo de respuesta. Por ejemplo, alguien paga una factura con algo como PayPal. PayPal puede llamar a un webhook que usted especifica que puede tomar alguna otra acción como actualizar su sistema CRM. Como se mencionó anteriormente, los web sockets se utilizan comúnmente para aplicaciones más en tiempo real donde necesita mantener esa conexión abierta y tener una conversación. Puede ser necesario intercambiar cierta cantidad de estado al conectar o reconectar para reanudar donde lo dejó por última vez, como, en un mecanismo de chat, qué mensaje vimos la última vez para operaciones en tiempo real?

GraphQL también tiene algo ahora llamado transmisión de data que llaman suscripciones. Es un poco como un patrón de publicar-suscribir, que a veces llamamos PubSub. Hay otras opciones aquí, incluyendo mecanismos más nuevos llamados eventos enviados por el servidor, donde los servidores pueden enviar data a un cliente. De nuevo, porque estos canales asíncronos se mantienen abiertos durante un largo período de tiempo. Aún así, lo asíncrono tiene algunos problemas. Puede ser más difícil de design y planificar ya que no sabes qué eventos están sucediendo en ningún orden particular. Así que podrías necesitar reconciliar tus data en ambos extremos de la conexión para asegurarte de que todo se completó. Los mecanismos de webhook necesitan asegurarse de que cualquier sistema que lo llame pueda realmente enrutar a el servidor, lo cual es complicado cuando estás lidiando con mecanismos de red internos o pasarelas de API y así sucesivamente. Hay otros problemas que puedes encontrar con lo asíncrono, incluyendo la limitación de la tasa y el estrangulamiento de data, lo cual puede ser más desafiante.

Así que voy a hacer una pausa en esta pantalla por un momento si quieres mirar algunas diferencias primarias entre las API RESTful y las API asíncronas en cuanto a mecanismos de transferencia de data y complejidad de design y así sucesivamente. Las API asíncronas, tradicionalmente WebSockets, van a estar construidas principalmente en la versión HTTP dos. Los webhooks todavía pueden estar actuando como API RESTful y todavía usando HTTP 1.1. Pero en las API asíncronas, obteniendo esa respuesta, el cliente proporciona un medio para responder más tarde o ser interrumpido más tarde cuando un evento ha sucedido. Pero eso aumenta tu complejidad de design. Y el orden en que tus solicitudes y respuestas están volviendo no siempre es predecible y puede que necesite haber alguna reconciliación más tarde.

Así que hablemos sobre el rendimiento de la API y algunas cosas a tener en cuenta si necesitamos tomar lo mejor de las API RESTful y las API asíncronas. Por supuesto, podríamos escalar nuestro hardware y añadir más sistemas para manejar la carga. Y eso ayudará un poco en el lado del rendimiento, pero plantea otras preocupaciones y problemas, especialmente con el costo de los proveedores de computación en la nube. Entonces, ¿cómo podemos combinar lo mejor de las arquitecturas de API que hemos mencionado hasta ahora, como controlar nuestros data, pero también manejar cosas como data transmitido o tener conexiones de larga duración? ¿Qué pasaría si hubiera un tipo de API que nos diera la flexibilidad de una única solicitud de respuesta como REST o la capacidad de transmitir data en cualquier dirección, del cliente al servidor o ambos, y también permitir que esas conexiones permanezcan abiertas durante largos períodos de tiempo, pero también te dé un gran impulso de rendimiento para acelerar mientras minimizas tu rendimiento de data? Así que tomando lo mejor de todas estas cosas juntas, y podemos mirar a gRPC. Así que gRPC fue desarrollado por Google y está construido sobre la versión HTTP 2. Esto permite esas conexiones de larga duración, similar a los web sockets, y utiliza un enfoque de data binario por defecto. Todavía es un trabajo en progreso. No hay demasiadas API gRPC de cara al público por ahí. Pero estamos viendo mucho crecimiento. Otra área de crecimiento que estamos viendo es una biblioteca de JavaScript llamada gRPC web, que te permitirá conectarte a servidores gRPC desde aplicaciones web, donde principalmente fue introducido para ser comunicación de microservicios de servidor a servidor. gRPC tiene cuatro diferentes mecanismos de transferencia de data.

El primero es muy parecido a una API RESTful de una única solicitud, una única respuesta, y luego una desconexión. Los otros son una combinación de que el cliente quiere transmitir un montón de data al servidor o el servidor transmitiendo un montón de data al cliente, o transmitiendo en ambas direcciones. La idea de transmitir aquí es que puedes enviar múltiples solicitudes o respuestas en cualquier momento a medida que ocurren eventos en ambos extremos de la conexión.

Debido a todo esto, junto con cierta compresión incorporada, gRPC es típicamente de siete a diez veces más eficiente que las API RESTful, principalmente debido a la versión HTTP 2, y eso permite mucha de la comunicación de ida y vuelta entre el cliente y el servidor antes de desconectar.

Entonces podrías estar diciendo, bueno, gRPC es solo para el nivel de sistema o desde un dispositivo móvil a un servidor. Pero de nuevo, esta biblioteca web gRPC, fue introducida hace un tiempo, fue puesta en disponibilidad general hace cinco años en 2018. La biblioteca ha tenido mucho trabajo en ella, es bastante robusta, y hay varios ejemplos por ahí para implementar gRPC en frameworks como React y Vue, WebAssembly y Blazor, y más. gRPC tiene todo lo que necesitamos, colectivamente para reemplazar potencialmente REST y WebSockets en aplicaciones de front-end con una única architecture, y las data estructuras son de tipo estático. Así que si la biblioteca del cliente la desempaqueta, puedes confiar en que la data validation ya ha ocurrido, no necesitas validar si este atributo es realmente una cadena, es este atributo realmente un número. Si el cliente gRPC es capaz de desempaquetar esa data payload, ya ha hecho esa validation por ti. Y comienza a enviar un error de vuelta a lo que envió ese mensaje diciendo que no puedo procesar eso.

Todo esto es bastante nuevo, sin embargo. Y necesitamos que más personas comiencen a usar esta tecnología y ayuden con la documentation y ejemplos y comiencen a hacer aplicaciones reales para este proceso web gRPC para realmente tomar hold. Así que de nuevo, voy a hacer una pausa aquí por un momento y puedes ver algunas de las diferencias entre las API RESTful y las API gRPC. Las API gRPC tienen mucha similitud con las API asíncronas, pero te dan este extra performance boost. Así que de nuevo, está construido en la parte superior de la versión HTTP dos. Obteniendo una respuesta, puedes hacerla síncrona como REST. Puedes hacerla asíncrona como webhooks. Pero la design complejidad es generalmente mucho más alta. No permite la flexibilidad para lo que envías en el mensaje. Es un formato de mensaje muy rígido. Y como vimos entre REST y RESTful, algunos desarrolladores quieren más de esa flexibilidad. Hay algunos data tipos que permiten la provisión para esto dentro del formato binario que envías estos mensajes llamados protocol buffers que permitirán diferentes tipos de data para ser enviados o puedes simplemente enviar cosas como largas cadenas y hacer tu propia codificación y decodificación.

El caso de uso típico de gRPC ha sido tradicionalmente mobile apps y comunicación de servidor a servidor para cosas como registro de eventos y así sucesivamente, o para juegos móviles, pero con la biblioteca web gRPC, hay mucha flexibilidad aquí para ahora introducir esto como algo para trabajar en el front end también. De nuevo, porque esa data estructura es un formato binario usando protocol buffers o proto buffs como podrías escucharlos referidos, obtienes un gran performance boost y esa data validation ya está cuidada, lo que simplifica tu código.

La pregunta aquí entonces es, bueno, ¿no podríamos simplemente implementar una API RESTful en la parte superior de HTTP2 y ganar algunos de esos beneficios que vimos entre Websockets y gRPC y webhooks? Es como, sí, podrías si quieres construir eso. GraphQL es un poco de REST y gRPC con cargas útiles JSON donde puedes decirle a GraphQL, quiero llamar a esta instrucción y quiero que estos campos vuelvan, y con su nuevo proceso de suscripción es un poco como asíncrono también con ese patrón PubSub donde puedes suscribirte a diferentes canales y obtener eventos de vuelta del servidor a medida que ocurren. ¿Podríamos usar un formato binario en una API RESTful que haga cumplir los data tipos? Absolutamente. De hecho, puedes usar protocol buffers dentro de una API RESTful si quieres. Solo tienes que asegurarte de que cada cliente que se conecta sabe cómo desempaquetar el formato de mensaje protobuf y también lidiar con la rigidez del mensaje tiene que ser enviado en este formato.

Ahora, en el protobuf, puedes especificar que algunos campos son opcionales. Por lo tanto, no tienen que estar allí. Y de nuevo, puedes hacer tu propia codificación y decodificación, pero eso podría tener otras implicaciones en la eficiencia y el rendimiento de tu software.

Lo bueno de gRPC es que en realidad tiene un mecanismo de descubrimiento incorporado que permite a los clientes aprender sobre los payloads de mensajes de la API, así como los diferentes tipos de instrucciones que se pueden llamar. Ahora, normalmente esta introspección se desactiva en producción, pero mientras estás en modo de desarrollo o en modo de preparación, podrías activar esta introspección y ser capaz de recopilar datos del servidor en cuanto a lo que es posible, ¿qué métodos puedo llamar? ¿Cuáles son estos formatos de datos? ¿Cómo envío estos datos?

Otra pregunta es, ¿podríamos simplemente implementar algo como una arquitectura orientada a eventos usando REST? Más o menos, pero seguiría siendo un ciclo de solicitud y respuesta único debido a la versión HTTP uno y simular un flujo de datos entrantes es técnicamente posible. Así es como hemos gestionado el contenido en streaming durante algunas décadas, pero tiende a ser más construido en UDP para mecanismos de streaming para cosas como video y audio. Parte de la versión HTTP dos es que tus datos están cifrados por defecto. Con HTTP uno, tienes que construir tu propio cifrado o confiar en cosas como TLS. Así que podrías añadir otras capas de cifrado a esos datos también. De hecho, animamos a todos, por favor, cifren sus datos.

Hasta ahora, sin embargo, construir todas estas cosas y tener en cuenta todas estas cosas, has aumentado la complejidad de tu diseño de API bastante. Has hecho tu despliegue y tu gestión mucho más complejos, y probablemente has hecho tu infraestructura más compleja. Entonces, ¿realmente vale la pena? Elegir una arquitectura de API es un equilibrio delicado de rendimiento. Pero, ¿qué significa realmente el rendimiento? Cuando pensamos en la evolución entre la versión HTTP 1 y la versión 2 y las mejoras que se hicieron allí con las conexiones de larga duración y los formatos binarios y demás, y mirando hacia adelante a lo que va a ser el rendimiento de la versión HTTP 3, en realidad va a ser bastante interesante.

Así que hablemos por un momento de la versión HTTP 3. En realidad, se basa en un nuevo protocolo llamado QUIC, Q-U-I-C, y solo se construye en UDP. No se va a construir en TCP. Esto va a reducir parte del ruido de la comunicación, porque para cada paquete enviado, no tienes que esperar a que vuelva una respuesta. Va a tener una nueva gestión de sesiones incorporada para imitar las llamadas sin estado mientras sigue conservando los métodos HTTP, los encabezados y los sistemas de códigos de estado que hemos estado usando durante bastante tiempo ahora. De hecho, ha sido soportado ahora desde 2020 y 2021 en la mayoría de los navegadores principales. De hecho, la mayoría de las bibliotecas de clientes ya están soportando completamente HTTP 3. La última vez que lo comprobé, la única que no lo estaba soportando era la biblioteca Curl, que sigue siendo una biblioteca bastante importante.

Así que cuando se trata de rendimiento, lo otro en lo que pensar es ¿qué tan rápido puede el equipo trabajar en esto? Así que tengo algunas notas en esta diapositiva que básicamente dicen que soy un fan de los equipos que aprenden algo nuevo, pero si tu empresa necesita sacar algo rápidamente, ¿son estas tecnologías algo que tu equipo ya conoce? ¿O tu equipo va a tener que aprender esto? ¿Tu equipo de DevOps ya sabe cómo construir este tipo de infraestructura para soportar HTTP 2 o HTTP 3? Así que cuando pensamos en rendimiento, a menudo pensamos en el rendimiento del software. Pero, ¿qué pasa con el rendimiento del equipo y la cantidad de tiempo que le lleva al equipo construir lo que necesita construir? ¿Esa infraestructura ya está en su lugar? ¿Ya saben cómo configurar estas cosas? ¿O hay un camino de migración más fácil para el rendimiento en lugar de una reescritura total en alguna nueva arquitectura? Así que todas estas son cosas muy interesantes en las que pensar cuando pensamos en diferentes tipos de arquitecturas de API. Cuando pensamos en la historia de REST, y pasamos a las API asíncronas y las API orientadas a eventos cuando hablamos de cosas como WebSockets y Webhooks, pero también considerando el rendimiento de cosas como gRPC. Así que espero que este fondo haya sido útil. Estoy feliz de responder a cualquier pregunta que tengas. Mi nombre de usuario en la mayoría de las plataformas sociales, incluyendo LinkedIn y Twitter es iandouglas736. Si quieres hacer más preguntas, el código QR que ves en esta diapositiva también te llevará a toda mi información de contacto. Así que gracias de nuevo a todos en Test.js por tenerme hoy, y no dudes en ponerte en contacto con preguntas. Gracias por tu tiempo.