1. Introducción a la Tecnología y Java
La tecnología es una espiral. Las ideas fundamentales vuelven. COBOL y MVC. El monolito y Java. Java cambió las aplicaciones empresariales. Lento, mecánico, requiere mantenimiento. Java comenzó a construir APIs.
Hola a todos, soy Matteo. Hola a todos, soy Luca. Bienvenidos a JS Nation, y estamos muy contentos de estar aquí. Después de 6 años juntos. Después de 6 años en los mismos lugares, diferentes conferencias, diferentes momentos, es fantástico.
Antes de comenzar, por cuestiones de brevedad, ya saben que solo tenemos 20 minutos, hemos abreviado algunos pasos de la historia, así que si no es perfecto, no es correcto, por favor avísenos, pero está bien, ¿de acuerdo?
Así que quería comenzar todo diciéndoles que la tecnología es en realidad una espiral. Cada generación de tecnología, ya saben, la implementación cambia todo el tiempo, ya saben. Hace algunos 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, vuelven una y otra vez. Ya saben que MVC fue inventado por Smalltalk hace algunos 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 monolitos muy bonitos para sus aplicaciones? ¡Yay! No sean tímidos, no sean tímidos. Está bien. Y así, sí, el monolito. Y, miren, una vez en el mundo de las APIs, estaba Java. Y esto es JS Nation, es una conferencia de JavaScript. Pero, ya saben, no el grano de café o la isla. ¿Sabían eso? Saben que en Ámsterdam tenemos Java Island, está justo allí. Pero ahí no es donde crearon Java, por cierto. De acuerdo. Entonces, gracias. Todo comenzó con la programación de aplicaciones 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 paquete tar. Y luego lo copias por SSH o simplemente lo arrastras y sueltas, si estás en Windows, y lo colocas en tu servidor de aplicaciones, ¿verdad? Así es como todo comenzó. Y Java es una tecnología fenomenal que cambió enormemente la forma en que vemos las aplicaciones enterprise, pero es un poco lento, mecánico, requiere mucho mantenimiento, pero puede llevarte de A a B. Sin problema. Todos hemos estado allí, ¿verdad? Y Java comenzó a construir el mundo de las APIs.
2. La Evolución de los Servicios Web y REST
En ese momento, los servicios web eran conocidos como archivos Weasel. La era del análisis SOAP. El modelo monolítico. La llegada de REST y JSON. El impacto de Ruby on Rails. La facilidad de construir APIs y sitios web. La simplicidad perdida de generar sitios web con REST.
Pero en ese momento se les llamaba 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í.
De acuerdo, algunos de ustedes. Sí, saben, se llama WS star, y no sé, cuando estábamos en la universidad nos burlábamos de esto y lo llamábamos así. Así que por eso está el escritorio detrás. De acuerdo, lo siento, no expliqué esto, porque me dijeron que no estaba claro.
Y todos construimos, también más tarde, conozco el análisis 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 en el lado del servidor, y renderizado en el 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 implementación, pero era multi-threaded y síncrona. Así que cuando estaba, hace algunos años, estudiando mi doctorado, y eché un vistazo a esta tesis fantástica. Había 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 conocida como REST. Es genial, ¿de acuerdo? Además, alrededor de esa época, en el año 2000, aproximadamente en 2001 y así sucesivamente, comenzamos a ver otra invención interesante en el mundo. JSON.
¿Cuántos de ustedes usan JSON hoy en día? Están levantando la mano. No veo suficientes manos levantadas. De acuerdo, están usando XML en el fondo del estado. Sé que están usando XML. Los fanáticos. Los fanáticos. 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, oh, puedo construir un sitio web o algo fantástico en 20 minutos, fue impresionante. Y hicimos fantásticas plantillas HTML con ERB y otra tecnología interesante llamada PrototypeJS, que fue un éxito. Y scriptaculous, lo que sea. No sé cuántos de ustedes estuvieron allí en ese momento. Pero es una gran tecnología. Y esa, la developer experience de construir APIs y sitios web, se trataba de los data, así que comenzaste a generar tu migración para tu database. Luego estas cosas se generaban automáticamente, y más o menos obtenías un buen andamiaje de HTML, tu controlador, archivos ERB, y una bonita API REST CRUD. Todo esto estaba, no sé, a un comentario de distancia. ¿Dónde perdimos la capacidad de generar un sitio web completo con una API agradable en un comentario? No sé cuánto tiempo les lleva hacer eso hoy en día, pero definitivamente no es lo que hace REST.
3. Ruby on Rails and Node.js
Ruby on Rails fue genial para moverse rápidamente de A a B, pero más lento de B a C. La experiencia del desarrollador para implementar cosas mejoró con Rokon y git push. La nube elevó la ejecución de servicios con proxies inversos y perfiles. La programación síncrona seguía siendo la norma. Node.js surgió en la conferencia JS Nation en 2009, cambiando el desarrollo web. A pesar de mi falta de conocimiento en JavaScript, me subí al carro de Node.js.
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 te subes a los Rails, oh, súper alta velocidad, entonces necesitas salir un poco de los Rails. Luego empezaste a ir un poco más lento. Necesitas descarrilarte. Sí, bueno, un poco.
En ese momento, también obtuvimos la mejor developer experience para implementar cosas. Y de nuevo, asombrados. Antes de eso, era muy difícil. Cuando salió Rokon y realmente podías hacer git push a un repositorio, y podías implementar tus cosas. ¿Cuántos de ustedes hacen git push para implementar hoy en día? De acuerdo. Deberían agradecer a estos chicos. Y en realidad podías implementar en cualquier lugar, pero es increíble. Fue una experiencia de desarrollo increíble, y probablemente sigue siendo la mejor que puedes obtener. Todos querían copiar esto.
En el núcleo de todo esto, 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 perfiles agradables para definir qué ver. Muchos de ustedes no lo saben, pero no se preocupen. Y tenemos múltiples procesos para cada máquina que ejecuta todo esto. Es una arquitectura muy simple, pero en realidad muy efectiva. Aún así, seguiremos haciendo programación síncrona. ¿Qué significa eso? Recibe una solicitud, procesa esa solicitud antes de pasar a la siguiente.
Sin embargo, esta es la conferencia JS Nation, y cualquier aplicación que se pueda escribir en JavaScript eventualmente se escribirá en JavaScript. Así que gracias, Jeff, y este fue el momento en que Node llegó a existir. 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 carro, aunque no sabía nada de JavaScript. Soy ingeniero mecánico de profesión. No sabía nada de JavaScript. Y C++. Esa es otra historia.
4. Node.js and Microservices Revolution
Node.js permite un desarrollo rápido y personalizado con su bucle de eventos. Dividimos el monolito en microservicios, revolucionando el backend.
Como mecanismo de transporte,
Node.js es un pequeño SUV que puedes mover de A a C. No vas super rápido. Puedes usar
Node.js para hacer cosas muy personalizadas y moverte rápido mientras lo haces. Ahora hay, no sé, millones de módulos en MPM. Probablemente muchas vulnerabilidades, pero ese es un tema diferente. En ese momento nos dijeron que debido a que
Node.js tiene este enorme bucle de eventos, podemos ser de un solo hilo. Y, ya sabes, ejecutar muchas solicitudes por segundo en paralelo en un proceso dado. ¡Wow! No sé. ¡Es súper fantástico, ¿verdad?! Y, entonces... ¡Bam, bam! ¿Qué hicimos? ¡Bam! Rompimos el monolito. ¡Sí! Finalmente, el monolito se rompió en pedazos y todos estamos familiarizados con el concepto de dividir y conquistar, ¿verdad? Todos pasamos por ese hermoso bucle. Y ese fue el momento en que comenzamos a revolucionar el mundo del
backend, dividiendo el monolito con una sola aplicación en microservicios.
5. Encountering Technologies and False Promises
El encuentro con tecnologías como Docker y el service mesh llevó a una falsa promesa de 'funciona en mi máquina'. Esto generó reflexiones sobre cómo podría evolucionar este espacio.
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 ambos 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, luego enviaremos tu máquina, ¿verdad? Porque seamos honestos. Docker no funciona en tu máquina y en la cloud de la misma manera, ¿verdad? Es un gran ejercicio de marketing, pero esta promesa realmente comenzó a generar muchas más reflexiones e ideas sobre cómo podría evolucionar este espacio.
6. The Transformation to a Distributed System
El frontend comenzó a desacoplarse, lo que llevó al crecimiento de aplicaciones de una sola página y móviles. El viaje se transformó de una aplicación monolítica a un sistema distribuido y APIs REST. Vercel y NeXT revolucionaron la experiencia de backend a frontend. Sin embargo, los desarrolladores de backend quedaron rezagados en la transición a un sistema distribuido. La coordinación en un sistema distribuido es un desafío y surgieron herramientas como el Service Mesh. Los desarrolladores aún carecen de una herramienta para construir, gestionar y escalar microservicios sin problemas. Platformatic tiene como objetivo llenar este vacío ayudando a los desarrolladores a construir aplicaciones Node.js con la misma velocidad y flexibilidad que Rails.
Mientras tanto, el frontend estaba cambiando. Todos saben a qué me refiero, ¿verdad? Comenzamos a desacoplarnos. Ahora tienes el frontend y la lógica de negocio, la aplicación de una sola página comenzó a crecer. El crecimiento móvil fue masivo. Y así, este viaje nos llevó de tener una aplicación monolítica a un sistema distribuido, pero probablemente a la transformación a APIs REST.
Y la mayor parte del tiempo, lo que sucedía en realidad era que simplemente renderizabas lo que está en tu base de datos desde el lado del servidor. En este viaje, claramente todos estamos familiarizados con la revolución y el jugador más importante que Vercel y NeXT pusieron en marcha, porque realmente trajeron esa experiencia que se perdió en este viaje del backend al frontend. Dijeron que solo necesitábamos hacer un git push, implementar nuestra aplicación y podríamos 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 nos preguntamos a dónde diablos fue, esta experiencia en este viaje? Y así, todos estábamos en medio de ser transformados en un sistema distribuido.
Y como ingeniero de sistemas distribuidos y al igual que muchos de ustedes, sé perfectamente que un sistema distribuido es extremadamente complicado porque la coordinación es un gran desafío. ¿Están de acuerdo con eso? La coordinación lo es todo, ¿verdad? Y así vimos el viaje desde el lado del operador. Vimos herramientas como el Service Mesh. Puedo poner un sidecar en tu aplicación y darte todas las funcionalidades. Como, por ejemplo, el seguimiento distribuido porque es bastante miserable cuando tienes cientos de microservicios y alguien te llama a las 2 de la madrugada y dice que algo está roto y tienes que buscar en cientos de microservicios. Y vimos el auge y caída de los registros. Todas herramientas para operadores, pero ¿dónde están los desarrolladores? ¿Dónde están los habilitadores de eso? Porque todavía les falta una herramienta que permita a los desarrolladores construir, gestionar y escalar microservicios sin problemas. ¿Y cómo podemos devolver esta alegría al desarrollo de API? Sí.
Bueno, ya saben... En algún momento del año pasado, decidimos que íbamos a financiar una empresa. Así que entra Platformatic. Y mira, estamos ayudando a los desarrolladores a deshacerse de todo el trabajo pesado y no diferenciado de construir aplicaciones Node.js. Y lo que queremos lograr es la misma velocidad que experimenté hace algunos años cuando comencé con Rails, con la flexibilidad de Node.js al mismo tiempo. Entonces, esto ya no funciona por alguna razón. No producimos baterías. Por eso el problema. Sí. Lo siento. Pasó. Bien. Bueno.
7. Introduction to Platformatic
Todo es de código abierto y se construye sobre Fastify. El servicio de Platformatic incluye todas las herramientas necesarias para construir APIs, incluyendo soporte para Open API, GraphQL, REST, métricas personalizadas, registros y protección contra problemas de bucle de eventos. También ofrece soporte para TypeScript y recarga automática de módulos, así como comprobaciones L. PlatformaticDB es una poderosa herramienta para construir APIs rápidamente.
Genial. De acuerdo. Lo siento. Lo siento por eso. De acuerdo. Así que, un poco de Mischa. Y, lo siento. ¿Por qué no está esto? ¿Puedes? De acuerdo. Lo siento. Tú sigues... Explotó. De acuerdo. Bien. De acuerdo.
Entonces, todo es de código abierto. Y, todo es de código abierto. Y, se apoya en los hombros de gigantes. Se construye sobre un framework llamado Fastify. Así que, no sé. Échale un vistazo. Escribí la cosa hace unos años. Y, otra cosa llamada Node. Así que, también, está compuesto de algunas cosas. Y, la primera es el servicio de Platformatic. Básicamente, incluye todas las cosas que necesitas para construir APIs hoy en día. Open API, soporte para GraphQL, REST. Pero también tiene métricas personalizadas, registros. Te protege de los problemas de bucle de eventos, ya sabes, aplicaciones de malla, lo cual es muy bueno. Y, hace TypeScript y soporte de recarga automática de módulos, así como comprobaciones L. También construimos una cosa llamada PlatformaticDB, que es fantástica para construir APIs realmente, realmente rápido.
8. Introducing Platformatic and Composer
Con Platformatic puedes crear fácilmente migraciones y APIs. Admite múltiples bases de datos. Presentamos el Composer, que combina múltiples servicios REST en un solo punto final. El tiempo de ejecución de Platformatic permite ejecutar múltiples aplicaciones dentro del mismo tiempo de ejecución de Node.js. Crea un sistema sobre microservicios, lo que permite la resolución de conflictos de dependencias y el orden de clasificación topológica de los servicios.
Porque si solo creas tu migración, y después de haber creado tu migración, puedes hacerlo y crear tus APIs. También, admite múltiples database, y así sucesivamente. En realidad, es muy fácil de usar y deberías probarlo.
Ahora, 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, hemos preguntado a muchos desarrolladores, y todos nos dijeron, bueno, realmente nos gusta REST. Y empezamos a decir, oh, vale, 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 punto final, más o menos, eliminando el patrón backend, frontend. También maneja muchas cosas agradables que, ya sabes, hacen que este tipo de cosas sean muy desagradables de hacer, y nosotros nos encargamos y lo hacemos por ti, así que no hay problema. Simplemente funciona de inmediato. 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. De acuerdo. 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. Forma parte de la nueva Platformatic Cloud, y crea cosas...te permite ejecutar todas ellas juntas. Más sobre eso más adelante. Un déjà vu. Un déjà vu. Y como sabemos que gestionar sistemas distribuidos puede ser muy doloroso, en realidad decidimos tomar una dirección diferente a la de una malla de servicios, y dijimos, en realidad podemos crear un sistema, un grafo, sobre todo este conjunto de microservicios, y básicamente crear un sistema de taxonomía generativo que permite, como, hacer múltiples e interesantes cosas. Así que podríamos tener resolución de conflictos de dependencias, o básicamente tener un orden de clasificación topológica de servicios, y son todas cosas por las que más o menos hemos pasado construyendo sistemas distribuidos y microservicios. Y cuando dije que es un déjà vu, parece que estamos retrocediendo, ¿verdad? Empezamos toda esta conversación con Java y la implementación en un servidor de aplicaciones, y parece que estamos yendo hacia donde Matteo nos estaba llevando al principio, a un círculo. Y en realidad nos dimos cuenta en este viaje que en realidad había una oportunidad de evolucionar lo que estaba estandarizado y más como el statu quo para construir microservicios de Node.js. Pero queríamos hacerlo de una manera moderna, en una arquitectura moderna. Así que... No se está transmitiendo a la...
9. Transformando Microservicios en Nanoservicios
Transformamos microservicios en nanoservicios, desplegándolos como una única unidad dentro del tiempo de ejecución. El tiempo de ejecución de Platformatic crea una malla virtual entre sistemas, interconectando servicios automáticamente. Se ejecuta en cualquier máquina, incluyendo nuestra nube, Platformatic.cloud. Cobramos en función de la potencia de cálculo y ofrecemos opciones gratuitas. Todo es de código abierto y tenemos un lanzamiento sorpresa en el escenario. Visítanos en platformatic.dev.
Entonces... Vale. Y así que decidimos transformar microservicios en nanoservicios. Y esto es gracias a lo que Matteo acaba de decir sobre el tiempo de ejecución. En realidad, somos capaces de reunir una multitud de servicios y desplegarlos como una única unidad dentro del tiempo de ejecución y luego trasladar el tiempo de ejecución directamente a cualquier máquina. Y este tiempo de ejecución, gracias a la taxonomía y todas las demás cosas que acabamos de ver, está creando una malla virtual entre ambos sistemas.
Así que es una superposición, pero no es una superposición con un sidecar. Una de las características clave del tiempo de ejecución de Platformatic es que los servicios no están automáticamente accesibles a través de Internet. Básicamente, los estamos interconectando automáticamente utilizando algunas tecnologías que hemos desarrollado a lo largo de los años y también es compatible con la API de búsqueda estándar, por lo que podrías simplemente buscar y en lugar de pasar por una ruta completa de HTTP, todo se enruta realmente dentro del mismo proceso, como en una malla virtual en el mismo proceso en sí. Es bastante genial.
Así que es genial, ¿verdad? Y ¿qué quieres decir, Luca? Que finalmente se ejecuta en mi máquina, en tu máquina, en nuestra cloud o en tu cloud, así que finalmente podemos hacerlo funcionar en todas partes. Hoy estamos lanzando nuestra cloud y puedes desplegar todo esto en Platformatic.cloud. Y desde cero de forma gratuita, si solo necesitas cosas básicas, o si necesitas un nombre de dominio u otras cosas así, por $99. Es en dólares, no en euros, así que ya sabes, si te importa eso. Y lo que realmente pensamos que era más justo para los desarrolladores, fue realmente cobrar lo que realmente importa. Que es la potencia de cálculo. Así que nos gusta mirar hacia atrás en historias exitosas, 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álculo.
Oh, pero ¿no dijimos que todo lo que hablé es de código abierto? Bueno, tenemos una sorpresa. Vamos a hacer un lanzamiento en el escenario. ¿Felices? Aquí vamos. ¿Estás listo? ¿Listo? Sí. ¿Lo hacemos? ¿Lo hacemos? Vamos a abrirlo. Vamos a abrirlo. ¿Estás listo, Luca? ¡Adelante, presiónalo! ¡AAAAHHHHHHHHH!!! Genial. Ya está disponible todo. Visítanos en platformatic.dev. Se ha lanzado mientras hablamos. Las GitHub actions están haciendo su trabajo. Así que dale tiempo para que se levante, no para que aparezca. Así que vamos a ello.
Platformatic Release and Q&A
Todo está disponible ahora. Visítanos en platformatic.dev. Se está lanzando. Nos aseguraremos de que te pongas en marcha. Mientras hablamos, las acciones de GitHub están haciendo su trabajo. Codificación en vivo definitiva. Haciendo un lanzamiento, no sé, de un año de trabajo en el escenario. Con un lanzamiento nuclear. Por supuesto. Maletín. Genial. Gracias a todos. Gracias.
Todo está disponible ahora. Visítanos en platformatic.dev. Se ha lanzado mientras hablamos. Las acciones de GitHub están haciendo su trabajo. Así que dale tiempo para que se levante, no para que aparezca. Así que vamos a ello.
Se está lanzando. Se está lanzando. Se está lanzando. Si no te estás levantando, está bien. Nos aseguraremos de que te pongas en marcha. Se está lanzando. 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 que se levante, no para que se bloquee y despliegue nuestras cosas porque realmente las hemos desplegado ahora mismo. Cosas totalmente en vivo, así que, ya sabes, podrían haber fallado, pero a lo grande. Así que veremos. Codificación en vivo definitiva. Haciendo un lanzamiento, no sé, de un año de trabajo en el escenario. Con un lanzamiento nuclear. Por supuesto. Maletín. Genial. Gracias a todos. Gracias. Y no olvides visitar y revisar nuestro sitio web.
Te invito a unirte a mí en el rincón de preguntas y respuestas. De acuerdo.
Q&A: Características y Beneficios de la Plataforma
Hay un par de preguntas de la audiencia sobre la plataforma. Es 100% gratuita y de código abierto, sin trampa. Los beneficios de los nano servicios sobre los microservicios convencionales incluyen una implementación simplificada y un único canal de implementación. La plataforma proporciona una experiencia fluida tanto para los ingenieros de backend como para los desarrolladores de frontend, con generación automática de clientes para facilitar el consumo de las API de Platformatic desde aplicaciones frontend de React o Vue.
Fantástico. Donde voy a poner todos mis dispositivos. De acuerdo. Porque tenemos un par de preguntas de la audiencia. Me encanta. De acuerdo. Así que si tienen algunas preguntas para Luca y Matteo, por favor, sigan haciéndolas. También pueden pararse frente al bloque. También soy alto. Sí, vivir en los Países Bajos no ayudó a mi altura. Está bien.
Veamos algunas preguntas. Entonces hay una pregunta si es realmente gratuita y de código abierto y cuál es la trampa. 100% gratuita y de código abierto. No hay trampa. Sin trampa. Perfecto. Eso es lo que queremos escuchar. ¿Cuáles son los beneficios de tener una granularidad tan pequeña de los nano servicios en comparación con los microservicios convencionales? El beneficio es que puedes hacerlo muy rápido, como si estuvieras usando microservicios tradicionales esencialmente necesitas lidiar con la implementación de cada uno de ellos. Y por lo tanto, si estás haciendo microservicios correctamente, los estás gestionando como una unidad de implementación independiente. Y por lo tanto, hay mucho terraform y entorno de CI para implementar cada uno de ellos. Un sistema como el nuestro es muy sencillo y porque es nano dentro del mismo proceso no tienes que lidiar con eso, solo puedes implementarlo una vez y tienes un único canal de implementación.
Perfecto, también tuvimos una pregunta sobre hablaste mucho sobre la developer experience. ¿Qué pasa con la UX? ¿Qué pasa con? Experiencia de usuario. Experiencia de usuario. Nosotros hacemos APIs, vale, soy un ingeniero de backend. Así que si los cofundadores son ingenieros de backend, también tenemos un fantástico desarrollador de frontend 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, por lo que tienes una experiencia más de línea de comandos para ingenieros de backend y también puedes abordar lo mismo en nuestra interfaz de usuario y la interfaz de usuario 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 cosas más grandes para los desarrolladores de frontend es que ofrecemos una generación automática de clientes para que puedas usar fácilmente las API consumibles de Platformatic desde tu frontend de React o Vue.
Contract Testing and Integration Plans
Pruebas de contrato y planes de integración. Estamos trabajando en pruebas de contrato y tenemos planes para integrar Platformatic en otros proyectos. El desafío más interesante fue la recarga en caliente en JavaScript y TypeScript. Estamos invirtiendo más en la recarga en caliente y he contribuido al núcleo de Node.js. Tenemos una solución autohospedada y una demostración.
Muy bien, tenemos una pregunta, ¿dónde entra en juego la prueba de contrato? Prueba de contrato. 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í.
¿El próximo lanzamiento será igual de espectacular? Oh, por supuesto, mantendremos el futbolín. Eso es muy bueno.
Otra pregunta, ¿hay planes para integrar Platformatic en SST u otros proyectos similares? Claramente queremos asociarnos y participar en todo el ecosistema, por lo que tenemos una hoja de ruta de diferentes tipos de integraciones. Estamos cuidando al principio de crear las bases adecuadas para construir más funcionalidades, pero no sabemos exactamente cuándo lo tendremos listo.
Muy bien, aquí hay una pregunta divertida. ¿Cuál fue el desafío más interesante durante el desarrollo de esto? No se pueden saltar preguntas. No, esto es realmente, esto es muy difícil. ¿Cuántos de ustedes saben lo difícil que es hacer recarga en caliente en JavaScript y TypeScript y así sucesivamente? Es un problema enormemente difícil, ¿de acuerdo? He estado trabajando durante dos años y medio para resolver este problema y estoy feliz de que la solución que encontramos realmente funcione 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 contribuido al núcleo de Node.js para mejorar eso. Probablemente haga una charla al respecto en otoño porque aún no se ha implementado. Así que crucemos los dedos.
Muy bien. Tenemos dos preguntas muy similares, a saber, ¿hay 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 nube y, sí, estará principalmente dedicado a instalaciones empresariales, pero claramente, porque es beta, puedes... Oh, pero, perdón, tal vez la pregunta era algo mucho más simple que eso, Luca. Puedes ejecutar npm install platformatic y simplemente funcionará. Oh, por cierto, no mencioné esto. Haré 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.
Platformatic WebSocket Support
Platformatic ofrece soporte para websockets para datos en tiempo real. Sí, ahora. ¡Hurra! Gracias.
Realmente funciona. De acuerdo. Así que la gente necesita ver esa demostración. Sí. Listo. Muy bien. Perfecto. Listo. ¿Listo?
De acuerdo. Oh, tengo que responder eso. ¿Platformatic ofrece algún tipo de soporte para websockets para datos en tiempo real? La respuesta es sí. Ahora. Ahora. Sí. ¡Hurra! Muchas gracias. Gracias. Muchas gracias.
Comments