Workflows should not be app-scoped about dapr HOT 5 CLOSED

Thank you for sharing feedback! I think the Dapr docs could do with an uplift to make it clear what is and isn't possible, which may have guide you down the supported path from the start.

One of the premises of Dapr, as I understand it, is to provide seamless communication and services between different microservices, embracing a poliglot and distributed approach.

That is certainly true of some Dapr Building Blocks, I.e. Service Invocation, and PubSub. But I wouldn't say that extends to all.

However, as workflows are implemented currently, all the components (activities, child workflows) need to belong to the same application, negating the possibility of distributing the different activities or using different apps / languages for each of the activities and, even worse, making impossible to seamlessly using child workflows from one application to another.

Current implementation looks to embrace a monolith of code.

It's entirely subjective, but its very normal for a single domain to be encapsulated in a single App. Just because a Workflow is being used to orchestrate units of work (i.e. Activities) across compute boundaries (i.e. horizontally scaled pods) within that domain, doesn't make it any more of a Monolith.

If your Workflow does need to communicate with another domain/service (which may or may or not be in any other language), its entirely reasonable to call the API of that Service, either synchronously via Dapr Service Invocation, or asynchronously via Dapr PubSub.

Don't get me wrong, I know in theory all workflow inputs and outputs are serializable, so they could be exchanged betwen Apps. But then there would be the issue of discovery (How does each app know what is available from the other Apps in the mesh?)

Assuming this is solved, another challenge - Workflows and Activities interoperating across App boundaries would open up a greater risk of breaking changes. Each App would have to be versioned and deployed together to mitigate. Think about a worst-case scenario where every App in the mesh has a highly coupled bond to another App in the mesh via workflows & Activities, with no independent versioning available - the entire mesh of Apps would have to be deployed in lock-step, which is an anti-pattern for distributed systems/micro-service architecture.

Assuming this is solved, another challenge - There would need to be an extremely robust access-control model wrapped around each Workflow and Activity to ensure that Activities can be locked down and only callable from certain Workflows.

I'm no expert or authority, but I'm sure there would be other challenges lurking too.

Where I do think Workflows can do better is to reduce its boilerplate when integrating with other Dapr Building Blocks, for example #7226

from dapr.

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

from dapr.

This issue has been automatically closed because it has not had activity in the last 67 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

from dapr.

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

from dapr.

This issue has been automatically closed because it has not had activity in the last 67 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

from dapr.