Firebase

Martita- #1 Jun '16 Last Sorcerer Standing

Buenas compañeros.

Junto con un amigo, voy a hacer mi primera aplicacion "seria" que si sale bien, pues bien, y sino, pues cogemos experiencia para futuras entrevistas y trabajos.

El tema es que la aplicacion necesita mandar avisos a todos los usuarios cuando uno de ellos envia algo, bien sea un mensaje, una alerta, etc.

Habiamos pensado en firebase, ya que hemos mirado las caracteristicas que tiene, y nos ha parecido muy interesante, el hecho de que te haga el envio de mensajes solo y ademas tambien te hace la autenticacion de usuarios y cosas por el estilo, todo de una manera bastante sencilla, aparentemente.

El tema es que necesitamos hacer estadisticas tambien, y no se en este caso, al ser una base de datos NOSQL, si podremos hacer algo parecido a SELECTS para hacer counts y demas historias.

Habeis tenido trato con firebase? Que tal es? Como la veis?

Gracias!

MartiONE #2 Jun '16 El reportero de guerra sonriente

Hola!

he tocado un poco de firebase en alguna aplicación que he hecho por hobby, y no diría que está pensado para estadísticas ni nada complejo como la "segunda parte" que queréis hacer.

Yo firebase la utilizaría para la gestión de logins, mensajes, notificaciones y poca cosa mas, que lo hace muy fácil. Luego para estadísticas o algo más complejo, quizá otra base de datos relacional por detrás.

Es mi opinión personal.

m4andg4 #3 Jun '16 Cofrade

#1 claro, pero tendrás que implementarlas a mano. Parseado de los archivos JSON y tratamiento mediante procedimientos y funciones.

Merkury #4 Jun '16

#1 Si vais a usar NoSQL pensand en utilizar un ODM que os permita mapear la base de datos a su equivalente en Clases, y programaticamente os picais la extraccion de las estadisticas y prau.

sh31k #5 Jun '16

#1 Si lo que quieres es tratar información almacenada no te recomendaría el uso de firebase, ya que como te comentan arriba tendrás que programar la extracción de datos de los json y mapear la bd.

Puedes echarle un vistazo a Socket.IO, que haría algo parecido a lo que hace firebase para la parte de funcionalidad realtime

Zerokkk #6 Jun '16

Has pensado en Parse Server? Nosotros estamos pensando implementarlo en una startup y tiene una pinta que te cagas.

1 respuesta

robb #7 Jun '16

#1 Estoy en las mismas

#6 Parse va a cerrar xD en breves además

EDIT: Has dicho Parse Server, perdona no lo había leido; Pero según tengo entendido ha quitado muchas características de Parse original

2 respuestas

Martita- #8 Jun '16 Last Sorcerer Standing

No lo he hecho nunca, pero tan dificil es hacer un simple "count" o cosas por el estilo con la base de dato que usa firebase?

Cuando me refiero a estadisticas, es sacar un %, contar algunas cosas, y demas.

1 respuesta

Zerokkk #9 Jun '16

#7 A mí me han contado que viene a ser prácticamente lo mismo, sólo que ahora lo hosteas tú, esa es la diferencia.

1 respuesta

eZpit #10 Jun '16 Juntabrackets

#7 Parse Server es basicamente la instancia del defunto parse que te la puedes hostear tu (hay también otros servicios que la hostean por ti, de pago logicamente).

Respecto a Firebase, pues es un backend "dummy"; es decir que no hace nada más que tragarse los datos que le mandes. Si necesitais procesar o medir esos datos, tendreis que correr código en algun lado que se conecte a Firebase y haga lo que querais con esos datos. Otra opción es que los propios clientes hagan esos calculos que necesitais (si es que es posible, que con lo que habeis explicado no queda claro que teneis en mente).

Para que os hagais una idea de lo que estoy diciendo os dejo un tutorial de google en el que explican un ejemplo de AppEngine controlando datos de firebase:
https://cloud.google.com/solutions/mobile/firebase-app-engine-android-studio#writing_the_servlet_code

#8 El problema de Firebase es la estructura que useis para la base de datos. No es dificil medir cosas si estrucutrais bien y denormalizais bien los datos. Podeis usar contadores que se incrementen en tiempo de escritura y asi no teneis ni que hacer counts.
Tener en cuenta que cada vez que accedes a un "nodo" de Firebase te tienes que bajar TODO lo que tenga nesteado (es json a pelo) así que según la estructura que monteis hacer un count puede ser muy facil o muuuuuuy dificil.

Martita- #11 Jun '16 Last Sorcerer Standing

Imagino que tener una base de datos duplicada, una con firebase, y otra donde se ingresan al mismo tiempo los datos, simplemente para tenerlos ahi y hacer estadisticas y sacar esos datos con MySQL no seria una solucion optima verdad?

1 respuesta

eZpit #12 Jun '16 Juntabrackets

#11 No necesitas dos bases de datos; puedes leer los datos de Firebase, hacer todos los calculos/estadistica que necesites y luego guardar los resultados en Firebase.

1 respuesta

Martita- #13 Jun '16 Last Sorcerer Standing

#12
Esque en una base de datos relacional normal y corriente, tengo muy claro como hacerlo, pero en esta no SQL, no se muy bien como hacer referencia luego a la PK de quien son las estadisticas y tal, una vez las tenga que volver a guardar y demas.

Tendre que investigar a fondo.

B

[Borrado] #14 Jun '16

#9 y que no hay soporte ni dinero destinado a ello y creo recordar que hay muchos menos features, entre ellos push notifications, webhooks, background jobs... Y a saber si facebook le dara por meterlos o abandonarlo todo completamente

Parse server seria sin duda la peor opcion a mi parecer

2 respuestas

Zerokkk #15 Jun '16

#14 Todo eso sigue estando disponible en Parse que yo sepa xD, quien está llevando las especificaciones técnicas del backend así lo constata, al menos.

¿Qué sustitutivo recomendarías si no?

aerotoad #16 Jun '16

#14 Si te pasas por el repositorio de github de Parse Server verás que tiene muchísima actividad, la cosa ya no está en manos de Facebook sino de la comunidad y parece que le va bien porque, si bien es cierto que a la salida le faltaban las características que mencionas, la cosa ha cambiado mucho desde entonces.
Ya hay soporte para push y cloud-functions.

Los background jobs tenían sentido cuando Parse era una plataforma cerrada, pero ahora que es self-hosted, tienes acceso al código y Parse corre como una instancia de Express...puedes hacer lo mismo con kue o un simple cron.

Por otra parte han añadido una nueva funcionalidad: las LiveQueries que permite "suscribirte" a los cambios en una determinada clase de tu backend y obtenerlos en tiempo real.

Por otra parte no hay que perder de vista el hecho de que tiene los sdk que siguen funcionando con Parse-Server y te evitar todo el lío de tener que moverte por el json como en firebase.

Edit:

Se me había olvidado mencionar Parse-Dashboard que permite tener una representación visual de tu base de datos...y es exactamente igual que la versión beta que sacaron en parse.com poco antes de cerrar.

1 1 respuesta

robb #17 Jun '16

#16 Eso ya me interesa mucho más, no sabía que habían features nuevas y lo estaban manteniendo.

Pero la cosa, entonces podrías responderme en que se diferencia firebase y parse server? Que ventajas tienes en parse server respecto. Firebase?

1 respuesta

s4suk3 #18 Jul '16 Penitente

#17 Llevo utilizando parse en varios proyectos, firebase no lo he tocado, pero te responderé pq no lo he probado, simplemente por el precio, firebase está el mínimo en 25 euros/mes, mientras que el otro te lo instalas en un vps cualquiera, y los hay por 4 euros al mes.

1 respuesta

robb #19 Jul '16

#18 A ver, firebase tiene un precio muy competitivo para lo que es eh

La cosa es, podrías contestarme si parse server tiene hoy dia las mismas features que tenia el anterior Parse?

1 respuesta

s4suk3 #20 Jul '16 Penitente

#19 las mismas no, lo básico si, push y cloud code, que más te interesa?

bLero #21 Jul '16

Hola, yo estoy usando Firebase en el curro para un proyecto mediano.

Elegimos Firebase por sus características real-time que lo hacían perfecto para lo que buscábamos, porque escala hasta el infinito, porque es gratis hasta tener bastante actividad y por el ecosistema que hay detrás (notifications, crashlytics, analytics, testlab ...)

Después de unos 2 meses de desarrollo tengo que decir que no nos equivocamos y estamos muy contentos, pero no sirve para cualquier proyecto.

Hay que pensar muy bien la estructura de la base de datos antes de ponerse a picar código. Al estar tan limitadas las queries es necesario estudiar muy bien los datos que vamos a solicitar, y muchas veces incluir datos precalculados para que puedan ser rápidamente consultados después (por ejemplo los counts). En caso contrario y como dicen por ahí, es necesario bajarse el fichero JSON y hacerle queries a mano.

Recomiendo estas 2 charlas del Google.IO:
Deep dive into the realtime database
The key to Firebase security

1 respuesta

Martita- #22 Jul '16 Last Sorcerer Standing

#21
El problema es que los count, por ejemplo, para las stats, yo no los podria hacer antes de insertarlos, ya que tendria que contar desde la propia base de datos cuantos hay.

2 respuestas

eZpit #23 Jul '16 Juntabrackets

#22 Pero puedes tener un contador y subirlo a mano junto a cada insert. La duplicidad es necesaria

varuk #24 Nov '16

#22 Perdón por reflotar pero estaba buscando sobre este tema... y este está bien para preguntar esto mismo:

¿Al final usaste Firebase? ¿Cumplió tus expectativas?

La verdad es que estoy interesado pero he visto que el plan gratuito admite solo 100 conexiones simultáneas y eso me echa para atrás, aunque ya sé que es gratis y no puedo ir pidiendo peras al olmo.

1 respuesta

Martita- #25 Nov '16 Last Sorcerer Standing

#24
El tema es que al final si quieres hacer notificaciones push, tienes que hacerte una API REST igualmente.

Por lo demas, es una pasada la base de datos en tiempo real.

2 respuestas

varuk #26 Nov '16

#25 mmm muchas gracias Martita

1 respuesta

Martita- #27 Nov '16 Last Sorcerer Standing

#26
Si no es tu caso de las notificaciones push, yo le daria un tiento, a mi me gusta mucho.

Fastestwat #28 Nov '16

#25 Por qué necesitas una API REST para hacer notificaciones push?

1 respuesta

Martita- #29 Nov '16 Last Sorcerer Standing

#28
Igual me equivoco, pero no puedes enviar notificaciones desde la propia firebase.

Osea si puedes, pero no que lleguen automaticas cuando pase X cosa, como cuando te llegue un nuevo mensaje o algo asi. Puedes enviar notificaciones pero desde el panel de control a X hora determinada y cosas asi nada mas.

1 respuesta

MartiONE #30 Nov '16 El reportero de guerra sonriente

#29 Ah no? https://firebase.google.com/docs/notifications/

1 respuesta

Firebase

Usuarios habituales

Tags