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 en el
backend. Entonces, ¿por qué no simplemente poder llamar a una función en lugar de pasar por todos estos pasos para tener un tipo de tipo para simplemente llamar y obtener algunos
data o escribir algunos
data? ¿Cómo haces lo mismo en TRPC? Lo primero que haces es escribir una función en tu
backend, hablaré un poco más sobre esto, es un poco pequeño. Y luego usas esa función. Todo lo que necesitas hacer es definir una función en tu
backend, todos los datos de tipo se infieren directamente en tu
frontend sin necesidad de ninguna generación de código o pasos adicionales. Veamos un ejemplo un poco más completo. Aquí tenemos un servidor completo de
Node.js usando TRPC. En la parte superior importamos algunas dependencias, configuramos TRPC, enrutador y un punto final o procedimiento o función. Usaré las palabras punto final, procedimiento y función de manera intercambiable en esta charla. Y luego al final, iniciamos el servidor HTTP. Lo que quiero que nos centremos en esta parte. Esto es lo que cambia de enrutador a enrutador, de punto final a punto final. Entonces, lo que hacemos aquí es configurar un enrutador en TRPC, definimos un procedimiento y una función llamada greet. Decimos que esto toma un argumento de entrada que es una cadena usando un validador seguro de tipo llamado Zod. Y luego decimos que esto es una consulta y devolvemos un saludo con hola usuario. Y luego aquí está la magia de TRPC y
TypeScript. Simplemente exportamos nuestro
backend como un tipo. Y en el
frontend, usamos eso, usamos eso, veamos, ese tipo para configurar un cliente TRPC y de inmediato obtienes autocompletado en todas las rutas de API que tienes. Obtienes salidas seguras de tipo inferidas directamente desde tu función
backend. Ten en cuenta aquí que no declaras ningún tipo en absoluto, simplemente lo obtienes de inmediato. Lo que hace TRPC es permitirte construir APIs seguras de tipo fácilmente sin ningún esquema o generación de código.
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.
aquí que ya no devolvemos el título desde nuestra
database. Y creo que saltaré la última parte de esta demo. Y entonces, ¿quién aquí usa
TypeScript? Sí, todos. Genial. No necesito convencerte de eso. Como
TypeScript es genial. Puedes usarlo en el
backend,
frontend. Puedes usarlo en el móvil. Realmente me encanta que podamos usar la misma herramienta en todas partes. Y realmente creo que menos es más, como tal vez
JavaScript o
TypeScript no sean los lenguajes más agradables para todo, pero es algo que puedes usar en todas partes de verdad. Y con tRPC, creo que puedes tener una colaboración mucho mejor entre tus equipos de
backend y
frontend, porque todo lo que necesitas hacer para entender lo que está sucediendo es solo un clic de comando de distancia. No hay una arquitectura complicada para descubrir de dónde vienen las cosas. tRPC no está vinculado a
React o
Node.js en absoluto. Y no tiene dependencias. Entonces puedes usarlo en demo. Puedes usarlo en
Svelte, puedes usarlo en
React Native, y funciona igual. Y tampoco hay pasos de compilación. Entonces no tienes que preocuparte por ninguna magia de
webpack o lo que sea. Es solo
TypeScript. Y puedes tener tu
backend y tu
frontend en dos paquetes independientes en un
monorepo. No es necesario implementarlos juntos, pero aún puedes obtener este tipo de seguridad de tipo mágica donde puedes sumergirte en tu
backend desde donde sea que estés. Y puedes usarlo para el desarrollo web de pila completa, desarrollo móvil. Mucha gente lo usa como un
backend para
frameworks frontend. Como un
backend para
frameworks frontend, si tienes muchos servicios y no quieres unir las respuestas de la API en el
frontend, puedes hacer una capa delgada de tRPC donde haces esa especie de unión de APIs. Y también, en el lado del servidor, puedes usarlo para la comunicación entre servicios. Y obviamente, esto es solo una charla superficial de tRPC. Pero tenemos muchas más características en el cliente. Hemos tomado prestados muchos conceptos de
GraphQL. Entonces tenemos batching automático en el
backend, tenemos cosas que probablemente ya hayas usado en express. Entonces tenemos middlewares, tenemos contexto de solicitud. Entonces, cuando llega una solicitud HTTP, creamos los objetos de contexto de eso, que
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.
Podemos usarlo para obtener información contextual del usuario. Y te mostraré un poco más, te mostraré un middleware en TRPC que es bastante genial. Aquí tenemos, antes hablamos de procedimientos, todo lo que te mostré fueron procedimientos públicos. Y aquí tenemos un procedimiento público donde usamos un middleware. Y si los objetos de contexto devuelven una sesión o un usuario basado en la solicitud entrante, y aquí estamos creando un procedimiento de protección donde lanzamos un error si no hay un usuario en el contexto. Luego llamamos a nuestra función siguiente con el usuario que ahora se sabe que no es nulo porque lanzamos en cualquier otro contexto. Lo que obtenemos cuando usamos este procedimiento de protección es este comportamiento aquí donde cuando defines un procedimiento, sabrás que el usuario del contexto está configurado. Si enumeramos aquí, tenemos este usuario de contexto que es usuario o indefinido porque estamos usando el procedimiento público. Así que solo con hacer esto, obtienes un middleware seguro en cuanto a tipos que funciona para ti. Y no sé por qué entra en modo de suspensión. Y a medida que avanzamos, obtenemos un ecosistema realmente grande en torno a esto. Por ejemplo, tenemos create T3 app que es un punto de partida muy popular para configurar una aplicación con
Next.js, Tailwind y NextAuth, etc. También tenemos un paquete TRPC OpenAPI donde puedes usar TRPC como base para crear APIs compatibles con OpenAPI. Y está TRPC Chrome para crear complementos de Chrome. Y hay mucho más. Puedes verlo en trpc.io/awesome. Y también quiero tomar un momento para agradecer a estas personas. Si tienes un teléfono, toma una foto de la diapositiva y sigue a estas personas. Son geniales. Sí, hay muchos colaboradores en TRPC, no solo yo haciendo esto. Llevo haciéndolo un poco más de dos años y no podría estar aquí si no hubiera una gran comunidad de código abierto. Y si te gusta cómo se ve TRPC, si te gusta trabajar con
TypeScript, por favor háblame porque siempre estamos buscando más personas para ayudar. Y muchas empresas están utilizando TRPC, es posible que reconozcas algunos de esos logotipos. Y no es solo un proyecto de juguete para startups. También hay muchas empresas serias que lo están utilizando. Y sí, espero que pruebes TRPC. Y si tienes preguntas, por favor pregúntame. Genial, Alex, muchas gracias. Fue una charla muy interesante. Tenemos muchas preguntas. De acuerdo, genial.
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
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.
donde hay muchos hallazgos sobre cómo usarlo con Nest.js. Genial. Sí, hay muchas preguntas interesantes. De hecho, tenemos tiempo para intentar responder a algunas de ellas. ¿Por qué crees que Corba RMI gRPC no ha generado mucho interés? ¿Perdón? ¿Por qué crees que Corba y otros protocolos, como los protocolos RPC, RMI gRPC, no han generado mucho interés en tu opinión? Quiero decir, gRPC es bastante grande, ¿verdad? Creo que es bastante conocido y utilizado por muchos. Pero quiero decir, la razón por la que tRPC específicamente, ha generado tanto interés probablemente se deba a que es tan fácil de configurar en comparación con gRPC, donde tienes que hacer el paso de proto, proto buff y todo con gRPC. Es solo como, se llama RPC, pero no tienes que escribir ninguna, no tienes que escribir estos interfaces o esquemas para tu comunicación. Es simplemente mágico, debería evitar palabras como mágico, ¿verdad? Pero está en el compilador de
TypeScript. Simplemente vive de forma transitoria en el compilador de
TypeScript. No hay nada en runtime que defina tus salidas de tu
backend, a menos que lo definas explícitamente. Y tampoco tienes que generarlo. Sí, no tienes que generar nada, ningún tipo, porque sí, el código es la fuente de verdad. Sí, ¿es suficiente la sintaxis de
TypeScript para cubrir todos los tipos de datos necesarios para una definición de contrato eficiente? Sí, ¿signo de interrogación? Quiero decir, ¿qué tipos de datos buscarías? Como TRPC ya es más flexible que, por ejemplo, OpenAPI o REST porque con TRPC, puedes, por ejemplo, devolver un objeto de datos en tu
backend y usar ese objeto de datos en tu
frontend de inmediato porque tenemos soporte para tener una serialización personalizada de JSON. Entonces puedes simplemente usar todos los objetos incorporados de
JavaScript, como mapas, conjuntos y fechas, y se serializarán y deserializarán automáticamente a través de la red. Entendido. ¿Tenemos validación incorporada en TRPC? Creo que mostraste eso. Tenemos una validación de entrada y salida de tus procedimientos, y admitimos varios validadores de entrada diferentes. SOD es el que siempre menciono porque es mi favorito personal, pero también funciona con Jup, y puedes hacer tus propios validadores de entrada y salida si te gusta eso. No sé por qué alguien haría eso.
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.
en mi propio camino, como he usado
GraphQL durante unos cinco o seis años. Desde que salió, fue como un momento de revelación para mí. Aún soy un gran, gran, gran fan de
GraphQL. Sin embargo, en ese momento estaba construyendo mi propia empresa, hace un par de años, y estaba desarrollando una aplicación web de pila completa en
react y
next.js o algo así. Y quería un
backend para eso. Y me parecía un poco absurdo hacer un
backend completo de
GraphQL para una aplicación que solo tiene un consumidor.
GraphQL es increíble y muy flexible, pero realmente no necesitaba esa flexibilidad. Y, sí, también estaba contribuyendo a
BlitzJS desde el principio, que también tiene una idea similar de RPC, pero solo quería una capa de RPC. Y una vez que descubrí que podía hacerlo sin ninguna generación de código, me volví loco tratando de hacer que algo funcionara. Sí, y funciona. Increíble. ¿Sabes si el RPC funciona en diferentes runtimes de JS como los trabajadores de
Cloudflare? Sí, funciona en los runtimes de borde, y tenemos adaptadores para los runtimes de borde y muchos otros
frameworks de
backend como
Fastify, tenemos un adaptador para eso. Y puedes usarlo en Dino, algunas personas lo están haciendo. Entonces, sí, no tiene ninguna dependencia. No importamos nada de node en nuestro
backend, por lo que no usamos Async storage ni nada por el estilo. Me gustaría hacerlo. Haría muchas cosas más agradables. Bueno, eso fue una larga sesión de preguntas y respuestas. Creo que, sí, honestamente, tenemos muchas más preguntas pendientes. Así que los animo a unirse a la sala de preguntas y respuestas y unirse a Alexander allí. Muchas gracias, Alex, de nuevo. Gracias, y también hablen conmigo. Sí.
GraphQL Galaxy 2021
Comments