Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split Foundatio.Extensions.Hosting in two #279

Open
pinkfloydx33 opened this issue Sep 14, 2022 · 4 comments
Open

Split Foundatio.Extensions.Hosting in two #279

pinkfloydx33 opened this issue Sep 14, 2022 · 4 comments

Comments

@pinkfloydx33
Copy link

Currently, Foundatio.Extensions.Hosting has a FrameworkReference to Microsoft.AspNetCore.App in order to accommodate the startup filters and middleware. However, this package isn't just limited to ASP.NET. In fact, we use it inside of a Worker Service (no web component) to leverage the HostedJobService and friends. I noticed today while examining the outputs of a self-contained publish that the ASPNET shared framework assemblies were all being included. This is increasing application publish size (and the size of our docker images) and is entirely unnecessary for non-ASP applications.

I suggest splitting the package into two -- one for the hosted service infrastructure and the other for the ASP.NET-specific components.

@ejsmith
Copy link
Contributor

ejsmith commented Sep 14, 2022

Hmm... not opposed to breaking it up, but I'd prefer not to. Our job services still use web just so they can serve health and readiness probes. How much is it adding to the docker image?

@pinkfloydx33
Copy link
Author

pinkfloydx33 commented Sep 14, 2022

It adds the entirety of the aspnetcore shared framework. Not at my desk atm to check size, but it's considerable compared to the size without it.

HealthChecks is its own set of packages and doesn't need aspnet. Obviously you can use it to expose endpoints but that's not required. You can still make use of the abstractions and health check service from within a Worker Service application without pulling in all of aspnet (we do that in other non webapps that don't use foundatio). It's about selecting the right dependencies.

I realize the tools in this package are conveniences...the background service is our primary use case. I'd reimplement it myself for our own use but that seems heavy handed. I dont need the probes in this case.

FWIW: one can write to files or expose other health check reporters... if you want the endpoint, it's easy to create an http-listener backed service that publishes the results without bringing in all of aspnet. I'm not by any means saying to do that here, just calling out it can be done. There's examples on the web for exposing file based reporters for k8s probes etc. as well. It's a great set of tools.

To me, what's here would really make sense as two packages so it could be consumed independently depending on how you are leveraging the rest of foundatio. Not everything is a web app ;-)

@ejsmith
Copy link
Contributor

ejsmith commented Sep 15, 2022

Yeah, what you are saying makes sense. Not sure what we would call the 2 different packages. Ideas? Can you create a PR for the changes?

@pinkfloydx33
Copy link
Author

Taking Serilog as an example, they call them Serilog.Extensions.Hosting and Serilog.AspNetCore. The latter is exactly like what I'm proposing with basically Middleware and AppBuilder/ServiceCollection extensions and a reference to/dependency on the former.

So perhaps:

  • Foundatio.Extensions.Hosting
  • Foundatio.AspNetCore

I'm having oral surgery tomorrow. Not sure how willing I'll be to do anything immediately, but certainly something I can contribute to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants