APIs están Evolucionando. Otra vez.

Hola a todos, soy Matteo. {{^}}Hola a todos, soy Luca. Bienvenidos a JS Nation, y estamos muy felices de estar aquí. Después de 6 años juntos. Después de 6 años en las mismas ubicaciones, lo que sea, diferentes conferencias, diferente tiempo, es fantástico.

Así que antes de comenzar, en aras de la brevedad, saben que solo tenemos 20 minutos, hemos abreviado algunos pasos de la historia, así que si no es perfecto, no es correcto, por favor háganoslo saber, pero está bien, ¿de acuerdo?

Así que quería comenzar todo diciéndoles que la tecnología es realmente una espiral. Cada generación de tecnología, saben, la implementación cambia todo el tiempo, ya saben. Hace unos años estábamos programando en COBOL, ahora estamos programando en Typescript, o Zig, o Rust, o lo que sea. Pero la mayoría de las veces, las ideas fundamentales no lo hacen. De hecho, regresan y regresan y regresan. Saben que MVC fue inventado por Smalltalk hace unos años, ¿verdad? Como COBOL, también. COBOL.

Y, bueno, estábamos hablando de COBOL, y el más grande, nuestro buen amigo, el monolito. ¿Cuántos de ustedes aman programar en muy bonitos monolitos para su aplicación? ¡Yay! No sean tímidos, no sean tímidos. Está bien, está bien. Y así, sí, el monolito. Y, miren, una vez en el mundo de las APIs, existía Java. Y esto es JS Nation, es una conferencia de JavaScript. Pero, ya saben, no el grano de café o la isla. No sé, ¿sabían? Saben que en Ámsterdam tenemos la Isla Java, está justo allí. Pero no es donde crearon Java, por cierto. Está bien. Así que, gracias. Todo comenzó con la programación de aplicaciones, ¿verdad?, en Java. Todos sabemos cómo comenzó, con tu hermoso IDE, presionas el botón mágico de construir o reproducir, y creas un archivo war. Bueno, sí, al final del día es solo un tarball. Y luego copias por SSH o simplemente arrastras y sueltas, si estás en Windows, y lo pones en tu servidor de aplicaciones, ¿verdad? Así es como comenzó todo. Y Java es una tecnología fenomenal que cambió enormemente la forma en que vemos las aplicaciones empresariales, pero es un poco lenta, mecánica, requiere mucho mantenimiento, pero puede llevarte de A a B. No hay problema. Todos ya hemos estado allí, ¿verdad?

Pero en ese momento se llamaban servicios web, y todos hemos pasado por la hermosa fase de tener tu archivo Weasel. ¿Cuántos de ustedes han codificado un Weasel en su vida? Muchos grippears están aquí.

Bien, algunos de ustedes. Sí, ya saben, se llama la estrella WS, y no sé, cuando estábamos en la universidad nos burlábamos de esto y lo llamábamos esa estrella. Así que por eso está el escritorio detrás. Bien, lo siento, no expliqué esto, porque la gente me dijo que no estaba claro.

Y todos construimos, también luego sé el análisis de SOAP, porque todo era XML, ¿verdad? Y en el lado de la interfaz de usuario, la ecuación era un poco diferente. Todo se construía del lado del servidor, y renderizado del lado del servidor, y usábamos tomcat. El modelo que implementamos era un modelo muy monolítico, como dijo Matteo, porque teníamos una única unidad de despliegue, pero era multi-hilo y sincrónico. Así que cuando estaba, hace unos años, estaba estudiando mi doctorado, y nosotros, y eché un vistazo a esta tesis fantástica. Estaba la tesis de Roy Fielding, que fue uno de los pioneros de lo que llamamos la web. Teorizó esta pequeña cosa llamada Transferencia de Estado Representacional, o también conocido como REST. Es genial, ¿verdad? También, por esa época, esto fue el año 2000, alrededor del año 2001 y así, comenzamos a ver otra bonita invención en el mundo. JSON.

¿Cuántos de ustedes usan JSON hoy en día? Lo están levantando. No veo suficientes manos levantadas. Bien, están usando XML en el fondo del estado. Sé que están usando XML. Los duros de matar. Los duros de matar. Pero, en 2004, tuvimos otra gran invención en el mundo de la web, que fue Ruby on Rails. No sé cuántos de ustedes quedaron asombrados cuando salió Rails y fue capaz de, oh, en realidad puedo construir un sitio web o una cosa fantástica en 20 minutos, como fue asombroso. Y hicimos plantillas HTML fantásticas con ERB y otra tecnología agradable llamada PrototypeJS, que fue un éxito. Y es scriptaculous, lo que sea. No sé cuántos de ustedes estuvieron allí en ese momento. Pero es una gran tecnología. Y eso, la experiencia del desarrollador de construir APIs y sitios web, se trataba de los datos, así que comenzaste a generar tu migración para tu base de datos. Luego estas cosas se generaban automáticamente, y más o menos obtienes un buen andamiaje de HTML, tu controlador, archivos ERB, y toda una agradable API REST CRUD. Todo esto era como, no sé, a un comentario de distancia. ¿Dónde perdimos la capacidad de generar un sitio web completo con una buena API para él en un comentario? No sé cuánto tiempo te lleva hacer eso hoy en día, pero no es en absoluto lo que hace REST.

Sin embargo, Ruby on Rails, especialmente mi experiencia, fue una tecnología fantástica para moverse muy rápido de A a B, y en realidad lento de B a C. Querías llegar a C, pero si vas en los Rails, oh, súper alta velocidad, entonces necesitas salirte un poco de los Rails. Luego empezaste a ir un poco más lento. Necesitas descarrilarte. Sí, bueno, un poco.

Así que, en ese momento, también obtuvimos la mejor experiencia de desarrollador para desplegar cosas. Y de nuevo, asombrado. Antes de eso, era súper difícil. Cuando salió Rokon y podías realmente hacer git push a un repositorio, y podías desplegar tus cosas. ¿Cuántos de ustedes hacen git push para desplegar hoy en día? Bien. Deberían agradecer a estos chicos. Y podías desplegar a cualquier extremo, para ser honesto, pero es increíble. Fue una experiencia de desarrollador increíble, y probablemente todavía la mejor que puedes obtener. Todos querían copiar esto.

En el núcleo de estas cosas, y mientras antes, con Java y esas otras cosas, estábamos haciendo estos grandes servidores de aplicaciones. Ahora la nube comenzó a elevar la ejecución de nuestros servicios, y comenzamos a tener este agradable proxy inverso en su lugar, y estos agradables perfiles para definir qué ver. Muchos de ustedes no saben eso, pero no se preocupen. Y tenemos múltiples procesos para cada máquina ejecutando todas estas cosas. Es una arquitectura muy simple, pero en realidad muy efectiva. Aún así, estaríamos haciendo programación sincrónica. ¿Qué significa eso? Recibe una solicitud, procesa esa solicitud antes de hacer la siguiente.

Sin embargo, esta es la conferencia JS Nation, y cualquier aplicación que pueda ser escrita en JavaScript eventualmente será escrita en JavaScript. Así que gracias, Jeff, y este fue esencialmente el momento en que Node llegó a ser. Y en 2009, Node.js comenzó a cambiar la forma en que construimos cosas para la web. Cuando vi la primera demostración de Node.js, dije, no, esta es la tecnología para las próximas dos décadas, al menos, y me subí a ese tren, aunque no sabía nada sobre JavaScript. Soy ingeniero mecánico de profesión. No sabía nada sobre JavaScript. Y C++. Esa es una historia diferente. mecanismo de transporte, Node.js es un pequeño SUV que puedes mover de A a C.

mecanismo de transporte, Node.js es un pequeño SUV que puedes mover de A a C. No vas súper rápido. Puedes usar Node.js para hacer cosas muy personalizadas y moverte rápido mientras lo haces. Hay, no sé, millones de módulos en MPM ahora. Muchas vulnerabilidades, probablemente, pero ese es un tema diferente. Y nos dijeron en ese momento que debido a que Node.js tiene este enorme bucle de eventos, podemos ser de un solo hilo. Y, ya sabes, ejecutar muchas, muchas solicitudes por segundo en paralelo en un proceso dado. ¡Guau! No lo sé. Es súper fantástico, ¿verdad? Y, entonces... ¡Bam, bam! Entonces, ¿qué hicimos? ¡Y bam! Rompimos el monolito. ¡Sí! Finalmente, el monolito se rompió en pedazos y, ya sabes, todos estamos familiarizados con el concepto de dividir y conquistar, ¿verdad?

Y este viaje nos llevó básicamente a encontrarnos con tecnologías como Docker y más recientemente el service mesh, ¿verdad? Creo que todos están familiarizados con ambos conceptos. Y esos dos conceptos, en realidad, llevaron a una falsa promesa. Que funciona en mi máquina. Y creo que todos están familiarizados con el meme, ¿verdad? Que funciona en mi máquina, entonces enviaremos tu máquina, ¿verdad? Porque seamos honestos. Docker no funciona en tu máquina y en la nube de la misma manera, ¿verdad? Es un gran ejercicio de marketing, pero esta promesa en realidad comenzó a desencadenar muchas más reflexiones e ideas sobre cómo podría evolucionar este espacio.

Mientras tanto, el frontend estaba cambiando. Todos saben a lo que me refiero, ¿verdad? Comenzamos a desacoplar. Así que ahora tienes el frontend y la lógica de negocio, la aplicación de una sola página comenzó a crecer. El móvil creció enormemente. Y así este viaje nos llevó de tener esta aplicación monolítica a un sistema distribuido, pero muy probablemente a la transformación a REST APIs.

Y la mayoría de las veces lo que sucedió en realidad es que simplemente renderizas lo que está en tu base de datos desde el lado del servidor. En este viaje, claramente todos estamos familiarizados con probablemente la mayor revolución y jugador que Vercel y NeXT pusieron en marcha, porque realmente trajeron esa experiencia que se perdió en este viaje del backend al frontend. Dijeron que podemos simplemente tener un git push, desplegar tu aplicación, y puedes pasar de cero a producción en poco tiempo. Pero, ¿qué pasa con los desarrolladores de backend? Yo era un desarrollador de backend, Matteo era un desarrollador de backend, todos hemos estado allí, y dijimos a dónde diablos se fue, este viaje, esta experiencia? Y así todos estábamos en medio de ser transformados en un sistema distribuidor.

Y como ingeniero de sistemas distribuidores y como muchos de ustedes, sé exactamente que un sistema distribuidor es extremadamente complicado porque la coordinación es un gran desafío. ¿Estás de acuerdo con eso? La coordinación lo es todo, ¿verdad? Y así vimos el viaje siendo tomado desde el lado del operador. Así que vimos herramientas como el Service Mesh. Puedo poner un sidecar en tu aplicación y darte todas las funcionalidades. Como, por ejemplo, el trazado distribuidor porque es bastante miserable cuando tienes cien microservicios y alguien te llama a las 2 AM en la noche y dice que algo está roto y necesitas ir y profundizar en cien microservicios. Y vimos el auge y caída de los registros. Todas las herramientas de operadores, pero ¿dónde están los desarrolladores? ¿Dónde están los habilitadores de eso? Porque todavía falta una herramienta que permita a los desarrolladores construir, gestionar y escalar microservicios sin dolor. ¿Y cómo podemos realmente devolver esta alegría al desarrollo de APIs? Sí.

Bueno, ya sabes... En algún momento del año pasado, decidimos que íbamos a fundar una empresa. Así que entra Platformatic. Y mira, estamos ayudando a los desarrolladores a deshacerse de todo el trabajo pesado no diferenciador de construir aplicaciones Node.js. Y lo que queremos alcanzar es la misma velocidad que experimenté hace unos años cuando comencé con Rails, con la flexibilidad de Node.js al mismo tiempo. Así que, esto ya no está funcionando por alguna razón. No producimos baterías. Ese es el problema. Sí. Lo siento. Pasó. Bien.

Bien. De acuerdo. Lo siento. Lo siento por eso. De acuerdo. Entonces, un poco de Mischa. Y, lo siento. ¿Por qué esto no está? ¿Puedes? De acuerdo. Lo siento. Sigues... Explotó. De acuerdo. Bien. De acuerdo.

Entonces, es todo de código abierto. Y, es todo de código abierto. Y, se apoya en los hombros de gigantes. Está construido sobre un framework llamado Fastify. Entonces, no sé. Échale un vistazo. Escribí la cosa hace unos años. Y, otra cosa llamada Node. Entonces, también, está compuesto de algunas cosas. Y, la primera es el servicio de Platformatic. Entonces, básicamente, agrupa todas las cosas que necesitas para construir APIs hoy. Open API, soporte para GraphQL, REST. Pero también tiene métricas personalizadas, registros. Te protege del event loop, ya sabes, aplicaciones mesh, lo cual es muy bueno. Y, hace soporte para TypeScript y recarga automática de módulos, así como verificaciones L. También construimos una cosa llamada PlatformaticDB, que es fantástica para construir APIs realmente, realmente rápido.

Porque si simplemente creas tu migración, y después de haber creado tu migración, podrías terminarlo y crear tus APIs. También, soporta múltiples bases de datos, y así sucesivamente. Es realmente muy fácil de usar y deberías darle una oportunidad.

Ahora, ya sabes, todo esto es para construir monolitos, ¿verdad? Has construido una cosa, y un servicio o un PlatformaticDB, esos son solo monolitos. Y ahora estamos presentando algo nuevo. Estamos presentando el Composer. Así que quieres, como, estábamos preguntando a muchos desarrolladores, y todos nos dijeron, bueno, realmente nos gusta REST. Y comenzamos a decir, oh, está bien, pero ¿cómo podemos combinar múltiples servicios REST muy fácilmente? Bueno, el Composer te permite combinar múltiples APIs construidas en REST y OpenAPI y exponerlas como un solo endpoint, más o menos, eliminando el patrón de backend, frontend. También maneja muchas cosas agradables que, ya sabes, hacen que este tipo de cosas sean muy desagradables de hacer, y nosotros simplemente nos encargamos y lo hacemos por ti, así que no hay problema. Simplemente funciona desde el primer momento. Sí.

También estamos lanzando una nueva tecnología llamada Platformatic Runtime. Y es... Sí, esto es... No es correcto. Lo que sea. No es correcto. Bien. De todos modos, el Platformatic Runtime es una nueva tecnología que te permite ejecutar múltiples frontend...múltiples aplicaciones dentro del mismo Node.js Runtime. Es parte del nuevo Platformatic Cloud, y crea cosas...te permite ejecutarlas todas juntas. Más sobre eso más tarde. Un déjà vu. Un déjà vu. Y porque sabemos que gestionar sistemas distribuidos puede ser muy doloroso, en realidad decidimos tomar una dirección diferente a un service mesh, y dijimos, en realidad podemos crear un sistema, un gráfico, sobre todo este conjunto de microservicios, y básicamente crear un sistema de taxonomía generativa que permite hacer múltiples y interesantes cosas. Así que podríamos tener resolución de conflictos de dependencias, o básicamente tener un orden topológico de servicios, y son todas cosas que más o menos hemos pasado al construir sistemas distribuidos y microservicios. Y así, cuando dije que es un déjà vu, se siente como si estuviéramos dando un paso atrás, ¿verdad? Comenzamos toda esta conversación con Java y el despliegue a un servidor de aplicaciones, y se siente como si estuviéramos yendo a donde Matteo nos estaba llevando al principio, a un círculo. Y en realidad notamos en este viaje que en realidad había una oportunidad de evolucionar lo que estaba estandarizado y más como el status quo para construir microservicios Node.js. Pero queríamos hacerlo de una manera moderna, en una arquitectura moderna. Así que... No está transmitiendo al...

Entonces... Bien. Y así, en realidad decidimos transformar microservicios en nanoservicios. Y esto es gracias a lo que Matteo estaba diciendo sobre el runtime. En realidad, podemos juntar una multitud de servicios y desplegarlos como una sola unidad dentro del runtime y luego trasladar el runtime directamente a cualquier máquina. Y este runtime, gracias a la taxonomía y todas las otras cosas que acabamos de ver, en realidad está creando una malla virtual entre ambos sistemas.

Así que es una superposición, pero no es una superposición con un sidecar. Así que una de las características clave del Platformatic Runtime es que los servicios no son automáticamente accesibles a través de Internet. Estamos esencialmente interconectándolos automáticamente usando algunas tecnologías que hemos desarrollado a lo largo de los años y también es compatible con la API estándar fetch, por lo que podrías simplemente fetch y en lugar de pasar por una ruta completa de HTTP, todo se enruta dentro del mismo proceso, como en una malla virtual en el mismo proceso. Es realmente genial.

Así que es genial, ¿verdad? ¿Y qué quieres decir, Luca? Que finalmente funciona en mi máquina, tu máquina, nuestra nube o tu nube, así que finalmente podemos hacerlo funcionar en todas partes. Así que sabes, hoy estamos lanzando nuestra nube y podrías desplegar todo esto en Platformatic.cloud. Y desde cero de forma gratuita, si solo quieres cosas básicas, o si necesitas un nombre de dominio o alguna otra cosa así, por $99. Es dólar, no euro, así que sabes, si te importan esas cosas. Y lo que realmente pensamos que era más justo para los desarrolladores, era realmente cobrar por lo que realmente importa. Que es la potencia de cómputo. Así que echamos un vistazo a historias de éxito, como donde Mateo nos llevó con Roku y dijimos que estos desarrolladores deberían poder colaborar y trabajar juntos en la construcción de esas aplicaciones y solo deberíamos cobrar por unidad de cómputo.

Oh, pero ¿no dijimos que todo de lo que hablé es solo de código abierto? Bueno, tenemos una sorpresa. Vamos a hacer un lanzamiento en el escenario. ¿Feliz? Aquí vamos. ¿Estás listo? ¿Listo? Sí. ¿Lo hacemos? ¿Lo hacemos? Abrámoslo. Abrámoslo. ¿Estás listo, Luca? ¡Vamos, presiona! ¡AAAAHHHHHHHHH!!! Así que, genial. Todo está disponible ahora. Visítanos en platformatic.dev. Ha sido lanzado mientras hablamos. Las acciones de GitHub están haciendo su trabajo. Así que dale tiempo para levantarse, no para aparecer. Así que vamos a ello.

Está todo disponible ahora. Visítanos en platformatic.dev. Ha sido lanzado mientras hablamos. Las acciones de GitHub están haciendo su trabajo. Así que dale tiempo para levantarse, no para aparecer. Así que vamos a ello.

Está en vivo. Está en vivo. Está en vivo. Si no te estás levantando, está bien. Nos aseguraremos de que te pongas en marcha. Está en vivo. Si no te estás levantando, está bien. Nos aseguraremos de que te pongas en marcha. Nos aseguraremos de que estés en marcha. Mientras hablamos, las acciones de GitHub están haciendo su trabajo. Así que dale tiempo para levantarse, no para fallar y para desplegar nuestras cosas porque realmente lo desplegamos ahora mismo. Totalmente en vivo, así que, ya sabes, podría haber fallado pero a lo grande. Así que veremos. Codificación en vivo definitiva. Haciendo un lanzamiento de, no sé, un año de trabajo en el escenario. Con un lanzamiento nuclear. Por supuesto. Maletín. Genial. Gracias a todos. Gracias. Y no olvides mirar y revisar nuestro sitio web.

Te voy a pedir que te unas a mí en la esquina de preguntas y respuestas. Está bien.

Fantástico. Donde voy a poner todos mis dispositivos. Muy bien. Así que tenemos un par de preguntas de la audiencia. Me encanta. Muy bien. Así que si tienes algunas preguntas para Luca y Matteo, por favor, sigue enviándolas. También puedes ponerte delante del bloque. También soy alto. Sí, vivir en los Países Bajos no ayudó a mi altura. No pasa nada.

Así que veamos un par de preguntas. Entonces, hay la pregunta de si realmente es gratis y de código abierto y cuál es la trampa. 100% gratis y de código abierto. No hay trampa. No hay trampa. Perfecto. Eso es lo que queremos oír. ¿Cuáles son los beneficios de tener tal granularidad de nano servicios sobre los microservices convencionales? El beneficio es que puedes muy rápidamente como si estuvieras usando microservice tradicional necesitas esencialmente lidiar con el despliegue de cada uno de ellos. Y por lo tanto necesitas si estás haciendo microservice correctamente estás gestionándolos como unidad de despliegue independiente. Y por lo tanto hay mucho terraform y ambiente de CI para desplegar cada uno de ellos. Un sistema como el nuestro es en realidad muy sencillo y porque es nano dentro del mismo proceso no tienes que lidiar con él puedes simplemente desplegar una vez y tienes una única tubería de despliegue.

Perfecto, también tuvimos una pregunta sobre que hablaste mucho sobre la developer experience. ¿Qué pasa con la UX? ¿Qué pasa con? User experience. User experience. Hacemos APIs, vale, soy un ingeniero de back-end. Así que si los cofundadores son ingenieros de back-end también tenemos un fantástico desarrollador de front-end y diseñador para hacer nuestro trabajo así que sí, esa es probablemente la respuesta. Probablemente sea interesante saber que en realidad abordamos ambos lados así que tienes una experiencia más de ingeniero de back-end CLI y también puedes abordar lo mismo a través de nuestra UI y la UI que ves en tu máquina local es lo que ves en nuestra cloud en tu cloud. Solo queremos tener una experiencia fluida. Una de las mejores cosas para los desarrolladores de front-end es que ofrecemos una generación automática de clientes para que puedas usar las APIs consumibles de Platformatic desde tu aplicación de front-end de React o Vue muy, muy fácilmente.

Muy bien, tenemos una pregunta ¿dónde entra en juego la prueba de contrato testing? Prueba de contrato testing. Así que esto es realmente interesante. Tendrás que... ¿Puedo decir algo? Sí, adelante. Probablemente tendrás que esperar a nuestro próximo lanzamiento, lo siento. Sí.

¿Será el próximo lanzamiento tan espectacular? Oh, por supuesto, mantenemos el futbolín. Eso está bastante bien.

Otra pregunta, ¿hay planes para que Platformatic se integre en SST o proyectos similares? Claramente queremos asociarnos y comprometernos con todo el ecosistema, así que tenemos un plan de diferentes tipos de integraciones. Estamos cuidando al principio crear las bases correctas para que podamos apilar y construir más funcionalidades, pero no sabemos exactamente cuándo lo tendremos hecho.

Muy bien, aquí hay una pregunta divertida. ¿Cuál fue el desafío más interesante durante el desarrollo de esto? No hay preguntas que saltarse. No, esto es realmente, esto es muy difícil. ¿Cuántos de ustedes saben lo difícil que es hacer una recarga en caliente en JavaScript y TypeScript y así sucesivamente? Es un problema enormemente difícil, ¿vale? He estado trabajando durante dos años y medio para resolver este problema y estoy contento de que la solución que encontramos funciona más o menos. Hay algunos fallos, pero está bastante bien. Y seguimos invirtiendo aún más en la recarga en caliente. Incluso he hecho una contribución al núcleo de Node.js para mejorar eso. Probablemente daré una charla sobre ello en otoño porque todavía no ha aterrizado. Así que crucemos los dedos.

Muy guay. Tenemos dos preguntas muy similares, a saber, ¿existe una solución autohospedada y puedo alojar mi propia instancia de Platformatic? Sí. Si vas a nuestro sitio web, estamos abriendo nuestro programa beta para ejecutar Platformatic en tu propia cloud y, sí, va a estar dedicado principalmente a la instalación enterprise, pero claramente, porque es beta, puedes... Oh, pero, lo siento, tal vez la pregunta era algo mucho más simple que eso, Luca. Puedes tomar npm instalar Platformatic y simplemente funcionará. Oh, por cierto, no dije esto. Voy a dar una charla sobre todo esto más tarde esta tarde. Así que si quieres unirte a mi sesión, eso será... Hay una demostración. Hay una demostración. Puedes ver que realmente funciona.

Realmente funciona. Vale. Entonces la gente necesita ver esa demostración. Sí. Hecho. Muy bien. Perfecto. Hecho. ¿Hecho?

Vale. Oh, tengo que responder a eso. ¿Ofrece Platformatic algún tipo de soporte para websocket para realtime data? La respuesta es sí. Ahora. Ahora. Sí. ¡Yay! Muchas gracias. Gracias. Muchas gracias.