Get rid of your API schemas with tRPC

Estoy muy feliz de estar aquí. Y hoy estamos hablando sobre cómo deshacerse de su esquema API con trPC. Así que quiero comenzar mi charla con las fatigas del esquema. Entonces tenemos dos formas principales de comunicarse desde su servidor y cliente. Tenemos Open API, y tenemos GraphQL. Entonces Open API es la especificación de Open API, la interfaz agnóstica de lenguaje final. Entonces conoces los verbos HTTP como POST, GET, PATCH, DELETE, etcétera, etcétera. Y es un nuevo lenguaje para conocer.

Entonces, si quieres usar Open API, tienes que aprender una nueva especificación. Luego necesitas escribir JSON o YAML sensible a mayúsculas y minúsculas. Por cierto, YAML apesta. Y tienes que generar tu esquema, tus tipos de TypeScript, cada vez que cambias algo en la documentación de Open API.

Bien. Veamos la parte de GraphQL. Con GraphQL, es una consulta de datos de código abierto, lenguaje de manipulación, nuevamente lenguaje, y necesitas aprender cosas nuevas. Entonces es un formato de GraphQL. Y necesitas aprender la nueva especificación, así que consulta, mutaciones, cosas así, y así sucesivamente. Y luego siempre tienes que generar tus tipos de TypeScript.

Entonces, si cambias algo en el GraphQL, necesitas generar este tipo y lo vuelcas en el cliente.

Bien. Estoy luchando mucho con este tipo de cosas porque estoy trabajando en una empresa de consultoría, Flowing, y encontré una solución en TRPC, y luego te mostraré cómo.

Mi usuario en LinkedIn y Twitter es Giorgio underscore boa. Si quieres tuitear sobre esta charla y etiquetarme y también etiquetar la conferencia, lo agradecería mucho. Así que volvamos a TRPC. TRPC es una biblioteca bastante famosa. Más de 100,000 descargas semanales en npm y más de 60,000 estrellas en GitHub. Así que bastante popular. Bien.

Toda la biblioteca se basa en este tipo que puedes ver en la pantalla. Bien. Así que aquí tenemos un objeto. Mi objeto de trabajo con mi nombre y apellido. Y con el tipo de, podemos extraer la forma de este objeto para obtener un tipo. Bien. Y ahora mostraremos cómo funciona con TRPC.

Aquí tengo una aplicación de Next JS, una simple, y decidí agregar desde cero TRPC para mostrarte lo fácil que es implementarlo. Así que también creé una conexión con Prisma porque TRPC y Prisma son realmente una gran combinación. Bien. Así que aquí tenemos nuestro esquema, el esquema de Prisma es nuestro modelo, modelo de autor, bien, y tenemos una semilla porque Prisma puede ayudarnos con la semilla en nuestra base de datos si está vacía. Bien, tenemos una carpeta de origen, y como puedes decir, sabes, en páginas tenemos la carpeta slash API. Dentro de la carpeta API necesitamos crear una carpeta tRPC, y dentro de la carpeta tRPC necesitamos definir un archivo como este con corchetes, y Next para nosotros toma todos los parámetros de consulta y nos da la información. Así que necesitamos exponer este endpoint. En este endpoint definimos desde tRPC next con esta API, definimos nuestro endpoint. En este endpoint tenemos algunas configuraciones, pero lo más importante es este up-router. En este up-router tenemos la posibilidad de definir muchos enrutadores. Aquí solo tenemos el enrutador de autor y aquí tenemos el tipo de que mencioné antes. Así que, de este objeto estamos extrayendo la forma del objeto y definiendo el up-router. Este tipo es realmente importante para el cliente. Y ahora veremos cómo. Este es mi enrutador de autor y en este enrutador de autor, tengo algunos procedimientos diferentes. Así que, defino para obtener una lista de autores, puedo agregar autores y luego puedo eliminar uno, por supuesto. Así que, esta es mi lógica de negocio y en la lógica de negocio, pongo la API de Prisma. Así que, Prisma autor punto encontrar muchos o, por ejemplo, si quiero agregar un nuevo autor, Prisma autor encontrar primero y luego si no está presente, crearé el registro.

Bien, pero saltemos al cliente. Vemos antes que exportamos el tipo up-router. Así que, estamos extrayendo la forma de este enrutador y ahora en la carpeta del cliente, definimos el archivo TRPC, y en este archivo, hay algunas configuraciones, pero la parte más importante es esta crear TRPC next con el genérico y aquí definimos el up-router. El up-router llega directamente de la carpeta que vimos antes. Así que, enrutadores del servidor guion bajo app.

De esta manera, somos capaces de usar TRPC en la parte del cliente. Entonces, aquí está nuestro índice slash, vale, la propia página de nuestra aplicación. Podemos usar TRPC así, TRPC punto autor punto lista, pero si elimino esta lista y yo presiono control espacio, como puedes ver con TypeScript, somos capaces de saber que puedo llamar al añadir, eliminar, y listar. Y esto es genial porque no generamos ningún tipo de tipos para hacer eso, es todo de serie.

Vale, entonces, vale, genial, como puedes ver aquí, estamos buscando a los autores. Luego gestionamos el manejo de la eliminación y el guardado, y cada vez que guardo y elimino, yo invalido la lista para refrescar la lista. Así que podemos iniciar nuestra aplicación. Aquí hay algunos códigos de Prisma. Vale. Y si vamos aquí, tenemos esta lista, y con el botón de guardar guardamos un nuevo autor, y luego podemos eliminarlos. Genial. Una cosa realmente genial es que si vas a los enrutadores, en el enrutador del autor, genial, y decidimos cambiar el nombre del procedimiento, así que cambiemos este, podemos renombrar el Añadir a nuevo, y boom, en el índice aquí, puedes ver que TypeScript lo renombró por mí, así que es realmente genial. Pero si decidimos, no hacerlo con el símbolo renombrado, sino hacerlo manualmente, así que elimino aquí cabeza, vale, si lo hacemos manualmente, como este, tan pronto como me muevo al índice, podemos ver que TypeScript me notifica que algo cambió internamente. Así que es un gran beneficio interactuar desde tu servidor y la parte del cliente, y creo que esto es genial.

Pero quiero mostrarte más. Ahora vamos a profundizar en la biblioteca, porque quiero mostrarte cómo funciona por dentro. Así que permíteme refactorizar mi clase. Aquí, añadir nuevo, eliminar, guardar. Así que creo que ahora está bien. Así que si voy aquí. Sí, perfecto. Si abro la inspección, coloco algunos puntos de interrupción en la biblioteca del cliente de TRPC. Vale, así que si hago clic en este, genial. Y refresco. Como puedes ver aquí, estamos definiendo, estamos en el cliente TRPC. Quizás no puedes ver. Quizás sí. Vale, estamos dentro del cliente TRPC, y estamos definiendo los métodos. Así que, la consulta es un get, la mutación es un post, por supuesto, porque una mutación necesita tener algo de información extra. Vale, si seguimos, hicimos el depurador, y habilitamos esto para debug.

Vale, refrescar. Quizás puedo, vale. Vale, acercar un poco. Vale, como puedes ver, tenemos use query. Esta es nuestra función interna, y dentro de use query, tenemos el path, así que author.list. Si seguimos con el depurador, tenemos la mutación, así que tenemos author.add, y también author.delete. Genial.

Y quiero mostrarte otras cosas desde el cliente. Si seguimos, aquí tenemos la solicitud HTTP, así que bajo el capó, la biblioteca va a desencadenar una solicitud HTTP, y mira la URL. Así que como puedes ver, slash API slash TRCP slash blah blah blah. Así que author.list es nuestro procedimiento, y luego tienes un montón de parámetros que Next.js bajo el capó, recoge para nosotros, y luego nosotros, la parte del cliente de TRCP es capaz de llamar a nuestra lógica de negocio. ¿Pero cómo? Veamos en acción la parte del cliente, la parte del servidor.

Así que si pongo un depurador aquí, y ejecuto, quizás detengo este, y ejecuto el depurador desde el Visual Studio Code, la aplicación, por supuesto, es la misma, porque es la misma base de código. Vale. Como puedes ver aquí, tenemos un punto de interrupción en nuestra parte de la lógica de negocio. Pero si retrocedemos un poco, podemos ir a la biblioteca. Así que aquí puedes ver TRCP server, este index dot blah, blah, blah. ¿Vale? Así que si refresco la aplicación, quiero mostrarte esta propiedad en particular. Así que vamos a comprobar. Vale. Genial. Así que dentro de OPTS, tenemos procedimientos. Dentro de estos procedimientos, tenemos list, add y delete. Y esta es la función interna del servidor TRPC. Y dentro de delete, tenemos underscore def. Y dentro de underscore def, tenemos el resolutor. Resolver es una función. Tenemos cosas de Webpack. Pero al final, la función es nuestra función. Así que Prisma dot author dot find many.

Selecciónalos. Blah, blah, blah. Entonces, si ejecuto la aplicación, como puedes ver, todo el flujo termina aquí. Así es más o menos como funciona el servidor TRPC.

Genial. Entonces, volvamos a las diapositivas. Para discutir sobre las ventajas y desventajas de la biblioteca.

Entonces, ventajas. No hay code generation, como viste antes. No generamos ningún tipo de código sobre nuestros procedimientos, mutaciones y cosas así. Seguridad de tipo por defecto. Así que cambiamos el nombre del procedimiento, y TypeScript pronto nos alertó de que algo estaba mal. Y luego, mejor colaboración entre el front end y el back end. Porque tenemos un gran lenguaje, porque en el back end, llamamos al add, y en el front end lo mismo. Con REST API, a veces el nombre de la función es diferente. Así que ahora, con esta biblioteca, creo que la colaboración es mejor.

¿Cuáles son las desventajas? Pila Typescript. Así que necesitas tener back end en TypeScript, y front end en TypeScript también. Si quieres tener una versión de tu API, o seleccionar algunos campos particulares en un modelo, quieres seleccionar solo un campo, cosas así, necesitas crear más procedimientos. Uno para la versión 1, uno para la versión 2, y así sucesivamente. Y otra desventaja, que no es realmente una desventaja. Si necesitas exponer esta API al público, necesitas usar esta biblioteca en particular. Esta biblioteca está encima de TRPC y es TRPC-openAPI. Así que con un decorador, puedes exponer esta API al público y también crear la documentation de open API.

Genial. Entonces, un resumen. Si quieres empezar ahora mismo con TRPC, puedes usar create.t3.gg. Esta biblioteca inicia la aplicación TRPC con Tailwind, Prisma, NextAuthentication, y etc, etc. Muchas cosas que hacer sin configuración manual y es realmente genial. ¿Quién está usando TRPC? Netflix, InterValcal.com, pero en este problema en particular, puedes encontrar muchas empresas que firmaron el nombre para mostrar que están usando TRPC y si quieres probarlo ahora, puedes ir a trpc.io y encontrarás muchos recursos sobre TRPC.

Así que aquí inserto una diapositiva para tomar una foto de ustedes porque necesito demostrarle a mi esposa que estuve en la conferencia. ¿Pueden saludar? Hola. Genial, genial. Gracias. Muchas gracias Giorgio. Por favor, ven a nuestro stand de Preguntas y Respuestas.

Esa fue una gran charla. He sido un poco perezoso yo mismo aprendiendo sobre TRPC y me alegro de no haberlo hecho porque ahora lo aprendí de ti. Así que fue tiempo bien invertido. Eso es asombroso. Y creo que muchas otras personas también han aprendido mucho porque tenemos muchas buenas preguntas aquí.

Y por supuesto tenemos que empezar con la primera pregunta. Es la pregunta de Elon. Vale. ¿Aprobaría Elon Musk más de 200 llamadas TRPC y cómo te aseguras de que no estén mal agrupadas? Vale. Creo que Elon Musk es demasiado exigente. Déjame decir. Bueno, depende de tu contexto. Tienes que razonar sobre la pila TRPC. Y si tienes muchos procedimientos, necesitas dividirlos en muchos servicios y luego comunicarte con los servicios, con TRPC o quizás otros canales. Sí. Vale. Así que básicamente no sabe de lo que está hablando. Sí. Sí. Nunca, nunca. Ellie está aplaudiendo allí. Sí, un aplauso muy triste. Vale. Sigamos.

Esta es una pregunta que también me estaba haciendo. ¿Cómo manejarías una situación en la que tienes múltiples front-ends que no están en un mono-repo con un back-end, ¿verdad? ¿Es eso algo que TRPC puede soportar o es solo para ese tipo de back-end para front-end arquitectura?

Vale. Así que tienes un mono-repo con un ... No tienes un mono-repo. No tienes un mono-repo. Así que tienes un cliente en un repositorio y tienes un servidor en otro repositorio. ¿Cómo se mantienen estas dos cosas sincronizadas y cómo se comunican? Vale. Esta es una pregunta realmente buena. Desafortunadamente, tengo la respuesta. Así que puedes ... Si tienes múltiples repositorios, pierdes la característica de refactorización, por supuesto, porque tienes la base de código en dos partes diferentes. Pero si encapsulas el tipo de router dentro de nuestra biblioteca, puedes incluir esa biblioteca en el cliente. Pero al final, tendrás problemas con las cosas de versionado y cosas así. Así que puedes hacerlo. ¿Lo recomendarías? Creo que el enfoque de TypeScript de pila completa es el mejor. Pero si quieres incluir TRPC en tu aplicación con múltiples repositorios, puedes hacerlo.

La siguiente pregunta es una cuestión de escala, como siempre. ¿Puede TRPC funcionar para aplicaciones a gran escala, especialmente monolitos? ¿O es más adecuado para aplicaciones más pequeñas y microservicios? Creo que es mejor con microservicios y crear múltiples servicios. Hay algunas POC del autor de TRPC que muestran cómo integrar múltiples servicios para comunicarse y crear una arquitectura de microservicios. Eso es genial.

Hay una pregunta. ¿Cuáles son las ventajas de TRPC sobre Relay, específicamente, el marco de Relay de Facebook? ¿Lo has usado y sabes cuáles podrían ser las ventajas? No. Sí, esa es una pregunta difícil, creo. Relay es una de esas cosas donde las personas que lo aman realmente lo aman y todos los demás no lo entienden. Así que hablen entre ustedes, encuentren un amigo de Relay y convénzanse mutuamente de usarlo. No creo que haya respondido a esta pregunta tampoco.

Es una pregunta de Elon Musk. ¿Cómo manejas el almacenamiento en caché y la invalidación de la caché de las entidades en TRPC? ¿Está incorporado o tienes que hacerlo tú mismo? Hander De Hoody está utilizando una consulta de React por lo que puedes aprovechar todas las características de una consulta de React. También una característica interesante de TRPC es la agrupación. Así que si en un segundo lanzas muchas llamadas, Hander De Hoody las agrupa para crear cosas interesantes.

Genial. Permíteme ver, hay un par de preguntas más, tal vez déjame pasarlas por la moderación y luego las leeremos juntas. Aquí vamos.

¿tRPC maneja condiciones de carrera cuando varias personas acceden a la API para realizar la misma acción? ¿O cosas como esa se delegan a Prisma? Básicamente creo que la pregunta es sobre la resolución de conflictos. La resolución de conflictos está dentro de tu lógica de negocio. Como mostré antes, si quiero crear otro autor con el mismo apellido, el apellido en este caso es la clave, la clave primaria, necesitas comprobar antes si la clave primaria existe o no. Y luego, si existe, lanza una excepción. De acuerdo.

Esta es una pregunta interesante. ¿tRPC solo para clientes? ¿Tiene tRPC algún uso si en realidad no tienes un componente de servidor? No hay mucho que puedas hacer con él, ¿verdad? Creo que no. No. Entonces, el cliente tRPC no tiene sentido sin el servidor tRPC. Porque está llamando al endpoint trcp, trpc, y no. Sí. Por cierto, tRPC, es un verdadero trabalenguas para decir. Así que RPC son llamadas a procedimientos remotos. Pero, ¿qué significa la T? ¿Es TypeScript o tipos? TypeScript, creo que es TypeScript RPC. Porque RPC está llamando a una función de otro servidor. Confundo mucho trcp, trcp. Es un lío. Sí.

Muy bien. Bueno, vamos a entrar en nuestro tema candente, cuestión espinosa. ¿Crees que GraphQL o REST es mejor que tRPC en algunos casos? ¿Hay casos en los que tRPC no va a ser la solución correcta y GraphQL o REST sería un enfoque mejor? Sí, estoy sonriendo. Porque conozco la respuesta. ¿Vale? En algunos contextos, tRPC es muy bueno. Pero si necesitas exponer con una API pública, tal vez la API REST es mejor, GraphQL también. Si tienes múltiples clientes, como digamos TV, móvil, y aplicación frontend, y necesitas obtener alguna propiedad de un modelo, tal vez GraphQL se ajuste mejor para ti. Así que hay muchos casos de uso para usar GraphQL y OPA API también. Esto no será un reemplazo para ellos, por lo que puede ser una buena solución en algunos contextos.

Bien, sí. Siempre usa la mejor herramienta para el trabajo. No hay una bala de plata o un martillo mágico. Y siempre depende. Depende, por supuesto. ¿TRPC proporciona una verificación de tipos en tiempo de ejecución o la validation de los data que entran en la API? Sí, esta es una parte que necesito omitir por el momento. Pero cuando llamas a una mutación, tienes en el objeto de entrada por supuesto, si quiero añadir un autor necesito pasar el nombre, el apellido, y en este caso, el país. Y luego tienes Zod y muchas otras bibliotecas para la validation de la entrada, y lanzar una excepción y notificarte que estás pasando algo incorrecto. Así que Zod está en la capa base para TRPC y hay muchas otras bibliotecas de validation que pueden ser útiles en este caso. Es increíble cuánto ha tomado Zod realmente como el mundo del desarrollo de TypeScript por asalto porque ha habido bibliotecas para esto siempre pero creo que Zod acierta en algo sobre la API. Es tan amigable de usar. Es realmente asombroso. Es muy agradable. Lo uso para todo también. Es maravilloso. Muy bien, sigamos. Tenemos tiempo para un par de preguntas más. Esta es interesante. ¿Podemos usar TRPC para la comunicación de servicio a servicio? ¿O es solo para cuando tienes un frontend hablando contigo? Mencionamos antes la arquitectura de múltiples microservicios, por lo que puedes usarlo para la comunicación. Permíteme hacer mi propia pregunta porque esto es algo que me estaba preguntando. Por ejemplo, si miras otros marcos de RPC como gRPC de Google, una de las razones por las que es realmente bueno para la comunicación entre servicios es que maneja cosas como la versión de las cosas siempre puedes agregar en documentos sin romper los servicios existentes y hace el empaquetado binario de diseño de cosas por lo que es muy eficiente para las cosas. ¿Está tRPC en absoluto preocupado por estas cosas o es principalmente como una solución más sencilla para donde tRPC podría ser excesivo? Creo que si tienes múltiples servicios en múltiples repositorios tienes el mismo problema porque necesitas versionar el tipo y luego usar la versión correcta para el servicio correcto por lo que si cambias algo en múltiples servicios terminas con un despliegue de gran alcance. Así que eso va a ser un desafío por lo que tal vez tRPC sigue siendo mejor para la comunicación entre servicios. Aquí hay una pregunta, parece que los CMS sin cabeza son un gran tema hoy en día, ¿has trabajado con tRPC para casos de uso clásicos de CMS sin cabeza y es beneficioso allí? No, no he usado tRPC para CMS sin cabeza. Actualmente estoy trabajando con DATO CMS y estoy usando GraphQL y termino en la fatiga del esquema. Así que si cambio algo en el esquema, necesito crear todos los tipos de typescript y es un lío. Bien. Vale, y una última pregunta. Esta es la fácil. Aquí vamos, esta. Así que en primer lugar, felicitaciones por hacer una charla de codificación en vivo y no estropear nada. ¿Podemos aplaudir a Giorgio? Eres más valiente que yo. Bien hecho. Entonces, ¿dónde podemos encontrar el código de tu demostración? ¿Está disponible en algún lugar donde la gente pueda verlo? Sí, puedo compartir mi repositorio en mi Twitter. Y también etiqueto a la conferencia por supuesto. Así que puedes encontrar todo el código y las diapositivas allí. Sí, por favor, haz fotos de Giorgio para Giorgio para que su esposa no se ponga demasiado celosa de nosotros y de su amor por JavaScript. Ahora vamos a dar un gran aplauso a Giorgio. Muchas gracias.