"queue": { "<queue_type>": { "specs": {
}, "tasks": { "<user_id>": { "<task_id>": { "foo": "bar" }, "<task_id>": { "foo": "bar" } }, "<user_id>": { "<task_id>": { "foo": "bar" } } } } },That way I can fetch the tasks by user but I don't know how to reference the data correctly for the firebase queue. If I would set the reference to /queue/<queue_type>/tasks will receive the user with all it's tasks as data which is not the data I need as the right one would be the sub task for each user. I could reference to /queue/<queue_type>/tasks/<user_id> but that way I would have to setup a big amount of queue workers which seams quite strange aswell. So do you have tips if the data structure is simply wrong or if I can configure firebase-queue in another way?
Hi Alex,
Generally speaking, I tend to structure my tasks like follows:
/queue/specs
/queue/tasks
/queue/results
Note that you would use the same task id in results/ as you use in tasks/. In this way, your client can just listen for the results to be written and then delete them once processed (a sort of reverse queue, if you will). Note that it’s nice to keep a timestamp on those as well, so you can occasionally purge expired tasks for clients that disconnect while a task is in progress and never come back to process and delete it.
That’s certainly not the only way to get this done, and quite a bit depends on what you’re monitoring for here and how much robustness you need. I find this approach a decent compromise.
I hope that helps!
☼, Kato
--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/55433ff5-1e3d-4f1e-bd1b-06212ad19b52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.