On Sun, Jun 10, 2018 at 12:36 PM, Jonathan Matthews <cont...@jpluscplusm.com > wrote:
> 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 > > Hi, what's the use case? Is this API gateway kind of thing? Baptiste
