Thinking we know it all is very dangerous!

Even better if you use CliWrap
github.com/Tyrrrz/CliWrap

let! result = Cli.Wrap("path/to/exe")
.WithArguments([
"--foo"
"bar"
])
.WithWorkingDirectory("work/dir/path")
.ExecuteAsync()

3. Javascript automation script can do anything you can think of.

Personally I hate writing shell scripts because of weird syntax, hard to reuse, zero testability, mostly I think I am not smart enough for it and I am more than ok with it. For me, simplicity wins.

Zero mocks means less code to maintain. Tests ignorant of implementation details are also remarkable easy to write and maintain, and they bring freedom to refactoring which lead to easy to read maintainable code.

testing the .net webapi backend(ef and postgres) from the outside using Testcontainers library and .net’s WebApplicationFactory also give us very high degree of confidence. Game changer.

Take away: ef core 9 support value object in many ways, however I ended up not using any of them:

1. eager loading collection of value object causes performance issue

2. the non-collection value object are treated as stealth entity, polluting audit trails.

I do not like the look of the audit log with an implementation detail like owned entity jamming up the audit trail. So with regret, I unpacked the all and use regular properties instead for cleaner audit trails.

Moving on, I also implementation audit trails to record all transactions, for the capability of being able to roll back transitions. Then I found that The single owned entity in the domain is being treated as separate entitiy by ef core therefore they uses one entry in the audit log…

I am happy with middle ground achieved above where I can apply DDD and enjoy the best performance, with a bit of hack.

However these operators are not without downsides. I ended up using regular entities for collection of value object and make them inaccessible from the DBContext to force the use of aggregate. Those entity models can so implementation ValueObject behaviors, Id being one of the property for equality

Collection of value objects are mapped to separate tables and they are always eager loaded with the aggregate, this causes potential performance issue. For read only queries, we can use AsNonTracking to improve performance and for commands we can use AsSplitQuery.

Maybe the news is too new, did a search, seems no other news reporting the same. Scaled back but nothing about stopping the production.

The answer

And I told ChatGPT I am Chinese, this is the new picture supposed to reflect my life. What’s up with the hexagons..and my god, the screens I have!

In one of my project, I send messages via SignalR when data updated, react query would invalidate the relevant query, so simple to do and improved user experience by a mile.

Missing the power of react-query in the remix app I am working on. Cannot wait for TanStack Start!