The previous update on the Critter Stack roadmap was in early March.
I spent some time yesterday writing and thinking about the road map for the Critter Stack. Call this post a mix of me sorting out what I personally think happens next, but mostly asking for feedback and input on these thoughts.
Wrapping up Marten 8 and Wolverine 5
I think we’re pretty close to turning the page on the current versions of Marten and Wolverine. I made a housecleaning effort yesterday to either deal with any outstanding issues or pull requests against the current versions, or to tag issues for the next major milestone.
To that end, a new Marten 8.34 and Wolverine 5.34 release dropped this morning that I’m going to say symbolically marks the current versions of both tools as “done.”
Of course, software tools are never actually completed, only abandoned. At this point though, I think the only enhancements to these versions will be merely reacting to reported issues or client requests that don’t require any breaking changes (or changes for CritterWatch). We’re certainly happy to continue taking in community pull requests, but at least for me, I’m out of any ideas for new functionality right now.
Recent highlights of the two main tools are:
- PostgreSQL Role Level Security support for Marten as part of its Multi-Tenancy (community pull request)
- gRPC Support in Wolverine from core team member Erik Shafer
I also snuck in quite a few minor improvements for the “cold start” with both tools, and that’s going to be a theme of this post.
And I know full well that between the time I write this and you read it that there will be some new kind of bug report like “if I hop up and down on my left foot while pointing at the Big Dipper, I would have expected…” to land. Which we’ll address of course:)
CritterWatch and JasperFx Update
Just speaking personally, I should be putting the majority of my time for awhile pushing CritterWatch to a 1.0 release. We’re also working toward having all the infrastructure in place to allow customers to purchase licensing for CritterWatch and access to our new AI Skills collection on our website. Babu and I have also been very busy doing a complete overhaul of the JasperFx Software website.
At a bare minimum, I’m hoping to have every single bit of functionality in flight today for CritterWatch in a usable and somewhat polished state by the end of this week.
While the sales mechanisms aren’t completely in place yet, you can see the updated pricing online now.
And just so everybody knows, CritterWatch will be available on Nuget, but only usable in a read only way without the presence of a license file.
On to the next cycle!
The next big set of releases will be Marten 9, Wolverine 6, and Polecat 3. The key goals for me are to do everything possible to improve the “cold start” performance of Marten, Wolverine, and Polecat to make our tools much more usable in “serverless” usage and to attempt to ruthlessly remove duplication today between Marten and Polecat.
The big ticket and potentially breaking changes are to:
- Move JasperFx.RuntimeCompiler and its massive dependency on Roslyn to being a development time dependency. We’ve already got a plan underway to allow you to deploy Marten and/or Wolverine applications (Polecat strictly uses source generators instead of our older code generation model) without that dependency so that we can actually do…
- AOT Compliance. I didn’t think this was ever going to be possible before, but it looks like we can pull this off
- We’re going to make a large effort to switch default configurations of the tools to reflect the absolute best performing and monitored application you can have. See Building a Greenfield System with the Critter Stack for plenty examples of the settings I mean. We introduced quite a few improvements to both Marten and Wolverine over the past year that we made “opt in” because using them would require database schema changes. A new major release is always the time to reconsider those defaults. I’m also hoping that AI tools make the converstions and upgrades a lot easier even with these kinds of changes to behavior.
- Dump [Obsolete] APIs of course, but I don’t think there are too many of those floating around anymore
- Drop support for .NET 8, then add support for .NET 11 when that hits later this year. If nothing else, our EF Core support is a nightmare for diamond dependency problems and our multi-targeting makes that much worse. Fewer .NET versions leads to fewer headaches.
- Try hard to eliminate duplication between Marten and Polecat, with more utility and infrastructure code landing in JasperFx.Events or Weasel.Core. I’m hoping that this work would shrink the Marten codebase especially, and open up some opportunities to reduce duplication in Wolverine too. I’m also hopeful that this elimination of duplication can lead to more advanced visualizations and tracking in CritterWatch.
- JasperFx will be working with a client this year for some pretty extreme scalability of the Event Store features in Marten. As part of that, I would like us to pursue using the HSTORE extension in PostgreSQL for more efficient “Dynamic Consistency Boundary” usage and to also pursue using alternative serializers for just event data as some early experimentation with MemoryPack inside of Marten has been very promising.
And just in case anyone asks, I don’t think it’s remotely possible to convert Wolverine to use source generators instead of our current source code generation model.
Bobcat?
This is my rough notes here, so don’t take any of this too seriously.
I haven’t talked about this much, but I’ve been playing a bit with a new Gherkin test runner tentatively called “Bobcat” half inspired by Storyteller (https://storyteller.github.io). What’s different about Bobcat from Reqnroll is much more focus on data intensive testing, and making it more CLI friendly purposely to create visibility on runtime activity so AI agents could iterate on the test execution results. This is my current thinking for “Spec Driven Development” w/ the Critter Stack as opposed to a quixotic attempt to do anything with user interface centric tooling.
So for example, if your spec calls through the Wolverine tracked sessions, the test output would have information about every exception encountered and the full messaging history on test failures. The test output itself is written to the CLI too where AI tools can scrape it.
I’ve already played w/ built in helper packages for Alba and the Wolverine tracked sessions. Also trying to think through how Bobcat could be optimized for real integration testing where you have to juggle Docker dependencies and `IHost` lifecycles.
To some degree, Bobcat is maybe just what I’ve always wanted to test the Critter Stack tools themselves.
I’m also thinking about how to make Bobcat + AI skills drive Spec Driven Development w/ the Critter Stack. So accelerators build the Gherkin runners based on event types and projection types. Then being able to generate code from the Gherkin specs. I’ve been watching a couple other event sourcing toolsets and how they’re trying to do Access 97 style user interfaces to “model” event sourcing workflows and have yet to see anything out there that would be faster than just writing C# or F# event types and maybe even the projection types themselves. My thought is just to lean on our existing code tools and build generators to quickly translate from C#/F# types to Gherkin syntax. I’m also hoping we can leverage the existing Gherkin language integration in Rider or VS Code rather than building something all new.
And lastly, I’m not opposed to trying to make this work with Reqnroll in the end.
The Shade Tree Developer 