Autenticación del lado del servidor con Remix, Prisma y la Plataforma Web

Hola Congreso de Node, mi nombre es Kent C. Dodds y estoy realmente emocionado de dar esta charla, autenticación en el lado del servidor con Remix, Prisma y la plataforma web. Estamos trabajando en Node porque Node es increíble y Remix se ejecuta en Node y amo Remix.

Entonces, si no me conoces, trabajo en Remix como director de developer experience, así que si has probado Remix y tu developer experience no fue buena, es mi culpa, lo siento. Estoy trabajando para mejorar todo eso. También soy el creador de epicreact.dev y testingjavascript.com y puedes visitar mi sitio web kentcdodds.com porque es bastante legítimo.

Esta charla es una demostración en vivo de code de cómo agregar autenticación a una aplicación existente y en realidad estamos basando esto en parte del tutorial de Remix. Entonces, si has pasado por el tutorial de chistes en Remix, eso es más o menos lo que vamos a ver aquí. Esto no está completo. Solo tengo unos 20 minutos contigo, por lo que no va a tener todo, pero debería darte la idea correcta de cómo Remix aborda la authentication, y creo que es de una manera realmente buena.

Así que vamos a empezar ya que no tenemos mucho tiempo, vamos a saltar directamente a la codificación. Así que aquí vamos a quitar la pantalla completa, deshacernos de esto, Remix puedes encontrarlo en Remix.run y puedes leer todo sobre ello y desplazarte por esto, es en realidad una experiencia de desplazamiento bastante genial para pasar por eso y tener una idea de lo que es Remix.

Esta es la aplicación en la que vamos a trabajar, Remix, es tan genial que es divertido. Es una aplicación de chistes donde puedes obtener chistes aleatorios y simplemente tendrá un montón de diferentes chistes para ti. Es bastante divertido y luego tienes permalinks y cosas así y en el tutorial añadimos la capacidad de borrar los chistes, puedes añadir los tuyos, y esto en realidad funciona ahora mismo, pero el problema es que no hay autenticación aquí así que cualquiera en el mundo podría añadir sus propios chistes, nunca sabríamos quién lo hizo y las personas que añaden chistes no pueden eliminar esos chistes y no queremos añadir esa capacidad hasta que puedan iniciar sesión porque no queremos que la gente elimine los chistes de otras personas.

Así que eso es lo que vamos a añadir a nuestra aplicación, es simplemente la capacidad de autenticar. Así que vamos a empezar en nuestro archivo schema.prisma, así que ya tenemos Prisma en funcionamiento que está sosteniendo todos nuestros chistes y tenemos una semilla para poner todos estos chistes en la base de datos ya, pero queremos añadir autenticación de usuario y para hacer eso vamos a necesitar un modelo de usuario para poder asociar chistes a usuarios específicos. Así que vamos a decir modelo de usuario y Copilot nos va a ayudar con esto. No todo esto es lo que queremos, así que obtenemos un ID, me gusta el UUID personalmente, gracias mucho Copilot. Queremos la aplicación creada, queremos la aplicación actualizada, y luego vamos a tener un nombre de usuario, no sólo un nombre y esto necesita ser único. Y luego realmente no necesitamos un correo electrónico aquí así que nos desharemos de eso, sí queremos una contraseña aunque, pero no estamos almacenando contraseñas crudas, vamos a almacenar un hash de las contraseñas para hacerlo agradable y seguro. Y luego tenemos una relación con el modelo de chiste dentro de este usuario así que tendremos chistes y eso es un array de chistes. Y parece que mi datetime, o Copilot no lo entendió bien así que esto va a ser por defecto ahora, y ahí vamos. Así que ahora estamos obteniendo una línea roja aquí porque el modelo de chiste no está asociado al modelo de usuario y, uff, eso fue un susto, teníamos dos N's justo ahí. Así que ahora queremos añadir un ID de bromista, y esto va a ser una cadena, y luego tendremos al bromista, que en este caso va a ser un usuario, y vamos a añadir una relación con los campos para esta relación es sólo el ID del bromista, ahí vamos, gracias, y las referencias son sólo el ID, y luego en la eliminación vamos a hacer un cascade. Así que cuando eliminamos al bromista todos sus chistes se van a ir. Y asegurémonos de deletrear esto correctamente. Ahí vamos. Bueno, genial, hemos actualizado Prisma, vamos a ejecutar un par de scripts de Prisma así que ejecutaremos npx Prisma db push, para implementar todos estos cambios. Sí, íbamos a eliminar todas las cosas, y ahora deberíamos tener algunos errores de tipo justo aquí, porque ahora estamos sembrando la base de datos con chistes que no tienen bromistas asociados. Así que vamos a hacer nuestro primer bromista. Y este va a ser Cody, vamos a esperar Prisma user create, y los datos para esto van a tener el nombre de usuario de Cody. Y el hash de la contraseña, en realidad va a ser twixrocks. Y tengo esto pegado por aquí, porque yo, no quieres verme escribir eso. Pero esto es básicamente twixrocks, hasheado. Y así va a ser nuestra contraseña para nuestro usuario Cody. Así que ahora que tenemos a Cody, podemos usar a Cody para generar o crear todos estos chistes. Así que diremos que nuestros datos van a ser todas las propiedades del chiste más el ID del bromista de Cody.ID. Y así pueden ser nuestros datos. Y ahora nuestro TypeScript cosas, esperemos que se vaya.

No estoy seguro de por qué no es así, vamos a averiguar qué está pasando aquí. ID del bromista, ¿estoy deletreando algo mal? ID del bromista. Ahí vamos. Tienes que deletrear las cosas correctamente en programación, se vuelve un poco gracioso si no lo haces. O más bien, de manera consistente. No tiene que ser correcto, pero tiene que ser consistente.

Lo sabemos por el encabezado del referente. Muchas gracias. Vale. Entonces tengo este script aquí llamado npm run setup DB. Esto va a empujar y luego regenerar todo. Y por supuesto, explota porque el usuario no existe en la database. Así que vamos a Prisma DB reset. Oh, vaya. No, es Prisma DB push. Pensé que ya había hecho eso. Ahora es Prisma DB migrate dev o no, es solo Prisma. Oh, hombre. Me estoy tropezando todo el tiempo. Ah, ¿qué estoy haciendo? Sí. Y esto va a ser usuarios. Genial.

Vale. Así que ahora hemos podido sembrar nuestra database y ahora tenemos usuarios y todo y todo sigue funcionando. Así que sí, técnicamente todavía estoy ejecutando esto. Así que la aplicación todavía funciona técnicamente hasta que intentamos crear un chiste. Ahora crear un chiste no funcionará porque necesitas tener un ID de usuario para crear chistes, pero cada uno de estos chistes está asociado a nuestro usuario Cody y ahora todo lo que necesitamos hacer es hacer que podamos iniciar sesión como nuestro usuario Cody para que podamos añadir chistes adicionales y cosas a nuestra aplicación. Así que con eso en mente, vamos a ir a nuestro inicio de sesión, que ya está todo codificado para nosotros. Vamos a /login, entonces veremos que tenemos tanto inicio de sesión como registro aquí. No tengo mucho tiempo así que pre-codifiqué todo esto y ya tenemos nuestra acción para manejar nuestro envío de formulario así que puedes ver el envío de formulario justo allí.

Tenemos nuestra validation siendo manejada aquí para mostrar errores de validation y todo eso. Eso ya está codificado para nosotros. Así que todo lo que necesitamos hacer es escribir la lógica para iniciar sesión de un usuario y luego escribiremos algo de lógica para obtener la información de los usuarios cuando están creando un nuevo chiste.

Así que vamos a hacer un nuevo archivo para manejar todas nuestras cosas de sesión. Así que iremos a utilidades y crearemos una nueva utilidad llamada SessionServerTS. Así que esto es solo un archivo de servidor. Por eso se llama Session.server. Y vamos a exportar una nueva función. Esa es una función asíncrona llamada login. Esto va a aceptar un nombre de usuario y una contraseña. Y ese nombre de usuario es una cadena, y la contraseña también es una cadena. Ambas cosas son necesarias.

Y ahora solo necesitamos, vamos a traer la database en realidad. Así que db vendrá de nuestro servidor db. Esta es nuestra conexión a Prisma. Y diremos user.find first, y diremos donde el nombre de usuario. Y ahora tendremos nuestro usuario es, oh espera. Así que ahora si no tenemos un usuario, entonces no hay un usuario con ese nombre de usuario. Y entonces vamos a devolver null, y luego nuestra UI lo manejará y dirá, tu nombre de usuario o contraseña está mal.

Si tenemos un usuario, necesitamos verificar que la contraseña es correcta. Y vamos a, usamos bcrypt para generar el hash. Podemos usar bcrypt para comparar el hash. Así que diremos bcrypt de bcrypt.js. Y con eso podemos decir const isCorrectPassword equals bcrypt, oh vamos a esperar esto, es asíncrono, porque es lento, y eso es como, esa es la característica en realidad, es que es lento y por eso es seguro. Qué curioso. Así que si no es, si esta no es la contraseña correcta, entonces devolveremos null y dejaremos que nuestra UI diga que el nombre de usuario o la contraseña está mal. Y ahora si todas esas cosas están bien entonces podemos devolver el usuario. Así que eso es authentication, eso es inicio de sesión, cuando tienes tu propia database y solo estás haciendo hash con bcrypt. Es realmente bastante simple. Y así podemos iniciar sesión, podemos obtener un usuario, pero necesitamos crear una sesión.

Y entonces, vamos a hacer eso después, pero sigamos con esto por ahora. Así que obtengamos nuestro usuario. El usuario es await, login, lo traeremos, nombre de usuario y contraseña, y si no hay usuario, entonces vamos a devolver una mala solicitud con un error de formulario que dice, hey, este usuario no existe, o lo que queramos decir. Así que usuario, o sí, nombre de usuario o contraseña incorrectos. Gracias, copiloto, eso ayuda mucho. De lo contrario, si realmente hay un usuario, entonces podemos redirigir y todo. Y haremos eso más tarde. Asegurémonos de que podemos obtener al usuario primero. Así que vamos a console registrar al usuario, y ahora ese console registro aparecerá en nuestro registro de salida aquí. Así que voy a despejar un poco de espacio. Diremos Cody, y Twix rocks, y aún no está implementado. No estamos redirigiendo realmente, pero en el lado del servidor estamos obteniendo al usuario. Así que eso funciona totalmente. ¡Hurra! Eso es genial. E incluso nuestra validation también funciona. Así que si voy a registrarme, y nos quedan solo un par de cosas, vamos a obtener toda nuestra lógica de validation y todo. Lo construimos antes. Así que genial. Así que ahora lo que necesitamos hacer es crear la sesión del usuario y redirigirlos a la página de chistes. Así que hagamos eso.

En nuestro servidor de sesiones, la forma en que gestionamos las sesiones en Remix es usar cookies, y tenemos soporte incorporado para esta API de la plataforma web. Así que vamos a importar un par de cosas de Remix. Y lo que queremos es crear almacenamiento de sesiones de cookies. Y aquí obtendremos nuestro almacenamiento de crear almacenamiento de sesiones de cookies. Y hay un par de propiedades que vas a establecer para esto. Y todas están en la cookie. Así es como configuramos nuestra cookie. Así que hay un par de cosas que queremos hacer al configurar nuestra cookie. Primero necesitamos darle un nombre y puedes llamarlo como quieras. Está bajo el dominio de tu dominio.

Así que voy a llamarlo la cookie de sesión de chistes de remix. Eso parece tener sentido para mí. Y luego también queremos codificar esta cookie. Así que incluso si el usuario abre sus herramientas de desarrollo y miran la cookie, no tendrán idea de qué es esto. Así que vamos a codificarlo. Y también... Significa que incluso si intentan cambiarlo o algo así, sabremos que lo estropearon. Así que sí tenemos un secreto. Y esto es processenv session secret. Y con eso, por supuesto, TypeScript está enfadado con nosotros por esto. Así que vamos a hacerlo constante y llamar a esto session secret. Y luego diremos que si eso no está definido, entonces lanzaremos un nuevo error que dice, vamos Copiloto, gracias. El secreto de la sesión debe estar establecido. Genial. Así que ya tenemos nuestro secreto configurado.

Queremos establecer esto solo para HTTP, para que los usuarios o scripts de terceros no puedan acceder a esta cookie en el navegador. Ese es uno de los grandes problemas con el uso de JWTs en el almacenamiento local. Así que sí, solo HTTP. También queremos que solo se aplique a conexiones seguras, así que no hay ataques de hombre en el medio allí, o raramente, supongo. Y luego la edad máxima. Hagamos que esto vaya, no, no siete días. Hagamos 30 días. ¿Quién quiere iniciar sesión en una aplicación de chistes cada siete días? No yo. No. Bien, genial. Así que ahora hemos configurado nuestro almacenamiento, así que ahora podemos crear sesiones con este almacenamiento.

Así que vamos a hacer una función llamada createUserSession con el ID de usuario como una cadena. Y también podríamos tener un redirectTo para que redirectTo sea configurable, pero siempre los redirigiremos a slash, ya sabes qué, hagámoslo. Digamos, redirectTo string. Así que pueden controlar a dónde quieren que vaya el usuario cuando creamos esta sesión de usuario.

Así que vamos a escribir esto correctamente. Ahí vamos. Genial. Así que vamos a hacer nuestra sesión, tenemos nuestra sesión igual a await storage, getSession. Lo que esto va a hacer es que automáticamente va a crear una nueva sesión para nosotros. Así que no estamos obteniendo una sesión de una cookie existente. No estamos pasando una cookie existente. Así que simplemente creará un objeto de sesión para nosotros. Esto también es asíncrono. Así que tendremos que hacer eso asíncrono.

Y ahora diremos session set user ID, user ID. Así que no tenemos que hacer ningún tipo de búsqueda en la database o algo así. Todo simplemente vive en la cookie. Y sabemos que si está en la cookie, entonces el usuario está autenticado. Y no había otra forma de que eso llegara allí más que a través de nuestra sesión secreto de codificación y todo eso. Así que esto es realmente muy, bastante seguro. Es impresionante.

Así que ahora que tenemos esto, el ID del usuario establecido en la sesión, vamos a devolver una redirección a donde quieran redirigir. Una parte importante de todo esto es que establecemos el encabezado set cookie para que el navegador establezca la cookie en el registro de cookies del navegador o lo que sea. Así que tendremos algunos encabezados aquí con un set cookie, y usaremos el almacenamiento para confirmar la sesión. Y aquí está nuestra sesión. Y la sesión es asíncrona. Así que esperaremos eso. Y luego esta redirección es una utilidad de Remix que simplemente es como, te ayuda a crear objetos de respuesta. Así que eso es lo que estamos devolviendo de esta crear sesión de usuario. Exportaremos esto. Y ahora podemos usar crear sesión de usuario aquí mismo. Simplemente devolveremos crear sesión de usuario con user.id y redirigir a, que viene de la UI. Así que, basándonos en cómo llegamos a esta UI en primer lugar, las páginas que pueden redirigir a el inicio de sesión establecerán el redirigir a. Así que el usuario puede volver exactamente a donde empezó.

Bien, genial. Así que probemos esto. Así que estamos en el inicio de sesión. Puedo decir, Cody, Twix, Rox, y boom. Ahora estoy en la página de chistes y tengo mi aplicación justo aquí. Así que puedo mirar mis cookies aquí mismo y boom, ahí está. Esa es mi sesión RJ. Está todo codificado y cosas así. Como usuario no tengo idea de qué es esto y si intento cambiarlo o algo así, no funcionaría porque mi servidor no podría decodificarlo en absoluto. Así que eso es genial.

Ahora, cuando quiero ir a la página de chistes/nueva, quiero poder introducir un chiste aquí y agregarlo y todo explota. Aún no tengo un buen manejo de errores en esta página y la razón por la que está explotando es porque aún no estamos obteniendo el ID del usuario. Así que vayamos a eso realmente rápido en los últimos minutos que tenemos aquí y diremos, hey, sí, gracias TypeScript. Me habrías salvado de un terrible destino. Lo que realmente quiero hacer es en la parte superior de mi acción de manejo de este formulario, no quiero pasar por todas las cosas de validation y decir, hey, te equivocaste en esto. Te equivocaste en esto. Y luego finalmente lo hacen bien. Y sólo entonces se dan cuenta, Oh vaya, en realidad se supone que debo estar conectado. Así que vamos a poner esto en la parte superior para obtener el ID del usuario y diremos, oh, espera, obtener ID de usuario. Y en realidad llamemos a esto requerir ID de usuario para que sepamos que si no lo tienen necesitamos redirigirlos porque como algunas rutas podrían ser, podría ser opcional tener un ID de usuario. Así que en nuestro caso es obligatorio. Así que vamos a decir requerido aquí y pasaremos la solicitud. Así que requerir ID de usuario va a venir de nuestro servidor de sesión y exportaremos una función llamada requerir ID de usuario que toma la solicitud y la solicitud es lo que contiene la cookie. Y así es un objeto de solicitud. Y eso es sólo, eso es un estándar web ahí mismo solicitud que viene de la web fetch API, la web API. Super genial. Así que ahí está la parte web de todo lo que estamos haciendo. También las cookies, pero sí, así que obtengamos nuestra sesión. Así que espera almacenamiento, obtén la sesión de los encabezados de la solicitud, obtén la cookie. Así que la solicitud automáticamente va a tener la cookie en ella porque así es como funciona el navegador.

Y si eso, um, si tenemos el ID de usuario o más bien, si no tenemos el ID de usuario, entonces sabemos que el usuario no ha iniciado sesión. Y en lugar de lanzar un nuevo error, podemos lanzar una redirección para decir redirigir al inicio de sesión. Entonces los usuarios no deberían estar aquí. Vamos a redirigirlos. Así que en cambio, puedes lanzar respuestas en remix, lo que significa que esto es realmente agradable y abstracto doble. No tienes que hacer un montón de lógica aquí. Como, ¿hay un ID de usuario? No lo hay. Así que déjame redirigir o lo que sea. No tienes que hacer eso en cada lugar. Necesitas el ID de usuario. Puedes hacerlo justo aquí y remix se encargará de eso por ti. Es realmente, realmente impresionante. Y puedes hacer eso para, ¿están autorizados y un montón de otras cosas también es realmente genial. Uh, está bien. Entonces, si tienen el ID de usuario, entonces devolveremos ese ID de usuario. Y vendremos aquí, lo tomaremos del servidor. Y ahora tenemos el ID de usuario justo allí. Y ese va a ser nuestro ID de bromista. Boom. Genial. Así que ahora puedo decir, uh, vamos a refrescar tu leche y, uh, veamos, leche, uh, la leche es también el líquido más rápido en la tierra. Está pasteurizada antes de que incluso la veas. Jaja. Genial. Así que ahora tenemos, uh, un chiste que pudimos crear y está asociado a nuestro usuario. Y eso es increíble. Desafortunadamente, no tengo suficiente tiempo para mostrarte, como, vamos a añadir registro y cerrar sesión y cosas así, pero deberías tener una buena idea. Básicamente, cerrar sesión es una cuestión de, um, en lugar de confirmar sesión, destruyes la sesión y uh, eso funciona. Es, es bastante simple. Pero lo que realmente quiero señalar aquí es que esto es realmente bastante simple.

Está utilizando APIs de plataforma. Eres capaz de hablar directamente con la database. Todo es como una integración perfecta entre el cliente y el servidor. También, realmente me encanta eso porque lo hemos implementado, vemos todo este code y en realidad es simple, podemos agregar y cambiar lo que queramos. Así que esa es la belleza de remix, hace que estés en control y puedas cambiar las cosas con el tiempo según sea necesario. Y realmente aprecio esa simplicidad de remix.

Así que esa es la demostración. Siéntete libre de ir al repositorio para echar un vistazo al code. Y como dije, esto viene directamente de los docs de remix. Vaya. No dos los docs. Si vas a la aplicación de chistes deep dive, puedes pasar por todo esto, vamos desde nada hasta la configuración de la database de Prisma y todo hasta las mutaciones y authentication, todas esas cosas. Es asombroso. Ah, y por cierto, también hablamos de configurar JavaScript. Puede que no lo hayas notado, pero si miras la pestaña de red aquí y miras el JavaScript que se carga en la página, no hay JavaScript en la página. Así que hicimos todo eso sin ningún JavaScript en la página, lo cual es solo un truco divertido. Por supuesto que queremos JavaScript en la página para accessibility y una mejor user experience. Pero eso es solo una especie de spoiler divertido para ti mientras vas al tutorial.

Eso es todo. Muchas gracias a todos. Espero que tengan un tiempo increíble en el Congreso de Node y nos veremos todos en el futuro. Adiós. Hola. Hola de nuevo. Es un placer tenerte. Gracias por esta increíble charla. Así que la mayoría de las personas, el 48 por ciento dijo azul, verde, amarillo, rosa, rojo. Danos la palabra. ¿Cuál es el orden correcto? Eso es correcto. Así que bien hecho al 48% de ustedes.

No puedo. Bueno, no puedo. Es realmente genial que la gente recuerde esto. Yo solo recuerdo la fuente. Pero eso soy yo. Con las sombras. Es un logo bonito pero no recuerdo el orden de los colores. Conozco los colores del logo de Coca-Cola. Ah, ahí lo tienes. Eso es un poco más fácil.

Entonces, de nuevo, vamos a pasar a las preguntas de nuestra audiencia, si eso está bien contigo. Estoy encantado de responder a sus preguntas. Estoy mirando el chat aquí. Ya tenemos un par. Me encantaría escuchar más. Sigue enviándolas.

La primera ya la respondiste en el chat pero para la gente que no ha estado leyendo el chat es de Argentyle1990. Los data en la cookie, ¿están cifrados o codificados? Sí, esa es una gran pregunta. La respondí antes de darme cuenta de que se suponía que debía esperar para responderla ahora. No hay problema. Pero, sí, está firmado con el secreto, así que la gente no puede hacer el suyo propio o cambiarlo o lo que sea. Excelente. Así que cuando vuelve al servidor, puedes verificar que realmente fue creado por el servidor. Vale, genial, gracias. ¿Acabas de avanzar al nivel uno en el Servidor de Discord? Felicidades. Oh, pregunta realmente importante de CCCChris. ¿Está REMIX listo para la producción? Sí, totalmente. Así que mi sitio web es un sitio web de producción, tiene cerca de 3,000 usuarios, y eso es, como, personas que han creado cuentas y todo. Recibo alrededor de medio millón de visitas a la página al mes y más de cien a doscientos mil espectadores únicos al mes. Así que eso es bastante producción.

No es como lo que construí en PayPal, pero estaría muy feliz de tener Remix cuando trabajé en PayPal. Así que sí, cuando llegamos a la versión 1.0, eso fue una señal para el mundo de que Remix está listo para producción y que estamos manteniéndolo y trabajando en él activamente. Y luego, como seguimiento a eso, digamos que Elon Musk viene a ti y dice, estoy empezando PayPal de nuevo, ¿elegirías Remix entonces? Oh, sí. ¿Estás bromeando? Por supuesto. Sí, sí, sí, definitivamente me gustaría que toda la propiedad de PayPal estuviera muy bien adaptada para Remix. Y luego, en ese sentido, ya que mencionaste a Elon, él no se ha puesto en contacto conmigo o algo así, pero estoy en conversaciones con ingenieros de Tesla. Puedo decirte eso porque nuestra conversación comenzó en Twitter. Así que sé que es público. Pero sí, estamos hablando con gente de Tesla y varias otras empresas que no estoy seguro de si estoy en libertad de decirte, así que no lo mencionaré, pero sí, a mucha gente le interesa mucho. Muy genial. Sí. Bueno, tal vez tenga que unirme al equipo de ingeniería de Tesla aquí en Ámsterdam. ¡Hazlo! La siguiente pregunta es de argentile1990 de nuevo.

Así que funciona como un JWT donde puedes decodificar los data, pero no hay nada que puedas hacer con ello en el servidor. Quiero decir que puedes, puedes hacer cosas con ello. Puedes extraer el ID del usuario de él. Podrías almacenar todo el estado de la aplicación en la cookie si quisieras. Y para algunos casos de uso eso tiene sentido. Estás limitado al tamaño de las cookies y podrías hacer varias cookies sin ningún problema. Solo ten en cuenta que cuando almacenas cosas en una cookie, cada solicitud va a tener esa cookie en ella. Así que probablemente no almacenes todo el estado de tu aplicación en la cookie. Pero, pero podrías si quisieras. Y así que sí, como las cookies como una tecnología o tecnología de plataforma web, esto tiene muy poco que ver con Remix aparte de que Remix te da una API muy agradable para trabajar con cookies. Pero aparte de eso, son todas tecnologías web. Y así, sí, puedes hacer lo que quieras porque es una cookie.

Y así, sí, puedes hacer lo que quieras porque es una cookie.

La siguiente pregunta es de Hail to the Wood. ¿Qué es lo que más te emociona de lo que Remix puede proporcionar para las aplicaciones de tamaño enterprise? Excelente seguimiento a la pregunta anterior. Sí, sí, esa es una súper pregunta. Creo que para cualquier enterprise, uno de los mayores problemas con enterprise no es realmente la tecnología. Es cómo hacer que esto funcione con un equipo de desarrolladores. Tienes como, o incluso media docena de equipos trabajando en el mismo proyecto. Ese fue probablemente el mayor, uno de los mayores problemas que tuve cuando estaba en PayPal. Probablemente el mayor problema que tuve cuando estaba en USAA, simplemente coordinando esfuerzos en un solo proyecto con personas que nunca hablan entre sí y ni siquiera revisan el code de los demás porque están en diferentes áreas de la aplicación.

Lo genial de Remix es que el modelo mental es el mismo en todas partes de la aplicación. Y así, como la state management no es realmente una pregunta cuando estás trabajando con Remix. En mi charla, mencioné cómo no tienes que preocuparte por la state management aquí porque Remix es simplemente... Básicamente, tu tienda Redux es la database. Y así no estás pensando en cómo mantengo al cliente sincronizado con el servidor? Estás construyendo tu aplicación y Remix asegura que esas cosas se mantengan sincronizadas simplemente por la naturaleza de cómo está construido. Por lo tanto, el modelo mental es básicamente un modelo mental de Web 1.0 con una experiencia de desarrollador de Web 4. No quiero decir Web 3 porque eso ya tiene un significado ahora. Pero sí, es una experiencia de desarrollo realmente impresionante con un modelo mental muy simple. Y así, cuando estás trabajando con un equipo de desarrolladores como las aplicaciones enterprise son, no puedo pensar en un framework más simple para elegir.

Además de eso, es como la user experience es estelar. Y así tú y como la experiencia de usuario predeterminada es realmente buena. Y así estás haciendo... ¿Experiencia de usuario final o experiencia de desarrollador? Sí. Experiencia de usuario final. Sí. Entonces, la experiencia del desarrollador es increíble, el modelo mental es simple, todo eso. Pero luego la experiencia del usuario y la experiencia del usuario es realmente impresionante también. Y así no tienes que pasar tanto tiempo tratando de hacer que la experiencia del usuario sea impresionante porque simplemente la experiencia de usuario predeterminada es realmente buena. Y así, quiero decir, como, por supuesto, vas a querer pensar en la gestión del enfoque y cosas así para la accessibility. Solo hay tanto que un framework podría hacer. No podrás construir una abstracción para la gestión del enfoque.

Quizás en algunos aspectos, pero como react para usar efectos más referencias son una forma muy agradable de hacer la gestión del enfoque. Y todo react funciona perfectamente con remix. Y supongo que aprovecharé esta oportunidad para decir que en el futuro, otras bibliotecas de UI probablemente funcionarán con remix también. Y entonces no es un react framework, es un framework web. Y sí, de todos modos, esa es una respuesta larga a esa pregunta simple. Pero las empresas amarán remix.

Genial. Bueno, esa es la respuesta. ¿Verdad? Sí, a todos. Así que mi MC está preguntando si puedes dirigir preguntas a mi hijo, pero mantengámoslo con Kent. Kent, creo que si puedes ver a mi hijo y déjame saber pero creo que la gente está aquí para ti.

Donde vemos CCC Chris está preguntando si las cookies son la opción predeterminada. Podría haber otras opciones que podrían ser mejores para ciertos escenarios o no necesarias. Sí, así que no puedo pensar en otras situaciones en las que querrías usar algo más para una aplicación web. Pero Remix también puede ser utilizado para otros tipos de aplicaciones. Así que podrías tomar tu Koa o tu servidor REST express y reescribirlo en remix, como reimplementar todo, remix.

Podrías tener una API GraphQL que esté escrita con Remix y en realidad el aspecto realmente genial de hacer eso es que si eventualmente decides, oye, tenemos este servidor API REST, quiero tener algún tipo de interfaz de administración para ello o algo así, sabes, para inspeccionar algo de los data o lo que sea. Entonces podrías construir eso porque lo has construido con Remix sin tener que re-arquitecturar completamente algo o ejecutar otra cosa al lado o hacer algún tipo de cosa hacky para como generar HTML o lo que sea. Y entonces, sí, en esas situaciones, si estás apoyando y en realidad podrías tener tu aplicación que está construida con Remix y decir, oye, quiero que mi cliente móvil sea capaz de interactuar con esto. Puedes tener lo que se llama una ruta de recurso que puede hacer cualquier cosa que quieras responder a cualquier solicitud con cualquier tipo de respuesta y poner un punto final GraphQL en tu aplicación web. Y entonces tienes clientes móviles. Y todo eso para decir que para esos casos de uso, otras estrategias de authentication podrían tener más sentido. Pero si solo estás construyendo una aplicación web, si eso es todo lo que tu aplicación web está apoyando, no puedo imaginar por qué querrías hacer una estrategia de authentication diferente. Esto es la web, y así es como lo hacemos en la web. Así que solo usa la plataforma. Seguir con la plataforma suele ser la mejor opción.

Sí. Sí. Tenemos tiempo para una pregunta más, y es de useAna Andrazin. Tienes dos minutos para esta pregunta.

¿Qué dirías que es la característica más única que distingue a Remix de otros frameworks? Buena pregunta. Sí. Sí. Entonces, para aquellos que se lo preguntan, mucha gente compara Remix con Next.js. Y no nos gusta hablar mucho de eso porque distrae, pero la gente se lo pregunta, así que escribimos una entrada de blog al respecto, y compartiré un enlace a la entrada del blog en las notas aquí más tarde, o en el servidor de Discord. Pero si simplemente buscas en Google Remix versus Next y miras la entrada del blog de Remix, puedes ver una comparación muy profunda y objetiva de los dos. Y lo más importante para mí que distingue a estos dos, o cualquier framework de Remix, es que Remix construye una base super, super sólida sobre el abismo de red entre el front end y el back end. Y ese es uno de los mayores desafíos para todos los frameworks o para todas las web apps. Ese abismo de red es la razón por la que la state management es difícil para las interfaces de usuario. Es la razón por la que el performance es un problema para las interfaces de usuario. Entonces, con un puente de red realmente agradable, puedes simplificar drásticamente el modelo mental, mejorar el performance, y reducir la cantidad de cosas que tienes que gestionar tú mismo. Eso es lo más importante para mí. Otro bastante significativo es el enrutamiento anidado, donde como la mayoría de los frameworks como Gatsby y Next, estoy pensando específicamente, tienen como enrutamiento anidado basado en archivos donde puedes poner archivos en, ya sabes, anidar tus archivos y cosas así. Pero eso no tiene nada que ver con dónde estás solicitando data y dónde estás renderizando UI. Tienes que renderizar todo en todas partes, pero con Remix, tenemos enrutamiento anidado verdadero. Y eso es una característica realmente enorme que permite una muy buena developer experience y también una buena user experience porque podemos optimizar cosas debido al enrutamiento anidado. Sí, recuerdo haber leído cómo funciona el enrutamiento, y quedé realmente impresionado con eso. Así que muchas gracias, Kent, por esta increíble masterclass. Desafortunadamente no tenemos un chat espacial para la sala de conferencias de Kent, pero hay una discussion room que se realizará más tarde hoy. No puedo decir la hora porque los horarios son diferentes para todos. Pero asegúrate de unirte a eso, si quieres hablar más sobre Remix con Kent. Kent, muchas gracias por unirte a nosotros, y fue realmente un placer tenerte aquí. Muchas gracias por invitarme, agradezco tus preguntas, y saluda a tu hijo de mi parte! ¡Saludos de él! Un pequeño saludo. ¡Hola!