Adding Wangkanai.Detection.Abstraction about wangkanai HOT 8 CLOSED

Thank you for the nice complement. I really much appreciated your kind words.

While the original interfaces and abstract was in the NuGet package Wangkanai.Detection.Core when 2.0 was released and is still the most package i have on NuGet. https://github.com/wangkanai/wangkanai/tree/release/2.0/src/Detection.Core/src, Interesting the library didn't serve much use much benefits within the whole Wangkanai.Detection itself.

But, nevertheless. I'm very curious about your needs and why you need just the abstraction package in your module project. Because the whole Wangkanai.Detection is so light weight already 69kb vs 44Kb. There must be something I am missing right?

I had a quick looked at the project you are working https://github.com/CrestApps/OrchardCore that is very promising and following principle of single responsibility.

I'm looking forward to hear back from you.

from wangkanai.

Hi @wangkanai,

First, I'd also like to thank you for putting together this library. It's definitely made tracking browser information much simpler for our analytics.

I'm not the original poster, but I was just looking at something similar from a different angle. I found this issue while doing a supply-chain audit for our internal products. This is to verify what all of our dependencies are so we could know what projects we would need to track for vulnerability alerts and license notifications.

It appears that while Wangkanai.Detection is indeed lightweight, it references Wangkanai.WebServer, which in turn references the Microsoft.EntityFrameworkCore.SqlServer package, which pulls in not only EF, but also the SQL Server clients, and their native dependencies (~5MB of libraries, all together).

This might be the source of the concern from the OP, or it could also be about allowing them to create modules that don't have to reference the ASP.NET Core framework - or any of the other dependencies that the Detection package requires like the DI registration or configuration - at all.

Additional details on the dependency chain:

As far as I have been able to determine, the whole usage of the Wangkanai.WebServer project in the Wangkanai.Detection library is here: https://github.com/wangkanai/wangkanai/blob/main/Detection/src/DependencyInjection/DetectionApplicationExtensions.cs#L27
where an extension method used to check that a marker service is registered in the container.

Additionally, it appears that the EF package is only pulled in to support a IApplicationBuilder extension to trigger EF migrations, which is only used (at least in this repository) in a commented out line in the test project for the WebServer package.

I'd be happy to contribute a PR that cleans up those dependencies (and lifts a copy of the marker check method into the Detection library) if they're truly unneeded. I wasn't sure if there was another project that wasn't in this repo that depended on the WebServer project and/or it's migration helpers, and didn't just want to drop an unsolicited PR if there was a reason for it.

Thanks!

from wangkanai.

Hi @wangkanai,

The project https://github.com/CrestApps/OrchardCore provides provides a modular framework. So I created a module that would provide browser detection in my app obviously depending on your project. This module would register any of the required services.

Now if any of my other modules need browser detection, all it needs is an access to the interface like IDetectionService to be able to detect the browser. No other module care about the implementations or default services. For that reason, I suggest we move out the interfaces into Abstractions package to reduce the dependencies needed and also make maintenance such as upgrade a bit easier.

from wangkanai.

Hi @wangkanai,

First, I'd also like to thank you for putting together this library. It's definitely made tracking browser information much simpler for our analytics.

I'm not the original poster, but I was just looking at something similar from a different angle. I found this issue while doing a supply-chain audit for our internal products. This is to verify what all of our dependencies are so we could know what projects we would need to track for vulnerability alerts and license notifications.

It appears that while Wangkanai.Detection is indeed lightweight, it references Wangkanai.WebServer, which in turn references the Microsoft.EntityFrameworkCore.SqlServer package, which pulls in not only EF, but also the SQL Server clients, and their native dependencies (~5MB of libraries, all together).

This might be the source of the concern from the OP, or it could also be about allowing them to create modules that don't have to reference the ASP.NET Core framework - or any of the other dependencies that the Detection package requires like the DI registration or configuration - at all.

Additional details on the dependency chain:

As far as I have been able to determine, the whole usage of the Wangkanai.WebServer project in the Wangkanai.Detection library is here: https://github.com/wangkanai/wangkanai/blob/main/Detection/src/DependencyInjection/DetectionApplicationExtensions.cs#L27 where an extension method used to check that a marker service is registered in the container.

Additionally, it appears that the EF package is only pulled in to support a IApplicationBuilder extension to trigger EF migrations, which is only used (at least in this repository) in a commented out line in the test project for the WebServer package.

I'd be happy to contribute a PR that cleans up those dependencies (and lifts a copy of the marker check method into the Detection library) if they're truly unneeded. I wasn't sure if there was another project that wasn't in this repo that depended on the WebServer project and/or it's migration helpers, and didn't just want to drop an unsolicited PR if there was a reason for it.

Thanks!

@nkilzer Thank you very much for your breakdown analysis. I'm very much appreciate it. I was trying not to duplicate my code and reuse them as much as possible.

Also it would be an great honor if you could come and help contribute to the project.

from wangkanai.

from wangkanai.

Hi @wangkanai,

The project https://github.com/CrestApps/OrchardCore provides provides a modular framework. So I created a module that would provide browser detection in my app obviously depending on your project. This module would register any of the required services.

Now if any of my other modules need browser detection, all it needs is an access to the interface like IDetectionService to be able to detect the browser. No other module care about the implementations or default services. For that reason, I suggest we move out the interfaces into Abstractions package to reduce the dependencies needed and also make maintenance such as upgrade a bit easier.

Okay, I can now understand the issue and its make sense to have no dependency on thing that are not required.

from wangkanai.

Hi @wangkanai,
First, I'd also like to thank you for putting together this library. It's definitely made tracking browser information much simpler for our analytics.
I'm not the original poster, but I was just looking at something similar from a different angle. I found this issue while doing a supply-chain audit for our internal products. This is to verify what all of our dependencies are so we could know what projects we would need to track for vulnerability alerts and license notifications.
It appears that while Wangkanai.Detection is indeed lightweight, it references Wangkanai.WebServer, which in turn references the Microsoft.EntityFrameworkCore.SqlServer package, which pulls in not only EF, but also the SQL Server clients, and their native dependencies (~5MB of libraries, all together).
This might be the source of the concern from the OP, or it could also be about allowing them to create modules that don't have to reference the ASP.NET Core framework - or any of the other dependencies that the Detection package requires like the DI registration or configuration - at all.
Additional details on the dependency chain:
As far as I have been able to determine, the whole usage of the Wangkanai.WebServer project in the Wangkanai.Detection library is here: https://github.com/wangkanai/wangkanai/blob/main/Detection/src/DependencyInjection/DetectionApplicationExtensions.cs#L27 where an extension method used to check that a marker service is registered in the container.
Additionally, it appears that the EF package is only pulled in to support a IApplicationBuilder extension to trigger EF migrations, which is only used (at least in this repository) in a commented out line in the test project for the WebServer package.
I'd be happy to contribute a PR that cleans up those dependencies (and lifts a copy of the marker check method into the Detection library) if they're truly unneeded. I wasn't sure if there was another project that wasn't in this repo that depended on the WebServer project and/or it's migration helpers, and didn't just want to drop an unsolicited PR if there was a reason for it.
Thanks!

@nkilzer Thank you very much for your breakdown analysis. I'm very much appreciate it. I was trying not to duplicate my code and reuse them as much as possible.

Also it would be an great honor if you could come and help contribute to the project.

I have refactor this dependency from Wangkanai.Webserver to Wangkanai.Hosting now with the release of 5.3.0. Therefore, now there are no dependenc to entity framework sqlserver now.

from wangkanai.

@CrestApps Please see if Wangkanai.Detection release fit your requirements. Because for me adding another package with just the abstractions for such a small contracts doesn't really provide much benefits. I have tried this approach with nuget package Wangkanai.Detection.Core. If I'm making something big like yours, I can see the huge benefits.

But let open this topic to discussion. I would like to hear more about it.

from wangkanai.