Introducing Solid.Http 2.0
This has been a long time coming, but it’s finally here. The oldest issue that was tagged for 2.0 was from March 2018. There are a few issues that are pending that might make the release, but we are in 2.0.5-RC at the time of this writing and the release is looking pretty good.
What’s changed? Why a new version?
We originally were going to create a new minor version (1.2). Our main concern was how the HttpClient was being created. Using a single instance for the whole application lifecycle can be problematic. You can, for example, have DNS caching problems. We looked for ways to do this and found that we weren’t the only ones that were concerned about this. Microsoft had released it’s own package trying to mitigate this issue. That package was Microsoft.Extensions.Http. When we saw this extension and what it did, we decided that we wanted to integrate it. However, that meant breaking changes.
ISolidHttpClientFactory as singleton
This is something that bugged us incredibly often. ISolidHttpClientFactory was registered as a scoped service. There was no reason that it wasn’t a singleton. Every time we were creating a singleton service and needed ISolidHttpClientFactory, we needed to get it through “other means”.
Removal of IHttpClientFactory
This is one of the main reasons for the major version bump. We needed to use the interface from Microsoft.Extensions.Http so ours needed to be removed. To be honest, it probably didn’t matter that much. There are probably not a lot of Solid.Http users that actually used the interface.
Actions and Funcs
This is a change that just felt right. Using event delegates felt outdated so we moved to actions and funcs. An added bonus with this change was that certain events (OnRequest and OnResponse) could be asynchronous and return a Task.
The old version had extension methods for IServiceCollection called AddSolidHttp and AddSolidHttpCore. These two extension methods returned the SolidHttpBuilder. This felt a bit rude. Since we started working with IServiceCollection in other projects, registering services in a fluent manner just felt better. When we had to stop the service registration flow because of Solid.Http, it didn’t really sit well.
Now these registration methods take in a builder action parameter and return IServiceCollection.
Manual builder gone
Our manual builders (SolidHttpBuilder and SolidHttpCoreBuilder) just complicated some startup code, so we decided to scrap them. However, there are classes with these names still in the code base, but they are used for other purposes now.
These might be breaking and might not be. It’s more of a convenience. It was decided that all extension method classes in the library would use the same namespace as the class/interface that they were extending. This makes Solid.Http functionality more visible.
In the next few days, we’ll update our Solid.Testing library to use Solid.Http 2.0 and then we’ll finally open source it and write a blog post and documentation about it. For the uninitiated, Solid.Testing is an http testing library to test your aspnetcore/owin service using http calls. The service is hosted in memory and Solid.Http is used for the http calls. This means that all extensions made for Solid.Http will work with Solid.Testing.