Hiya,
I'm the maintainer of the https://github.com/Hawxy/Auth0Net.DependencyInjection package that's used by a significant number of Auth0.Net consumers. Looking at v8, I have some feedback on some improvements that could be made:
-
Some of the response nullability seems to be a bit off. The UserResponseSchema has UserId as nullable which I'm not sure is even possible? There might be something wrong with the annotations in the schema document this was generated from.
-
ManagementClient isn't a wrapper at the moment, it's more of a reimplementation of ManagementApiClient. It doesn't implement the IManagementApiClient interface (which is a backwards step over v7), decorate the client, or inherit from the client. Maybe something to consider to improve ergonomics & testability.
-
The TokenProvider func option isn't very usable - it only exposes a sync codepath which isn't acceptable in the current year. The implementation of the token provider itself also does a lot of sync-over-async which is simply going to harm performance. I'd suggest exposing an ITokenProvider interface with a ValueTask-returning function to users and allow them to implement their own type. It's an easy change that you can see on the branch here: Hawxy@33aeb82
Otherwise this a good direction and a welcome improvement.
Hiya,
I'm the maintainer of the https://github.com/Hawxy/Auth0Net.DependencyInjection package that's used by a significant number of Auth0.Net consumers. Looking at v8, I have some feedback on some improvements that could be made:
Some of the response nullability seems to be a bit off. The
UserResponseSchemahasUserIdas nullable which I'm not sure is even possible? There might be something wrong with the annotations in the schema document this was generated from.ManagementClient isn't a wrapper at the moment, it's more of a reimplementation of
ManagementApiClient. It doesn't implement theIManagementApiClientinterface (which is a backwards step over v7), decorate the client, or inherit from the client. Maybe something to consider to improve ergonomics & testability.The
TokenProviderfunc option isn't very usable - it only exposes a sync codepath which isn't acceptable in the current year. The implementation of the token provider itself also does a lot of sync-over-async which is simply going to harm performance. I'd suggest exposing anITokenProviderinterface with aValueTask-returning function to users and allow them to implement their own type. It's an easy change that you can see on the branch here: Hawxy@33aeb82Otherwise this a good direction and a welcome improvement.