TurnoClase meltdown

Ayer en clase la aplicación se volvió loca y descubrí que no está preparada para que 40 usuarios le pidan simultáneamente el turno.

¿Qué ocurre? Que el código que desarrollé en su día para Parse funciona bien siempre y cuando no haya dos accesos a la vez al aula.

En Firestore, la cola se almacena como un array y el cliente actualiza ese array cuando pide el turno, añadiendo su ID al final. El problema es que en el tiempo que pasa desde que lee, actualiza y vuelve a escribir, otro cliente puede haber leído el mismo estado de la cola, añadirse a sí mismo, actualizar y, sin enterarse, ver sus datos sobrescritos por la primera petición que todavía no había llegado a la base de datos. Un desastre.

Toca rehacer el proceso usando una colección de turnos, en vez de un array simple.

Trafikoa

Hoy ha nevado y el mapa de Trafikoa.eus se cuelga en el iPhone, así que partiendo de los datos de de incidencias de tráfico en tiempo real en formato XML sacado de Open Data Euskadi y el código fuente de EuskoEvents he creado un Frankestein hecho de retales.

Para variar, problemas con los datos: el fichero XML en su cabecera dice que está codificado como ISO-8859-1 y el servidor lo envía como UTF-8; un rato perdido hasta dar con el modo de arreglarlo.

Reglas de seguridad de Firestore

Hasta ahora no nos hemos preocupado por la seguridad de los datos que estamos almacenando, pero tenemos que configurar correctamente las reglas de acceso a nuestra base de datos si no queremos tener problemas. Cada usuario sólo tiene que poder acceder a la información que definamos, y a nada más.

Para conseguirlo vamos a definir reglas de seguridad de Firestore que se aplican automáticamente en cada acceso a la base de datos, creando un mecanismo de protección muy eficaz.

Veamos como:

Perfeccionando el modelo de datos

Mientras empezaba a pensar en cómo aplicar las reglas de seguridad incorporadas de Firestore, me he dado cuenta de que le puedo hacer un cambio interesante al modelo de datos y simplificar el funcionamiento.

Voy a eliminar la colección de usuarios (Firebase ya se encarga de guardar la lista de usuarios y proporcionar el UID del usuario actual) y guardar en cada lista el UID del usuario al que pertenece.

Eso permite que:

  • El modelo sea más simple.
  • Las reglas de seguridad se puedan escribir de modo más efectivo (sólo dejaremos acceder a un documento concreto a su propietario).
  • Si en algún momento nos planteamos compartir listas, sólo habría que añadir los UIDs a esas listas compartidas.

El diagrama actualizado queda así (lo que está en gris desaparece):

Vamos a desarrollarlo: