jet / dotnet-templates Goto Github PK

As noted by @fnipo the proReactor template (and possibly others throws a cryptic runtime exception due to

| [<AltCommandLine "cosmos">] Cosmos

Fix is to bottom out on whether Cosmos needs to be renamed back to SrcCosmos or some other solution

TL;DR remove all RunSynchronously as that was only chucked in there in the interests of getting something out

In the C# port in #5, I took the time to make the initialization a) happen as part of startup b) before loading c) without blocking a thread d) without wacky side -effects in the DI

The various templates that support >1 database wiring need to have the wiring [which was added to the Equinox repo in the
https://github.com/jet/equinox/blob/master/CHANGELOG.md#2.0.0-rc8 timespan] applied so the command line allows one to nominate ms my or pg as the store alongside es and cosmos - Without looking, I think that's just the equinox-web and equinox-web-csharp templates. eta: eqxBench also needs it

As a way to assist folks in doing experiments leveraging the stores, it'd be useful to port key elements to C# so people can self-service:

• startup.fs (and program.fs) wip
• aggregate.fs
• todoservice.fs

Per this writeup, VS will start supporting showing the templates in 16.8 Preview 2...

• The checklist mentions adding a defaultName as a best practice
• Also need to check stuff looks ok in VS

(Things work fine from the command line and Rider, so I'm tempted to close this soon on the assumption that it will Just Work)

Link to file in question.

I ask because the Propulsion docs state

Ingesters ... are not acting in reaction to events emanating from the Consistent Event Store

It further states:

Reactors: drive reactive actions triggered by either upstream feeds, or events observed in the Consistent Event Store

My reading of ReactorTemplate.Ingester.handle is that it is acting in reaction to events from the event store. In particular, it is passing events to TryIngest, which apparently tries to Consume the event. Am I correct in thinking that Ingester is a Reactor, or are there nuances/grey areas here that I'm missing? Things might be complicated because it is producing its own event stream for reasons I currently don't grok. (The events are then treated as Commands, which breaks my brain.) I might be being too pedantic and you mean this as a more throwaway example.

Ultimately, I'm trying to figure out what to base my (non Kafka) projector code on. The proReactor template looks promising, and instead of a TodoSummary module I'll have a TodoProjector which writes to Azure Table Storage/ElasticSearch in response to events.

Per @baronfel (maintainer of Destructurama.FSharp) on the F# slack, this shim package is completely unnecessary, being a long-gone short term hack; the official (non .NetCore-suffixed) package has long been multitargeted

I'm not really sure if this is even much of a problem but I noticed that the generated web app when using eqxwebcs will reference the newer 2.2 version of Microsoft.AspNetCore.App but the project targets netcoreapp2.1. I'm unsure if this is a bug or feature, thoughts?

See:

As noted by @aarondandy, the C# template's sln marks the projects as being F#. This is highly likely to be due to me copy-pasting the sln file. This should be addressed in order to ensure no nasty side-effects like tooling or intellisense not working happens.

As per https://github.com/jet/dotnet-templates#microservice-programfs-conventions, there should be a section detailing an outline format together with DOs and DONTs

Overhang work from jet/equinox#55 and jet/equinox#56:

• (I'm likely to work on this next as a backburner task) Add TodoBackend sample (think: https://github.com/panesofglass/TodoBackendFSharp, but on aspdotnetcore like https://github.com/ChristianAlexander/dotnetcore-todo-webapi/blob/master/src/TodoWebApi/Controllers/TodosController.cs so we can run it via https://www.todobackend.com/) - see jet/equinox#63
• Merge feature/inventory branch ? (I've put an InventoryItem.fs on master which is a port of https://github.com/gregoryyoung/m-r/tree/master/SimpleCQRS). The associated GUI is showing its age and to be honest I don't see much point progressing in that direction given how it's kinda a contrived tech example.
• allows us to e.g. do a sample of serialization using Fleece instead of json.net, without loading that dependency, volume of code and conceptual complexity onto this repo (moved to jet/FsCodec#6)
• apply CQRS to Todo app - see #29
• Polish Web to make it more representative? i.e. Cart does not have a controller, and there is no checkout. I don't personally have much interest or bandwidth to do it at present, although I believe there's a good opportunity to do a very nice minimal example of event sourcing which most people can relate to
• Work with @mateusz-kula to do a simplified edition of Store, TodoBackend, which would be emitted from a generator to add:
  • a GUI clickable way of running something on Equinox (i.e. the Web endpoint only has APIs; we can give instructions for postman and curl all we like, it won't feel the same to some folks)
  • consumer driven contracts (stuff used in the genned app will be considered to be core API, even before we start aggressively versioning)
  • allows us to cut corners for pedagogical reasons
    • (i.e. SFL and Favorites both do some very fancy pants use of .NET non mutable data structures for perf reasons which are interesting and important, but would be better replaced with more compact immutable representations)
    • can also demonstrate testing story as more direct example based tests

dotnet new eqxwebcs -ag -t -e

In ServiceBuilder:

        public Todo.Service CreateTodoService() =>
            new Todo.Service(
                _handlerLog,
                _context.Resolve(
                    EquinoxCodec.Create(Todo.Event.Encode, Todo.Event.TryDecode),
                    Todo.State.Fold,
                    Todo.State.Initial,
                    Todo.State.IsOrigin,
                    Todo.State.Snapshot));

        public Aggregate.Service CreateAggregateService() =>
            new Aggregate.Service(
                _handlerLog,
                _context.Resolve(
                    EquinoxCodec.Create(Aggregate.Event.Encode, Aggregate.Event.TryDecode),
                    Aggregate.State.Fold,
                    Aggregate.State.Initial,
                    Aggregate.State.IsOrigin,
                    Aggregate.State.Snapshot));

This repo should include an integration test that validates that all combinations of options yield usable templates