TRtroycarlson·Mar 10, 2017
A lot of people use the Firebase Queue library for this:
https://github.com/firebase/firebase-queue
In Introducing Cloud Functions for FirebaseFirebaseExtended
firebase-queue
JavaScript2016–2017
FirebaseExtended / firebase-queue · Archived
firebase-queue
Discover this repository through its Hacker News conversations.
3Distinct people
3Mentions
0Explicit recommenders
777GitHub stars
What to know before exploring
What it is
A public description has not been verified.
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month3 dated mentions
Observed mentions: 2016-07-27 08:01:04 UTC to 2017-03-10 13:55:04 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Jul 2016 | 2016-07-01 00:00:00 UTC | 2016-08-01 00:00:00 UTC | 1 | 0 | 1 |
| Aug 2016 | 2016-08-01 00:00:00 UTC | 2016-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2016 | 2016-09-01 00:00:00 UTC | 2016-10-01 00:00:00 UTC | 1 | 0 | 1 |
| Oct 2016 | 2016-10-01 00:00:00 UTC | 2016-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2016 | 2016-11-01 00:00:00 UTC | 2016-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2016 | 2016-12-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2017 | 2017-01-01 00:00:00 UTC | 2017-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2017 | 2017-02-01 00:00:00 UTC | 2017-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2017 | 2017-03-01 00:00:00 UTC | 2017-04-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
3 sourcesFirebase engineer here. I hope you've been in touch with our support team and I'm sorry to see you've had so much trouble. You point out some genuine limitations with our product. We have some great improvements in the pipeline and I'm sorry that they came too late for you. In case others have had similar experience, it's worth mentioning that some of these seem fixable by structuring your data differently[1].
Specifically, complaints 2-4 sound like they all arose from nesting all of your data in one tree[1] and using a query for all children[2]. This means you'll load too much data in every request, which will slow down your microservices and cause a large bill for unnecessary outbound traffic.
#5 has two possible solutions. Either use the push() message to avoid any conflicts in the data you're writing or the transaction() method to man
Read the rest
age the conflicts in an online-only mode. push() requires some work to recompose something from a series of changes, but has the advantage of being offline-compatible.
Regarding #6, I agree we can better support data migrations (we're looking into it). If your problem is as simple as the one listed, I'd really recommend checking out a library like lodash[3]. The ugly if statement could have been
if(_.has(user, 'new_subdocument.new_property')) {
/* do stuff */
}
or even:
var thing = _.get(user, 'new_subdocument.new_property', default);
// always do something with thing; we just added an in-memory
// value that we would have made a data migration for in the
// past.
Finally, regarding queues, are you referring to firebase-queue?[4] This is an open-sourced part of our internal infrastructure. There are currently 16 issues open, but they seem to be mostly feature requests. If you've found bugs we'd love some repo steps.
I hope that helps. We're always listening on firebase-talk@googlegroups.com, stackoverflow.com, and our slack channel.
[1]: For a great article, see https://firebase.googleblog.com/2013/04/denormalizing-your-d... or the general Firebase data layout guide at https://firebase.google.com/docs/database/web/structure-data
[2]: Try using order + limitToFirst(N) https://firebase.google.com/docs/database/web/retrieve-data#...
[3]: https://lodash.com/
[4]: https://github.com/firebase/firebase-queue
True, maybe https://github.com/firebase could help with some reverse engineering. However, I discovered the Firebase document and the deepstream.io record structure to be fairly similar, so with the help of https://github.com/firebase/firebase-queue the migration from Firebase to deepstream.io + RethinkDB might be possible.
As a more general note, I would expect some of the stuff you mentioned to happen in the upcoming months/years, since Firebase is right now set to become the universal plattform for app devs (analytics, dynamic links etc.) rather than a standalone database offering.
In How to escape lock-in with a multi-cloud stack