On 10 June 2018 at 08:44, amotz <amot...@gmail.com> wrote: > I found myself needing the options to do "fantout" for a call. Meaning > making 1 call to haproxy and have it pass that call to all of the endpoint > currently active. > I don't mind implementing this myself and push to code review Is this a > feature you would be interested in ?
Hey Amotz, I'm merely an haproxy user (not a dev and nothing to do with the project from a feature/code/merging point of view), but I'd be interested in using this. I feel like an important part of it would be how you'd handle the merge of the different server responses. I.e. the fan-in part. I can see various merge strategies which would be useful in different situations. e.g. "Reply with *this* backend's response but totally ignore this other backend's response" could be useful for in a logging/audit scenario. "Merge the response bodies in this defined order" could be useful for structured data/responses being assembled. "Merge the response bodies in any order, so long as they gave an HTTP response code in the range of X-Y" could be useful for unstructured or self-contained data (e.g. a catalog API). "Merge these N distinct JSON documents into one properly formed JSON response" could be really handy, but would obviously move haproxy's job up the stack somewhat, and might well be an anti-feature! I could have used all the above strategies at various points in my career. I think all but the first strategy might well be harder to implement, as you'll have to cater for a situation where you've received a response but the admin's configured merging strategy dictates that you can't serve the response to the requestor yet. You'll have to find somewhere to cache entire individual response bodies for an amount of time. I don't have any insight into doing that - I can just see that it might be ... interesting :-) If Willy and the rest of the folks who'd have to support this in the future feel like this feature is worth it, please take this as an enthusiastic "yes please!" from a user! Jonathan
