Despídete de tus esquemas de API con tRPC

Si quieres usar la API abierta, debes aprender una nueva especificación. Luego debes escribir JSON o YAML sensible a mayúsculas y minúsculas. Por cierto, YAML es horrible. Y debes generar tu esquema, tus tipos de TypeScript, cada vez que cambies algo en la documentación de la API abierta. De acuerdo. Veamos la parte de GraphQL. Con GraphQL, es un lenguaje de manipulación y consulta de datos de código abierto, nuevamente un lenguaje, y necesitas aprender cosas nuevas. Así que es un formato GraphQL. Y debes aprender la nueva especificación, por lo tanto, consultas, mutaciones, cosas así, etcétera y así sucesivamente. Y luego siempre debes generar tus tipos de TypeScript. Así que si cambias algo en el GraphQL, debes generar este tipo y lo cargas en el cliente. De acuerdo. Estoy luchando mucho con este tipo de cosas porque trabajo en una empresa de consultoría, Flowing, y encontré una solución en TRPC, y luego te mostraré cómo.

Mi nombre de usuario en LinkedIn y Twitter es Giorgio underscore boa. Si quieres tuitear sobre esta charla y etiquetarme y etiquetar también a la conferencia, lo apreciarí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. Bastante popular. De acuerdo.

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

Aquí tengo una aplicación Next JS, una simple, y decidí agregar TRPC desde cero para mostrarte lo fácil que es implementarlo. También creé una conexión con Prisma porque TRPC y Prisma son realmente una gran combinación. De acuerdo. Aquí tenemos nuestro esquema, el esquema de Prisma es nuestro modelo, modelo autor, y tenemos una semilla porque Prisma puede ayudarnos con la semilla en nuestra base de datos si está vacía. De acuerdo, tenemos una carpeta de origen y, como puedes ver, en las páginas tenemos la carpeta 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 cuadrados, y luego para nosotros, obtener todos los parámetros de consulta y darnos la información. Así que necesitamos exponer este punto final. En este punto final, definimos desde TRPC next con esta API, definimos nuestro punto final. En este punto final, tenemos algunas configuraciones, pero lo más importante es este enrutador 'up'. En este enrutador 'up', tenemos la posibilidad de definir muchos enrutadores. Aquí solo tenemos el enrutador de autores y aquí tenemos el tipo del que mencioné antes. Entonces, a partir de este objeto, estamos extrayendo la forma del objeto y definiendo el enrutador 'up'. Este tipo es realmente importante para el cliente. Y ahora veremos cómo. Este es mi enrutador de autores y en este enrutador de autores, tengo algunos procedimientos diferentes. Entonces, defino obtener una lista de autores, puedo agregar autores y luego puedo eliminar uno, por supuesto. Esta es mi lógica empresarial y en la lógica empresarial, utilizo la API de Prisma. Por ejemplo, Prisma.author.findMany o, por ejemplo, si quiero agregar un nuevo autor, Prisma.author.findFirst y luego, si no está presente, crearé el registro.

De acuerdo, pero pasemos al cliente. Vimos antes que exportamos el tipo 'up router'. Entonces, 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 enrutador 'up'. El enrutador 'up' llega directamente desde la carpeta que vimos antes, 'server routers_app'.

De esta manera, podemos usar TRPC en la parte del cliente. Así que aquí está nuestro slash index, ok, la propia página de nuestra aplicación. Podemos usar TRPC de esta manera, TRPC.author.list, pero si elimino esta lista y presiono control espacio, como puedes ver con TypeScript, podemos saber que puedo llamar a add, delete y list. Y esto es genial porque no generamos ningún tipo para hacerlo, todo está listo para usar.

Ok, genial, como puedes ver aquí, estamos buscando los autores. Luego gestionamos el manejo de delete y save, e invalidamos la lista cada vez que guardo o elimino para actualizarla. Así que podemos iniciar nuestra aplicación. Aquí hay algunos códigos de Prisma. Ok. Y si vamos aquí, tenemos esta lista, y con el botón save guardamos un nuevo autor, y luego podemos eliminarlos. Genial. Una cosa realmente genial es que si vamos a los enrutadores, en el enrutador de autores, genial, y decidimos cambiar el nombre del procedimiento, así que cambiemos este a new, y boom, en el index aquí, puedes ver que TypeScript lo renombró automáticamente para mí, así que es realmente genial. Pero si decidimos no hacerlo con el símbolo renombrado, sino hacerlo manualmente, así que elimino aquí head, ok, si lo hacemos manualmente, como este, tan pronto como me mueva al index, podemos ver que TypeScript me notifica que algo ha cambiado internamente. Así que es un gran beneficio interactuar desde tu parte del servidor y 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 internamente. Así que voy a refactorizar mi clase. Aquí, añadir nuevo, eliminar, guardar. 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 cliente de TRPC. Ok, si hago clic en este, genial. Y actualizo. Como puedes ver aquí, estamos definiendo, estamos dentro del cliente TRPC. Tal vez no puedas verlo. Tal vez sí. Ok, estamos dentro del cliente TRPC, y estamos definiendo los métodos. La consulta es un get, la mutación es un post, por supuesto, porque una mutación necesita tener alguna información adicional. Ok, si continuamos, hicimos un depurador, y habilitamos esto para debug.

De acuerdo, actualicemos. Quizás pueda, de acuerdo. Ampliemos un poco. De acuerdo, como puedes ver, estamos usando useQuery. Esta es nuestra función interna, y dentro de useQuery, tenemos la ruta, por ejemplo, author.list. Si continuamos con el depurador, tenemos la mutación, por lo tanto, tenemos author.add y también author.delete. Genial.

Y quiero mostrarte otras cosas desde el cliente. Si continuamos, aquí tenemos la solicitud HTTP, por lo tanto, bajo el capó, la biblioteca va a desencadenar una solicitud HTTP y mira la URL. Como puedes ver, slash API slash TRPC slash blah blah blah. Entonces, author.list es nuestro procedimiento, y luego tienes muchos parámetros que Next.js, bajo el capó, recopila para nosotros, y luego nosotros, la parte del cliente de TRPC, podemos llamar a nuestra lógica del negocio. Pero ¿cómo? Veamos en acción la parte del cliente, la parte del servidor.

Entonces, si coloco un depurador aquí y lo ejecuto, tal vez detenga este, y ejecuto el depurador desde Visual Studio Code, la aplicación, por supuesto, es la misma, porque es la misma base de código. De acuerdo. Como puedes ver aquí, tenemos un punto de interrupción en nuestra parte de la lógica del negocio. Pero si retrocedemos un poco, podemos ir a la biblioteca. Aquí puedes ver TRPC server, este índice punto blah, blah, blah. ¿De acuerdo? Si actualizo la aplicación, quiero mostrarte esta propiedad en particular. Así que vamos a comprobar. De acuerdo. Genial. 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 resolvedor. El resolvedor es una función. Tenemos cosas de Webpack. Pero al final, la función es nuestra función. Entonces, Prisma.author.findMany.

Seleccionarlos. Blah, blah, blah. Así que 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. Volvamos a las diapositivas. Para hablar de las ventajas y desventajas de la biblioteca.

Entonces, las ventajas. Sin generación de código, como viste antes. No generamos ningún tipo de código para nuestros procedimientos, mutaciones, etc. Seguridad de tipos por defecto. Si cambiamos el nombre del procedimiento, TypeScript nos alertará de inmediato si algo está mal. Y luego, una mejor colaboración entre el front-end y el back-end. Tenemos un lenguaje común, porque en el back-end llamamos a la función add, y en el front-end hacemos lo mismo. Con una API REST, 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? Stack de TypeScript. Necesitas tener el back-end y el front-end en TypeScript. Si quieres tener una versión de tu API o seleccionar algunos campos específicos en un modelo, como seleccionar solo un campo, cosas así, necesitas crear más procedimientos. Uno para la versión 1, otro para la versión 2, y así sucesivamente. Y otra desventaja, que en realidad no es una desventaja. Si necesitas exponer esta API al público, necesitas utilizar esta biblioteca en particular. Esta biblioteca se llama TRPC-openAPI. Con un decorador, puedes exponer esta API públicamente y también crear la documentación de la API abierta.

Genial. En resumen, si quieres empezar ahora mismo con TRPC, puedes utilizar create.t3.gg. Esta biblioteca inicia una aplicación TRPC con Tailwind, Prisma, NextAuthentication, etc., etc. Hay muchas cosas que hacer sin necesidad de configuración manual y es realmente genial. ¿Quién está utilizando TRPC? Netflix, InterValcal.com, pero en este problema en particular, puedes encontrar muchas empresas que han firmado para mostrar que están utilizando TRPC. 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 decir hola? Hola. Genial, genial. Gracias. Muchas gracias, Giorgio. Por favor, pasen a nuestro stand de preguntas y respuestas.

Esa fue una gran charla. Yo mismo he sido un poco vago al aprender sobre TRPC y me alegra no haberlo hecho porque ahora lo aprendí de ti. Así que ese tiempo fue bien invertido. Eso es increíble. 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. ¿Elon Musk aprobaría 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. Permíteme decirlo. Vale, depende de tu contexto. Tienes que razonar sobre el stack de TRPC. Y si tienes muchos procedimientos, necesitas dividirlos en muchos servicios y luego comunicarte con los servicios, con TRPC o tal vez otros canales. Sí, vale. Así que básicamente él no sabe de qué está hablando. Sí, sí. Nunca, nunca. Ellie está aplaudiendo allí. Sí, un aplauso muy triste. Vale. Sigamos adelante.

Esta es una pregunta en la que también estaba pensando. ¿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 algo que TRPC puede admitir o solo es para ese tipo de arquitectura de back-end para front-end?

De acuerdo. Entonces tienes un mono-repo con un... No tienes un mono-repo. No tienes un mono-repo. Entonces tienes un cliente en un repositorio y tienes un servidor en otro repositorio. ¿Cómo se mantienen sincronizadas estas dos cosas y cómo se comunican? De acuerdo. Esta es una pregunta realmente buena. Desafortunadamente, tengo la respuesta. Entonces puedes... Si tienes múltiples repositorios, pierdes la función de refactorización, por supuesto, porque tienes la base de código en dos partes diferentes. Pero si encapsulas el tipo de enrutador dentro de nuestra biblioteca, puedes incluir esa biblioteca en el cliente. Pero al final, tendrás problemas con la versión de las cosas 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 pregunta sobre 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 pruebas de concepto 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 complicada, creo. Relay es una de esas cosas en las que las personas que lo aman realmente lo aman y todos los demás no lo entienden. Así que hablen entre ustedes, encuentren a un compañero de Relay y convéncanse mutuamente de usarlo. Creo que tampoco he respondido esta pregunta.

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

Genial. Permíteme ver, hay un par de preguntas más, déjame que las pase por moderación y luego las leeremos juntos. Aquí vamos.

¿tRPC maneja las condiciones de carrera cuando varias personas acceden a la API para realizar la misma acción? ¿O se encarga de eso Prisma? Básicamente, creo que la pregunta se refiere a la resolución de conflictos. La resolución de conflictos se encuentra dentro de tu lógica empresarial. Como mostré antes, si quiero crear otro autor con el mismo apellido, el apellido en este caso es la clave, la clave primaria, debes verificar antes si la clave primaria existe o no. Y luego, si existe, lanzar una excepción. Muy bien.

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

Muy bien. Bueno, entremos en nuestro tema candente, la patata caliente. ¿Crees que GraphQL o REST son mejores que tRPC en algunos casos? ¿Hay casos en los que tRPC no será la solución adecuada y GraphQL o REST serían un enfoque mejor? Sí, estoy sonriendo. Porque sé la respuesta. ¿De acuerdo? En algunos contextos, tRPC es muy bueno. Pero si necesitas exponer una API pública, tal vez una API REST sea mejor, GraphQL también. Si tienes múltiples clientes, como digamos TV, móvil y una aplicación de frontend, y necesitas obtener alguna propiedad de un modelo, tal vez GraphQL sea más adecuado para ti. Así que hay muchos casos de uso para usar GraphQL y API REST también. Esto no será un reemplazo para ellos, por lo que puede ser una buena solución en algunos contextos.

Genial, sí. Siempre usa la mejor herramienta para el trabajo. No hay una bala de plata o martillo mágico. Y siempre depende. Depende, por supuesto. ¿TRPC proporciona una verificación de tipo en tiempo de ejecución o la validación de los datos que ingresan a la API? Sí, esta es una parte que debo omitir por el momento. Pero cuando llamas a una mutación, tienes en el objeto de entrada, por supuesto, si quiero agregar un autor, necesito pasar el nombre, apellido y en este caso, el país. Y luego tienes Zod y muchas otras bibliotecas para validar la entrada y lanzar una excepción y notificarte que estás pasando algo incorrecto. Entonces, Zod está en la capa base de TRPC y hay muchas otras bibliotecas de validación que pueden ser útiles en este caso. Es increíble cuánto ha ganado popularidad Zod en el mundo del desarrollo de TypeScript, porque ha habido bibliotecas para esto desde siempre, pero creo que Zod simplemente hace algo bien con la API. Es tan fácil de usar. Es realmente asombroso. Es muy bueno. También lo uso para todo. Es maravilloso. Muy bien, sigamos adelante. Tenemos tiempo para un par de preguntas más. Esta es interesante. ¿Podemos usar TRPC para la comunicación entre servicios? ¿O solo cuando tienes una interfaz de usuario que se comunica 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 preguntaba. Por ejemplo, si miras otros marcos de RPC como gRPC de Google, una de las razones por las que es muy bueno para la comunicación entre servicios es que maneja cosas como la versión de las cosas que siempre puedes agregar a los documentos sin romper los servicios existentes y hace el empaquetado binario, por lo que es muy eficiente para las cosas. ¿TRPC se preocupa por estas cosas o es principalmente una solución más simple 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 una implementación masiva. Así que eso va a ser un desafío, por lo que tal vez TRPC sea mejor para la comunicación entre servicios. Aquí hay una pregunta, parece que los CMS sin cabeza son un tema importante hoy en día, ¿has utilizado TRPC para casos de uso clásicos de CMS sin cabeza y es beneficioso allí? No, no he utilizado TRPC para CMS sin cabeza. Actualmente estoy trabajando con DATO CMS y estoy usando GraphQL y termino con fatiga de esquema. Si cambio algo en el esquema, necesito crear todo el tipo de TypeScript y es un lío. Genial. De acuerdo, y la última pregunta. Esta es fácil. Aquí vamos, esta. En primer lugar, felicidades por hacer una presentación de codificación en vivo y no arruinar nada. ¿Podemos aplaudir a Giorgio? Eres un hombre valiente. 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 etiqueto también a la conferencia, por supuesto. Entonces puedes encontrar todo el código y las diapositivas allí. Sí, por favor, tuitea fotos sobre Giorgio para Giorgio, para que su esposa no se ponga demasiado celosa de nosotros y de su amor por JavaScript. Ahora demos un gran aplauso a Giorgio. Muchas gracias.