Help wanted

[nandorojo]

I started this repository last year when I was deep in using Firestore directly in my app. Since then, I've started a new company and am no longer importing Firestore in the frontend. As a result, it's harder for me to justify a lot of time spent maintaining this library. Instead, most of my open source time has transitioned to Moti and Dripsy.

This is likely apparent in the new speed of PRs and issues being resolved. I used to close them all very quickly, but I simply haven't had time now.

A few important improvements that are necessary for the future of this library:

• Are there any plans to integrate with firebase v9? #109 Firebase v8 support by default (and look into v9's alpha)
• swr-firestore uses SWR version ^0.2.0, could it be updated to modern one?  #107 Upgrade SWR to the latest version (0.7 might be the highest one that allows the current cache usage without a significant refactor)
• (Added proper query serializer #75 Bug with useCollection and where by timeStamp. #51) Merge this PR to allow dates, query snapshots, and perhaps other complex objects to be used when querying in useCollection
• Get id from created document #62 this one is simple

There are other important issues, but those are probably the most significant I've seen.

Help wanted

Long-story-short, I'm looking for someone else to help / take the reins of maintaining this library. It would be a great opportunity for you to get exposure to the SWR / Firestore community. Ideally you're an avid user of this library, so that you have an incentive to see it improved. Once upon a time, this was me. But for the sake of everyone who relies on this package, I want to make sure it's in the best hands.

Thank you

Thank you to everyone has helped with swr-firestore, from contributions, issues, and PRs. I decided to put this project out for free and abstract it outside of my own app so more people can take advantage of it. At the time, I didn't expect to stop querying Firestore from the front-end. But you never know how things will change.

If you are interested in helping maintain this library, please comment on this thread.

[mm-webx]

I will help you! 🙋

[gavry]

Thanks for the great work! I'd love to help if possible. I've never worked on an OS project before, but I've used this library a fair amount and would be happy to put in work to improve it / keep it up to date. Would be down to learn from example from any other potential maintainers.

[stephenlaughton]

i am also down to help maintain. thanks for all the great work on moti etc. !!!

[nguyenkhooi]

We've been using your library in production for my company App Takeoff, hence I could help maintain and contribute to it based on our experience!

[rolznz]

@nandorojo unfortunately I experienced a lot of bugs working with this library. It is using a very old version of SWR, firebase and some basic things like caching, date filtering and hard to track down / weird bugs due to how queries are serialized were popping up that wasted me a lot of time trying to figure out what the issue was.

Initially I was going to look at fixing the original source code but looking deeper realized there was a lot of duplication and boilerplate to completely abstract away firestore's functions, but this turned out to be quite limiting and does not work well with the latest version of firebase (I guess it is easy to look back in retrospect). Thank you very much for your work on the project and the initial idea.

I have started a complete rewrite on my fork here which is a couple of very simple hooks and works with the latest version of firestore and SWR.

https://github.com/rolznz/swr-firestore

[nandorojo]

I appreciate the sentiment. When I first made this library, I was all-in on using Firestore from the frontend.

But soon enough, I decided that data should be queried from a server instead of a db directly. We entirely abandoned the Firestore-from-the-frontend mindset.

Meanwhile, this library gained more popularity than I expected.

I love open source and putting out what I build as early as possible. But if you build something good, it comes with a curse: you need to maintain it. New versions, bug fixes, dependency upgrades.

If you stop using the library in your own app, the time spent doing so becomes hard to justify. You either abandon it to save your time, or work on it due to sunk cost.

If you take a look at my GitHub profile, you'll notice I actively maintain a number of other libraries now. I make sure to get every issue closed and I every PR reviewed.

Sadly, swr-firestore's popularity grew beyond my ability to maintain it.

your goal isn’t to make every app use your library. it’s to make other libraries copy the ideas you value the most. then your work won’t be lost because it’s upstreamed to the global programming consciousness. the failure case is good ideas dying with your code

I liked that tweet from Dan Abramov.

If the ideas from this library inspire the next iteration, with someone who is dedicated enough to use it in production and make it work properly, then I'll consider it a success in some form.

If you decide to relaunch the library, a nice thing to do is link back to this repo describing what kind of inspiration you drew from it. This can help other developers understand what led you to build your own.

[rolznz]

Thanks @nandorojo. The repository is still visibly forked from this one, but I'll update the README with reasoning as you suggested and a link to the original repository so it is more clear. This project was definitely a success, and don't feel bad - there's only so much one person can do!

[armouti]

@nandorojo would be interested to understand why you changed your mind about using Firestone-from-frontend and only querying from the backend?

[nandorojo]

As an app scales, you’ll notice that forwarding an entire db document to a user is untenable and undesirable. You’ll want private fields, combined responses, backend types that diverge from frontend, relational nested queries (solved by graph databases). Having a server in the middle is important for us. We have a DB schema that differs from the schema the frontend sees. And updating fields via a server lets us safely add type safety, per-field auth permissions that are much better, etc.

While I can see some simple use cases like chat or early projects to query firestore directly, we had to leave this method behind quickly. And while Firestore did grow with us until our app got giant, even with a server in the middle, it required a lot of Redis caching to keep big queries fast.

We’re now migrating our backend to a graph database (using dgraph) rather than NoSQL. It’s a really new concept to us, but we are getting queries in 20ms that would take 20 seconds with Firestore. And that’s with no caching, and adding URQL on the frontend.

That’s been my experience. We like Firestore and it’s treated us well as we’ve scaled. But every app will eventually graduate querying it directly from the front end, in my opinion. That said, if you’re just a solo frontend engineer needing a db, or if you want to ship fast and get moving, it’s a good way to start.