Un chat en tiempo real. Ya que estaban todos subidos en el hype train de Firebase también me subí. Lección más que obvia, no todo lo que brilla es oro ¿En serio? ¿Por qué si encontraste una herramienta nueva no haces el disclaimer de las limitaciones? Firebase, todas sus features, son geniales. La base de datos en tiempo real es realmente en tiempo real, el storage tiene una implementación estúpidamente fácil (son como 2 líneas y un listener para el completado optativo), el login es super simple (use el firebase-ui), y las nuevas notificaciones push son 2 servicios que funcionan automágicamente, hasta la integración es simple (creas un proyecto, eso te descarga un json que va en tu app, añades dependencias y listo) ¿Cuál es el problema?

Firebase no maneja lógica de negocios

Sí, estamos trabajando con una base de datos que funciona con nodos, por lo que el modelamiento de datos es distinto. No me refiero a eso. Me refiero a que en las bases de datos SQL se acostumbra a que los objetos puedan compartir datos. Déjenme dar un ejemplo, el current user tiene una foto. El current user sube su 1ra foto, esta foto se almacena y luego el current user sube su 2da foto. La 2da foto se almacena. Cada vez que otro usuario ve el perfil del otro usuario ve la foto actual. Porque user profile picture, siempre hace referencia a la última. En Firebase Database eso no se puede hacer, porque no hay reglas del negocio, entonces no puedes hacer referencia de un nodo a otro (o por lo menos eso entendí yo). Firebase Database tiene un set de reglas, pero ellos mismos dicen “Las reglas no son filtros“, las reglas son para validar y proteger la data ¿Entonces cómo habría que hacerlo? Si el usuario cambia la foto hay que actualizar todos los objetos de toda la base de datos donde está la foto… de hecho traten de pensar en un Twitter usando esta lógica, si es que el timeline es una colección de tuits de todos los usuarios que el usuario sigue ¿Cómo implemento esa lógica de negocios en algo que no tiene lógica de negocios?

¿Otros problemas de Firebase? La persistencia Offline

Sí, la persistencia offline no soporta reinicio de la aplicación. Esto quiere decir que si el dato es sensible y se tiene que sincronizar por obligación, hay que o advertirle al usuario visualmente (mala opción) o hay que añadir adicionalmente el manejo de datos (opción redundante, sacamos la database para volverla a poner, mejor vamos REST con ORM local). El manejo offline que tiene Firebase cubre sólo lo offline durante el transcurso de la apertura de la app.

Vean la documentación, y el pantallazo por si cambia xD

firebase_offline_warning

¿Algún otro problema? Notificaciones Push

Sí, la forma en cómo están planteadas las notificaciones push hace parecer que se pudiera directamente entre dispositivos, no soy el único con esa impresión miren esto en StackOverflow. No se puede, ahora las notificaciones push en el servidor son GCM como siempre, pero en el lado del cliente son Firebase Cloud Message ¿Es un improve? Sí, es facilísimo implementarlas en comparación al antiguo GCM, como dije son 2 archivos automágicos. Lo que pasa es que Firebase tiene un servicio de notificaciones desde la consola de tu proyecto Firebase hacía usuarios o grupos de usuarios. Si es grupos de usuarios, simple, pueden ser todos los que tengan instalada la app, si es hacía 1 dispositivo, hay que registrar el dispositivo antes (tal y como se hace para Firebase Cloud Message o el antiguo GCM). Ahora, esto todavía no resuelve el tema dispositivo a dispositivo, y no se resuelve, porque no se puede, hay que pasar por un servidor. Dispositivo 1 le hace un request http a un servidor y el servidor le manda el mensaje a GCM para que lo reciba el dispositivo 2 ¿Por qué hicieron esto si la base de datos en tiempo real funciona genial? No sé, pero la base de datos en tiempo real no reemplaza las notificaciones push porque no podemos esperar a que el usuario tenga la app corriendo 100% del tiempo.

[Actualización: Al parecer podría haber un workarround ¿Qué tal si la app le hace el post a GCM? ¡Problemon! En tu API queda el token del dispositivo del usuario, o peor, habría que igual consultarlo al backend cada vez]
[Actualización: Una app no cumple los requisitos que se necesitan para postearle a Firebase, ende lo de arriba no funciona]

¿Cuál es la conclusión?

Firebase es otra herramienta más en la caja de herramientas de un desarrollador. Así como en el backend hay servicios de cache, de autoescalamiento, ahora hay Firebase ¿Su app necesita un chat? No se caliente use Firebase ¿Su app necesita calcular un promedio de un atributo de todos los objetos que cumplan cierta condición? Hágalo en su servidor y si quiere que Firebase actualice a los front ends ¿Debería de actualizar GCM a FCM? Sí, es mucho más fácil ¿Usa Amazon S3 para almacenar archivos (fotos por ejemplo)? !Cámbiese a Firebase Storage! No puedo dejar de insistir en lo estúpidamente fácil que es el storage de Firebase, olvídese de esa burrada mal documentada con un foro que nadie responde que es S3.

Finalmente me queda invitarlos a que vean la app que hice Flash

¿Quiere conocer otro Backend as a Service? Lea acerca de BackendLess