1. Introducción a la Generación de Tipos
Hola a todos. Soy Matteo Collina, cofundador y CTO de Platformatic, y hoy voy a hablar de algo que me pone un poco nervioso, la generación de tipos. Entradas. ¿Por qué? Vamos a profundizar en ello. Así que, la primera pregunta para todos ustedes es, ¿cuántas cuerdas necesitan para subir a un árbol? Esta es una pregunta fundamental y vamos a intentar responderla en esta charla.
hablar de algo que me pone un poco nervioso, la generación de tipos. Entradas. ¿Por qué? Vamos a profundizar en ello. Así que, la primera pregunta para todos ustedes es, ¿cuántas cuerdas necesitan para subir a un árbol? Esta es una pregunta fundamental y vamos a intentar responderla en esta charla. Así que, vamos. Lo primero, un par de cosas sobre mí. Soy Matteo Collina, parte del Comité de Dirección Técnica de
Node.js, también miembro de la Junta Directiva de la Fundación Open Source Open JS. He creado un montón de bibliotecas, ayudado a mantener nodos, probablemente usando algunas de mis software dado que se descargaron 17 mil millones de veces el año pasado, así que sí, tal vez. Así que, algunas de mis decisiones afectan a algunas personas, así que espero no romper a demasiados de ustedes durante esta charla o después. De todos modos, vamos y saltemos. He escrito muchos módulos, mantengo muchos módulos en
NPM, muchas descargas, lo que sea que importe. Por cierto, si alguna vez usas uno de ellos, si quieres patrocinarme en GitHub, todo es apreciado. Tengo una pequeña confesión que hacer. ¿Qué? ¿Qué? Bueno, antes de 2022, casi nunca usé
TypeScript. Y aquí estoy hablando en el Congreso de
TypeScript. ¿Qué es eso? Es realmente fascinante. Evité y pasé por alto esta tecnología tanto tiempo como pude. ¿Qué pasó en 2022? Bueno, empecé una nueva empresa, y era una experiencia de desarrollo para empresas. Así que sí, tuve que adentrarme en
TypeScript. De hecho, todo se basa en algo que había hecho anteriormente, que es
Fastify, que es un proyecto dentro de la Fundación Open Source también. Y se trata de construir APIs. Soy un ingeniero de back-end de profesión y lo que quiero es ayudar a las personas y cómo ayudar a las personas con mi herramienta, ya sabes, para construir y usar APIs de manera mejor y hacerlo más rápido y más fácil de desarrollar, mantener, escalar, como quieras llamarlo. Así que sí, típicamente el flujo típico cuando uno de tus miembros del equipo o alguien más está comenzando a escribir tus APIs, tienes una API en un extremo y típicamente eres un ingeniero de back-end escribiendo algunas consultas SQL complejas o algunas consultas complejas de
MongoDB, lo que quieras, luego generan, escriben algo de documentación a partir de esa API y luego tu cliente, tu ingeniero, codifica su cliente. Entonces, ¿cómo se relaciona esto con la generación de tipos? Sí, permítanme presentar el problema primero. Esto es más o menos lo que Plasformatic quiere simplificar y mejorar cómo creamos software de back-end. Típicamente lo que queremos hacer es mover, permitirte moverte muy rápidamente de A a B utilizando tantos rieles como sea posible, rieles de protección para todos ustedes para moverse muy rápido. Y luego, ya sabes, puedes llevar tu viejo SUV exactamente donde quieras ir. Así que, queremos ayudar a los desarrolladores a deshacerse de todo el trabajo pesado indiferenciado de construir tus aplicaciones JS. Como parte de eso, en algún momento, nos enfocamos en trabajar
2. The Need for a Better Client Experience
Lo que descubrimos al hablar con mucha gente fue que tener un cliente para las APIs era fundamental para una buena experiencia de desarrollo. La generación de clientes se ha vuelto popular recientemente con bibliotecas como tRPC y TS Rest. Sin embargo, estas bibliotecas introducen un acoplamiento estrecho entre el cliente y el código del servidor, lo que dificulta la escalabilidad y la evolución. Necesitamos una mejor experiencia de cliente que permita flexibilidad y el uso de diferentes versiones de TypeScript.
mucho en las APIs y mejorar dos APIs que se habían escrito. Lo que descubrimos al hablar con mucha gente fue que, ya sabes, oh, pero tener un cliente para esas APIs era realmente fundamental para proporcionar una buena experiencia y agilizar el desarrollo. Entonces, lo que sucedió fue que, ya sabes, a la mayoría de las personas realmente les gusta mucho más este flujo. Así que, en lugar de tener que llamar al cliente y preparar
documentation para la API, solo quiero presionar un botón y generar un cliente. De hecho, esto ha sido tan popular desde hace mucho tiempo, y de alguna manera lo perdimos un poco en el camino, porque, ya sabes, recuerdo generar clientes para mis APIs cuando hacía WSDL y SOAP hace mucho tiempo. Así que, ya sabes, probablemente no sea una gran comparación, pero lo es. De todos modos, esto ha sido extremadamente popular recientemente. De hecho, esto ha sido popularizado en gran medida por algunas bibliotecas nuevas. Una es tRPC, que es fantástica, proporciona una experiencia de
developer experience fantástica. Te permite exponer tu... crea una llamada RPC desde el servidor al... desde el cliente al servidor de una manera completamente segura en cuanto a tipos. Es genial, ¿vale? Solo tiene una desventaja significativa, que es el acoplamiento de tipos introducido en el... el código de tu
frontend con el código de tu
backend, también utiliza un protocolo propietario para comunicarse. Así que sí, es muy estrecho. Es un acoplamiento muy estrecho entre el cliente y el servidor. Hay otra biblioteca llamada TS Rest, que también es genial, una biblioteca fantástica, pero tiene otro pequeño... todavía otro pequeño problema, que es que necesitas especificar el contrato entre tu cliente y tu servidor en su propia definición de espacio de tipos. Nuevamente, para consumir la biblioteca, necesitas tener una dependencia de código fuente en el servidor. Así que nuevamente, para mí, esto introduce un acoplamiento estrecho entre los dos. De hecho, el problema aquí es el concepto de ya sabes, lo que sucede en la mayoría de los equipos con los que he trabajado y desarrollado y demás, es que básicamente tienes alguna API que es desarrollada más o menos por un equipo y hay otro grupo de personas que, ya sabes, crea y consume o que consume esas APIs. Y esos grupos típicamente están más o menos separados en la mayoría de las empresas y en la mayoría de las organizaciones. Entonces, integrar todo junto, crear un acoplamiento estrecho entre todo eso hace que sea muy difícil descomponer y escalar y seguir evolucionando las cosas. Y por cierto, no hay nada que criticar a esas bibliotecas, que son fantásticas. Solo estoy hablando de por qué creo que necesitamos una mejor experiencia de cliente para las APIs. Entonces, ¿dónde nos quedamos? Bueno, algo que queremos proporcionar es una experiencia de desarrollador fantástica pero sin ningún acoplamiento estrecho. Entonces, sin ningún código compartido, esencialmente, entre el servidor y el cliente, para que puedas usar y consumir otras APIs. Y así, uno puede usar
TypeScript 4.9 y el otro puede usar
TypeScript 6 en el futuro. Y pueden evolucionar y tener diferentes versiones, diferentes cosas. Todo es divertido y perfecto. Entonces, ¿cómo podemos generar esta
developer experience? Comencé este viaje,
3. Generación Automática de Clientes REST API
Y como parte de este viaje, una encuesta mostró que el 80% de los desarrolladores prefieren REST en lugar de GraphQL. Mi viaje comenzó con la pregunta de cómo generar automáticamente un cliente mínimo y sencillo para las APIs REST. OpenAPI, un estándar, proporcionó una solución fantástica. Usando Fastify o plataforma, podemos generar fácilmente documentación y definiciones de especificaciones OpenAPI. El cliente tenía requisitos específicos: fácil consumo en el frontend, validación de datos en tiempo de ejecución, completamente tipado para detectar errores de los desarrolladores y sin dependencias en tiempo de ejecución. Mi primer intento de generación de código resultó complejo y difícil de depurar.
Uno de los tipos de trabajo de mi viaje fue esta pregunta. Y como parte de este viaje, hubo un poco de una encuesta que muestra que más o menos el 80% de los desarrolladores prefieren REST en lugar de
GraphQL, lo cual suena muy poco intuitivo para mí, pero así es. Y si tienes mejores datos que esto, por favor avísame, porque esto es algo que me intriga mucho.
Entonces, mi viaje comenzó con la pregunta de cómo podemos generar automáticamente un cliente para nuestras APIs REST. Y el código generado debería ser mínimo y sencillo. ¿Cómo podemos lograr eso? Bueno, algo muy fantástico fue que OpenAPI es un estándar. Y construí este
framework llamado
Fastify, que es un
framework realmente bueno. Está ganando cada vez más atención en estos días sobre cómo construir APIs en
Node.js. Y puedes obtener fácilmente una documentación OpenAPI o swagger, como se llamaba anteriormente, generada muy, muy rápidamente sobre tus rutas. Así que podemos obtener la documentación, pero también la definición de especificaciones para OpenAPI. Así que tenemos todo, podemos obtener esto en su mayoría de forma gratuita usando
Fastify o usando plataforma. Entonces, el cliente, de hecho, tenía algunos requisitos para mí. Y uno de ellos era, bueno, tengo mis rutas definidas usando OpenAPI y quiero consumirlas muy fácilmente en el
frontend. Realmente no quiero que ocurra ninguna validación de datos en tiempo de ejecución, o tal vez debería estar desactivada, está bien, porque no quiero perder tiempo en el cliente. Quiero que mi código sea lo más ágil posible. Pero también quiero que esté completamente tipado para detectar errores de los desarrolladores en el editor. Y quiero usar fetch, por lo que no tengo ninguna dependencia en tiempo de ejecución. Así que solo necesito obtener mi archivo generado, y eso es todo.
Mi primer intento de generar este código fue usar. Así que comencé a usar esta generación de código. ¿Cómo puedo obtener el código que generó mi código generado? Y leí un buen artículo en DevTool. Comencé a hacer muchas cosas y quería hacer. Hagamos un experimento. Generemos esta función muy, muy simple y este código a la derecha. Es lo que se necesita para generar esa función. Ahora mira el código. En realidad es complejo. Puedes leer lo que hace. Creo un identificador, creo la función, hace todas las cosas, pero es muy, muy difícil... Si hay un problema allí, en realidad es muy, muy difícil de depurar. También requiere mucho código.
4. Generación de TypeScript y Uso de Cold Block Writer
Pensé que podría generar TypeScript fácilmente, pero parece una tarea enorme. Sin embargo, encontré una biblioteca llamada Cold Block Writer que facilita la generación de código. Tiene una propiedad llamada block que permite la inserción automática de llaves y gestiona la indentación. La desventaja es que el código generado puede no ser válido, pero es una opción más pequeña y conveniente. Podemos usar la especificación OpenAPI para generar nombres de funciones basados en la ruta y el ID de operación.
Para generar muy pocas líneas. Así que no estaba necesariamente muy... Oh, estaba... Oh, ouch. ¿Cómo puedo... Pensé que podría generar
TypeScript fácilmente, pero ¿cómo puedo obtenerlo? Parece que es un árbol enorme que tengo que escalar y no pude hacerlo en mi línea de tiempo, así que pensé, tal vez no. No quería escalar ningún árbol, pero esto parece un árbol enorme para escalar, así que, ouch, ¿cómo puedo hacerlo? Así que hice otro intento. Hice algunas búsquedas y probé otra vez y encontré esta biblioteca llamada Cold Block Writer, que es absolutamente algo que es realmente, realmente bueno. Y creo que deberías echarle un vistazo a Cold Block Writer si estás intentando generar código dinámicamente. ¿Por qué? Porque tiene una propiedad muy, muy buena aquí. Si miras el código a la derecha, es básicamente homomórfico en el sentido de que el código, en cómo escribimos la función, es muy, muy similar al código generado que queríamos tener. Debido a que hay una homomorfía entre esas dos cosas, en realidad podemos encontrar errores y solucionarlos muy fácilmente porque, oh, estas son las tres líneas que generan el mismo código. Puedo ver estas tres líneas y esas líneas. Así que, en realidad, es muy útil, muy fácil de escribir porque tiene esta propiedad llamada block que nos permite crear llaves automáticamente. ¡Hey, genial! Y también genera y gestiona la indentación automáticamente. Realmente me gusta esta biblioteca. Solo tiene una gran desventaja. El código generado no está garantizado que sea válido. También es mucho más pequeño, por lo que si quisiera reducir el compilador de
TypeScript, como 50 y pico de megabytes, lo están reduciendo. Así que, tal vez ahora sea 30. No sé. De todos modos, es una dependencia masiva, el compilador de
TypeScript, pero este es realmente muy pequeño también. Así que, en realidad, es muy agradable y genial. Parece una opción perezosa aquí. Y soy un desarrollador perezoso, así que empecé a pensar, hagamos eso. Hagamos perezoso. De acuerdo. Y echemos un vistazo a la especificación OpenAPI y cómo genera el código. Qué código queremos generar. Así que, mira, la especificación OpenAPI, tiene una propiedad de ruta y dice que hay una barra diagonal películas, por ejemplo. Y cada ruta tiene un ID de operación. Y este ID de operación, podemos usarlo para generar los nombres de nuestras funciones. Entonces, cuando alguien quiera llamar a la función wait get movies,
5. Definición de Tipos para Parámetros y Respuestas
Podemos definir y generar tipos para cada parámetro y respuesta en la especificación OpenAPI. Esto nos permite generar interfaces y utilizarlas en nuestra API.
por ejemplo, podemos llamar automáticamente al punto final de películas. ¿De acuerdo? Además, ha definido sus parámetros y respuestas. Sí, es genial. ¿De acuerdo? Y luego podemos hacer lo mismo exactamente para cada una de las otras operaciones que están definidas en mi especificación OpenAPI. De hecho, incluso podemos, ya sabes, incluso podemos, ups, lo siento. Incluso podemos, ya sabes, verificar y definir los tipos y generar los tipos para cada uno de nuestros parámetros y respuestas. Si lo miras, en realidad es bastante genial. ¿De acuerdo? Y tenemos todos los parámetros definidos y luego tenemos todas nuestras respuestas definidas. Así que podemos generar interfaces para ambos.
6. Generando el Cliente y la Solicitud
Entonces tenemos create movie y hay una solicitud create movie que devuelve una respuesta. Hemos dividido los tipos de nuestras APIs con las interfaces reales, lo que permite una mejor manipulación. El código generado es muy simple y se puede generar rápidamente. Hagamos una demostración rápida para ver lo fácil que es. Creamos una pequeña API, la iniciamos y generamos el cliente usando TypeScript. El cliente se basa en fetch y no tiene dependencias. Tenemos una solicitud get movie en el archivo api.types.
y los usamos como parte de nuestra API. Entonces tenemos create movie y hay una solicitud create movie que devuelve una respuesta. Parece bien. Entonces creo que esto es, sabes, para mí, uno de los puntos interesantes aquí es que ves aquí hemos dividido, ups, lo siento. Hemos dividido aquí los tipos de nuestras APIs con las interfaces reales. De esta manera, las cosas se pueden manipular mejor, creemos. De todos modos.
Algunas de las buenas, hay algunas buenas ideas aquí, pero el código generado es en realidad muy, muy simple. Como puedes mapear con uno a uno a lo que necesitas. Y creo que fue, podríamos generar este cliente muy rápidamente. Así que hagamos una pequeña demostración rápida. Y para que podamos ver lo fácil que es hacer cosas. Así que creemos un poco de una pequeña API, para que podamos hacer create platformmatic. Y aquí vamos. Queremos estar aquí, nuevo SQLite, pero podríamos usar cualquier cosa. Ups, lo siento. Y sí, sí. Y no por ahora, porque no quiero hacer NPM install. Así que estoy creando automáticamente una API muy rápidamente. Y sabes que ahora mismo no necesito nada. Así que cuando inicio esto, podría aquí hacer un platformmatic start. Y si abrimos esto, está bien, y volvemos aquí, lo siento, aquí vamos, puedo ver exactamente lo que está sucediendo. Esto es lo que se carga y puedo abrir mi documentación OpenMPI documentation, y veo que tengo películas con todos mis parámetros, que podemos obtener automáticamente para crear todo. Entonces, ¿cómo usamos, cómo, ups, lo siento, cómo generamos el cliente? Ok, ups, lo siento, estoy... Entonces, ¿cómo generamos el cliente? Así que volvamos a cd client, ok, y aquí tenemos, preparé algo muy simple con un package json, vcsnode y typescript para no perder tiempo con npm install, así que ahora puedo hacer plt so-clear, y plt frontend, y necesito poner en la url de mi aplicación, y luego quiero generarlo como typescript, y nos ha generado dos archivos api-types.b.ts y api.ts, y tenemos dos de ellos, ok, y echemos un vistazo. Entonces este cliente es en realidad muy simple de usar, y tenemos uh tenemos aquí nuestro fetch. Así que necesito rts.config.json aquí, y necesito las opciones del compilador ok, y necesito el objetivo, y ok, de lo contrario las cosas serán incómodas. Aquí vamos, y comentamos atrás, ok, bien. Esto será incómodo, ok. De todos modos, lo que tenemos aquí, tenemos nuestro fetch. Así que todo se basa en fetch y en estándares. En realidad, no tenemos ninguna dependencia en absoluto, y luego en api.types, como mostré, tenemos nuestra solicitud get movie aquí
7. Using the Generated Client and Running the Test
Entonces probemos y usemos esto y veamos cómo se ve la experiencia. Importamos desde api y usamos setBaseURL, create movie y get movies. Encontramos algunos elementos faltantes en createMovieRequest. Después de crear la película, recuperamos las películas y las registramos. Ejecutamos la prueba y todo funciona sin problemas. Usamos las funciones run, await y Start Wars. Vamos a ejecutarlo nuevamente.
que obtiene las cosas. Entonces sí, esto parece bastante bueno. Entonces probemos y usemos esto y cómo se vería la experiencia. Entonces, si abro test yes, puedo importar desde api. Y ahora puedo obtener setBaseURL y, por ejemplo, create movie y get movies. Ahora puedo hacer setBaseURL 0.3.0.4.2. Y luego queremos crear aquí, no existe, como ves aquí, no existe aquí, ¿de acuerdo? Y nosotros, no existe en createMovieRequest. Entonces, de hecho, si miramos los tipos aquí, si vamos a createMovie, lo siento. De acuerdo, createMovieRequest, ves que tiene un ID, un ID opcional y luego un título requerido. Entonces aquí está bien, pero luego necesitamos, hemos creado nuestra película y no necesitamos nada aquí. Entonces, de acuerdo, y luego podemos obtener las películas aquí y hacer
console log, y necesito especificar algunos parámetros, pero en este caso están vacíos. Entonces, y hemos generado, hemos obtenido estas películas. De acuerdo. Y probemos esto. De acuerdo. Entonces, si hago TS node test. Ahora se está ejecutando. Genial. De acuerdo. Estoy ejecutando el precio. ¿Por qué se está ejecutando el precio? Porque estos dos, ya sabes, seamos amables. Seamos amables. Entonces la función run. Aquí vamos. Y creo que se ejecutaron en paralelo, ¿verdad? Entonces podemos hacer await. Y aquí hacemos Start Wars. Y aquí hacemos presionar await. Sí. Y luego run. Ahora podemos ejecutar esto nuevamente.
Generating the Client and Handling Internal Issues
Tenemos Star Wars. Obtenemos el mismo resultado exacto. Esta es una forma bastante buena de generar un cliente. Funciona con cualquier OpenAPI compatible con cualquier sistema OpenAPI. Prueba nuestra herramienta de código abierto en docs.platformatic.dev. Gracias por recibirme en el S-Congreso.
Y aquí vamos. Ves que tenemos los dos que teníamos antes. Y ahora tenemos Star Wars. También podemos verificarlo muy rápidamente, si todo está correcto. Y está aquí, podríamos probar esto y ver si funciona correctamente. Como puedes ver, obtenemos el mismo resultado exacto. Y este es el código que se ejecutará y generará. Entonces no, creo que esto es bastante bueno. Es una forma bastante buena de generar un cliente. Como dijiste, aquí voy a dejarme hacer un árbol. Aquí no tenemos dependencias en absoluto, aparte de ts-node y cosas así, como si puedes ver, aquí solo tenemos ts-node y tipos. Entonces no hay otras dependencias en esos archivos. Es súper pequeño y basado en API. Entonces, el beneficio de este enfoque de usar OpenAPI es que funciona con cualquier OpenAPI compatible con cualquier sistema OpenAPI, por lo que puedes obtener una muy buena experiencia de desarrollo simplemente generando código para esas definiciones de OpenAPI que ya están disponibles para muchas APIs, por lo que no necesitas generar nuevas o crear nuevas bibliotecas o cualquier cosa para consumirlas. Entonces, no sé, creo que este fue un enfoque muy, muy interesante para probar y verificar si todo nos habría ayudado de alguna manera. Entonces, la pregunta para ti es, ¿escalamos el árbol? Entonces, ¿hey, escalamos el árbol? No sé. De todos modos, muchas gracias por ver. Prueba nuestra herramienta de código abierto en docs.platformatic.dev. Y no sé, muchas gracias. Y gracias a todos por recibirme en el S-Congreso. Gracias. Adiós. ¿Qué pasa, Matteo? ¿Cómo estás? Hola a todos. Hola. Me encanta tu voz, hombre. Tienes un estilo de presentación genial. Eso es increíble. ¿Por qué no pasamos a algunas preguntas? Tenemos algunas muy interesantes aquí. Estábamos viendo esto justo antes de comenzar y estábamos hablando de esta. ¿Qué deberías hacer si tienes problemas internos y tu equipo de front-end no puede confiar en tu equipo de back-end? Mencionaste en tu charla que no crees que deberías estar usando validación con Zod en el front-end
Validation in Production and TypeScript Conversion
Realizar validación en producción puede ralentizar tu código y aumentar el tamaño del paquete. No se recomienda validar todas las respuestas en producción. Sin embargo, agregar un modo de desarrollo para identificar discrepancias en las respuestas puede ser útil. La capacidad de TypeScript para ejecutar código en el editor de desarrollo crea una experiencia única para los desarrolladores que me convenció de su valor.
o algo similar a Zod. ¿Qué deberías hacer en esas situaciones? Hay dos aspectos, vale. No, realmente no quieres hacer ese tipo de validación en producción. Principalmente porque hacer cualquier validación tiene, o tener cualquier biblioteca de validación en el front-end tiene más o menos dos efectos. Primero, ralentiza tu código. Este es el primero. Y el segundo, aumenta el tamaño del paquete. Por pequeña que sea, por pequeña que sea tu biblioteca, aún necesita ser analizada, evaluada. Cada vez que vas y llamas, estás validando esa respuesta y requiere bastante esfuerzo, vale. Entonces, para ser honesto, no es algo bueno para el uso en producción validar todas las respuestas.
Dicho esto, agregar algún tipo de modo de desarrollo o algo para poder señalar a tu equipo y al equipo del cliente y decir: mira, tu respuesta no es lo que dijiste que debería ser. Con un dedo pequeño, haces algo diferente. Has estado en esa posición, así que estoy bastante consciente, al igual que todos. Creo que agregaremos eso, de hecho, tal vez ya lo hicimos, pero en el momento en que grabé la charla. Así que está por venir, o si no está allí, está por venir pronto. Es útil, pero no tanto en ese sentido, porque si tienes este problema de que no quieres ejecutarlo en producción, ¿verdad? De lo contrario, pierdes muchas cosas. Sí. Quiero decir, tampoco necesariamente quieres que tu código de desarrollo sea diferente del código de producción. También está eso en la mezcla. Me encantó lo que dijiste al principio. Eres famoso, un converso reciente a TypeScript. Recuerdo, te he estado siguiendo en Twitter durante un tiempo, y hace unos años dijiste, sabes, TypeScript es malo, ¿por qué todos lo están haciendo? Y ahora estás aquí. Entonces, ¿qué pasó? ¿Qué cambió tu opinión? ¿Cuál es la historia de cómo te sentiste? OK. Me di cuenta de algo muy, muy interesante sobre TypeScript. TypeScript es código que se ejecuta en el editor de desarrollo. Y eso es probablemente la verdad más grande sobre TypeScript en la que puedes pensar. Y eso es lo que permite que TypeScript cree un cierto nivel de experiencia para el desarrollador que no es posible de otra manera. Y me encanta eso. OK, para ser honesto, esto es bastante fenomenal y asombroso. Así que esa es probablemente la razón. No he cambiado de opinión. Aunque te llevó un tiempo convencerte, ¿verdad? Quiero decir, no estabas de acuerdo de inmediato.
Initial Challenges with TypeScript
Al principio, tuve una mala experiencia con la comunidad de TypeScript. Me criticaron por no escribir en TypeScript, lo cual era difícil y no se traducía directamente a JavaScript.
No, no lo estaba. Tuve un impacto muy negativo al principio con la comunidad de TypeScript, y básicamente me rechazaron por completo como persona. Recibí cientos de problemas diciéndome que escribiera esto en TypeScript, y realmente no quieres que nadie venga a tu casa y te diga que cambies la pintura. O que cambies los cimientos también. Quiero decir, eso es un gran problema. Cambiar los cimientos, ¿de acuerdo? Y en algunos casos, ni siquiera es posible. Como cuando esto sucedió, TypeScript no era ni siquiera una traducción 1 a 1 con JavaScript, y fue bastante malo, para ser honesto. Bueno, bienvenido de nuevo. Me alegra no haberte alienado por completo, pero estás aquí y eres parte de la comunidad. Una vez, creo que vi lo potente que es TypeScript. Creo que finalmente lanzaron todas las cosas que amo, que eran necesarias para hacer buenos tipos. Creo que en TypeScript, creo que tal vez el primer bloque fue en la versión 2.8. Luego, la segunda parte fue mucho más reciente, tal vez algo en la línea del árbol o algo así. Luego lanzamos un sistema de tipos fenomenal para Fastify. Fastify tiene la capacidad de escribir tus rutas, tanto con tipos, como en, um, uh, uh, uh, ¿documentos de Jazz o? No, no, no. Puedes usar Zod o Typebox. No sé si usas Typebox, yo no, todos hablan de eso, pero Typebox tiene muchas más descargas que eso. Es increíble. De acuerdo. Lo siento. Tiene un orden de magnitud más, pero todos están tan emocionados con Zod y esta cosa se usa. También puedes usar eso con Fastify, ¿verdad? Como. Sí, puedes usar ambos, así que puedes configurarlo para que puedas escribir tus rutas y especificar tus parámetros de entrada o salida usando, ya sea Zod o Typebox, y todo está completamente tipado de ida y vuelta. Y una vez. Y ver ese tipo de cosas te llevó a sentirte. Sí, sí. Esta es una experiencia de usuario increíble. Así que echemos un vistazo porque ha eliminado una de las mayores fuentes de fricción en este tipo de desarrollo, que es. Entonces, creo que Mateo, lo siento, tenemos que, um, detenerte ahí, pero creo que tenemos que pasar al siguiente ponente, pero muchas gracias Mateo. Si tienes preguntas sobre cualquier cosa, por favor envíalas. No puedo responder en Slido. Así que por favor. Sí, vamos a tener un chat especial para asegurarnos de que podamos enviar preguntas a Así que muchas gracias, Mateo. Gracias por tu tiempo. A continuación, tendremos a Jake Bailey. Nos vemos, amigo.
React Advanced Conference 2021
Comments