Replies: 1 comment
-
Based on the information provided and the context from the sources, it seems that there is an interest in integrating Elsa Workflows with Dapr, which is a distributed application runtime that simplifies the building of microservice architectures. While there is no direct mention of an existing integration between Elsa Workflows and Dapr workflows in the provided sources, there is a discussion on GitHub (#4561) that proposes the idea of integrating Elsa with Dapr to leverage the benefits of both platforms. The discussion highlights the potential for service orchestration using Elsa's visual workflow capabilities and Dapr's service management, as well as the possibility of creating event-driven workflows by combining Dapr's pub/sub messaging with Elsa. However, it also mentions that the integration with Dapr is not yet complete. As for running Elsa Workflows as Dapr workflows, the sources do not provide a definitive answer. However, considering the modular and extensible nature of both Elsa (as described in the sources) and Dapr, it is conceivable that integration could be achieved with some development effort. The core reasons this might not work out of the box would likely involve differences in how workflows are executed, managed, and scaled within each system. To explore this possibility further, it would be advisable to engage with the Elsa and Dapr communities, perhaps by starting a discussion on the Elsa GitHub repository or the Dapr forums. This could help in understanding any technical challenges and the level of interest in such an integration from both communities. If you have specific technical questions or need further clarification on how Elsa's features align with Dapr's capabilities, please let me know, and I can provide more detailed information. This comment was generated by Glime. |
Beta Was this translation helpful? Give feedback.
-
We are big users of DAPR and in particular we are using the DAPR code-first workflow framework.
Here we are showing a domain model that generates two code-first DAPR workflows as aggregate-based-workflows...
DAPR WF use the DAPR Actor model to serialize and hydrate running instances. We wrap that within our DDD based aggregate model which provides state of flow that can then be invoked through API designed within the Domain tool, publish events, etc. This provides the ability to query the state of the flow and control the state of it via API (REST, GraphQL, gRPC are supported).
The domain model code-generates the backing services providing us a pro-code dev experience to modify the business logic for the orchestrations and activities.
DAPR WF runtime is unique in that it runs within the side-car of the service, which should bode well from scale out as well as scale up perspective.
DAPR WF follows a similar convention to ELSA including WF Activities.
That said, I really like the ELSA studio designer, and thus, I am curious if anyone as thought about integration with DAPR workflow.
Would it be possible to run ELSA WF's as a DAPR WF and if not, what are the core reasons this can't be made to work?
Cheers
John
Beta Was this translation helpful? Give feedback.
All reactions