Domando el Parpadeo: Patrones de Firebase para Componentes de Servidor de React

Hola, soy Rosario. Trabajo en el equipo de Relaciones con Desarrolladores de Firebase. Me gustaría comenzar esta charla con el hecho de que esta charla fue realmente preparada por mi colega James Daniels, y él es el verdadero experto en React. En realidad, soy un desarrollador de Android, pero como él no pudo asistir a la conferencia, decidí reemplazarlo. Así que si digo algo incorrecto sobre React, perdónenme. Es solo mi experiencia en Android saliendo a flote.

Así que si no conoces Firebase, Firebase es una plataforma con muchas herramientas para desarrolladores que pueden ayudarte a construir tu aplicación. Así que tenemos cosas como bases de datos, sistema de autenticación, configuración remota para cosas como la activación de características o pruebas A-B. Y ofrecemos esos servicios como SDK del lado del cliente para tu aplicación. Así que lo escribes en JS para la web, o como en Android, lo escribes en Kotlin o en iOS con Swift.

Pero, ¿cuál es el problema con el lado del cliente? El problema con el lado del cliente es que todo se ejecuta en el navegador. Pero si eres un desarrollador de React, podrías tener componentes del servidor de React que se ejecutan en el servidor. Y el problema con eso es que el flujo para el usuario va a ser un poco intermitente, porque si tu servidor está enviando el primer HTML, podría enviar un estado de inicio de sesión donde tienes un botón de inicio de sesión.

Así que vamos a actualizar la UI. Y luego hay un pequeño parpadeo allí para mostrar que el usuario está autenticado. Puede que hayas visto esto en tus propias aplicaciones o en otras aplicaciones. Definitivamente lo he visto mucho. Y luego la UI parpadea, y luego es como, oh, en realidad estás conectado. Y eso es todo.

Entonces, ¿cómo solucionas eso con Firebase? Si estás usando la autenticación de Firebase, en realidad tenemos una nueva, digo nueva, pero en realidad fue lanzada hace un par de años, una clase llamada Firebase server app. Así que puedes inicializar Firebase en tu servidor, y luego obtener todos los contactos de autenticación para esa aplicación, y luego usar eso para enviar al cliente para que el cliente ya sepa que el usuario está autenticado justo en la primera carga de la página. No tienen que esperar a que el lado del cliente entre en acción para poder decirle al usuario que, oh, estás autenticado, así que no necesitas el botón de inicio de sesión.

Y la autenticación es solo la primera parte de la historia porque también tenemos bases de datos. Y una de nuestras bases de datos se llama Firestore. Y Firestore tiene algunas características realmente geniales que pueden hacer que este proceso sea un poco más complicado. Una es el componente sin conexión de ella. Firestore tiene, por defecto, un caché sin conexión. Y así, si el usuario carga la página, y luego los registros de la base de datos llegan más tarde, y luego extraen los registros del caché primero, y luego los registros del servidor llegan después, eso significa que hay como un parpadeo más ocurriendo allí. Y luego otra característica que tiene Firestore es el lado del servidor, lo siento, son actualizaciones en tiempo real.

Así que podrías tener un segundo parpadeo porque ahora el componente en tiempo real entró en acción y hay más registros para mostrar. Y como puedes imaginar, esto es un total de como tres parpadeos que el usuario tiene que esperar antes de ver la página completa. ¿Cómo solucionas esto? Dos componentes principales. Hay una función en los SDKs del lado del servidor que se llama to JSON para que puedas serializar todos los datos. Básicamente puedes ejecutar una primera consulta en el lado del servidor, serializar todos los datos, y luego enviarlos al cliente. Y luego el cliente tiene una función llamada onSnapshotResume, que va a tomar esos datos serializados y simplemente reanudar desde allí, lo que significa que si hay actualizaciones en tiempo real siendo realizadas en la aplicación, no va a invalidar las anteriores si no es necesario.

Y luego para cosas como cachés sin conexión también intenta fusionar todos esos resultados para que el usuario realmente no vea un parpadeo sino más bien solo una adición de nuevos datos o registros siendo añadidos en tiempo real. Así que como dije, la forma en que funciona es que en el servidor, llamarías a to JSON, y luego en el cliente, simplemente pasas esos snapshots serializados y los renderizas. La tercera parte de esto es la configuración remota. Así que la configuración remota se usa para cosas como control de características o pruebas A-B. Y de hecho, recientemente lanzamos configuración remota para el servidor. Así que también puedes usarlo con componentes del servidor. Puedes, en el servidor, obtener todos los valores y luego en el cliente, puedes usarlo para decidir si mostrar la nueva UI o la antigua si estás haciendo algo como control de características o algo así. Y no tienes que esperar a que el cliente descubra todos los cambios para el usuario.

Solo un vistazo a hacia dónde vamos con esto o como, creo que probablemente ya ves un patrón con esto. Esto es solo mayormente una forma de mostrarte cómo estamos tratando de adaptarnos a la web moderna. Y una de las formas en que estamos haciendo eso es con, por ejemplo, tenemos una nueva herramienta llamada Firebase App Hosting que te permite desplegar tus aplicaciones de Next.js o Angular con renderizado del lado del servidor en Firebase. Y bajo el capó, utiliza productos como Cloud Run. Así que probablemente ya estés familiarizado con parte de la infraestructura que utiliza para desplegar estas cosas. También tenemos una nueva base de datos que se llama SQL Connect. Hablé con muchos de ustedes esta mañana durante en el stand y parece que muchos desarrolladores han usado Firestore que es nuestra base de datos no SQL. Pero la buena noticia es que ahora también tenemos una base de datos SQL. Se llama SQL Connect y los SDKs para la web, de hecho, usan consultas de 10 pasos. Así que está comenzando a usar los patrones con los que ya estás familiarizado para la web moderna. Y muy pronto vamos a tener Crashlytics para la web. Crashlytics es nuestra herramienta de informes de fallos para que cada vez que tus usuarios enfrenten algunos fallos puedas verlo en un panel centralizado. Durante mucho tiempo lo hemos tenido para Android e iOS, pero ahora lo estamos trayendo a la web. Y de hecho va a comenzar un programa de acceso anticipado muy pronto. Así que si estás interesado en probarlo, si estás interesado en ser uno de los primeros probadores de esta nueva herramienta, por favor escanea el código QR y encontrarás el formulario que puedes llenar para obtener acceso a ella. Y eso es todo. Muchas gracias por escuchar. Si tienes más preguntas, voy a estar en el stand de Firebase afuera y feliz de responder cualquier pregunta. Gracias.