Centralize common startup code used in all environments

[nm777]

Forgive me if there is already a way to do this or if there is a reason not to. I'm looking at the various StartupXXXX.cs files in the WebApi project and noticing that there is quite a bit of repeated boilerplate code in the Configure and ConfigureServices methods. I have several environments I have set up and changes I'd like to include in all of them. It might be nice to include keeping configuration that is common across all environments in a single place.

What do you think of the idea of refactoring the common code into your service extensions (WebApi/Extensions/AppExtensions.cs and WebApi/Extensions/ServiceExtensions.cs)? Alternatively you could just wire up methods for common configuration and leave them blank so idiots like me don't have to do it manually. :)

For example:

AppExtensions.cs

// ...

        public static void ConfigureForAllEnvironments(this IApplicationBuilder app)
        {
            app.UseCors("MyCorsPolicy");
        
            app.UseRouting();
        
            app.UseErrorHandlingMiddleware();
            app.UseEndpoints(endpoints =>
            {
                endpoints.MapHealthChecks("/api/health");
                endpoints.MapControllers();
            });
        }

// ...

ServiceExtensions.cs

// ...

    using Application;
    using Infrastructure.Persistence;
    using Infrastructure.Shared;
    using Microsoft.Extensions.Configuration;

// ...

        public static void AddServicesForAllEnvironments(this IServiceCollection services, IConfiguration _config)
        {
            services.AddCorsService("MyCorsPolicy");
            services.AddApplicationLayer();
            services.AddPersistenceInfrastructure(_config);
            services.AddSharedInfrastructure(_config);
            services.AddControllers()
                .AddNewtonsoftJson();
            services.AddApiVersioningExtension();
            services.AddHealthChecks();
        }

// ...

Then each of your StartupXXXX.cs files would end up like this:

// ...

        // This method gets called by the runtime. Use this method to add services to the container.
        // For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=398940
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddServicesForAllEnvironments(_config);

            #region Dynamic Services
            #endregion
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            app.ConfigureForAllEnvironments();

            #region Dynamic App
            #endregion
        }

// ...

Thanks for a great project!

Nate

[pdevito3]

Hey Nate! Sorry just seeing this. Feel free to tag me or shoot me a note on twitter if I don't respond in a couple days next time.

Regardless, to your question.

Yes, there is definitely repetition between environments when working with this setup. This is by design in this case to allow for multiple environments without a ton of complexity. For example, if you only have prod and dev, it's not to bad to toss in a conditional wherever you'd like to manage things (MS actually does this OOTB if you look at their example project), but once you toss in even one more environment (like QA) it can start to become unwieldy. This practice is to encourage a distinct and more explicit approach, though the code duplication can definitely be a downside as well. I'll think about implementing something like you mentioned above, but I also don't want to force people to have particular 'commons' and then have more work to pull it out into different types if needed (naming those doesn't sound fun either lol).

With that said, you're more than welcome to use the consolidated approach if you'd like! What you can do is delete all the Startups except the standard Startup.cs and consolidate them into there. Then do the same for your app config. If you're using Craftsman 0.6.0+, you'll want to tweak Program.cs to simplify your appsettings assignment.

Hope that helps. Happy to expand on anything if needed!

[pdevito3]

So better late than never, but FYI, after dog fooding the project for a bit I am changing my tune and consolidating startups to a single file. Will be built into the next release