Specialized CritterStackHostBuilder to simplify Marten & Wolverine usage

[jeremydmiller]

This is a placeholder for a longer conversation. There's starting to be more and more boilerplate code for bootstrapping both a headless application or a web application with both Wolverine and Marten -- plus the overhead of registering "do this in development" vs "do this in production mode".

I'd like to maybe consider some kind of customized ApplicationHostBuilder and/or WebHostBuilder that's a bit customized for using the two tools. I'd like to drop the WolverineOptions and Marten's StoreOptions on the actual builder too. Maybe separate "hive" properties for Development vs Production.

I'm also concerned about some of the dev vs prod settings like codegen or the application assembly location where both tools have the same settings. It would be nice to centralize some of that as well.

Of course, this could be beaten with just a new AddCritterStack(opts => ) where the opts let you configure both Marten & Wolverine at one time.

I kind of like a var builder = CritterStackHost.CreateApplicationBuilder() and/or a var builder = CritterStackWebHost.****()

[jeremydmiller]

I think this is getting kicked back to Marten 8 / Wolverine 4

[JeffryGonzalez]

I've been looking into it and wow they do not make it easy to create a Host Builder. Making a super opinionated one like you are suggesting here would be doable, but how well it would play with other things people might want to poke into it looks sketchy.

I think an extension of AddCritterStack(opts =>) like you suggested is probably the best, but that opts is what'll be challenging. Unless it keeps growing, eventually they'll want to bail and do it old-skool, and I feel like at that point even having a "default" builder for the WolverineOptions and StoreOptions (that they could override) would make me nervous because those could change underneath me.

One sorta big advantage of a custom host builder is it could "hide" the Oakton stuff. From the people I show and from the number of people that don't know about that, mess it up, etc. it would be good if that could be made more implicit.

I'm working on that template thing - I'm going to iterate a bit more on it. If nothing else, it will help answer the important question explicit in this issue - which is something like "What is a reasonable default configuration for a full-tilt CritterStack application?". I love the idea of having a "batteries included" template or something that is way less than any kind of "reference app", but it would have to be "tweakable" as your needs change and understanding grows.

[GotWoods]

I feel like the AddCriterStack method is more consistent with how other projects work and is easier to understand. If an org already has their own HostBuilder they create in-house, it would be a pain to try and balance both (at least I assume, I have not looked into how HostBuilder works internally).

Unifying things would be good for us around type loading and serializer. I worry a bit about assembly discovery as someone may want to discover something for Marten but not Wolverine (not sure what, I just feel like this may be something someone wants to do)

[jeremydmiller]

Here's an early take on this for Wolverine 4 / Marten 8 / Ermine 1:

        var builder = Host.CreateApplicationBuilder();
        
        // This would apply to both Marten, Wolverine, and future critters....
        builder.Services.JasperFxDefaults(x =>
        {
            // This expands in importance to be the master "AutoCreate"
            // over every resource at runtime and not just databases
            // So this would maybe take the place of AutoProvision() in Wolverine world too
            x.Production.AutoCreate = AutoCreate.None;
            x.Production.GeneratedCodeMode = TypeLoadMode.Static;
            x.Production.AssertAllPreGeneratedTypesExist = true;
            
            // Just for completeness sake
            x.Development.AutoCreate = AutoCreate.All; // default is still CreateOrUpdate

            // Unify the Marten/Wolverine/future critter application assembly
            // Default will always be the entry assembly
            x.ApplicationAssembly = typeof(Message1).Assembly;
        });
        
        // keep bootstrapping...

This is meant to centralize all the duplicated Marten/Wolverine/soon to be Ermine too configuration in one place, unify the "application assembly" determination and configuration, and replace all the "optimize artifact workflow" stuff in both Marten & Wolverine with what is definitely a more verbose syntax, but hopefully easier to understand.

What say you critter stack world?