I love the idea of templates the way it’s laid out in https://github.com/NetCoreWebApps/Web. Just curl the web dir, use a plugins directory in each app (or share a plugins directory across apps) and drop your html files in your app directories with templated filters and actions. It’s elegantly simple and may best be that it shouldn’t be tampered with, that it should just remain as is.
While I can create a separate AppHost in each app via plugins, what NetCoreWebApps/Web doesn’t do right now from I can tell, which keeps me from being able to use it’s simplicity on many of my projects, is allow further configuring aspnet core services by taking advantage of the ConfigureServices and Configure methods at startup (I’m referring to https://github.com/NetCoreWebApps/WebApp/blob/master/src/WebApp/Program.cs). Of course I can create my own version of NetcoreWebApps/Web, but why do that if you felt this could be in your implementation. But you may not like this, and that’s fine.
What I’ve been able to do successfully, prior to this cool implementation you provided, was create a plugin architecture where IPlugin implementations (or the AppHostBase implementation) could also extend the IStartup interface. The plugin discovery process then kicks off early on in the ConfigureServices portion, and for every plugin that implements IStartup, or if the AppHost implements IStartup, you can call the ConfigureServices and Configure methods on those, all this prior to doing app.UseServiceStack() in the Configure method. I also typically add a services.AddSingleton(appHost) inside ConfigureServices, so that the plugins that implement IStartup can access the appHost.
Notionally, it would be something like:
public void ConfigureServices(IServiceCollection services) {
var plugins = MethodToGetPlugins(services);
plugins.Each(p => services.AddSingleton(p.GetType(), p));
var appHost = MethodToGetAppHost(services, plugins);
services.AddSingleton<AppHostBase>(appHost);
plugins.Each(p => (p as IStartup)?.ConfigureServices(services));
(appHost as IStartup)?.ConfigureServices(services);
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
var appHost = app.ApplicationServices.GetRequiredService<AppHostBase>();
var plugins = MethodToGetPlugins(app, appHost);
plugins.Each(p => (p as IStartup)?.Configure(app));
appHost.BeforeConfigure.Add(ConfigureAppHost);
app.UseServiceStack(appHost);
}
The benefit of this is we can still use the https://github.com/NetCoreWebApps/Web methodology and just drop our plugins in a directory where are plugins can also configure additional 3rd party services to include in our ServiceStack app (for example: services.AddNodeServices, there are dozens/hundreds of useful libs out there we are able to leverage then with the simplicity you’ve provided with NetCoreWebApps/Web). This does also bring out some additional questions too, like how to deploy plugin related assemblies (for example if some plugins were referencing Handlebars.Net or EPPlus.Core do these just need to be part of the /web assemblies directory ahead of time or can they also be dropped in the plugins directory as 3rd party assemblies). A lot of this is what the guys at http://extcore.net/ are doing for their .net core extensible plugin framework.
I’d really love also where you can just put features *, OpenApiFeature, PostmanFeature, CorsFeature, ValidationFeature or something like it, where * means automatically include all plugins found from the /plugins directory assemblies so that I can make my apps more flexible in their implementation.
Interested in your thoughts about this for WebApps, and if nothing here fits within what you feel is the scope for ServiceStack WebApps & Templates, that’s perfectly ok. I can proceed with my own custom implementation of this, no problem.
–