You seem to do very much tight coupling of options and messaging/Responses like on the server type also for each handler 🤔
of course it makes sense in case they are just and only to be used by that handler, but that's also limiting the possibilities of extending the Handlers with similar but slightly different services via composition or inheritance like we would normally do with EndpointOptions in uno http extensions.
Like... I thought about that the AuthCallback Handler or any further added Handler could be considered based upon the Path Handler and having its path property defined as a base option maybe, so they could only define relative paths and the consumer would then have one ServerOptions but would not be required to define that same base url again e.g. for the handler options on the redirect url. Also considerable could be to have the limiting functionality of the Guard Handler with header attachments or the Sse with the functionality to kind if send multiple requests through the same connection. 🤔
Its for me as a reader of that sample and no eventing on browser interaction experienced Developer, also a bit difficult to understand how to use it along the sample in the readme, in the point of "Do we need to have a kind of Watch / Stopwatch even if we would still await a callback?"
As background information about the reasons I were considering this is OAuth Authorization Code Flow for example requires first the interaction of the user to grant the access and afterwards it would send the CodeExchange request to the token Endpoint. Currently I would just do that with a refit/http client instance then since this needs no browser interaction of the user anymore. But the thought would be the same.
You seem to do very much tight coupling of options and messaging/Responses like on the server type also for each handler 🤔
of course it makes sense in case they are just and only to be used by that handler, but that's also limiting the possibilities of extending the Handlers with similar but slightly different services via composition or inheritance like we would normally do with EndpointOptions in uno http extensions.
Like... I thought about that the AuthCallback Handler or any further added Handler could be considered based upon the Path Handler and having its path property defined as a base option maybe, so they could only define relative paths and the consumer would then have one ServerOptions but would not be required to define that same base url again e.g. for the handler options on the redirect url. Also considerable could be to have the limiting functionality of the Guard Handler with header attachments or the Sse with the functionality to kind if send multiple requests through the same connection. 🤔
Its for me as a reader of that sample and no eventing on browser interaction experienced Developer, also a bit difficult to understand how to use it along the sample in the readme, in the point of "Do we need to have a kind of Watch / Stopwatch even if we would still await a callback?"
As background information about the reasons I were considering this is OAuth Authorization Code Flow for example requires first the interaction of the user to grant the access and afterwards it would send the CodeExchange request to the token Endpoint. Currently I would just do that with a refit/http client instance then since this needs no browser interaction of the user anymore. But the thought would be the same.