3

I'm working in angular with firebase and geoFire. I figured out how geoFire works but i still have these 2 questions about performance:

  1. In the geoQuery.on() callback, can i get 1 array with keys returned instead of 1 callback per 1 event.
  2. In the ref.once() callback, can i get all the tikis in 1 go instead of 1 by 1 using .child(key)?

My controller:

var ref = new Firebase("https://blistering-heat-1126.firebaseio.com/");
var geoFire = new GeoFire(ref.child("geoFire"));

var geoQuery = geoFire.query({
    center: [50.315077, 3.13261],
    radius: 100 //kilometers
})

geoQuery.on("key_entered", function(key, location, distance) {

    ref.child("tikis").child(key).once("value", function(snap){

        console.log(snap.val())

    })

})

My firebase:

geoFire  

-JmE05U-Wbr5LGRSh0Z8
-JmE0COUFBRPZIBqwfYN

tikis

-JmE05U-Wbr5LGRSh0Z8
-JmE0COUFBRPZIBqwfYN
-JmE0Iq7-uvrk5Tg_K8_
-JmE0MrnstNv9d_8ozQ4

thx for your insight...

kevinius
  • 4,232
  • 7
  • 48
  • 79

1 Answers1

0

No, GeoFire doesn't offer a value read observer type so you are stuck with the Key Entered, Key Exited, and Key Moved read event types.

tommybananas
  • 5,718
  • 1
  • 28
  • 48
  • Which just boggles my mind. Say you have 100 keys. Even with promise.all(), you're still making 100 individual requests. So, who in their right mind would use this? – AlxVallejo Oct 24 '17 at 13:38
  • 1
    That's valid with a couple caveats. Firebase does a lot of under the hood optimization as far as I'm aware so even if the library only returns one at a time, odds are it is not actually doing a tcp handshake per callback. If you're using firebase/geofire in the first place you probably aren't writing a high speed trading application and the tradeoff in rolling your own real-time engine vs using firebase is probably not realistic. It's a great tool for general real time applications and you get googles reliability and bandwidth out of the box. – tommybananas Oct 24 '17 at 16:21
  • Sure, but say you need some sorting algorithm on the collection. Rather than parsing the array, you're looking at parsing the array 100x for each newly entered key. Unless that's where you suggest that there are optimal parsing techniques you can do on an individual item level, this ultimately creates more complexity than is desired. With Redux in the mix, you are also dispatching 100 actions for each item, after whatever parsing is required at the array level. I would argue that that creates a lot of complexity out of a simple app. – AlxVallejo Oct 25 '17 at 14:51
  • I would agree with you that since firebase doesn't handle spatial data natively, it is probably suboptimal. I think that's part of where the new firestore product comes in ( https://firebase.google.com/docs/firestore/ ). I would just suggest creating a throttling mechanism where you only render once per second or whatever maximum. If latency and spatial data is so core to your architecture then firebase probably wasn't a correct choice to begin with. Otherwise homemade or RX throttling might help in your use case. – tommybananas Oct 25 '17 at 15:27
  • Re: latency and spatial data. I would have thought choosing a real-time DB with a supported geo-spatial library tagged on to it would have led developers to believe that these were two well supported features. It's hard to imagine I'm the only developer who was misled there. – AlxVallejo Oct 25 '17 at 16:28
  • Like I said you can just build your own throttling mechanism to solve the batch problem. The whole point of geofire is to provide the ability for nodes to enter and exit the system in real time. If you need batch querying capabilities I bet you can just write your own normal snapshot query and do the parsing yourself. Geofire is a very thin layer on top of normal firebase data. I’m not saying I don’t agree it would be useful but it’s not exactly the core use case – tommybananas Oct 25 '17 at 16:31