You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you're writing the client package for a service, you want to be able to accept an httpclient.Client in the constructor, however you also want to be able to modify certain parameters of that httpclient.Client, like the service name, which is impossible once you are given a client which was already created.
There's isn't a straightforward extension to allow modifying an existing client given the current design given how the middleware is flattened into a list at client creation time and the ordering is important.
The current solution has been to make parameters request scoped which can always be specified in the service's client package even after receiving a fully formed httpclient.Client, however that can be annoying if the there are many individual httpclient.Client.XXX() calls, because each one must be sure to use these request parameters. Additionally it also bloats the API surface area with parameters that could be for requests or clients. Or you must always wrap the given httpclient.Client with a wrapper that adds the necessary request params to every call then calls the underlying httpclient.Client.
If these approaches are not used or are impossible because a request parameter hasn't been created yet, you end up requiring the service clients to construct their httpclient.Client with special parameters that they should not have to specify. For example, if I'm using a "Foo" service client package, I you may have to specify httpclient.WithServiceName("foo") when constructing the httpclient.Client to pass to fooclient.New(httpc httpclient.Client, when really fooclient.New(...) should just be setting that information internally.
This has also come up for ErrorDecoders as well.
It would be great to not make service client packages have to construct httpclient.Clients with special parameters specific to that package, which means we must enable service client package authors to more easily manipulate the httpclient.Clients they accept as part of their constructors.
The text was updated successfully, but these errors were encountered:
If you're writing the client package for a service, you want to be able to accept an
httpclient.Client
in the constructor, however you also want to be able to modify certain parameters of thathttpclient.Client
, like the service name, which is impossible once you are given a client which was already created.There's isn't a straightforward extension to allow modifying an existing client given the current design given how the middleware is flattened into a list at client creation time and the ordering is important.
The current solution has been to make parameters request scoped which can always be specified in the service's client package even after receiving a fully formed
httpclient.Client
, however that can be annoying if the there are many individualhttpclient.Client.XXX()
calls, because each one must be sure to use these request parameters. Additionally it also bloats the API surface area with parameters that could be for requests or clients. Or you must always wrap the givenhttpclient.Client
with a wrapper that adds the necessary request params to every call then calls the underlyinghttpclient.Client
.If these approaches are not used or are impossible because a request parameter hasn't been created yet, you end up requiring the service clients to construct their
httpclient.Client
with special parameters that they should not have to specify. For example, if I'm using a "Foo" service client package, I you may have to specifyhttpclient.WithServiceName("foo")
when constructing thehttpclient.Client
to pass tofooclient.New(httpc httpclient.Client
, when reallyfooclient.New(...)
should just be setting that information internally.This has also come up for
ErrorDecoder
s as well.It would be great to not make service client packages have to construct
httpclient.Client
s with special parameters specific to that package, which means we must enable service client package authors to more easily manipulate thehttpclient.Client
s they accept as part of their constructors.The text was updated successfully, but these errors were encountered: