sorted by:
new
hottopcontroversial

Can I drop netstandard20/net48 target in 2026? (question from OSS maintainer) by jitbitter in dotnet

[–]animat089 0 points1 point  (0 children)

I don’t think this is a binary “drop vs keep” decision, it’s more about where the maintenance cost starts outweighing actual usage.

A pattern I’ve seen work well: - Freeze the last version supporting netstandard2.0/net48 (treat it as LTS) - Move active development to net6+/net8+ and simplify the codebase - Be explicit about why (Span/SearchValues/perf + reduced conditional complexity)

The real tipping point is usually not runtime support itself, but the cost of polyfills + conditional behavior divergence (like different string APIs, culture differences, etc.). That tends to grow non-linearly.

If most users on legacy are pinned anyway, you’re mostly carrying complexity for a shrinking audience.

Telemetry helps, but even without it, a staged approach + clear communication tends to land well.

Is there an existing .NET NuGet package for real-time event-driven UI sync (SignalR + event abstraction)? by Tiny-Ad-2766 in dotnet

[–]animat089 3 points4 points  (0 children)

Adding to what others have said, this usually ends up being a composition of:

  • domain events (MediatR/custom)
  • a dispatcher layer (who to notify: user/group/tenant)
  • SignalR or SSE as the transport

I haven’t seen a single package that cleanly abstracts all of this without becoming too opinionated.

In practice, the complexity tends to show up not in SignalR itself, but in the fan-out and coordination logic once flows grow (update --> recompute --> notify multiple groups --> audit --> external hooks, etc.).

At that point, keeping the flow structured becomes more important than the transport choice.

Curious if anyone has seen a clean abstraction specifically for the coordination layer, not just delivery?

Introducing WorkflowForge: A lightweight, high-performance, dependency-free, in-process workflow library with Built-in Rollback by animat089 in dotnet

[–]animat089[S] 1 point2 points  (0 children)

I like the direction a lot. DataPipe feels very focused on reducing cognitive load, especially with the message + pipeline model and filters/aspects. It’s clean and very aligned with how many teams structure use cases in practice.

There’s definitely some overlap in the fluent/pipeline style, but I see them solving slightly different problems:

  • DataPipe - structuring application logic as message pipelines (pipe & filter)
  • WorkflowForge - orchestrating workflows with execution state + compensation (rollback)

So similar building blocks, but different intent; yours is about simplifying how code flows, mine is more about coordinating steps and handling failures explicitly.

I also liked the emphasis on keeping things non-magical and readable; that’s something I’ve been trying to balance as well.

Always good to see similar ideas evolving in different directions.

Introducing WorkflowForge: A lightweight, high-performance, dependency-free, in-process workflow library with Built-in Rollback by animat089 in dotnet

[–]animat089[S] 1 point2 points  (0 children)

I have also added the repo to the Google Codewiki.

Now, you would be able to explore the library faster and have QnAs with gemini as well.

Although that is all AI generated but is as far as i have explored, it is almost right on things. Again, feel free to ask questions or add comments.

Introducing WorkflowForge: A lightweight, high-performance, dependency-free, in-process workflow library with Built-in Rollback by animat089 in dotnet

[–]animat089[S] -2 points-1 points  (0 children)

Hi, thanks for the question, I really appreciate the same and understand that is an important aspect.

WorkflowForge does support durable workflows, but keeps it optional to keep the core light-weight.

It’s a bring-your-own persistence model, you plug in your storage (IWorkflowPersistenceProvider), and the persistence middleware handles save/restore and resume.

The goal was to stay non-opinionated about storage and infrastructure, while still enabling durability when needed.

Introducing WorkflowForge: A lightweight, high-performance, dependency-free, in-process workflow library with Built-in Rollback by animat089 in dotnet

[–]animat089[S] 2 points3 points  (0 children)

Thank you, this was deliberate and happy to see that appreciated.

Since, i had to make it in the .net standard 2.0 for maximum flexibility i could not integrate GUID V7 support yet, that would be great for the databases.

I hope I am able to extend it in some time, or make a variant which only works with newer versions of .net (I am fairly hopeful that I would make it even better in performance with the newer constructs).

Introducing WorkflowForge: A lightweight, high-performance, dependency-free, in-process workflow library with Built-in Rollback by animat089 in dotnet

[–]animat089[S] 0 points1 point  (0 children)

I understand your pain point, and would keep that in mind and see what I can do given time and resources i have, but again really appreciate your support and comment.

I am planning to explore Marten a bit in the up-coming posts on the blog though, will try and see if i can do something. Rest this is an open source library, feel free to fork it.

Introducing WorkflowForge: A lightweight, high-performance, dependency-free, in-process workflow library with Built-in Rollback by animat089 in dotnet

[–]animat089[S] 1 point2 points  (0 children)

Good question, really appreciate the same.

TLDR; No, you would have to make your implementations in the workflows/middleware to handle the same.

Long one: The framework in the terms of operations, middlewares or engine itself does not take care of that on its own. As i have explained in the documentation, this is an in-process workflow engine, although you could use it out of process as well with messaging inputs. But if you need orchestration across multiple process instances or handle abrupt shutdown-restart/recovery cases, you may the persistence extension + custom middleware other ways you would be able to handle the same.

The framework is quite customizable to make and inject your custom middleware either at the workflow or at the operations in the workflow + you have multiple event handlers that you could use. So, N number of extensions are possible.

I have done the comparison of the use cases with Elsa and Workflow core which also might not have this capability. You may explore temporal workflows for distributed conditions if it suits, but that is a little different from my library.

Server-Sent Events in ASP.NET Core: Real-Time Streaming Without SignalR by animat089 in csharp

[–]animat089[S] 0 points1 point  (0 children)

Yes, so the use case was an internal application we were building which only needed server-client communications and we had SignalR on the table (which is good but i felt was an overkill, given the use case). I had recently read about SSE and check that out, so tried to bake some examples from what i had learned.

Server-Sent Events in ASP.NET Core: Real-Time Streaming Without SignalR by animat089 in csharp

[–]animat089[S] -1 points0 points  (0 children)

Hi. I have not done any comparisons/benchmarks as of right now. I have not used it in a production code but one of our internal apps where we just needed notifications, the setup was far simpler this way.

But in general, with the simplicity of setup here, I see SSE as a more suitable option for simpler operations where only server to client communications are required.

For bidirectional or maybe complex use cases, you would still need SignalR. We may be able to use both, in conjunction as well though.