search

danielgerlag / workflow-es

Workflow / durable task library for Node.js (or modern browsers)
MIT License
202 stars 49 forks source link

Ever been used in an Angular app? #33

Open king612 opened 5 years ago

king612 commented 5 years ago

Do you know of / can you point me to any examples of workflow-es being used in an Angular app? Clearly the TS would enable that, but we are about to make a significant architectural decision about worklfow, and I'd like to use this library. But I'd sure love to see it being used in an Angular app before we make that commitment. (We're using Angular 6)

Any suggestions?

Thanks!

danielgerlag commented 5 years ago

Could you talk a little more about your use case for this? Are you intending to run workflows on a server in the backend or within a browser app? You can consume this library with JS or TS.

king612 commented 5 years ago

Thanks so much for getting back to me. We could do either but I would strongly prefer to run it on the client side in the browser (the TS version). We have a typical Angular (6) SPA app with a Node server and a Node-based server layer for data interaction. My use case is a user group of analysts who work on cases in a typical workflow procedure of building up a complex object over time, capturing analytical notes and other artifacts, going through a review and approval process, and having a dashboard to show the current status (step) of multiple of these at once. One thing I'm particularly interested in is how user events in the client app would trigger the advancement of the workflow to its next step. Most of the simple examples seem to run through an entire workflow process in one go. Of course in a real app, the steps play out just one step at a time over a period of days or weeks. It's not at all clear to me how your library would be used in that scenario.

We are using MySQL on the backend, so I was delighted to see that provider go up. And while the example code is certainly helpful, what I think would get your library a lot more traction would be a set of API docs and a concept paper (with a diagram or two) about how the system works in general. Trying to figure all this out from reading the source is tough. Your code is brilliant and elegant, but the techniques are so advanced that most folks will have a hard time try to figure out how to use it simply by reading the source. Again, the code examples are great, but they can only take a new user so far. Need to understand how the whole thing fits together and works as a framework. We're about to make a fundamental technology choice here that we will be living with for many years.

I would urge you to work up some documentation because I feel strongly if you did that your library would really take off. It looks like a fantastic piece of work - and the only one of its kind I could find after much searching - so I think your adoption rate could be really high. It definitely fills a critical need IMHO.

Thank you!

danielgerlag commented 5 years ago

I think if you're looking to do short lived workflows that only exist for a user session, running them inside your angular front end might be ok... but if you want long running workflows, you might want to keep them on the server inside your Node app. Also, I don't think the MySQL or MongoDB provider would work within a browser context. So I would build the workflows on the server tier and expose an API for your front end app to interact with them. If you want to build your server on another tech stack, I also have .net and Java versions of the library.

king612 commented 5 years ago

Thanks so much for the advice. Yes we already have a Node service layer and are planning to us MySQL for persistence generally. I think you're right, server-side is probably the way to go and would probably also eliminate possible CORS issues with persistence calls.

I'd like to reiterate though that I think your library is a marvelous piece of work and fills a critical need, yet is is only lightly used, at least according to NPM download stats. I'm very confident that a robust set of documentation (not just code samples) would increase the package's traction and usage. I would start with a concept paper about what the basic entities are, how they interaction with one another, event-driven use cases (i.e., events generated by the UI, which would be the most common one I think), how the execution engine works, etc. I would use as a working example the very common use case of a entity (e.g., a document) being collaborated on by a team, going through various reviews and approvals, requiring additional changes (a kick back loop), how a work queue would be generated from the raw pieces, etc.

Thanks again for the work and for getting back to me.