-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce behaviours #91
Comments
interesting idea. i am not exactly sure of the use case, but it could be but if we nest those clients, one would need a way to access both the |
Example use case: you have a sync client which you wrap in a flexible client, then wrap it in a batch client. I know this is kind of an edge case, but this is a case that we have at the moment. However, the current approach is not flexible enough to support any future use cases.
No, I don't think so. It's the responsibility of the user to now what behaviours are nested into each other. For example I can imagine two or three nested decorators end up in a batch client in the end. During the nesting we need to check in each case if the specific nest is supported (eg. the returned client from the previous nesting needs to be an HttpClient) and throw an error when an illegal nesting happens. |
i am not against it if the code for it looks sane. but at some point it
might become easier to just define your own service for the client,
rather than configuring it
|
Yeah, this idea was born on the suburban train in a pre-coffee state, so definitely needs some more thinking, examples, etc. |
Small note, as clients created through the config are all PluginClient, there are all flexible. |
Let's close, this didn't gain much traction |
At the moment we support flexible client and methods client via options of the client definition with simple flags set to true. However this makes it harder to nest these client behaviors (even if it might not make too much sense at the moment). Instead of these flags, I propose the following:
This would allow to nest multiple behavioral clients into each other. Of course we have to take care of type safety (behavioral clients might be sync or async clients (or both), but we need to check that before each nesting to see what the next behavior supports)
This would also ensure futureproof flexibility.
The text was updated successfully, but these errors were encountered: