¿Qué hay de nuevo en Firebase para desarrolladores backend de juegos?
Hola a todos.
Gracias por acompañarme virtualmente en este espectáculo en línea.
Sé que el título original de nuestra charla era
"¿Qué hay de nuevo en Firebase para desarrolladores backend de juegos?
Pero ¡alerta de spoiler!
Hablaremos de Cloud Firestore, qué es, por qué debería importarte
y porqué tu ingeniero de bases de datos está tan emocionado.
Como ya debes saber,
Firebase tiene herramientas que te facilitan
tener tu juego en pleno funcionamiento.
La idea es que nos dejes encargarnos del aburrido trabajo de infraestructura
y puedas enfocarte en otras tareas, como hacer que tu juego sea divertido,
lo cual debería ser tu prioridad.
Brindamos servicios como Firebase Authentication.
que hace que sea muy fácil para tu usuario
ingresar a tu juego desde diversos proveedores.
Tenemos Firebase Hosting.
La idea es que podamos hacer que sea sencillo
tener un sitio web en funcionamiento rápidamente
en un CDN global, que por defecto tiene SSL
y todas esas cosas geniales.
Y esto es genial si tienes, un sitio único de mercadotecnia
para tu juego que quieres alojar rápidamente.
Tenemos Cloud Storage, que es un servicio sólido y a la vez simple
para almacenar objetos binarios grandes.
Y eso puede ser contenido generado por usuarios,
como capturas de pantalla o videos; o contenido que tú proveas,
como datos de juegos posteriores a la instalación.
Tenemos Cloud Functions para Firebase,
que básicamente te permite ejecutar código de backend
sin tener que colocar servidores propios.
Y también tenemos bases de datos para almacenar datos en la nube.
Realtime Database es algo que muchos desarrolladores conocen.
Este es un producto central de Firebase,
de cuando era una empresa emergente independiente.
Y sigue siendo un gran producto.
La idea es que si el usuario cambia el valor en un dispositivo,
nuestros SDKs en los servidores
automáticamente actualicen ese cambio en cualquier otro dispositivo
que escuchen ese valor.
Debo destacar que Realtime es algo un poco diferente
de lo que conocen los desarrolladores de juegos.
Son unos cientos de milisegundos de latencia, así que probablemente
no sea adecuado para tu juego de acción en primera persona.
Pero definitivamente puedes usarlo para, por ejemplo, un juego de bingo.
De hecho, tengo un dato curioso.
Realtime Database se usó para impulsar Loteria.
Es un juego de estilo bingo que se ejecutó como un doodle de Google.
Se ejecutó en la página principal de Google en más de una docena de países.
Y Realtime Database se encargó del emparejamiento, anunciar las casillas,
mostrar los movimientos de tu oponente en tiempo real
y anunciar al ganador.
Y lo que es estupendo es que este juego
pasó de tener cero jugadores a millones
de la noche a la mañana, cuando empezamos a mostrarlo
en la página principal de Google.
Resulta que Google tiene mucho tráfico, quién lo diría.
Y Realtime Database lo manejó todo.
No hubo llamadas de pánico a los ingenieros.
Y de hecho, tenemos una entrada de blog muy buena
que detalla cómo el equipo de ingeniería logró todo esto.
Y les recomiendo leerla.
Y es genial.
Pero para desarrolladores web y de apps nativas
presentamos la próxima generación de Realtime Database,
un producto conocido como Cloud Firestore.
Y en general, ha sido un producto bien recibido,
excepto por el hecho de que no hay bibliotecas de cliente para C++ o Unity
hasta ahora, o supongo que hace unas semanas
cuando anunciamos que estaba disponible en versión Alfa.
Y hablaré más sobre esa etiqueta Alfa en un minuto,
porque es algo importante.
Quizás algunos de ustedes ya estén muy emocionados por esto
y estén corriendo a compilar sus índices compuestos o lo que sea.
Pero para los que no sean expertos en bases de datos,
quizás piensen "bueno, quizás son buenas noticias,
pero ¿qué significa esto y por qué debería importarme?
Así que vamos a explicar.
Cloud Firestore, al igual que Realtime Database,
es parte de una familia de bases de datos conocidas como bases de datos NoSQL.
Y si quieren una versión sobresimplificada
de qué significa eso, bueno, piensen en una base de datos tradicional.
Tienen un puñado de tablas, y cada una contiene
datos altamente estructurados.
Y pueden unir estas porciones de datos
usando un lenguaje de consultas llamado SQL.
Y puedes hacer muchas cosas complejas aquí.
Puedes fusionar diferentes porciones de datos
o fragmentos de datos calculados
de diferentes tipos de tablas.
Y aunque es genial, el rendimiento puede variar.
Esta consulta puede tomar mucho o poco tiempo
dependiendo de cuántos datos tenga, cómo estén estructurados
y qué tipo de consulta estoy realizando.
Ahora bien, las bases de datos NoSQL
difieren en algunos aspectos importantes
Algo que notarás es que tienden a ser un poco más relajadas con los datos.
Oficialmente, a esto se le llama no tener esquema.
Y por lo general es algo bueno.
Le permite a los desarrolladores iterar mucho más rápido
en sus datos subyacentes
sin tener que preocuparse por reabastecer cada cambio
que hacen a sus registros más antiguos.
También te permite almacenar datos que sean similares
pero no exactamente iguales.
Aquí pueden ver que estoy almacenando algunos personajes en la misma colección.
Y sí, claro que son similares.
Pero puedo añadir un libro de hechizos para mi mago
y un grito de guerra para mi guerrero,
y técnicas para abrir cerraduras para mi ladrón.
Y la base de datos no va reclamar
que la estructura de datos no sea exactamente igual
de un personaje al otro.
Simplemente puede lidiar con esto.
Pero creo que la mayor diferencia con una base de datos NoSQL
es el hecho de que no hay SQL.
Las consultas suelen ser mucho más simples.
No tienes todas esas uniones
que fusionan todos los datos o los datos calculados.
Y eso significa que a menudo verás cosas
que se algo inusuales al principio,
como que existan copias de los mismos datos en varios lugares.
Algunas de estas peculiaridades, como este concepto,
que se conoce como datos desnormalizados,
al principio asustaron un poco a los desarrolladores SQL.
Pero a la larga, esas rarezas se compensan.
En primer lugar, las bases de datos NoSQL pueden escalar horizontalmente.
Y eso es muy bueno.
Significa que a medida que tu conjunto de datos
se vuelve más y más grande, puedes ir acoplando más máquinas
y pasará a simplemente entregar tus datos en las diversas máquinas.
Y eso es muy útil en un entorno alojado en la nube
como Google Cloud Platform, donde tenemos tantos servidores
que podemos activar y desactivar según lo requiera la base de datos.
Tu base de datos simplemente crece y se expande
en estos diversos servidores detrás de escena
y sin que sepas que estamos haciendo todo este trabajo por ti.
Por el contrario, las bases de datos SQL tradicionales
suelen escalar verticalmente.
Significa que a medida que tu conjunto de datos crece,
debes conseguir computadoras más grandes para alojarlos.
Y eso puede ser problemático.
En cierto punto, probablemente te quedes sin supercomputadores masivas
en las que puedas ejecutar tus datos.
Y también significa que cada vez que necesites
cambiar a una computadora más grande y rápida,
probablemente haya periodos de inactividad.
Y a menudo, con las bases de datos NoSQL,
encontrarás que el rendimiento es mejor.
De hecho, algo que nos complace decir en el mundo de Cloud Firestore
es que las consultas escalan hacia el lado del conjunto de resultados,
no hacia el lado del conjunto de datos subyacentes.
¿Y qué significa eso?
Significa que si, por ejemplo, tuvieras un juego
donde guardas rompecabezas generados por usuarios
en Cloud Firestore y le pidieras a la base de datos,
"Oye, envíame los 10 principales niveles activos en EE. UU.
ordenados por calificación",
esa consulta tomaría el mismo tiempo sin importar si tienes que buscar
entre 300 registros o 300 millones, ¿no?
No importa cuán grande se vuelva el conjunto de datos de datos subyacentes,
la consulta va a tomar la misma cantidad de tiempo.
Y es genial, porque significa que generalmente
no debes preocuparte por tener que reestructurar
tus conjuntos de datos por razones de rendimiento
a medida que tu juego se hace más popular.
Así que repasemos otras características
que hacen que generalmente sea agradable trabajar con Cloud Firestore.
Primero, suele ser agradable trabajar con el modelo de estructura de datos,
especialmente en comparación con algo como Realtime Database
u otras bases de datos NoSQL.
Todos tus datos suelen almacenarse en documentos y colecciones.
Puedes pensar en los documentos como,
bueno, documentos que contienen pares clave-valor.
Y el valor de estos pueden ser cualquier cosa
desde arreglos a strings,
floats u objetos estilo JSON
o incluso pequeñas cantidades de datos binarios.
Estos documentos pueden ser de hasta 1 megabyte de datos
para cada documento, lo cual es bastante grande
considerando que trabajas mayormente con texto, números y elementos tipo JSON.
Estos documentos se almacenan en colecciones,
que son, como deben sospechar, colecciones de documentos.
Y estos documentos pueden referir, y a menudo refieren a subcolecciones
que contienen otros documentos,
que incluso pueden referir a otras subcolecciones
y así sucesivamente.
Algo para destacar aquí es que todas las consultas son superficiales,
lo que significa que puedes tomar un documento sin tener que preocuparte
por tomar todos los datos que están por debajo.
Y eso significa que puedes estructurar tus datos jerárquicamente
de tal modo que tenga sentido lógicamente
sin preocuparte por tomar muchos datos innecesarios
cada vez que tu usuario solicita uno de estos documentos
aquí arriba.
Cloud Firestore tiene un soporte sin conexión muy sólido
integrado en todas las bibliotecas de cliente,
así que las SDK almacenarán tus datos en caché automáticamente
a medida que los recuperas desde el servidor.
Y luego, si tu usuario fuera a subirse a un avión,
y se pusiera en modo avión,
seguiría teniendo acceso a todos los datos que están almacenados en caché
en el dispositivo, lo que significa que pueden seguir jugando
y tú puedes consultar cualquier dato
que esté almacenado en tu caché sin conexión.
Además, cualquier escritura que hagan tus jugadores
queda en cola en el dispositivo.
Y luego, tan pronto el usuario vuelve a estar en línea,
se envían a tu base de datos
en el orden en que hayan sido guardadas.
Así que no se pierden datos de la sesión de juego.
Cloud Firestore admite recuperaciones simples de datos
a lo que probablemente estés acostumbrado
si vienes de una base de datos más tradicional.
Y muchos desarrolladores comienzan a usar Cloud Firestore de esa forma,
pero también puedes añadir objetos de escucha en tiempo real,
para que tu cliente sea notificado inmediatamente
cuando cambie un valor en un documento.
Eso es estupendo, ¿cierto?
Simplemente le dices a la biblioteca,
"oye, quiero escuchar los resultados de esta consulta".
Y Cloud Firestore te envía actualizaciones
cuando estos valores cambien,
lo que significa que no tienes que lidiar con esa tontería
de pull to refresh.
Tus datos nuevos aparecen tan pronto como están disponibles,
lo que es genial para situaciones como en juegos de multijugador,
donde quieres que el estado de juego se actualice luego de que un usuario
haya tomado su turno.
Cloud Firestore tiene soporte multiregional,
lo que significa que podemos almacenar tus datos
en diferentes ubicaciones a unos cuantos kilómetros una de otra.
Y eso es muy bueno desde una perspectiva de confiabilidad
porque si, por ejemplo, algún tipo de lagartija radioactiva
o lo que fuera, dejara a toda la ciudad sin conexión,
tus datos seguirían siendo accesibles
desde estas otras regiones.
Pero al mismo tiempo, es fuertemente consistente,
es decir que los datos que estás recuperando
son la última versión de los datos que se han escrito en la base de batos
sin importar qué región haya pinchado tu cliente originalmente.
Y seré honesto.
Tener este suporte multiregional que a la vez es fuertemente consistente
es un problema realmente asombroso y difícil que solucionamos
detrás de escena por ustedes.
Y no creo que la gente realmente aprecie lo bueno que es esto.
Pero creánme cuando digo "resolvimos este problema complejo".
Cloud Firestore también tiene soporte para transacciones atómicas
si quieres asegurarte de que otro cliente no esté metiéndose con tus datos
al mismo tiempo que tú.
No tengo una diapositiva para eso,
pero sé que es algo que le preocupa a la gente.
Y tenía que mencionarlo.
Y dado que todos hacemos juegos
y que no siempre podemos confiar en los clientes,
también tenemos soporte para Cloud Functions y reglas de seguridad.
Las reglas de seguridad son reglas que tú defines
y que rechazarán solicitudes del cliente,
ya sea cuando el cliente esté pidiendo datos que no deberían pedir
o esté intentando escribir datos que no se ven como esperas.
Pero si necesitas controles más sofisticados,
puedes usar Cloud Functions.
Son funciones sin servidores que se ejecutan en la nube
en un entorno que puedes controlar y en el que puedes confiar.
Y eso significa que puedes asegurarte de que esta funcionalidad
sea consistente con todos tus clientes.
Y lo más importante, que confías en los cambios
que hacen en tu base de datos.
Sé que hemos hablado un montón sobre Cloud Firestore,
nuestra base de datos NoSQL en tiempo real
que se aloja en la nube.
Y quizás te estás preguntando
¿cómo se compara esto con Realtime Database de Firebase,
la base de datos en tiempo real que se aloja en la nube?
Y para ser claro, realmente no necesitas elegir una u otra.
Puedes usar ambas con el mismo proyecto dependiendo de tus necesidades.
Pero si necesitaras comparar y contrastarlas,
en general me gusta pensar en Cloud Firestore
como una versión reforzada de Realtime Database.
En general, creo que puede manejar mejor los datos más complejos.
Esto es una opinión personal,
pero creo que es más fácil trabajar con el modelo de datos.
Tienes capacidades de consulta más robustas.
Las transacciones son un poco más sofisticadas.
Escala aun mejor que Realtime Database.
Y tienes soporte multiregional para mejor confiabilidad.
Sin embargo, hay algunas cosas que Realtime Database hace mejor.
Suele ser algo más rápida si tus clientes están
en Norteamérica y tiene soporte integrado para la presencia.
Esto les interesa a muchos desarrolladores de juegos,
el que los jugadores sepan si sus amigos están en línea.
Hay alternativas para esto en Cloud Firestore,
pero no están integradas nativamente.
Y no es tan elegante como en Realtime Database.
Además, el modelo de precios es diferente.
En Realtime Database, tus costos se basan principalmente en la cantidad de datos
que intercambias con tus clientes.
Los costos de Cloud Firestore
se basan principalmente en la cantidad de operaciones de lectura o escritura
que realizas.
Así que en general, Realtime Database
será un poco más rentable cuando tengas muchas operaciones pequeñas.
Piensa en un juego como bingo o póquer,
en los que tus clientes frecuentemente envían
pequeñas porciones de información
como "voy", "subo" o "B14".
Cloud Firestore tiene a ser más rentable cuando tienes
cantidades más pequeñas de operaciones grandes.
Piensa en un juego de dibujo asíncrono
donde probablemente envíes una gran cantidad de datos JSON
que representan el dibujo del jugador
o quizás un juego de palabras o de ajedrez en los que se toman turnos,
donde tus jugadores suelen tomarse bastante tiempo para pensar
antes de tomar un turno.
No llevan a cabo tantas operaciones.
Pero diría que no te obsesiones tanto con el precio.
Hay muchas formas en que Cloud Firestore puede ayudarte.
Y sabes, tu tiempo de ingeniería también cuesta dinero.
Si te toman 10 horas extra de ingeniería
el ahorrarte 18 dólares en costos de servidores,
quizás no sea un intercambio adecuado.
Usa tu tiempo de ingeniería sabiamente.
Estas personas suelen comer bocadillos elegantes.
Así que ¿cómo usarías Cloud Firestore en la vida real?
Veamos un par de situaciones posibles del mundo real.
Uno de los casos de uso más simples
es guardar el juego de tu jugador en la nube, ¿no?
Tus usuarios quieren jugar en diferentes dispositivos.
Y Cloud Firestore hace que sea muy fácil guardar tu estado de juego en la nube.
Solo escribes el estado de tu jugador en un documento,
escribes ese documento en la base de datos
y cualquier otro cliente que escuche ese valor
puede tomar la última versión
y asegurarse de que el progreso del jugador se refleje
donde sea que juegue a tu juego.
También debo mencionar que el almacenamiento en Cloud Firestore
es relativamente asequible
si lo comparamos con la Realtime Database.
Así que puedes ir y guardar un par de versiones
para que cuando el jugador llame desesperadamente
a atención al cliente y diga "¡algo le pasa a mi juego!",
tengas la opción de que se restaure a un juego guardado anteriormente.
Otro buen caso de uso en Cloud Firestore es el estado de juego compartido.
Piensa en un juego de palabras o de dibujo por turnos.
Es muy fácil, en principio, que tus clientes
consulten los juegos en los que están participando.
Y luego, cada vez que tu jugador quiera tomar un turno,
puedes registrar ese nuevo estado de juego
en un documento compartido
al que tienen acceso todos los jugadores competentes.
Y luego, gracias a la magia de los objetos de escucha en tiempo real,
los clientes de otros jugadores pueden actualizarse
tan pronto como cambie el estado del juego,
así saben que es su turno.
Y si quieres seguridad extra,
en vez de hacer que tus clientes actualicen este documento directamente,
puedes hacer que envíen el movimiento deseado
a una Cloud Function.
Recuerda, estas son nuestras funciones sin servidores alojadas en la nube.
Esta Cloud Function puede luego validar el movimiento del jugador,
asegurarse de que todo se vea bien.
Y luego puede realizar el trabajo
de actualizar tu estado de juego compartido,
que luego se envía a tus otros jugadores.
Y además, gracias a nuestra integración con Firebase Cloud Messaging,
puedes enviar una notificación a tus otros jugadores
para que, incluso si no tienen tu app abierta en ese momento,
aun puedan ser notificados de que es su turno.
Los desafíos diarios probablemente sean otro buen ejemplo.
Son bloques de contenido que deberás enviar a todos tus clientes
cada vez que ingresen.
Sé que hay muchos juegos de rol, de rompecabezas,
de crucigramas y demás que tienen desafíos diarios.
Y son datos que pueden almacenarse y entregarse fácilmente
a través de Cloud Firestore.
El contenido generado por usuarios es un buen caso de uso también.
De nuevo, para objetos binarios grandes como videos o presentaciones en pantalla,
recomiendo que usen Cloud Storage.
Pero piensen en cualquier juego de rompecabezas o de plataforma
en el que los usuarios creen sus propios niveles.
Probablemente estos sean datos que almacenas como datos JSON.
Y pueden funcionar muy bien en Cloud Firestore.
Y luego, de nuevo, puedes hacer consultas como
"encuentra todos los rompecabezas creados en Norteamérica
ordenados por calificación"
o "encuentra los rompecabezas más recientes"
o "encuentra todos los rompecabezas de un autor en particular".
Pero creo que el caso de uso más interesante,
en especial para muchas compañías grandes y bien establecidas
es usar Cloud Firestore como una capa de caché escalable global en tiempo real
sobre tu infraestructura actual.
Pensemos por un segundo en una aerolínea.
Estas aerolíneas tienen servidores heredados de 30 años
con mucha lógica de negocio y cumplimiento normativo integrados.
Quizás no puedan simplemente mover todo a una nueva base de datos NoSQL, ¿no?
Pero al mismo tiempo, quizás quieran una infraestructura de aplicación moderna
que pueda lidiar con millones de consultas
y tenga actualizaciones en tiempo real y un buen soporte sin conexión
y todas esas cosas, ¿no?
Bueno, lo que estas empresas pueden hacer
es copiar algunos de sus datos a una instancia de Cloud Firestore.
Eso hace que sea realmente fácil para estos clientes realizar búsquedas,
como encontrar precios de boletos
y obtener información del estado de un vuelo y ese tipo de cosas,
y obtener esas actualizaciones en tiempo real
mientras dejas que tu servidor heredado se encargue de cosas importantes
como, por ejemplo, comprar un boleto, cosas que probablemente requieran
pasar por ese servidor original.
Ahora, si has estado mirando esta presentación,
supongo que no estás a cargo de una aerolínea.
Pero quizás tengas un MMO, un juego de cartas coleccionables
o un juego de rol donde tienes una tonelada de datos,
ya sea la configuración del equilibrio del juego
o perfiles de jugadores, o lo que sea, que tus clientes vayan a querer leer
regularmente.
Y de nuevo, esos son muchos clientes que constantemente
acceden a tus servidores.
Así que piensa en poner Cloud Firestore al frente de esto, ¿sí?
Tus clientes pueden consultar los datos
que has enviado a Cloud Firestore
a la vez que liberan tu servidor original
para que se encargue de cosas importantes, como transacciones de jugadores
o compras del usuario.
Ahora, habiendo dicho todo eso,
quizás estés muy entusiasmado por empezar a compilar
con Cloud Firestore, pero quiero hablar de esa etiqueta Alfa.
Aunque el servicio backend de Cloud Firestore
existe desde hace bastante tiempo
y se usa en aplicaciones de producción real,
estas bibliotecas de cliente nuevas son muy novedosas
y aún no han sido sometidas a prueba.
Así que espera que haya errores.
Probablemente haya algunos.
Sabemos que faltan algunas características avanzadas
en el SDK de Unity.
Algunas de las consultas más sofisticadas todavía no están disponibles.
Y cosas como transformaciones numéricas aún no son compatibles.
Y esperamos que la superficie de la API
cambie a lo largo de los próximos meses.
Así que tendrás que renombrar tus métodos en cierto punto,
cuando actualices tus bibliotecas de clientes.
Así que te recomiendo que vayas empezando a probar
estas nuevas bibliotecas.
Mira cómo encajarían dentro de la infraestructura de tu juego.
Y por supuesto, déjanos tus comentarios.
Pero quizás debas esperar para mover todo tu negocio a Cloud Firestore
hasta que llevemos unos cuantos meses.
Así que apartando ese molesto aviso de responsabilidad,
espero que te hayamos generado algo de interés
en usar Cloud Firestore para tu último juego.
Si quieres saber más sobre Cloud Firestore
o cualquiera de los otros servicios que brindamos,
visita firebase.google.com/games y échales un vistazo.
Y como siempre, gracias por mirar.