One docker image we require to run (eventstore) doesn't have a windows container - so run
docker-compose on linux only for now!
docker-compose build docker-compose up
The web frontend is configured to talk to the api server via
If you are running
docker-compose up on another machine you need to change that address to the remote machines ip.
frontend: build: args: API_SERVER: http://10.0.0.200:8080
Being this project has such a small domain context there are only a couple source files which contain real logic. Other files are helpers, extensions, or setup.
The first message sent through the whole system takes longer than all the others as NSB builds caches and does things in the background. In a true system this is what is known as "eventually consistent." The web app could fake adding the todo instead of submitting a new request to the web api to counter this.
Its a problem with the web api which I am unfamilar with. DELETE just returns "unsupported media type" and google doesn't have an immediate solution. After debugging DI containers for 2 days I lack the motivation to dive into this issue deeply at this moment.
Mainly because I use material-ui and am used to a more "react" way of styling - they are mostly correct
If the web app was returned via a GET from the asp net core endpoint we wouldn't have to worry about CORS or specifying the ip address of the host. I debated setting it up that way but integrating a typescript build pipeline with webpack into the C# build process is not my favorite thing to do. But it could happen and may be more ideal
EventSourcing is a process of representing domain objects (Orders, Invoices, Accounts, etc) as a series of separate events.
Your application ends up being 1 long audit log which records every state-changing event that occurs. The advantage of this approach is other processes can read this event log and generate models that contain only the information the process cares about. There is also additional information available that other services perhaps don't record themselves.
Imagine a shoppign cart which fills with items to buy. The warehouse only cares about the final order of the stuff the customer actually agreed to purchase -
but the marketing team might care more about the items the customer removed from their cart without buying.
Using eventsourcing correctly you can generate models which contain both sets of information to satisfy both departments with only 1 set of data.
CQRS stands for Command and Query Responsibility Segregation
In a nut shell - commands are everything that want to change the application state. Queries are anything that want to read application state. There is no overlap
Commands do not return any data other than if they were Accepted or Rejected. Accepted meaning the change was saved and read models will be updated. Rejected meaning the command failed validation or was not valid to be run at this time. (One example would be trying to invoice a sales order which has already been invoiced)