Unified Critter Stack Resource Model

[jeremydmiller]

This was spawned by a conversation in Discord today about how to reduce the Docker / AWS Lambda images for apps that use Marten but deploy with pre-generated code

Marten & Wolverine share quite a few underpinnings:

• The dynamic code generation
• The "resource" model from Oakton to manage environment setup at app startup. Stuff like database schema management, Rabbit MQ/SQS/Azure Service Bus queues

They both have some sort of "Optimized Artifact Workflow", but they're configured separately. It would be nice if there was one
single place in applications using both Marten or Wolverine to specify:

• The code generation model (auto, dynamic, static)
• The application project, which in this case maybe gets renamed to just mean "the assembly that has the pre-generated types"
• Rules related to resource setup. Analogous to Marten/Weasel's AutoCreate mode, but now more generic for other resources

For more context, see:

• https://martendb.io/configuration/prebuilding.html
• https://martendb.io/configuration/optimized_artifact_workflow.html
• https://wolverine.netlify.app/guide/codegen.html#optimized-workflow

To get there, I think maybe we could:

• Rip the stateful resource and environment check abstractions out of Oakton and into some new library? Maybe JasperFx.Framework? It's admittedly a little weird that that stuff is in the command line parsing library, and maybe that stuff is useful outside of Oakton
• The new JasperFx.Framework model has extension methods off of IServiceCollection and/or IHostBuilder to specify artifact/resource workflow? It's already there, but this time make that used by Marten itself and Wolverine

Decoupling from JasperFx.Compiler

The JasperFx.Compiler library is the main culprit for bloating the size of published Marten applications because of its dependencies on Roslyn elements. What we'd ideally like to do is to make this dependency only necessary at development time, but not actually be deployed in production with the assumption that teams would pre-generate all the necessary code.

To maybe make this work, here's a first alternative:

• Decouple Marten/Wolverine from JasperFx.Compiler at runtime
• Pull an interface out for IAssemblyGenerator in place of the AssemblyGenerator that's currently in the compiler library
• Change all the extension methods currently in the compiler project to depend on that interface
• Move all code except for AssemblyGenerator to the relatively harmless JasperFx.CodeCompilation library
• The next issue is how does the code in JasperFx.CodeCompilation know what the real IAssemblyGenerator is for the times
  when one of the frameworks needs to compile code on the fly? We could depend on IAssemblyGenerator being registered in the container or use pure Reflection to load the real AssemblyGenerator by string names and fail with descriptive names if it does not exist. The first is more changes. The second is looser coupling.
• Next, how do we still make Marten easy to set up and get started if there's not a hard Nuget reference to the compiler library? I think you'd have to make a development only reference directly from your project to JasperFx.Compiler to make this work. Dunno if you can make the "development only" reference be transitive (guessing you can't)
• Have a separate Marten.Lite for opting into the more efficient production model? (from experience, ick)
• Distribute dotnet new templates? (also an ick)