Hi Aleksandar,
That is a welcome follow-up to the tangent we went on in the announce
thread.
As there was the discussion about the future of the SPOE filter, let me
start a discussion about some possible filter options.
[...]
The question which I have is how difficult is it to add a http filter
based on httpclient similar to SPOE or FCGI filter.
Another option is to add some language specific filter like
haproxy-rs-api shown in this comment
https://github.com/khvzak/mlua/issues/320#issuecomment-1762027351 .
I personally find the latter much more appealing. If only because the
http client is "just" a much more restricted version of it.
And since I was the first (in that thread, certainly not everywhere) to
complain about the current language of choice for extending HAProxy
(LUA), I have to say again that a target "language" like WASM sounds
like an ideal selection:
- no need to pick/enforce/encourage a specific input language
- plenty of languages already compile to it, and likely to continue
trending up since browsers support it
The Idea to add the http filter is that there are so many http based
tools out there and with that could HAProxy use such tools based on http.
That is true, but needing an HTTP API + the loss in efficiency sounds a
bit painful.
And very painful if the response isn't so easy to parse.
Thinking of cases where XML decoding becomes relevant, for example
SAML-related ones which are common for auth-related matters still.
Any opinion on that?
Well on my end I certainly want to see this too. That said Willy had a
few counterpoints of relevance in that other thread that are worth
addressing here:
> WASM on the other hand would provide more performance and compile-time
> checks but I fear that it could also bring new classes of issues such
> as higher memory usage, higher latencies, and would make it less
> convenient to deploy updates since these would require to be rebuilt.
I'd say first that there are interpreters (and JITs) so the rebuild is
not necessary.
However, even if it was, I'm not sure that the buildless use-case has
that much traction as long as the build doesn't have to happen on the
LBs directly.
For example I don't remember seeing complaints that SPOEs essentially
require a build step.
> Also we don't want to put too much of the application into the load
balancer.
That's a much more fundamental question however. This is your project,
not mine, so your call.
But I have to emphasize that one reason I use HAProxy is specifically
because it's extremely configurable and allows me to offload a lot of
application-related logic directly at the edge.
In a more impersonal way, that is also a direction many are interested
in in general. See things like
https://blog.cloudflare.com/cloudflare-snippets-alpha/ which are
essentially ACL-triggered filters in HAProxy terms.
One example case I see up and again is tee-ing a request, for various
reasons:
- for silent A/B testing between 2 backends (ie tee to 1 control and 1 test)
- for routing the request that triggers a cached response both to the
cache and to something interested in it for statistics; so users gets
fast response and you still ALSO get to count those requests
And of course that has concerns related to memory used for buffering the
content if there are 2 targets and thus you can't purely stream through.
But in some places it has applicability I think.
> But as I said I haven't had a look at the details so I don't know
> if we can yield like in Lua, implement our own bindings for internal
> functions, or limit the memory usage per request being processed.
That is much more difficult for me to answer, so to save you some time
these seem to be the 3 main C-embeddable runtimes at the time of writing:
- https://github.com/bytecodealliance/wasm-micro-runtime
- https://github.com/wasm3/wasm3
- https://github.com/wasmerio/wasmer
I had a look and however didn't see a way to control memory or force
yielding... so it's not encouraging. But maybe I missed it.
> During the Lua integration we used to say that it would teach us
> new use cases that we're not aware of and that could ultimately
> end up as native actions/sample fetches/converters for some of them
> if they were popular.
I fully get that, and I think it wouldn't really change either way. For
example if it didn't exist yet, a cache like the native one would be
something to show up for sure.
But there are still quite a few more site-specific things that have no
chance of ever making it in mainline (and that's a good thing) but also
become more complex than a "just a few lines".
As in you COULD write it in 20 instructions yes, but the source being
150 would make it more readable even if in the end the actual amount of
executed instructions remains 20.
And having a decent developer experience while doing that is quite
helpful rather than randomly tweaking things around until it doesn't 503
anymore because something's nil-able and you didn't handle it.
> [...] for example I remember about JWT which stared in Lua and is
> now native
Saw that yes, and using the native JWT things atm myself. I'd note
however that while it's great to have it, it's still a little bit
awkward in practice, because of the number of fields to check. As in
proper validation of iss, aud, exp, and keys turns out to be very
verbose in the haproxy configuration.
Not saying it's a bad thing in any way, mind you. And it's great to have
it. But it's not quite the same as a theoretical
http-request filter oauth2
https://auth.foo.bar/.well-known/openid-configuration
Tristan
