search

FirebaseExtended / firebase-queue

MIT License
787 stars 108 forks source link

Workflow style task chains #20

Open dreadjr opened 9 years ago

dreadjr commented 9 years ago

Is it possible to write workflows instead of simple task chains with this library?

cbraynor commented 9 years ago

Not currently. Do you have an example of what you're trying to achieve?

dreadjr commented 9 years ago

So i was thinking about doing a generic "share" worker. A share would get broken into multiple paths.

ie. share -> email generation -> send email share -> add to users inbox share -> ...

Right now it seems it is a simple chain X then Y then Z. I have been thinking about adding the ability to do a directed acyclic graph but it might not be a good fit for this project. Maybe the api can expose the internals more which would allow to build on top of this library.

On Thu, Jun 11, 2015 at 4:09 PM, Chris Raynor notifications@github.com wrote:

Not currently. Do you have an example of what you're trying to achieve?

— Reply to this email directly or view it on GitHub https://github.com/firebase/firebase-queue/issues/20#issuecomment-111303357 .

cbraynor commented 9 years ago

I've been considering having multiple success states, but I haven't figured out a way yet that doesn't rely on the processingFunction having to know the exact states it's allowed to exit as or at least the number / order of such states.

It's possible to add tasks onto the queue from a task that's being processed, but doing so opens you up to race conditions if the process stops halfway through so it's not ideal.

For now, I think a linear path is a good compromise between performance and complexity, but if you have any specific ideas on how to improve this without making it too complicated I'd definitely take suggestions

dreadjr commented 9 years ago

Yeah I understand, i don't know the internals of the project well enough to suggest something specific at this point. But defining the transitions in the spec and allowing the user to set the finish state either based on a check function for each transition state, (dynamic in nature, check the resolved data), this would decouple the states from having to know about each other. So essentially each state would have conditions it needs satisfied in order to transition to it.

On Mon, Jun 15, 2015 at 12:06 PM, Chris Raynor notifications@github.com wrote:

I've been considering having multiple success states, but I haven't figured out a way yet that doesn't rely on the processingFunction having to know the exact states it's allowed to exit as or at least the number / order of such states.

It's possible to add tasks onto the queue from a task that's being processed, but doing so opens you up to race conditions if the process stops halfway through so it's not ideal.

For now, I think a linear path is a good compromise between performance and complexity, but if you have any specific ideas on how to improve this without making it too complicated I'd definitely take suggestions

— Reply to this email directly or view it on GitHub https://github.com/firebase/firebase-queue/issues/20#issuecomment-112176228 .