¡Ojo! Cuidado en Firebase con el forEach de los Snapshots de la Realtime Database

Firebase es un PaaS de Google con un nivel de abstracción muy alto que te permite tener un completo backend serverless. Hacía años que no lo usaba y estoy encantado con él, pero hay que andarse con ojo porque ningún entorno ni tecnología llega a ser perfecto.

La semana pasada estaba programando una cosa en Javascript usando la librería de Firebase, para un proyecto en el que he usado su Realtime Database para montar un sistema de presencia que me diga en todo momento quién está on y quién está off.

En un momento dado, detecté un problema que no entendía de dónde podía venir:

Hacía una query a la base de datos, que me devolvía unos resultados que yo procesaba. Sin embargo, el resultado era un único dato cuando en la BBDD tenía que haber más. Tras unos cuantos tests, me di cuenta de que si lo mismo lo programaba de distintos modos (que deberían comportarse igual) ¡el resultado era distinto!

snapshot.forEach(s=> array.push(s.val()));
//vs
snapshot.forEach(s=>{array.push(s.val())});

Esas dos estructuras, daban resultados distintos ¿cómo podía ser?

Tras darle unas cuantas vueltas con cara de absoluta incredulidad llegué a la clave del asunto en el último sitio que me quedaba por mirar de la documentación de Firebase:

Último ejemplo de la documentación de Firebase
https://firebase.google.com/docs/reference/js/firebase.database.DataSnapshot#for-each

Se habían alineado Roma con Santiago:

  • Un desarrollador/diseñador había elegido usar un nombre habitual, dándole un comportamiento no habitual.
  • En Javascript todo lo que no sea falso/0/undefined se evalua como true.
  • La información referente a como funcionaba estaba en el último rincón de la documentación.

Todo habría sido distinto si el método se hubiese llamado cancellableForEach; o si al menos hubiesen comprobado que el valor recibido era verdadero comparándolo con el operador de igualdad estricta (“=== true”); o si, ya cogiéndolo por los pelos, la ejecución del método cuando reciba algo que no sea booleano arrojase un warning…

En cualquier caso, tras un rato de frustración el problema quedó solucionado.

Valga este post tanto para recordar que hay que tener cuidado en Firebase con el forEach de los Snapshots de la Realtime Database, como para recordar la importancia de los nombres que ponemos a las cosas.

All in one serverless solutions

There are a lot of platforms and applications that are providing serverless capabilities to our developments, avoiding us of thinking a lot about servers.

You can find services for serverless storage, serverless notifications, mailing, payments, forms, but it could be quite difficult integrate all of them into one single solution. What is the best way to have all possible functionalities in one only place and don’t do a lot of work?

all in one photo

Actually, you are able to use a lot of serverless functionalities from wide platforms like Google Cloud, AWS or Azure. Did you remember that article about Azure Serverless? That platform has a lot of high-level functionalities and services that can allow you don’t think about machines, operating systems, RAM, network, etc. when your app needs to scale. But the problem is almost the same, you have all those functionalities in a single platform but you have to do a lot of work to integrate them into one single solution.

There are some platforms that are ready to start working, providing you a lot of capabilities that are planned to work together. They could not be the best in performance or other facets, but they are really god to prototyping and to start working on your MVP accelerating your development. This is because they just work. Some of those are the following:

  • Firebase: Real-time database, authentication, hosting. A powerful platform for your mobile or web application.
  • Backendless: Real-time database, authentication, hosting.
  • Stamplay: “IFTTT For Back-End Development“.
  • Kinvey: Build your digital business faster with mobile Backend as a Service.
  • Syncano: An all-in-one platform to create real-time apps without a server.
  • Hoodie: Hoodie is a complete backend for your apps: develop your frontend code.
  • Para: Flexible and lightweight backend service for rapid prototyping, based on open source software.
  • Wolkenkit: It is a CQRS and event-sourcing framework for JavaScript and Node.js which fits perfectly with domain-driven design (DDD).

Did you know all of them? Look over them and be ready to run developing your next app, and if they are not complete enough for your needs, look for what you need. The Internet is full of serverless services.

Azure Serverless

No, no es una nueva feature de Azure de la que no te hayas enterado. En este artículo vamos a entender que es “serverless” ese concepto tan en boca de todos, y los componentes de Azure que se pueden considerar parte de esta moda.

Seguir leyendo en CompartiMOSS.