search

elsa-workflows / elsa-core

A .NET workflows library
https://v3.elsaworkflows.io/
MIT License
6.27k stars 1.15k forks source link

Roadmap #3232

Open sfmskywalker opened 2 years ago

sfmskywalker commented 2 years ago

This issue lists high-level functionality I'd like to add to Elsa 3 and beyond. It's not a final list and the order in which each milestone will be picked up might change over time and depends on business value & community interest.

Engine

Runtime

Activities

Tooling

Integration & Modules

Studio

Ecosystem

cristinamudura commented 2 years ago

@sfmskywalker For the tooling maybe we can include the Debugger as well. And for activities the Soap Generator maybe 😄

PeterHuang-ST commented 2 years ago

@sfmskywalker What is the current ETA for V3? Also, is there going to be a migration process from V2 to V3 or this is not decided yet? TIA.

sfmskywalker commented 2 years ago

@PeterHuang-ST I’m hoping to be releasing a release candidate end of this year. Regarding migration path, I would love to do it but it depends on complexity and available resources. At the very least, we should write a migration guide.

Nokecy commented 1 year ago

v3 any update ? @sfmskywalker

sfmskywalker commented 1 year ago

Sure. There's still a ton of little things to do to achieve feature-parity with v2, but a preview is inching closer. At the moment I am working with a client to implement a real-world telephony workflow using Telnyx, which reveals many small bugs and oversights, boosting the development of the overall engine and tooling significantly.

I hope to get started on "getting started" tutorials soon.

hassanelsherbiny commented 1 year ago

is version 3 ready or when it will be released? and how can i get a preview?

sfmskywalker commented 1 year ago

Not ready yet, preview release on NuGet probably later this month or sometime next month.

You can give it a spin by following the Installation section of the documentation (which is far from finished): https://v3.elsaworkflows.io

sfmskywalker commented 1 year ago

PS. I just realized that the preview package feed of DevOps is outdated. The part “Packages” needs to be “Elsa3”. Will fix.

vgb1993 commented 1 year ago

Hey there!

I would be really nice if the Activity editor could be replaced to use custom Blazor components.

Perhaps a generic Attribute with some constrains making the editor "contract" compliant could work.

Also some activities may require complex controls and custom behabiour when configuring.

Say I have a FTP activity. I could try to connect using the credentials and give feedback to the user while it's configuring the activity.

Or build a drag and drop form within the activity that will somehow get shown to the user. Rember the chatbot? ;)

There are so many more examples I can think of. This would be pretty hard to do with the current stencil components.

Super powers for the people that want to create activities.

I'll create an issue for this :)

Have a nice day

sfanwar commented 1 year ago

When will we expect about Elsa 3 to be released as stable and final version.

GeorgeS2019 commented 1 year ago

Can someone update commitment in using Blazor for UI and Designer?

sfmskywalker commented 1 year ago

@vgb1993 Agreed! We are going to re-implement the designer in Blazor, but after 3.0 release as to not further delay it unnecessarily.

@sfanwar We expect RC to drop end of May.

@GeorgeS2019 Done ;)

bhanuchhabra7 commented 1 year ago

Do we know if the v3 will work with data from v2? We had a lot of issues migrating from v1 to v2. If there are breaking changes, would there be any clean way to migrate data?

sfmskywalker commented 1 year ago

Elsa 3 is a rewrite, so by default, there is no compatibility. However, I might do some experiments related to data migration or even interpretation of the V2 model to help bring over existing V2 projects.

bhanuchhabra7 commented 1 year ago

I think, as a practice, Elsa should think about backward compatibilities. It is not good if you want it to Project as THE LIBRARY for handling workflows. Every version having breaking changes is not a good experience.

mircotamburini commented 1 year ago

Mqtt Activities?

zejji commented 1 year ago

Re the rewrite of the designer in Blazor, I wonder if this is really a good idea?

While Blazor has a decent developer experience, it has very poor performance and extremely large bundle sizes. It's generally recognised that Blazor is a poor choice for anything other than internal/LOB applications.

Wouldn't it be preferable from an end-user perspective to have a relatively lightweight web component that can easily be embedded in another application (e.g. created using React/Vue/Solid/Svelte/Lit etc.)?

GeorgeS2019 commented 1 year ago

@zejji Blazor is the #Microsoft future web technology => high performance low latency is the GOAL and differentiation from other Web technology

That means, there is NOW fast iteration to make Blazor low latency with new innovation of hybrid/mixed frontend webassembly backend server performance optimization.

It is this committed Fast iteration and pushing new way to support global scalable web deployment with low latency the basis why we need to move to Blazor

Currently on preview .NET8 => Blazor United

Full stack web UI with Blazor - Big changes in .NET 8

GeorgeS2019 commented 1 year ago

@sfmskywalker

The fundamental motivation for choosing Blazor is to REMOVE incompatibility between the backend .NETCore and the existing frontend designer not based on .NETCore.

By harmonizing .NETCore between backend and frontend designer, this opens NEW Innovation not possible before that keeps Backend separated from the frontend developers

zejji commented 1 year ago

@GeorgeS2019 - I'm aware of Blazor United, but it doesn't fix the fundamental problem that Blazor WASM (i) requires the whole .NET runtime to be downloaded to the browser sooner or later and (ii) uses JavaScript interop to access the DOM. It will always be less efficient than a JavaScript-based web app, since JavaScript is obviously the only inbuilt language in browsers.

I say this as someone who loves .NET and would love to be able to use Blazor for production applications. However, currently the developer UX is the only argument for using Blazor - all performance and bandwidth considerations indicate strongly against it.

Cf. https://krausest.github.io/js-framework-benchmark/index.html, where Blazor WASM has the worst performance of all tested frameworks for speed, startup time and memory allocation.

Re bundle sizes - see https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1#31f0 for a comparison of common JavaScript frontend framework bundle sizes, where many libraries require only tens of kilobytes. Contrast that with Blazor WASM app, where a 'Hello World' application is just under 2 MB when compressed with Brotli and fully-fledged applications tend to be much, much larger still.

FransVanEk commented 1 year ago

@zejji Is there a restiction to use the Blazor as a WASM solution? Blazor can be used as Server side as well which reduces the concerns you have regarding performace and bandwidth due to large packages and performance.

sure there are some challenges there as well but for me at least less intrusive as the WASM approach.

GeorgeS2019 commented 1 year ago

@zejji

Issue 1

zejji commented 1 year ago

@FransVanEk - There are also some (different) major downsides with using Blazor Server unfortunately:

  1. The potential for high perceived latency for every user interaction, particularly where the server is geographically distant from the user, as every such interaction involves a network round-trip (unlike in WASM).
  2. Each active user requires some memory allocation on the server to store their current state. This is different from the situation in most web apps, where significant memory is only consumed when processing web requests.

These are trade-offs one might be willing to make when designing a bespoke application, as it may be the case that the requirement for an extremely large number of concurrent users is not present and that speed and resource usage are only secondary requirements.

However, when designing a library, they are not trade-offs I would personally make, as you would effectively be dictating the performance characteristics of the consuming application.

If there were no alternatives, then one would have to accept this, but obviously much more performant JavaScript-based alternatives do exist.

@GeorgeS2019 - I'm currently developing a small application using Blazor WASM on .NET 7 and, even with relatively limited functionality and all optimizations enabled (after a significant amount of research, including following recommendations from Microsoft and third parties), the published Blazor application bundle (compressed using Brotli and excluding all CSS, JavaScript, assets etc.) is 2.75 MB. For comparison, the equivalent application in e.g. SolidJS is well under 100kb.

Furthermore, despite using SSR in the project to improve perceived page load, there is a significant (often up to 5s) delay in the page becoming interactive. It's not possible to improve on this, as this is the time taken to download and initialize the runtime and framework.

I've enjoyed working with Blazor a lot, but I can't see it being appropriate for a public-facing high-traffic website any time soon.

That said, if the decision is made to go with Blazor specifically for productivity reasons, that would certainly be understandable.

bachratyg commented 1 year ago

The bundle size/startup performance may not be the key issue here. Right now there is no direct integration with the DOM, any interaction has to pass through javascript glue code including DOM events. For a diagram designer I'd expect lots of drag&drop interaction and that translates to a massive event stream crossing the JS-WASM boundary (or for Blazor Server the network boundary). Microsoft has to work with the WASM limitations no matter how much they are committed to fast iteration and this likely won't change until proposals like GC integration are fully speced, implemented and deployed. That could take a long time. IIRC the current "suggested" workaround is to stay in JS. At least some exploratory testing for usability should be done before this is fully committed.

GeorgeS2019 commented 1 year ago

If the Diagram designer is in blazor, there will be more users here who are Elsa backend developers will engage more regularly and directly with the diagram designer when it is Blazor using c# or c#-JS interop.

If it is not in Blazor, the situation will be the same now, we HOPE someone will take our feedback to implement the change to the Diagram Designer. Users here who could develop the Diagram Designer using the existing JS is perhaps 5% or even much smaller than the majority of the users here.

If it is important to engage iterative UI FEEDBACK from backend Elsa developers to have FAST iteration of the diagram designer, BLAZOR will have a significant advantage.

If we have a dedicated Diagram designer who will actively handle all issues raised by backend users, we could ignore Blazor suggestion. From what I observed at least last 2 years, this is NOT THE CASE.

Encouraging backend users to directly contribute to the Front end Diagram Designer will speed up the quality and usability of the Diagram Designer.

sfmskywalker commented 1 year ago

Here are some of the things I am taking into consideration.

Considering the above, it seems to me that there are 2 main groups of developers:

  1. Developers that prefer to use an existing dashboard framework that they can customise and extend.
  2. Developers who have their own UI into which they need to integrate workflow management features.

For the first group, we can divide them into two subgroups:

a) Developers who prefer to extend the dashboard using Blazor. b) Developers who prefer to extend the dashboard using JS.

For group no. 2, the dashboard application is useless. All they are interested in is to have a designer that they can embed in a page and interact with programatically. A big challenge with this standalone designer is to make it customisable, extensible and theme-able without the use of a framework and design system. Even more so when you consider that Elsa comes with increasingly more modules that one might want to take advantage of. Just to name a few:

The above is easily implemented using component libraries, which may or may not support theming. This is the main reason I want to do a dashboard application, and Blazor seems a fine choice to me. That being said, don't be surprised if I eventually start an Ionic dashboard implementation on the side ;)

Just to try and clarify certain points that were made by others:

Re the rewrite of the designer in Blazor, I wonder if this is really a good idea?

It depends on whom you ask. My initial idea was to wrap it in a custom element so that it doesn't matter what your application UI stack is. However, in order to make it extensible and customisable, being able to use an existing component library boosts productivity not just for me, but for anyone trying to customise and extend. So now I'm wondering the usefulness of a Blazor implementation of the designer outside the context of a Blazor dashboard. Instead, I think there are two main use cases (the two main groups of developers I mentioned earlier).

While Blazor has a decent developer experience, it has very poor performance and extremely large bundle sizes. It's generally recognised that Blazor is a poor choice for anything other than internal/LOB applications.

My personal experience with Blazor so far, is that it offers a great developer experience. Even without having figured out how to do hot reload from Jetbrains Rider. I just love the component model, the way binding works, and, best of all, using proper C#. As for the extremely large bundle sizes, you'd have to define "extreme". A couple of MBs seems not an issue for the average backend system (which, after all, is where most, if not all, workflow designers will end up anyway).

Wouldn't it be preferable from an end-user perspective to have a relatively lightweight web component that can easily be embedded in another application (e.g. created using React/Vue/Solid/Svelte/Lit etc.)?

Yes, absolutely. And I have tried to do this. But I don't think it's enough; I want the designer to be extensible and themeable, and have a solid component framework to build upon. It's possible to do, it currently has a concept of plugins, but for many users I have spoken with, it's a real barrier. And at the same time, there are many existing component libraries that can be reused. So maybe it's best to keep the Stencil component as-is for embedding, and not have it implement other modules, like the ones I listed. Instead, developers would implement those features themselves, and other developers who don't have their own dashboard, can chose to leverage the Blazor dashboard (and possibly in the future, a JS-implementation of the dashboard).

The fundamental motivation for choosing Blazor is to REMOVE incompatibility between the backend .NETCore and the existing frontend designer not based on .NETCore.

Actually, my motivation is a little bit different than that. My main motivation to use Blazor is because it enables me to use C#, .NET and Razor components, which in turn means I get to use component libraries such as MudBlazor, which boosts productivity like crazy. It also means that the dashboard can be made extensible and customisable extremely elegantly, which makes it easy for .NET developers to do.

By harmonizing .NETCore between backend and frontend designer, this opens NEW Innovation not possible before that keeps Backend separated from the frontend developers

@GeorgeS2019 I guess my previous statement puts a stain on this vision. Perhaps you can elaborate a bit on these opportunities? For example, are you talking about shared use of model classes, and/or making the backend and front end environments appear as "one" to the developer?

Let there be no confusion: The Elsa backend is equally intended to be consumable by whatever front-end, be it Blazor, JS applications, Postman automation, etc. At no point will the Elsa backend become tightly coupled with any kind of front end (and if that does happen, it's a mistake).

For a diagram designer I'd expect lots of drag&drop interaction and that translates to a massive event stream crossing the JS-WASM boundary

Actually, the Blazor dashboard implementation relies on the X6 diagramming library, which means that all drag & drop operations happen in JS-space. Except for dragging a new activity from the toolbox onto the designer - that toolbox is done in Blazor. But that's fine in terms of perf.

If the Diagram designer is in blazor, there will be more users here who are Elsa backend developers will engage more regularly and directly with the diagram designer when it is Blazor using c# or c#-JS interop

To be clear, the current diagram design surface is still provided via the X6 library. But, everything around it (activity picker, activity property panel) and even the activities being rendered themselves, are proper Blazor components. In addition, when using the Blazor dashboard framework, it now becomes that much easier to replace it with a (custom) implementation if you want to, like Azure Design Studio and Blazor Diagrams.

Thanks everyone for sharing your insights!

jensenw-pki commented 1 year ago

is v3 released now?

sfmskywalker commented 1 year ago

Not yet. We hope to release RC2 end of this month, but it largely depends on how fast we can work through the issues with the RC2 milestone. After that release, maybe one month later we can release 3.0 proper, barring any blocking issues we find in RC2.

GeorgeS2019 commented 1 year ago

Elsa-Studio

for Elsa v3 preview using Blazor works

@sfmskywalker <= thx

msedge_YEZIkQaFYo

Eitanski commented 10 months ago

Hey, what is the plan for an official release of Elsa 3? I am looking to use Elsa workflows at my workplace. However, since it is still in prerelease I'm not sure what to do. Also I love to see what are the current differences between 3 and 2, so that I can know what to opt for. Thanks a lot.

carlosmorenoaguilera commented 10 months ago

Hey, what is the plan for an official release of Elsa 3? I am looking to use Elsa workflows at my workplace. However, since it is still in prerelease I'm not sure what to do. Also I love to see what are the current differences between 3 and 2, so that I can now what to opt for. Thanks a lot.

Same here, im trying to determine if worth start with v3 or go on v2

sfmskywalker commented 9 months ago

@Eitanski @carlosmorenoaguilera

Elsa 3.0 will be out this month. The source code has moved from the v3 branch into the main branch and we're working on some minor improvements before we deploy the 3.0.0 packages to NuGet.

Almost there!

Eitanski commented 9 months ago

@sfmskywalker man, just wanted to say that this project is awsome and that you guys are great super stoked for the release

sfmskywalker commented 9 months ago

Cheers @Eitanski

kobeliu9527 commented 9 months ago

This project is great, please stick to blazor, this is Net's playground

Sudarsanam-Krishnan commented 9 months ago

Hi @sfmskywalker - Any update on 3.0 release?

Sudarsanam-Krishnan commented 9 months ago

Hey, what is the plan for an official release of Elsa 3? I am looking to use Elsa workflows at my workplace. However, since it is still in prerelease I'm not sure what to do. Also I love to see what are the current differences between 3 and 2, so that I can now what to opt for. Thanks a lot.

Same here, im trying to determine if worth start with v3 or go on v2

Same here too...Waiting for V3 to check it out.

sfmskywalker commented 9 months ago

The release will happen today or within the next few days, depending on what we still find in terms of blockers. But you don't have to wait for the release to give it a spin.The docker images and NuGet packages are all available.

Sudarsanam-Krishnan commented 9 months ago

The release will happen today or within the next few days, depending on what we still find in terms of blockers. But you don't have to wait for the release to give it a spin.The docker images and NuGet packages are all available.

@sfmskywalker - Facing a challenge with the pre-release version of V3. Please see below build error on WASM studio

image

On using Blazor Server studio, getting similar error on build

image

P.S.: Followed documentation on https://v3.elsaworkflows.io/docs/installation/elsa-studio-blazorwasm & https://v3.elsaworkflows.io/docs/installation/elsa-studio-blazorserver respectively

sfmskywalker commented 8 months ago

@Sudarsanam-Krishnan Thanks for reporting your findings. The documentation ha been updated to reflect the latest changes. Specifically, the build error you pointed out can be fixed by replacing the problematic lines with the following:

builder.Services.AddRemoteBackend(
    elsaClient => elsaClient.AuthenticationHandler = typeof(AuthenticatingApiHttpMessageHandler),
    options => configuration.GetSection("Backend").Bind(options));

I will close this issue as resolved, but please feel free to continue the conversation. Thanks!

sfmskywalker commented 8 months ago

Reopening, as this is the roadmap, not an actual issue 😄

bbenameur commented 7 months ago

Hello,

I don't know if you added autoscaling by event for example we can use the KEDA project, https://keda.sh/docs/2.13/scalers/mongodb/ by driving the scaling of any container in Kubernetes based on the number of events needing to be processed. In our case for example we can use the requests sent to a database like mongodb or other. It's very powerful.

sfmskywalker commented 7 months ago

I wasn't aware of that, thank you for the tip 😃

dwalba commented 4 months ago

Any idea when / if support for Azure functions will be added?

bhaeussermann commented 3 months ago

Is there a migration guide for migrating from Elsa 2 to 3?

sfmskywalker commented 3 months ago

@dwalba Yes, but it also depends on what you mean with support for Azure Functions. For example, if you want to be able to invoke an Azure Function from a workflow, you can do that today by creating a custom activity that invokes the Azure function. In addition, I can imagine having a module that connects to Azure Functions in order to enumerate the available functions, and automatically generate Activity Descriptors at runtime, allowing you to directly drag & drop Azure Functions as activities to the workflow designer. If you would like to explore potential other scenarios, please feel free to open an issue and/or discussion.

@bhaeussermann Unfortunately, I haven't had the opportunity yet to work on a migration guide.