Example app and service templates `dotnet new -i Equinox.Templates; dotnet new eqx*/pro*` https://github.com/jet/equinox https://github.com/jet/FsCodec
Polish Equinox's surface APIs, removing pain points accessing from C# and validating aspects of the F# usage:
its not a big conceptual stretch to support it, especially given recent language additions in v6 and 7 wrt pattern matching and expression bodies members etc
little effort has been invested in basics such making Equinox be natural for use from languages other than F# to date
Providing another way to illustrate the concepts of idempotent command processing, events, folds etc which are commonly agreed
provide a base sample that others can use refactor from to illustrate other (read: better) approaches using alternate libraries and techniques
improve the F# implementation via the above cross-polination (doing this exercise has highlighted numerous bugs/oversimplifications in the F#)
HT @aarondandy who put in lots of legwork to motivate the work (and various other discussions on the DDD-CQRS-ES Slack)
Components:
[x] port wiring for Cosmos, EventStore and MemoryStore in aspnetcore
I'm not entirely happy with some of the compromises in how I separate the code vs what works well with DUs in F# and am definitely open to PRs to make things better
By the same token, I'm not entirely dissatisfied - its important that the wiring be close to idiomatic C# and not too slavish a translation of what happens to work well in F#
[x] Provide basic shims allowing Handler functions to be written without F# interop (FuncConvert etc) littering the place (open to PRs to do more, but for now the key synchronous one is ported and life will go on)
[x] port Aggregate.fs to C#
[x] port Todo.fs to C#
[x] Port TodosController.fs to C#
[x] make it compile
[x] make sure it actually runs and functions correctly per https://todobackend.com (shouldn't be hard as it this is just a port, but its absolutely not been run)
[x] include equinox-web-csharp as a component within the Equinox.Templates nuget (consumption experience should only differ in having to specify a -l C#, i.e. it should go in sharing the same identity as the F# one)
[x] make improvements to Equinox (e.g. defaults etc) to enable simplification of some of the wiring (for now the plan is that C# wiring will continue to live in Infrastructure.cs, but if any tweaks and/overloads are needed in the Equinox repo, that'll be done - i.e. this may be experimental, but C# support is intended to be a first class supported thing) - see https://github.com/jet/equinox/pull/81 - this will merge after final integration test against 1.0.3-rc1 packages
[x] Final test required of 1.1.0-rc3 per readme in this branch
[x] Merge the key cleanup aspects of #6 in here (but probably not the OneOf ref)
Future work:
Perhaps provide an example of defining the Event and/or Command DUs in F# in order to attempt to see whether that's a better approach that the Encode/TryDecode implementation that's presently in place (I really believe its worth doing this work, even if the likelihood of one doing that for any sustained period is not the most likely)
This PR is in service of the following missions:
HT @aarondandy who put in lots of legwork to motivate the work (and various other discussions on the DDD-CQRS-ES Slack)
Components:
Handlerfunctions to be written without F# interop (FuncConvertetc) littering the place (open to PRs to do more, but for now the key synchronous one is ported and life will go on)Aggregate.fsto C#Todo.fsto C#TodosController.fsto C#equinox-web-csharpas a component within theEquinox.Templatesnuget (consumption experience should only differ in having to specify a-l C#, i.e. it should go in sharing the same identity as the F# one)Infrastructure.cs, but if any tweaks and/overloads are needed in the Equinox repo, that'll be done - i.e. this may be experimental, but C# support is intended to be a first class supported thing) - see https://github.com/jet/equinox/pull/81 - this will merge after final integration test against1.0.3-rc1packages1.1.0-rc3per readme in this branchFuture work:
Encode/TryDecodeimplementation that's presently in place (I really believe its worth doing this work, even if the likelihood of one doing that for any sustained period is not the most likely)