Workflow API Quickstart

[nyemade-uversky]

Description: This issue is to track work for the Workflow API quickstart

Ideally we'd like to have a quickstart created for the workflow api targeted for 1.10. For this quickstart, we can utilize the early workflow api demos as a starting place and contribute that back as a quickstart for users.

Requirements: Quickstart covers

• [ ] Perquisites needed to get started
• [ ] Process of setting up enviornment
• [ ] Process of invoking the workflow in Temporal. This would be the workflow shared in the API demo
• [ ] Entire quickstart packaged as github template. Something similar to this dapr-pubsub-servicebus quickstart
• [ ] .NET sample only for now. We'll release other quickstart languages in later versions. This is just to get something out there that users can interact with and get an understanding of the workflow API

[paulyuk]

let's def consider for 1.10 as the feature is stable and we can use it. I'd love your help figuring out the specific scenario to showcase.

[nyemade-uversky]

@hhunter-ms and @RyanLettieri putting this on both your radars as part of the requirements for Workflow API

[hhunter-ms]

@cgillum

[greenie-msft]

@RyanLettieri , @nyemade-uversky QuickStart maintainers discussed priority for 1.10:

• Scenario - order processing workflow
• Demonstrate more than just logging, for example - sequence, fan-in/fan-out
• Thorough README with instructions/tests on how to execute locally
• (Reach goal) Able to execute in K8s
• Examples for .NET, Python, JS

[cgillum]

Demonstrate more than just logging, for example - sequence, fan-in/fan-out

I spoke to @RyanLettieri about the sample, and I don't think fan-out/fan-in is a good match for an order processing workflow. Rather, a separate data processing workflow sample is probably better suited for that.

However, I think it would make sense for us to incorporate state store interactions as well as error handling/compensation to make the order processing workflow more interesting. Ryan's currently looking into this.

Examples for .NET, Python, JS

Can we clarify the expectation for v1.10? Currently we only have an SDK in .NET. The order processing app is also currently a single project. Is the intent to break it up into multiple projects, e.g., a JS frontend app that uses the Dapr API (HTTP) to start workflows that run in the .NET app? Maybe we could add Python as an app that consumes pub/sub messages emitted by the workflow?

[paulyuk]

Do we still need this or are we covered by #787 ? @nyemade-uversky @cgillum

[msfussell]

Closing since done in v1.10 for dotnet.