How does this differ from GeoFirestore?
Bengejd opened this issue · comments
I have been utilizing GeoFirestore in my application for some time now, and it works fairly similar to this library. I am curious to see if this was inspired by GeoFirestore, and how it truly differs? The one thing I have noticed so far is that it handles a lot of the logic inside the library, whereas Geofirestore forces the user to handle a lot of the entrances and exits of data.
I created this library because I had some specialized needs that would not work with GeoFire currently. Here are some of the main differences AFAIK.
- Compatible with compound Firestore queries
- Multiple query points on a single document
- Observable-based, hot and cached to allow multiple subscribers.
- Pipeable operators to transform return values to GeoJSON
- Returns data sorted by distance, with extra metadata about distance and bearing.
In addition, the actual source code is 100% different, as I built this from the ground up. It leverages Turf.js to make additional features easier to build and maintain going forward.
Geofirestore is most definitely based off of the Geofire library (I worked on it as a result of a PR I made converting Geofire to Typescript). I don't think that's an issue per se when it comes to future scaling... But we will see!
As far as caching and multiple subscribers, Geofirestore is able to do that. Firestore I'm general supports caching and the GeoFirestoreQuery object can have multiple subscribers listening for changes through the .on() function.
However the other comments and differences are absolutely correct, and I'd like to think in time I can bridge the gap. However I don't see myself implementing RxJS. (I love it, but I want to keep this as close to being independent of any packages, besides firebase, as possible).
I am interested/excited to look into how you @codediodeio do things when I get some free time! (Keep up the good work)
Thanks for clarifying @MichaelSolati. I think it is smart to leave out RxJS, as I see geofirex as more of a specialized option for apps already using it. Implementing compound queries in Geofirestore would be awesome and I think that'll be a common need among users. The big x factor is "will Firestore have built-in geospatial queries?" It's been hinted, but not sure when this might happen...
Oh I'm sure it will happen, but until it does I think there should be good solutions out there 😁