Firebase: lo grande, lo meh y lo feo

Saltamos directamente a Firebase cuando Google lo anunció en Google I / O en mayo de 2016.

Estábamos iniciando una aplicación React de una sola página que necesitaba funcionar en dispositivos móviles a través de Cordova y de escritorio a través de Electron. Entonces, Firebase nos pareció una solución mágica.

Ahora, después de 7 meses de trabajar con Firebase casi a diario, estoy listo para compartir nuestra experiencia con él.

El gran

Datos en tiempo real

Sí, eso es asombroso. Con un poco de plomería y un poco de brujería de vinculación de datos, puede conectar sus vistas con sus datos y cambian mágicamente cuando cambian los datos.

En nuestra experiencia, el rendimiento fue consistentemente excelente, aunque Firebase está diseñado con millones de usuarios en mente, por lo que ni siquiera arañamos la superficie de la bestia.

Nuestros usuarios todavía están impresionados por la rapidez con la que se ejecuta todo.

Alojamiento estático con esteroides

El alojamiento de Firebase viene con CDN y SSL gratuitos; todos se ejecutan en la plataforma Google Cloud. Esto significa que no debería tener problemas para entregar archivos a cualquier número de usuarios en todo el mundo.

Si está buscando un alojamiento de configuración cero para su próxima aplicación de una sola página o sitio web estático, realmente consideraría Firebase como una opción, incluso si no usa ninguno de los otros servicios de Google.

Superpoderes

Firebase también le proporciona una serie de servicios y SDK que son muy fáciles de integrar, como:

  • Autenticación OAuth
  • Almacenamiento de archivos
  • Backups de base de datos
  • Escalado automático
  • CLI para implementación y otras tareas
  • Nivel gratuito

El Meh

La consola

Es bastante y se le permite hacer una serie de cosas, pero no es que útil.

El administrador de bases de datos es realmente un editor JSON glorificado. Genial para lo que es, pero no es la solución completa que esperaba que fuera. Si viene de WorkBench, Postico, Mongotron o incluso PHPMyAdmin, esto vendrá como un buen juguete.

Otro aspecto muy limitante de la consola es la falta de registros o análisis detallados. Teniendo en cuenta que Google está obsesionado con los datos, estamos hablando de esto, parece extraño. Seguro que obtiene un buen gráfico para el uso de la base de datos, pero no hay forma de saber cuántas veces se ha descargado un archivo del almacenamiento a menos que implemente una solución usted mismo.

¿Sin servidor?

Firebase es alojamiento estático + API, nada más. Esta limitación no es el fin del mundo. Puede resolver esto fácilmente utilizando un servidor Node.js como otro cliente de Firebase, que probablemente necesitará para muchas tareas comunes, como crear miniaturas, enviar correos electrónicos a sus usuarios, etc.

Aparentemente, será posible usar Google Cloud Functions (todavía en Alpha) con Firebase, pero quién sabe cuándo. Quizás esto se anuncie en Google I / O 2017.

(Editar marzo de 2017 : Firebase acaba de anunciar Google Cloud Functions para Firebase)

( Edición de mayo de 2018 : consulte mi revisión de Firebase Cloud Functions)

Definición de reglas de seguridad

Firebase usa un archivo JSON con código Javascript en cadenas para definir reglas sobre la base de datos y el almacenamiento.

{ "rules": { "users": { "$uid": { ".write": "$uid === auth.uid" } } }}

Esto no es tan malo como parece, ya que puede usar Bolt para hacer que este proceso sea menos doloroso. Aunque, incluso cuando se usa Bolt, una vez que va más allá de unas pocas docenas de reglas, este archivo se convierte en comida italiana inmantenible.

Servicios como Dream Factory y Graph Cool le brindan una herramienta adecuada para hacerlo sin perder la cordura.

Tecnología patentada

Cuando Facebook decidió cerrar Parse, muchos proyectos se encontraron en una posición difícil. Honestamente, dudo que esto le suceda a Firebase, pero puedo entender la renuencia a acoplar su pila tecnológica con una plataforma como servicio de terceros.

No hay forma de desarrollarse localmente

Si viaja con frecuencia o vive en un país con poca conectividad, considere que no puede trabajar con una instalación local. No puede simplemente usar Docker o Node e iniciar su API.

El feo

SDK de JavaScript limitado

Hay una serie de funciones en Firebase que solo se implementan en sus SDK de iOS y Android.

El más evidente es la falta de persistencia fuera de línea cuando se trabaja con Javascript. Su aplicación web, híbrida o ReactNative continuará funcionando si el dispositivo pierde la conectividad momentáneamente. Pero una vez que cierre la aplicación o pestaña, sus datos desaparecerán. Depende de usted implementar un caché con persistencia. Esto realmente puede ser un esfuerzo serio, especialmente en dispositivos móviles.

El SDK de Javascript ni siquiera tiene una forma de almacenar datos en caché (no estoy seguro de iOS o Android). Si carga /productsy luego necesita esos datos nuevamente, tendrá que volver a cargarlos a menos que mantenga manualmente una conexión en segundo plano. No es difícil implementar esto, pero nuevamente, ¿por qué Firebase no proporciona una forma mágica de hacerlo?

No hay forma de consultar sus datos correctamente

Puede hacer un filtrado y una paginación muy básicos, pero aparte de eso, está solo.

De Verdad? ¿Google proporciona un servicio de datos sin capacidades de búsqueda o filtrado?

Si. De Verdad.

Si desea implementar la funcionalidad de búsqueda, tendrá que descargar todos los datos y hacerlo en el cliente, usar un servidor como describí anteriormente o implementar un servicio de terceros como Elastic.

Los desarrolladores de Firebase han dicho que esto es por diseño, por lo que pueden garantizar un alto rendimiento. OKAY. Pero, ¿por qué no dejar que los usuarios decidamos si podemos pagar el precio de rendimiento de nuestro caso de uso?

Sí, y olvídate de hacer uniones o cualquier cosa remotamente elegante con tus datos. Lo que me lleva a ...

Modelado de datos tontos

Lidiar con las relaciones con NoSQL es difícil, lidiar con las relaciones con Firebase es un dolor de cabeza. - Baptiste Jamin

Lo que dijo.

La base de datos de Firebase es básicamente un archivo JSON enorme. No hay forma de declarar relaciones de una a muchas o de muchas a muchas . En la práctica, esto significa que terminará duplicando sus datos por todas partes.

Esto no parece tan malo al principio. Después de todo, es conveniente poner el nombre del usuario en un mensaje de chat, ¿no?

{ “author”:”Pepito Flores”, “message”:”I want a taco!”, “time”: 1484269756951}

El problema surge cuando tienes que editar el nombre de Pepito, ya que tendrás que modificarlo en todos los lugares donde lo hayas usado y no solo en /users.

Decirle a sus usuarios que no pueden editar su nombre no suele ser una opción viable, así que:

  1. Su código de cliente para escribir y editar datos en Firebase se convertirá en muchos casos en Italian Food ™.
  2. Documentar dónde ha duplicado sus datos será difícil por decir lo menos.

Además, dado que muchas bases de datos NoSQL como MongoDB o RethinkDB han encontrado formas de solucionar este problema, me resulta difícil creer que Google no pueda resolver esto con al menos un rendimiento razonable.

TL; DR

Firebase es increíble para proyectos simples o para desarrollar pequeñas funciones que requieren datos en tiempo real. Por ejemplo, un chat o un sistema de notificaciones. Esas son las impresionantes demostraciones de 30 minutos que ves en YouTube. También funciona muy bien si sus datos son flujos de cosas con una estructura simple, como un servicio para un juego multijugador en línea.

Cualquier cosa con requisitos de datos más complejos se vuelve difícil o incluso imposible con Firebase. Las consultas periódicas de la base de datos del molino son en la mayoría de los casos más valiosas que los datos en tiempo real y, por impresionante que sea ver cambios en las cosas, probablemente no necesite nada de eso.

Como todo, elija la herramienta adecuada para el trabajo.

Anexo: lo que Firebase necesita para ser asombroso

  1. Capacidades reales de consulta. Busca, une, toda la enchilada.
  2. Algún tipo de referencias como MongoDB o RethinkDB.
  3. Persistencia real sin conexión con Javascript.
  4. Dame más análisis.
  5. Una API de caché.

Eso es todo.

Anexo 2: información del moar

Si está leyendo esto, es posible que esté evaluando Firebase como desarrollador o director de tecnología. Aquí hay algunos otros artículos que podrían ayudarlo a decidir si Firebase podría funcionar para usted y si vale la pena invertir más tiempo de desarrollo para la evaluación.

Firebase: Lo bueno, lo malo y lo feo - RaizException - Blog para desarrolladores de Raizlabs

Como parte de nuestro trabajo como desarrolladores de software en Raizlabs, evaluamos constantemente las últimas herramientas de desarrollo utilizadas… www.raizlabs.com Razones para no usar Firebase

La creación de aplicaciones en tiempo real es estándar en la actualidad. En Crisp, usamos Firebase en producción durante 9 meses, a partir de… crisp.im