Cómo, por qué y cómo usar tRPC por su creador
tRPC - Mueve rápido y no rompas nada
Video Summary and Transcription
tRPC es una herramienta que simplifica el desarrollo de API al permitirte llamar funciones en el backend y tener los datos de tipo inferidos en el frontend sin generación de código. Proporciona seguridad de tipo y autocompletado al consultar bases de datos usando Prisma. tRPC se puede utilizar con varios frameworks de frontend y tiene características como batching automático y middlewares. Se puede compartir entre repositorios utilizando un monorepo o publicando los tipos como un paquete npm. tRPC es fácil de configurar en comparación con gRPC y proporciona validación de entrada y salida incorporada.
1. Introducción a TRPC y Desarrollo de API
Estoy muy feliz de estar aquí para hablar de mi bebé, TRPC. Realmente está creciendo mucho. Pero quiero preguntar, ¿quién aquí ha usado TRPC? Un poco sobre mí. Comencé a hacer sitios web usando Microsoft Frontpage. Y luego me pasé a Node.js principalmente en 2011. PHP siempre ha sido como una estrella polar en DX para mí. Desde que dejé PHP, tenemos que trabajar con APIs. Pasamos mucho tiempo discutiendo sobre cuál es la forma correcta de los datos. Y solo mira cómo hacemos una API hoy en día. Así que me pregunto si podríamos hacer que las APIs sean tan fáciles como llamar a una función, porque muchos de nosotros aquí hoy, todos somos personas de Node, probablemente estaremos usando JavaScript tanto en el frontend como en el backend.
Entonces, bienvenidos. Estoy muy feliz de estar aquí para hablar de mi bebé, TRPC. Sí, mi bebé está creciendo mucho. En este momento tenemos más de 24,000 estrellas en GitHub, acercándonos a las 200,000 descargas semanales de npm y no muestra signos de desaceleración. Realmente está creciendo mucho. Pero quiero preguntar, ¿quién aquí ha usado TRPC? OK. Muy bien. Espero que haya más después de hoy. Un poco sobre mí. Aquí estoy en mi primera sesión de programación en grupo a los ocho o nueve años, tal vez. Alrededor de esta edad, también comencé a hacer sitios web usando Microsoft Frontpage. Y luego comencé con este tipo de pila LAMP, PHP y MySQL. Y me pasé a Node.js principalmente en 2011 o algo así. Y PHP para mí siempre ha sido como una estrella polar en DX. Realmente me encantaba la simplicidad de poder llamar a una consulta de base de datos junto con tu HTML y simplemente renderizarlo. ¿Se apagó? Vale, problemas técnicos. Vale, se duerme si no lo toco durante un tiempo. Así que voy a acelerar. Pero sí, desde que dejé PHP, sabes, tienes que trabajar con las APIs, cuando haces aplicaciones nativas, también trabajé con eso. Tienes que trabajar con API. Así que siento que cada vez que construimos o consumimos APIs, es un dolor, pasamos mucho tiempo haciendo especificaciones de API. Pasamos mucho tiempo discutiendo sobre cuál es la forma correcta de los datos. Y tenemos muchas herramientas fragmentadas para lidiar con eso tanto en el backend como en el frontend. Y solo mira cómo hacemos una API hoy en día. Así que hoy, por lo general, cuando comienzas a hacer una API, comienzas con una especificación porque quieres tener un contrato entre tu backend y frontend. Para que sepas cómo debería lucir la forma de tus datos. Y luego, con suerte, tienes alguna generación de código para tener un entorno seguro en el backend, donde validas que tu API cumple con la especificación y allí también escribes tu lógica empresarial real. Y luego, en tu frontend, escribes, en el caso de GraphQL, escribes una consulta GraphQL y luego esperas un poco más de generación de código y luego obtienes un buen hook al final, en el caso de React, que puedes usar. Y siento que hay demasiados pasos en esto. Así que me pregunto si podríamos hacer que las APIs sean tan fáciles como llamar a una función, porque muchos de nosotros aquí hoy, todos somos personas de Node, probablemente estaremos usando JavaScript tanto en el frontend
2. Llamando funciones y consultando bases de datos con TRPC
Entonces, en TRPC, puedes llamar a una función en tu backend y tener los datos de tipo inferidos en tu frontend sin generación de código. Puedes configurar un enrutador, definir un procedimiento y usar validadores seguros de tipo como Zod. TRPC te permite construir APIs seguras de tipo fácilmente sin esquemas ni generación de código. También puedes consultar una base de datos usando Prisma y obtener autocompletado y seguridad de tipo en tu frontend.
Y nuevamente, un ejemplo un poco más completo, en este caso, estamos consultando una base de datos. Aquí tenemos un enrutador de publicaciones donde puedes consultar publicaciones por ID, puedes consultar una lista, puedes agregar una publicación. Entonces aquí tenemos un procedimiento que toma una entrada que es un objeto y un ID. Y decimos que esto es una consulta, usamos Prisma, que es seguro en términos de tipo o M para TypeScript para consultar nuestra base de datos, obtener algunos campos y devolver esa publicación. Lo que obtienes de inmediato en el frontend es el autocompletado de todas tus rutas de API. Obtienes seguridad de tipo y autocompletado en la consulta. Aquí estoy usando la biblioteca React de TRPC. Y luego obtienes ese resultado seguro de tipo directamente desde la base de datos. Si cambias algo aquí, se actualizará de inmediato en tu frontend. Para mostrarte algo de codificación en vivo, grabé un video justo antes de esta charla hoy porque la codificación en vivo en el escenario es un poco arriesgada.
3. Aplicación de inicio de TRPC y seguridad de tipo
Aquí tenemos una aplicación de inicio de TRPC donde puedes ver algunos posts, agregar un post y ver el post. El enfoque está en la página y cómo funciona. En la aplicación Next, la carpeta de páginas contiene el componente React para el ID del post. La consulta para el post por ID proporciona una respuesta segura de tipo desde la base de datos. Al hacer clic en el hook de React, vamos directamente a la función del backend. Al editar el retorno de la base de datos, se muestran inmediatamente errores de tipo en el frontend.
Solo te mostraré aquí, aquí tenemos una aplicación de inicio de TRPC donde puedes ver algunos posts, puedes agregar un post y si enviamos esto, obtenemos algún error de validación desde el backend porque nuestro texto es demasiado corto. Y luego puedes ir y ver ese post. Entonces, en lo que quiero enfocarme es en esta página, cómo funciona. Entonces aquí podemos ver, tenemos una aplicación Next aquí y en nuestra carpeta de páginas tenemos este post/ID que corresponde a este componente React aquí. Y aquí consultamos el post por ID y puedes ver que tenemos una respuesta segura de tipo de nuestra consulta a la base de datos de inmediato. Y si hago clic en mi hook de React, en realidad voy directamente a mi backend en esta función que estoy definiendo. No hay pasos adicionales en eso. Y si tomamos esto lado a lado y editamos lo que vamos a devolver en esa base de datos, obtendremos errores de tipo de inmediato en nuestro frontend. Entonces, sin siquiera guardar el archivo, comentas eso y obtenemos un error de tipo.
4. Beneficios de tRPC para Colaboración y Desarrollo
Y con tRPC, puedes tener una mejor colaboración entre los equipos de backend y frontend. tRPC no está vinculado a React o Node.js y no tiene dependencias. Puedes usarlo en demo, Svelte, React Native, y no hay pasos de compilación. Proporciona una seguridad de tipo mágica para el desarrollo web y móvil de pila completa. Puede ser utilizado como backend para frameworks frontend y para la comunicación entre servicios. tRPC tiene características como batching automático, middlewares y contexto de solicitud.
5. TRPC Middleware and Ecosystem
Aquí tenemos un middleware en TRPC que es bastante genial. Te permite crear un procedimiento de protección donde puedes lanzar un error si no hay un usuario en el contexto. Al usar este procedimiento de protección, obtienes un middleware seguro en cuanto a tipos que proporciona un comportamiento confiable. TRPC tiene un gran ecosistema con herramientas como create T3 app, TRPC OpenAPI package y TRPC Chrome. Hay muchos colaboradores en TRPC y empresas de todos los tamaños lo están utilizando. Si estás interesado en TRPC y TypeScript, por favor contáctanos, siempre estamos buscando más personas para contribuir.
6. Compartir el Contrato TS entre Repositorios
Para compartir el contrato TS entre diferentes repositorios de código, el enfoque recomendado es utilizar un monorepo como NX, Turbo repo o Lerna. Esto permite que tanto el frontend como el backend estén en el mismo repositorio, facilitando el intercambio de información de tipos. Sin embargo, tRPC también se puede utilizar con repositorios separados publicando los tipos del backend como un paquete npm. Aunque este enfoque puede no proporcionar todas las comodidades de un monorepo, aún es posible utilizar tRPC sin uno.
Sí, sí, comencemos con el primero. Por cierto, el orden es muy aleatorio para mí. ¿Cómo compartes el contrato TS entre diferentes repositorios de código? Entonces, el enfoque recomendado es utilizar un monorepo, ¿verdad? Puedes usar NX que está aquí o algo como Turbo repo o Lerna o algo así para tener tanto el frontend como el backend en el mismo repositorio, porque luego es más fácil compartir este tipo de información. Pero también puedes usar tRPC con repositorios separados, pero luego necesitas una forma de publicar los tipos de tu backend como un paquete npm que luego puedes importar en el frontend. Y si haces eso, te perderás algunas de las comodidades donde puedes, ya sabes, hacer clic en el comando en la cosa correcta en un paquete y actualizar directamente el backend. Pero definitivamente es posible usarlo también sin un monorepo.
7. Exponiendo el Enrutador de la Aplicación y Compatibilidad
En una configuración de monorepo, la mejor práctica para exponer el enrutador de la aplicación al cliente es crear paquetes separados para la lógica del backend y el cliente, donde solo se exporta el tipo. Esto asegura que la aplicación del backend no sea accesible en el navegador. tRPC se puede utilizar con la función $server de desarrollo rápido, lo que permite reutilizar la misma API en varias aplicaciones. Actualmente se está desarrollando el soporte para bling y proyectos similares. Hay adaptadores disponibles para usar Nest.js con tRPC y hay discusiones en GitHub sobre cómo integrar los dos.
Sí, el siguiente está relacionado con eso. En una configuración de monorepo, donde el backend no está realmente exportando nada, ¿cuál es la mejor práctica para exponer el enrutador de la aplicación al cliente? Entonces, lo que podrías hacer es crear un paquete que sea tu lógica de backend, como su propio paquete, y luego tener aplicaciones que usen tanto tu frontend como tu backend. Y, para hacerlo extra, extra seguro, puedes crear un paquete para el cliente, donde solo exportas el tipo. Así puedes garantizar que tu aplicación de backend nunca termine en el navegador, donde alguien pueda leer ese código fuente.
Genial. Sí, el siguiente. Tal vez sepas cómo responder a esto. ¿Cómo se compara eso con la función $server de desarrollo rápido? Quiero decir, rápido... Creo que tRPC funciona con la función $server de desarrollo rápido. He visto a alguien hacer una prueba de concepto con eso. Con rápido, es muy básico, ¿verdad? Básicamente tienes una función de devolución de llamada con un controlador. Y sí, está muy, muy acoplado a tu aplicación. Y en tRPC, también puedes reutilizar la misma API en varias aplicaciones. Pero también puedes usar tRPC dentro del contexto de funciones de devolución de llamada rápidas. Pero personalmente no he usado mucho rápido. Pero supongo que es similar a lo que he visto con bling y cosas así. Sí, en este momento estamos trabajando en brindar algún tipo de soporte para bling y proyectos similares. Sí. ¿Y qué hay de Nest.js? ¿Se admite allí? Sé que algunas personas lo han usado. Yo no. No he usado mucho Nest.js yo mismo. Pero sé que hay personas que han hecho adaptadores para usarlo. Así que creo que si buscas en Google Nest.js, gRPC, GitHub, hay un montón de, hay, sé que hay una discusión en GitHub
QnA
TRPC Q&A
¿Por qué crees que gRPC no ha generado mucho interés? TRPC es fácil de configurar en comparación con gRPC, ya que no requiere escribir interfaces o esquemas. La sintaxis de TypeScript es suficiente para la definición de contratos en TRPC. TRPC proporciona validación incorporada de entrada y salida, admite varios validadores de entrada y permite la serialización personalizada de JSON. TRPC se puede utilizar en aplicaciones móviles nativas con React Native o Expo. Para clientes en otros lenguajes, se puede utilizar el paquete TRPC Open API para generar una especificación compatible con Open API. Se está desarrollando herramientas para generar clientes TRPC en otros lenguajes. La motivación para construir TRPC fue satisfacer la necesidad del creador después de usar GraphQL durante varios años.
Entonces, ¿qué tan bueno es tu portugués? ¿Dónde vives en Brasil? Quiero decir, es bastante vergonzoso en este punto, como hace cuatro años desde que lo hablé mucho, pero está bien. Sí, tengo una pregunta. ¿Qué hay de las aplicaciones móviles nativas? No estoy seguro a qué diapositiva se refiere eso. Entonces, las aplicaciones móviles nativas son interesantes, así que si estás usando React Native o Expo, puedes usar TRPC de la misma manera. Si quieres usar TRPC y tener clientes en otros idiomas que no sean TypeScript, probablemente quieras usar el paquete TRPC Open API para generar una especificación compatible con Open API, para que luego puedas generar un cliente seguro en el frontend. Estamos trabajando en herramientas para el análisis estático de tu backend TRPC para generar clientes TRPC reales automáticamente en otros idiomas, pero es un poco, no está llegando en los próximos meses o a corto plazo. De acuerdo, si también estás investigando el enfoque de generación . Sí. De acuerdo. ¿Cuál fue tu motivación para construir TRPC? Satisfacer mi
Motivación para construir TRPC
Desde que salió GraphQL, he sido un gran fanático. Pero al construir la aplicación web de mi propia empresa, no necesitaba la flexibilidad completa de un backend de GraphQL. Estaba contribuyendo a BlitzJS, que tiene un concepto similar de RPC, pero quería una capa de RPC más simple. Cuando descubrí que podía lograr esto sin generación de código, me emocioné mucho.