Descansa de REST (y GraphQL)

Gracias a Callstack por patrocinar. Callstack es un equipo de consultores y desarrolladores de React y React Native con colaboradores principales a bordo. Personalmente he trabajado con ellos y son personas maravillosas. Gracias también a Brintem, que ayudó al mundo a mantenerse en horario con su biblioteca de widgets de JavaScript. El conjunto de herramientas de interfaz de usuario contiene componentes de programación, gráficos de Gantt y cuadrícula de datos. Visiten a Brintem en su stand aquí para una demostración personal o si están en casa, vayan a Brintem.com.

Ahora, sin más preámbulos, vamos a invitar a Aleksandra al escenario. Recuerden hacer preguntas en Slido. Si van a Slido.do y usan el código 0212, podrán hacer preguntas que luego se le harán a Aleksandra aquí en el escenario en vivo. Aleksandra es una ingeniera de software y está basada en Wroclew, Polonia. Ha hecho muchas cosas. Es una desarrolladora full stack. Ha trabajado en Elixir, Golang, Python y TypeScript. Anteriormente fue líder técnica de la consola de Hasura y recientemente ha estado trabajando, siendo la principal responsable de Blitz. Muchas gracias. Demos un gran aplauso a Aleksandra Stikora. Bienvenidos, todos. Gracias por la introducción.

Así que mi charla de hoy es descansar de REST. Probablemente te estés preguntando qué pasó aquí, ¿verdad? ¿De qué trata esta charla? Me enfocaré en construir aplicaciones full stack de React, pero específicamente quiero hablar sobre la capa de API porque para mí es muy emocionante lo que está sucediendo en el desarrollo web full stack. Tenemos el nuevo Next.js con componentes del lado del servidor de React. TRPC se está volviendo muy popular. Remix está creciendo y recientemente fue adquirido por Shopify. Así que hay mucho en torno a la capa de API y la construcción de aplicaciones full stack.

Antes de comenzar, quiero explicar. Sí, hay un meme. Quiero explicar qué es una API. En un mundo de programación distribuida, cuando tenemos computadoras que necesitan comunicarse entre sí, por ejemplo, tenemos una aplicación cliente, una aplicación servidor o diferentes servidores que necesitan comunicarse entre sí, necesitamos un puente que permita esa comunicación y una API es ese puente. ¿Por qué estamos hablando de esto? Porque un escenario común para una aplicación full stack es que tienes una base de datos y el cliente necesita acceder a esta base de datos. Pero incluso si tu base de datos fuera accesible públicamente, no puedes llamarla desde el cliente porque eso expondría todas las credenciales de tu base de datos. Por lo general, tenemos servidores que son responsables de comunicarse con la base de datos. Pero cada vez que tenemos que hacer que dos entidades separadas se comuniquen y se entiendan entre sí, en este caso el cliente y el servidor, nos enfrentamos a muchos problemas. Algunos de ellos son toneladas de código repetitivo, pérdida de seguridad de tipos, manejo repetitivo de errores. ¿Podemos hacer algo al respecto? Afortunadamente, sí podemos. Ahora vemos nuevas herramientas, nuevos proyectos que están listos para resolver este problema. Tenemos procedimientos TRPC. Tenemos BlizRPC con resolutores de consultas y mutaciones. Tenemos Remix Data Loader, Componentes del lado del servidor de React y probablemente muchos más que no incluí en esta diapositiva. Pero en mi charla de hoy, me enfocaré en el enfoque adoptado por los primeros dos, TRPC y BlizRPC.

Esto significa que vamos a hablar de RPC. Pero para entender cómo llegamos aquí, cómo llegamos a tener herramientas como TRPC y BlizRPC, voy a llevarte de vuelta a los años 80 para ver un poco de historia. ¿Por qué empezamos aquí? Porque RPC es el comienzo de los servicios web. Y 1981 fue el año en que Bruce J. Nelson escribió una tesis y acuñó este término. Así que comencemos explicando qué es RPC. Significa Llamada a Procedimiento Remoto. Imagina que tienes un procedimiento local, Bienvenida.

Y cuando lo tienes en la misma computadora, simplemente lo llamas así, como en la diapositiva. Pero ahora imagina que Bienvenida está en un procesador diferente, en un servidor diferente, y tienes que usar una red para llamarlo. Ahí es cuando entra en juego RPC, y RPC es la práctica de llamar funciones de forma remota. Y una API de RPC se construye con funciones, y las funciones se llaman con argumentos. Por supuesto, así no se veía RPC hace 40 años porque no existía HTTP ni JavaScript todavía, pero esa era la idea.

Entonces, ¿cuáles eran los problemas? Uno de los problemas principales era que la convención de procedimiento hacía que el cliente y el servidor estuvieran estrechamente acoplados, lo que significa que era casi imposible que el servidor fuera consumido por muchos clientes. Otro problema era que estaba ligado a un lenguaje específico. Otros problemas eran la falta de cancelación de solicitudes, el envasado de parámetros, el manejo de excepciones, y obligar a los desarrolladores a usar servidores multi-hilo. Algunos de esos problemas ya no son relevantes, pero hace 40 o casi 40 años atrás, hizo que los desarrolladores buscaran algo mejor, algo más adecuado para el mundo de la programación distribuida. Y esta nueva cosa era Corba.

Entonces, ¿qué fue genial en los años 90 aparte de las boy bands, Nintendo y los patines en línea? La programación orientada a objetos. Y en eso confiamos en Corba. Así que en Corba tenemos un proceso de servidor, que contiene objetos, y tenemos un proceso de cliente que realiza solicitudes para obtener este objeto. Corba, a diferencia de RPC, su objetivo era ser independiente de la plataforma y el lenguaje. Y para lograr eso, introdujo el lenguaje de definición de interfaz. Así que eso fue una gran mejora. Y uno de los IDL más populares con el que es posible que estés familiarizado es actualmente Protobuf. Pero introducir IDL resolvió muchos problemas, pero tampoco fue tan fácil. Hubo muchos problemas de mapeo. Porque ¿podemos mapear todo, como tipos, excepciones, manejo de excepciones? La respuesta terminó siendo no. Y aparte de eso, este objetivo de ser agnóstico agregó mucha complejidad y causó que Corba tuviera una curva de aprendizaje pronunciada. Así que nuevamente, hubo una necesidad de algo mejor, algo nuevo.

Y como Corba era complejo y pesado, había una necesidad de algo simple. Así que aquí vamos, el protocolo simple de acceso a objetos a finales de los años 90. Entonces, en SOAP, tenemos este sobre que las solicitudes son por defecto publicaciones HTTP. Sin embargo, SOAP no está ligado a ningún protocolo de transporte. Pero por defecto, utiliza HTTP. Así que es XML. Tenemos un sobre que identifica la API solicitada. Y luego tenemos un cuerpo SOAP con los parámetros que se pasan al servidor.

También es fácil eliminar el problema de sobreobtención de datos, porque es el cliente quien controla los datos que obtiene. Pero GraphQL comparte algunas ideas similares a SOAP, lo que significa que también comparte sus problemas. Uno de ellos es que también es por defecto una solicitud HTTP POST, por lo que no hay almacenamiento en caché en la capa HTTP a menos que uses algo como GraphQL CDN creado por MaxTeuber. Luego, si deseas tener seguridad de tipo de extremo a extremo, debes generar tipos, lo cual no es un gran problema. Funciona muy bien, pero siempre debes considerar un paso adicional.

Otro problema es que escribir servidores GraphQL es una tarea bastante difícil y hay mucho código repetitivo que debes hacer. Por otro lado, puedes usar herramientas como Hasura o Postgre file, pero esas herramientas mapean tu base de datos a una API de GraphQL, lo que puede significar que trasladas mucha lógica de dominio al frontend.

Entonces, ¿qué sigue? Como recientemente aprendimos que GraphQL es solo un montón de llamadas RPC mal agrupadas, volvemos a hablar sobre RPC. Vamos a revisitar la promesa original de RPC, que era permitirte tratar las llamadas remotas como si fueran locales. ¿Por qué es genial y por qué es importante en este momento? Es porque TypeScript y la tipificación estática se han convertido en un estándar de facto, y nunca ha sido tan importante tener seguridad de tipo de extremo a extremo. Este problema de seguridad de tipo de extremo a extremo en la capa de API es algo crucial que resolver. Ya vimos este ejemplo anteriormente. Ahora mismo, solo agregué una llamada adicional a la base de datos. Entonces, si tu backend es perfectamente seguro en cuanto a tipos, luego haces esta llamada fetch en el frontend y pierdes esa seguridad de tipo. Quiero decir, podrías generar tipos, esa es una opción, o puedes volver a escribir los tipos en el cliente, pero, ya sabes, eso es trabajo adicional. Sería genial si pudiéramos deshacernos de esta parte de fetch, si pudiéramos, por ejemplo, crear un cliente en el lado del cliente que conozca todo sobre la API, que sepa cuáles son los procedimientos disponibles en el servidor, cuáles son los tipos de argumentos, y así sucesivamente, algo así.

Ahora tengo una pequeña aplicación de demostración. Esto es algo que construí recientemente, porque pronto es Navidad y realmente no me gusta recibir demasiados regalos, porque eso es mucho desperdicio. Así que construí esta aplicación que estoy usando con mi familia y amigos, que te permite sacar un nombre, para que solo compres un regalo para una persona. Y vamos a ver cómo se ve este sorteo de nombres tanto en trpc como en Blitz RPC. Te llevaré a VS code. Aquí está una mutación de sorteo de nombres con Blitz RPC. Lo que está sucediendo aquí es que estoy usando el tubo de resolución de Blitz. Ni siquiera es necesario. No entraré en muchos detalles al respecto. Pero lo importante aquí es que esta mutación es una función asincrónica de JavaScript. Tengo toda la lógica adentro. Tengo llamadas a la base de datos, lógica para determinar qué nombres están disponibles, y así sucesivamente. Y luego lo que sucede es que estoy usando esta función importándola directamente desde el servidor, desde la carpeta de mutaciones en mi componente React. Hay este gancho useMutation que es un envoltorio de Blitz en React query.

Tiene las mismas propiedades. Entonces, ¿qué sucede aquí es que Blitz es algo mágico? Esta importación se intercambia por una llamada HTTP en tiempo de compilación para que no haya filtración de datos de la base de datos al frontend. Pero tenemos todas las definiciones de tipo que conocemos con las mutaciones de dominio de retorno. Sabemos que tenemos acceso a todas las propiedades de consulta de React. Sabemos qué argumentos acepta esta función. Tengo un ejemplo aquí, acepta un nombre de grupo y un nombre de miembro, así que si elimino esto, obtendré un error, TypeScript me dirá que me falta un argumento.

Entonces eso fue BlitzRPC, ahora veamos tRPC. Con tRPC estoy definiendo los procedimientos, este es un proyecto Next.js, así que lo defino como una ruta de API de Next.js. Creo un enrutador tRPC. Eso es inesperado. Eso es muy lento. De acuerdo. De todos modos, estoy escribiendo todos mis procedimientos, tanto consultas como mutaciones, en un solo archivo, y luego no estoy seguro de por qué no se desplaza, pero luego si voy al mismo archivo cuando estaba llamando a la mutación del donante, si me deja. No lo hace. Oh, sí. Funciona. Ahora siempre tengo que desplazarme. De acuerdo. No tengo tiempo para esperar a que VS Code se ponga al día.

Entonces eso fue una descripción general de cómo funciona en BlitzRPC y tRPC. Mi objetivo no era entrar en muchos detalles. Mi objetivo era darte un vistazo de que cosas como tener seguridad de tipo de pila completa y seguridad de tipo de 10 ahora son posibles. Creo que mi computadora se congeló. Así que vamos a terminar. Te daré mi dedo. Sí, creo que mi computadora se está reiniciando. Solo quedan dos diapositivas, así que creo que puedo improvisar. La conclusión de mi charla es que a veces no necesitamos algo completamente nuevo. Podemos revisar cosas del pasado e iterar sobre ellas, podemos mejorarlas, porque la cosa es que RPC tenía muchos problemas hace un tiempo, pero ahora tenemos frameworks como Next.js, como Remix.

Podemos revisar ideas como RPC, y ahora son una combinación perfecta para el ecosistema de JavaScript en cosas como next.js. Tengo esta cita, que en mi opinión es un buen resumen de mi charla. Por lo tanto, RPC es una opción natural para la práctica cada vez más ubicua del desarrollo full stack con frameworks como next.js. Y, por cierto, Telefunk es otra cosa similar a TRPC y BlitzRPC. Así que podemos ver que tenemos un montón de ellas. Tenemos un montón de herramientas que ahora se basan en APIs de RPC porque lo que antes era una desventaja, como el acoplamiento estrecho entre el servidor y el cliente en RPC, ahora puede ser utilizado a nuestro favor. Porque ahora tenemos TypeScript, queremos saber exactamente cuáles son los nombres de los procedimientos, queremos saber exactamente qué parámetros son aceptados por nuestras APIs. Eso es todo.

Si tienes alguna pregunta después de esta charla, puedes seguirme en Twitter. Alexandra dice que si escaneas este código QR, te llevará a mi sitio web personal con las diapositivas. También tengo un montón de recursos que utilicé para preparar esta charla. Y si quieres comprar menos regalos, puedes visitar Everybody.gives. Gracias. Muchas gracias, Alexandra. Por favor, toma asiento y tengo algunas preguntas.

De acuerdo. Eso es genial. Sí. Veamos. Muy bien. Genial. Así que felicidades por superar el primer desafío técnico del día. Sí, fue estresante. Sí, pero creo que lo manejaste muy bien. Así que buen trabajo.

Comencemos con una pregunta sencilla de la audiencia. Si alguien nunca ha utilizado RPC, ¿qué les recomendarías probar primero? Supongo, ¿qué biblioteca o qué herramienta, qué enfoque? Bueno, RPC no es una idea tan nueva. Puedes imaginar que cuando llamas a funciones de JavaScript, como las que están en un archivo separado, pero ahora no están en un archivo separado, están en otro lugar, y necesitas este puente del que hablé al principio de mi charla, para poder acceder a ellas. Esa es toda la idea detrás de RPC. Así que creo que puedes empezar con tRPC o incluso BlitzRPC. Depende del proyecto que quieras construir porque BlitzRPC actualmente solo funciona para Next.js. tRPC funciona con Next, Spelt y es independiente del framework. Así que puedes empezar a jugar con tRPC, ver cómo funciona para ti y eso debería ser un buen comienzo para aprender más sobre RPC.

Bien, y creo que aquí hay una pregunta que encaja perfectamente con eso. ¿Cuál sería una solución de RPC fluida cuando el backend utiliza Java o Kotlin como backend de JVM? Y tal vez una pregunta más amplia es si RPC es una solución adecuada para un entorno no monolenguaje. Sí, sí, pero necesitamos tener... Cuando hablaba de Korba, me refería a este lenguaje de definición de interfaz (IDL). Así que necesitamos algo así. Necesitamos una correspondencia entre lenguajes.

Por ejemplo, existe este framework de RPC, gRPC, que utiliza Protobuf y ese mapeo entre diferentes lenguajes, por lo que puedes usar... Puedes tener comunicación entre servidores escritos en diferentes lenguajes. Y Protobuf contiene toda la información sobre el esquema, los tipos y cómo debe funcionar el mapeo. Entonces, para utilizar Java como backend y algo más como otro backend o como cliente, necesitas tener algo así. Tal vez gRPC sea algo para probar o algo similar. Supongo que esa es la forma de hacerlo.

Bueno. Permíteme hacer la pregunta opuesta, que es cuando tienes múltiples clientes para un solo servidor. La pregunta aquí es si el uso de gRPC o Blitz es un problema cuando tenemos múltiples clientes, por ejemplo, una aplicación móvil nativa y un cliente web. Bueno, si tienes la misma aplicación y tienes una aplicación web y una aplicación móvil, puede que no sea un problema. Pero es cierto que BlitzRPC y tRPC no están diseñados para crear APIs que sean consumidas por muchos clientes. Para ese tipo de cosas tenemos GraphQL, tenemos REST. Y lo que es peor, BlitzRPC y tRPC son ideales para frameworks de pila completa como Next.js, cuando todo está estrechamente acoplado porque eso es lo que también se menciona en la documentación de tRPC, que para bien o para mal, tRPC acopla estrechamente el cliente y el servidor. Sí, creo que, si me permites, la forma en que siempre he pensado en tRPC, está casi en el nombre, es una llamada a procedimiento remoto. Es como si quisieras hacer una llamada a una función, pero hay un límite de red en medio. Y es solo una solución a ese problema y no necesariamente una capa de API para todo. Sí, sí. Sí, genial.

Voy a responder un par de preguntas más de la audiencia, pero quería hacer mi propia pregunta, creo, porque una cosa que diste fue la perspectiva histórica, pasamos por diferentes enfoques, Corba y SOAP y así sucesivamente. Y a veces parece un poco como si lo estuviéramos inventando. Como si siguiéramos, ya sabes, de un cliente FAT a un cliente THIN. Seguimos haciendo RPC a catálogos orientados a servicios, y luego volvemos al anterior. Sí. ¿Son estas solo tendencias y fuerzas? ¿O crees que hay algo que está cambiando en el tipo de entorno o los problemas que estamos tratando de resolver que ahora realmente hace que RPC sea una solución más apropiada hoy que hace tal vez cinco años? Sí, sí. Creo que todavía está relacionado con cómo evolucionan otras cosas. Cómo evolucionan los lenguajes, cómo evolucionan los frameworks alrededor de los lenguajes, porque, ya sabes, con el estado de los frameworks y el estado de JavaScript y TypeScript, no sé, hace 10 años, RPC y, ya sabes, herramientas como tRPC y bt-rpc no tendrían mucho sentido. Pero ahora, dado que tenemos esta evolución en los frameworks de pila completa, como Next.js, Remix, Svelte, Kit y la creciente popularidad de TypeScript, podemos reconsiderar esas cosas. Y creo que esto es por qué seguimos yendo en círculos porque, ya sabes, otras cosas se vuelven populares o se crean otras cosas. Entonces, algunas cosas que alguna vez fueron inadecuadas para el estado actual del ecosistema ahora pueden ser reconsideradas. Interesante. Y ¿crees que el surgimiento de entornos de ejecución distribuidos de JavaScript también hace que RPC sea más atractivo porque de repente el límite de red se vuelve mucho más rápido, ¿verdad? Es más fácil modelar las cosas como una llamada a función.

Sí. Sí, creo que sí. Entonces, um, sí, una de las razones por las que RPC era algo así como odiado o no particularmente apreciado en ese entonces era porque se comercializaba como algo que te permitía tratar los procedimientos remotos exactamente igual que si fueran locales, pero eso era muy defectuoso porque había una red y hacia la, había un montón de problemas a los que te enfrentas cuando hay una red involucrada, cuando hay una capa de transporte involucrada.

Entonces, um, ahora creo que cuando tenemos estas, estas, um, funciones en el borde y cuando limitamos esos problemas con la red, podemos volver a visitar esta promesa. Podemos no ser tan escépticos acerca de esta promesa de tratar las llamadas remotas como si fueran locales, porque en realidad esta parte de la red, uh, la parte de la red es muy mínima. Entonces, los problemas serán mínimos.

Sí. Es casi como si la física estuviera cambiando, ¿verdad? Si puedes llamar a una función remota 60 veces por segundo, de repente, las cosas se vuelven mucho más atractivas. Sí. Genial. Volvamos a las preguntas de la audiencia. Tenemos unos minutos más. Um, así que cada solución tiene sus desventajas. Quien haya mencionado esto, desafortunadamente es cierto. ¿Cuáles son las desventajas del estado actual de las bibliotecas de RPC y en cuáles de ellas deberíamos trabajar para solucionar? Entonces, ¿qué falta todavía en el panorama de, digamos, por ejemplo, RPC en JavaScript o TypeScript en lo que deberíamos trabajar a continuación?

Oh, esa es una buena pregunta. Um, algo que podría faltar es esto. Uh, mencioné antes que TRPC y BlitzRPC acoplan estrechamente el servidor y el cliente. Entonces, tal vez eso es algo en lo que deberíamos trabajar para tener, uh, tener APIs del servidor que puedan ser accedidas por múltiples clientes. Es lo primero de lo que estábamos hablando, uh, hoy. Uh, eso es, eso es una cosa. Y, bueno, todavía espero tener la mejor herramienta de experiencia de desarrollo, porque, para ser honesto, puedo ser bastante parcial aquí porque solía trabajar en Blitz RPC. Pero todavía me gusta la experiencia de desarrollo de Blitz RPC. Me gusta cómo funciona. Hay un compromiso. Como, uh, estas importaciones mágicas, uh, tienen la desventaja de que Blitz se mezcla con Webpack. Pero, pero es una experiencia de desarrollo bastante agradable. Y tRPC funciona de manera ligeramente diferente, es más explícito. Um, así que me encantaría ver una herramienta que lo combine. Que sea agnóstica al framework. Que tenga más de la experiencia de desarrollo de Blitz RPC.

Sí. Um, pero, actualmente, no trabajas a tiempo completo en Blitz. Así que, como última pregunta, ¿qué sigue para ti? ¿En qué estás emocionado y en qué te gustaría trabajar? Um, no lo sé. Esa es una pregunta muy honesta. Lo siento. Pensé que iba a ser una pregunta fácil, pero, uh, no, no. Todavía lo estoy descubriendo. Hay muchas cosas que me gustan. Me gusta hablar sobre APIs. Me gustan las bases de datos, así que creo que algo relacionado con eso.

Genial. Y, uh, ¿el código de demostración que acabas de mostrarnos estará disponible en línea? Sí. Sí. Está en mi GitHub. Mi apodo es B-Rose. Sí. Genial. Uso un diario de emojis. Genial. De acuerdo. Desafortunadamente, no tenemos más tiempo para preguntas porque el almuerzo está esperando. Así que digamos gracias a Alexandra y si tienen más preguntas, pueden encontrarla en el puesto de preguntas y respuestas.