Múltiples aplicaciones, un código para gobernarlas a todas

Rate this content
Bookmark

Cada vez más, React se utiliza para aplicaciones complejas que acomodan numerosos tipos de usuarios, flujos de trabajo y mecánicas. A veces son personas diferentes las que utilizan cada parte de la aplicación, pero también es común un escenario de un solo usuario con múltiples flujos de trabajo.

En esta sesión, aprenderemos sobre nuestras opciones al construir múltiples experiencias dentro de una sola aplicación de React, sin perder la cordura. Utilizaré algunos ejemplos de lo que hacemos en Wilco.

20 min
21 Jun, 2022

Video Summary and Transcription

Esta charla discute los beneficios de utilizar una sola aplicación para alojar múltiples experiencias o mini-aplicaciones, en lugar de una arquitectura de micro front-end. Al utilizar una sola aplicación, se vuelve más fácil compartir estado, simplificar el intercambio de código, manejar análisis y errores, y desplegar y monitorear la aplicación. La charla también aborda el manejo de la aplicación principal, enrutamiento, autenticación y subdominios para autenticación.

Available in English

1. Introducción a las Aplicaciones Múltiples

Short description:

Hola a todos y bienvenidos a mi charla, múltiples aplicaciones, un código para gobernarlos a todos. Hoy voy a hablar un poco sobre un caso de uso interesante que tuvimos en Wilco cuando comenzamos. En Wilco, teníamos un par de pantallas, un par de experiencias. Necesitábamos crear dos experiencias para el usuario, que se mueve entre ellas. Una es una micro front-end, y podemos jugar con las últimas novedades que siempre están de moda en JavaScript. Pero antes de implementar esta arquitectura tan complicada, quiero decirle a nuestro equipo que espere un minuto y piense en esta arquitectura, si es realmente lo que queremos hacer. Porque no quiero que esto sea una crítica contra el micro front-end, me encanta el micro front-end, entiendo el valor. En esta charla, quiero convencerlos y tal vez detenerlos antes de que sigan por este camino.

Hola a todos y bienvenidos a mi charla, múltiples aplicaciones, un código para gobernarlos a todos.

Hoy voy a hablar un poco sobre un caso de uso, uno muy interesante del que podemos aprender. Pero antes de comenzar, quiero hablar un poco sobre mí.

Me llamo Jem Agnesi, soy el CTO y cofundador de Wilco. En Wilco, estamos tratando de construir una plataforma de aprendizaje donde cada ingeniero pueda practicar sus habilidades de desarrollo y obtener escenarios de la vida real para practicar. Antes de Wilco, trabajé como ingeniero senior y ingeniero de personal en WeWork y Meta. Pueden encontrarme en Twitter con este nombre de usuario.

Y como dije, hoy quiero hablar un poco sobre un caso de uso interesante que tuvimos en Wilco cuando comenzamos. En Wilco, teníamos un par de pantallas, un par de experiencias.

Entonces, como dije, estamos construyendo una especie de plataforma que permite a los usuarios y desarrolladores realizar una especie de búsqueda, donde cada búsqueda es una práctica para las habilidades de desarrollo.

Una experiencia es la plataforma Wilco, como se llama. Y como pueden ver, tenemos un feed de búsquedas del stack del futuro, la búsqueda futura, la búsqueda anterior que el usuario hizo, la búsqueda actual que está en curso, el perfil del usuario, las habilidades, la cantidad de monedas y los puntos que obtuvieron.

Esto es, como pueden ver, muy elegante, con un aspecto y una sensación de tema oscuro.

Por otro lado, teníamos el juego. Cuando comienzas el juego, ingresas a una especie de portal de una empresa muy antigua y cooperativa. Nuevamente, puedes ver tu búsqueda actual, lo que necesitas hacer. Tienes todo tipo de enlaces. Tienes tus usuarios.

Estas dos experiencias son muy, muy diferentes. Este es uno de los primeros requisitos que recibimos de nuestra gestión de productos. Necesitamos crear dos experiencias para el usuario, que se mueve entre ellas. Sé lo que piensan de inmediato si tenemos un elemento.

Entonces, esta es una micro front-end, y podemos dividirla en micro front-end, y podemos jugar con las últimas novedades que siempre están de moda en JavaScript.

Y entiendan, esto es lo que teníamos en mente cuando pensamos por primera vez en ello desde nuestra gestión de productos. Y antes de implementar esta arquitectura tan complicada, quiero decirle a nuestro equipo que espere un minuto y piense en esta arquitectura, si es realmente lo que queremos hacer. Porque no quiero que esto sea una crítica contra el micro front-end, me encanta el micro front-end, entiendo el valor. Incluso di una charla al respecto, como pueden ver. Y como alguien que ha jugado con el micro front-end y ha visto todo tipo de soluciones que tenemos allí, realmente necesitamos entender que el micro front-end puede introducir mucha complejidad en la implementación y en cómo trabajamos con esas aplicaciones. Hay muchas cosas en las que debes pensar antes de sumergirte en la implementación de este tipo de arquitecturas. Y en esta charla, quiero convencerlos y tal vez detenerlos antes de que sigan adelante.

2. Beneficios de una Aplicación Única

Short description:

Cuando elegimos una sola aplicación que aloja múltiples experiencias o mini-aplicaciones, podemos compartir fácilmente el estado entre ellas. Esto simplifica el intercambio de datos y el progreso del usuario, lo cual requeriría mucho trabajo en una arquitectura de micro front-end.

antes de seguir este camino. Porque una vez que te adentras en el camino del micro front-end, hay muchas cosas que hacer. Y realmente no es tan fácil revertirlo. Entonces, ¿por qué elegirías, por qué alguien elegiría una sola aplicación para crear este tipo de solución de dos experiencias muy diferentes? Cuando elegimos una sola aplicación que aloja esas dos o más experiencias o mini-aplicaciones, podemos compartir el estado entre esas aplicaciones. ¿De acuerdo? Como viste antes, tenemos dos aplicaciones muy, muy similares, tal vez no en la apariencia pero sí en los data que muestran, la búsqueda actual, el usuario, dónde se encuentran, qué pueden hacer, en qué estado se encuentran. Y una vez que lo haces en una aplicación React, puedes compartirlo fácilmente. No es que no puedas compartir el estado entre micro front-end, pero eso requiere mucho trabajo y no lo obtienes de forma predeterminada.

3. Beneficios de una Aplicación Única (Continuación)

Short description:

Cuando trabajamos en una sola aplicación, obtenemos el manejo de análisis, informes y manejo de errores de forma gratuita. El intercambio de código se vuelve más simple, ya que no es necesario dividir la base de código en múltiples repositorios. La implementación y monitorización únicas simplifican los aspectos técnicos. La ley de Conway destaca la importancia de la estructura del equipo en la arquitectura del producto. Para implementar una sola aplicación, se construye una aplicación shell para determinar la mini-aplicación apropiada en función de varios parámetros, como la ruta o el rol del usuario.

Otra cosa que obtenemos de forma gratuita cuando trabajamos en una sola aplicación es el manejo de análisis e informes, porque recuerda que en nuestro caso de uso, cuando el recorrido del usuario parece muy sólido, comienza desde la página de inicio de Wilco y se sumerge más en el juego y el portal de finalización del juego y queremos mantener estos análisis en la misma vista para rastrear el flujo del usuario a lo largo del camino, así que necesitamos tener los mismos análisis, lo mismo ocurre con el informe de errores, no queremos dos instancias de informe de errores para seguir y muchas más. También tenemos mucho código que se comparte entre esas dos aplicaciones, ya sea la sesión de usuario que necesitamos gestionar, ya sea el código que obtiene cosas del servidor, tal vez sea el manejo de errores y cosas así, así que una vez que tenemos una sola aplicación de React el intercambio de código es algo muy simple. De nuevo, también hay algunas soluciones para micro-frontend pero es un poco más complicado y muchas cosas que configurar. Cuando tienes una sola aplicación, puedes aprovechar un solo repositorio. No necesitas dividirlo en varios repositorios que debas mantener, vigilar y gestionar. Un solo repositorio, al igual que una sola aplicación, nuevamente, como dije antes, también para un micro-frontend. Puedes trabajar en un solo repositorio pero debes configurarlo. Hay cierta sobrecarga para configurar espacios de trabajo o aprendices y así que hay soluciones pero hay cierta sobrecarga pero lo obtienes de forma gratuita. Y una última cosa, en el aspecto técnico, puedes obtener solo una implementación, una implementación para vigilar y una implementación para monitorizar. Hay pros y contras, por ejemplo, si introduces un cambio en solo una aplicación, también obtendrás una implementación en la otra aplicación, pero por lo que vimos, en la mayoría de los casos se cambian en ambas direcciones, así que está bien para nosotros. Pero más allá del aspecto técnico que debes tener en cuenta, también hay una cosa de la que quiero hablar cuando se divide un repositorio y se dividen las aplicaciones y esta es la ley de Conway. Para aquellos que no están familiarizados con la ley de Conway, dice que tu producto, lo que construyes y las cosas que los usuarios obtienen, realmente es una copia de la estructura de tu equipo o cómo te comunicas. Por ejemplo, si tienes muchos equipos dentro de tu organización, por ejemplo, uno para el front-end y otro para el back-end y otro para la vista de mensajes, otro para el menú, el producto se verá así. Verás pilares aislados donde se ve que hay algunos equipos aislados y en nuestro caso solo teníamos un equipo, un equipo muy pequeño, recuerda que somos una startup que acaba de comenzar somos muy pequeños y no quería crear algún tipo de aislamiento en el producto porque nuestro equipo era muy pequeño y muy cercano entre sí, así que quería que todos los equipos pudieran trabajar en ambas aplicaciones y poder escribir una solicitud de extracción o escribir código que los cambie a todos juntos y eso es una de las cosas que debes tener en cuenta. No es solo técnico, tal vez los problemas técnicos. Estos son más fáciles de evaluar, pero tal vez lo más difícil que necesitarás cambiar es la estructura del equipo. Esto es muy, muy importante para tener en cuenta.

De acuerdo, espero haberlos convencido de que hay valor en mantener este tipo de aplicación como una sola aplicación. Entonces, veamos cómo vamos a hacer esto. Al final del día, lo que vas a construir es una aplicación shell. Esta es la aplicación de alojamiento que podrá decidir cuál es la aplicación correcta que deben agrupar o cuál es la aplicación correcta que deben conectar a la vista del usuario. En esta aplicación shell, recibiremos una solicitud y, en función de todo tipo de requisitos o parámetros, podremos decidir cuál es la mini-aplicación correcta que deben conectar a la aplicación shell. Y esta decisión puede basarse en todo tipo de propiedades. Por ejemplo, en nuestro caso de uso, se basó en la ruta del usuario. Si el usuario va a la aplicación vilko, obtendrá la oscura, y si va a anything.vilko, obtendrá el portal de anything. También puedes hacerlo no solo en función del subdominio. Puedes hacerlo en función de la ruta de la aplicación. Tal vez lo hagas en función del rol del usuario. Tal vez un usuario regular obtenga una experiencia y los administradores o internos o usuarios conectados obtengan la otra. Tal vez

4. Manejo de la Aplicación Shell, Enrutamiento y Autenticación

Short description:

La aplicación shell maneja funcionalidades comunes entre aplicaciones, como el manejo de errores, el estado global de la aplicación, el manejo de sesiones, la comunicación con la API, los web sockets y el almacenamiento en caché. El enrutamiento puede basarse en el dominio o en la ruta, pero el enrutamiento por dominio puede presentar dificultades con el estado compartido en React. La sincronización de la autenticación entre aplicaciones requiere un manejo cuidadoso para garantizar una experiencia de inicio y cierre de sesión sin problemas. Compartir cookies entre subdominios puede ser un desafío.

basado en la vista de los usuarios, lo que decidas. La interrogante allí. Al final del día, es una función de JavaScript que puedes decidir. La aplicación shell, como puedes ver, espero que puedas verlo. La aplicación shell manejará todo lo que es común a todas tus aplicaciones. Ya sea el manejo de errores, como puedes ver allí, estamos usando WorldBar. El estado global de la aplicación que decimos que puedes compartir entre esas aplicaciones. El manejo de sesiones, si el usuario ha iniciado sesión o no. Y si no, lo redirigimos al camino correcto. La comunicación con la API, la comunicación con el servidor y tal vez la autenticación, cosas como estas. Los web sockets y cómo recibir notificaciones del servidor, cómo crear y abrir este web socket, el almacenamiento en caché, etc. Todas esas cosas muy comunes que necesitas manejar, tanto en la aplicación Portal como en WorldBar. Y como puedes ver, todo esto sucede sin problemas, sin importar en qué aplicación estés trabajando y en qué se base, específicamente aquí, en la ubicación o región de la ventana, podemos conectar la aplicación correcta.

De acuerdo. Entonces manejamos la aplicación Shell y luego necesitamos decidir qué tipo de enrutamiento queremos hacer. Específicamente para nosotros, teníamos dos opciones. Ya sea utilizar el dominio, el subdominio, como digo, app.will.gg o anything.portal.gg. Así que tenemos la opción de decidir en función del dominio o de la ruta. Utilizarán el mismo dominio, pero decidiremos en función de la ruta, tal vez. will.gg/barra-aplicacion will.gg/portal. Esto es algo de lo que hablamos junto con nuestro producto. Una cosa muy importante que debemos tener en cuenta al utilizar el enrutamiento por dominio, es que no puedes aprovechar el estado compartido de manera transparente dentro de React con un solo contexto, porque al moverte entre dominios, hay una especie de actualización. No puedes simplemente usar push state, esto está en la especificación de Mozilla. Así que esto es algo de lo que discutimos mucho con nuestro producto y decidimos seguir utilizando el dominio para distinguir entre las dos aplicaciones y tal vez perder una gestión de estado muy sencilla o el almacenamiento de estado entre estas dos aplicaciones. Todavía hay algunas soluciones, como utilizar iframes en segundo plano, estado compartido y mover el estado al servidor, pero no es tan fácil. No es tan fácil y no lo obtienes de forma predeterminada.

Entonces tenemos la aplicación shell, decidimos sobre el enrutamiento, ahora necesitamos manejar la autenticación. Y lo que necesitábamos en nuestro caso, porque usamos Auth0, pero no importa realmente qué proveedor de autenticación utilices, debes manejar la sincronización entre esas dos aplicaciones. Cuando inicio sesión en Wolco, en la aplicación, también quiero iniciar sesión automáticamente en Portal sin que yo o los usuarios necesitemos registrarnos nuevamente o ingresar su nombre de usuario y contraseña nuevamente, y lo mismo ocurre cuando inicias desde Portal. Y también cuando cierras sesión, debes borrar todas las sesiones de todas las demás aplicaciones. Nos enseñaron que es sencillo, pero no es tan simple, porque el intercambio entre subdominios, como vimos, no funciona tan fácilmente, porque no puedes compartir cookies fácilmente entre ellos.

5. Autenticación y Subdominios

Short description:

Configuramos un subdominio dedicado para la autenticación y utilizamos un iframe para la autenticación de cierre de sesión y obtener un token. Para obtener más detalles sobre esta solución específica, recomiendo leer nuestra publicación en el blog escrita por Eric, que cubre los pasos de implementación y los requisitos de código para manejar el movimiento de sesiones entre subdominios.

Lo que hicimos fue crear y configurar un subdominio dedicado para la autenticación que podemos aprovechar para esas dos aplicaciones. Y en una de ellas, creamos un iframe en segundo plano que realiza la autenticación, la autenticación de cierre de sesión para obtener un token. No voy a hablar mucho al respecto. Es muy, muy específico para la solución que, si eliges un subdominio, pero si también tienes esto en mente, te recomendaría leer nuestro blog escrito por Eric de nuestro equipo. Hay mucha explicación allí. Cómo hacerlo, qué código necesitas escribir, cómo se mueve la sesión entre todos los subdominios, y qué necesitas hacer para admitirlo. Una última cosa que debes recordar es la división de código, porque al final del día estamos creando algo como esto. Una aplicación shell que contiene tanto la aplicación Wilco como la aplicación Portal y si, por ejemplo, entro en la aplicación Wilco, obtendré toneladas de basura o recursos que no se utilizan realmente y que manejan la aplicación Portal y es solo una pérdida de tiempo y de red, ¿de acuerdo? Entonces, lo que podemos hacer, afortunadamente tenemos React para resolverlo muy fácilmente para nosotros. Cargamos cada una de las aplicaciones con React Lazy. Eso significa que detrás de escena React creará para nosotros dos paquetes diferentes. Uno para el Portal y otro para el Wilco y los dividirá y solo cargará el que realmente vamos a usar. Entonces, si voy a Wilco, cargará la aplicación Shell y la Shell solo cargará el paquete de la aplicación Wilco y solo cuando vaya al Portal cargará todos los recursos relevantes. Lo mismo ocurre con el paquete compartido porque, como dijimos, hay mucho código que se comparte entre estas dos aplicaciones y no queremos volver a descargarlo. Cuando voy a la aplicación Wilco, se agrupará junto con la aplicación Wilco muchas bibliotecas que también se utilizan en la aplicación Portal. Entonces no quiero volver a descargarlo. Entonces, nuevamente, el mismo truco se aplica allí, vamos a dividir el código compartido en su propio paquete para que cuando vaya a la aplicación Wilco obtenga el paquete compartido y cuando vaya a la aplicación Portal el paquete compartido ya esté en mi caché y ya lo haya descargado. También ayudará al cambiar el código. Si estoy cambiando todo el código compartido, la aplicación Wilco y la aplicación Portal no lo cambiarán, ya estará en caché. Entonces, como resumen de lo que hicimos aquí antes de seguir este camino de microfronted por favor, piensa antes. Romper puede ser tu solución predeterminada, pero puede ser muy, muy difícil después invertirlo. Si decides usar una sola aplicación, piensa cómo dividir y cuál es la lógica de dar a cada uno la aplicación correcta, ya sea en la sesión del usuario, en un rol, una contraseña, un subdominio o una ubicación geográfica. El manejo de sesiones, especialmente si usas diferentes subdominios, puede ser complicado, pero también no olvides manejar el cierre de sesión y borrar la sesión. Y una última cosa, piensa en la experiencia del usuario, cómo agrupar el código, cómo ahorrarles tiempo y red y entregar una aplicación más rápida. Eso es todo, muchas gracias, pueden encontrarme en Twitter con este nombre y me encantaría que prueben Wilco en esta dirección. Gracias, adiós.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
React Advanced Conference 2022React Advanced Conference 2022
29 min
Understanding React’s Fiber Architecture
Top Content
We've heard a lot about React's Fiber Architecture, but it feels like few of us understand it in depth (or have the time to). In this talk, Tejas will go over his best attempt at understanding Fiber (reviewed by other experts), and present it in an 'explain-like-I'm-five years old' way.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.