Starting context
Let's question this original design decision.
The original idea behind proxy_mode
was that Filters would often have paired logic, one for client side proxying and one for server side proxying. So it would be expected for logic to change depending on the proxy mode, to match what was happening on the other side.
To provide a concrete example, here is what a Filter than would do compression/decompress would look like:
version: v1alpha1
proxy:
mode: CLIENT
static:
filters:
- name: quilkin.extensions.filters.compression.v1alpha1.Compression
config:
mode: SNAPPY
endpoints:
- name: server-1
address: 127.0.0.1:7001
Data going to the Client Proxy would be compressed when sent up to the proxy, and expect compressed data to come back from a Server Proxy on the way back down.
Conversely, a proxy in proxy_mode: SERVER
will expect incoming data from a client to it's local port to be compressed, and will send decompressed data back through to the Server.
The whole idea being it would be easier to reconcile if something was a "Client" or a "Server" because it's written in the actual configuration.
The flip side to this, is if we throw away the whole notion of Client/Server proxies as first class citizens - and instead just have Proxies, with explicit Filter configurations. So the Client Proxy configuration as above would instead be something like:
version: v1alpha1
static:
filters:
- name: quilkin.extensions.filters.compression.v1alpha1.Compression
config:
mode: SNAPPY
receive:
local: compress
endpoints: decompress
endpoints:
- name: server-1
address: 127.0.0.1:7001
To provide the same logic, and instead be explicit at the Filter level what is going to happen when receiving data in both directions and what we should do about it. (not sure about the naming of the config elements, but hopefully you get where I'm going with this).
This is indeed more flexible a setup, but also requires some more verbose configuration from the end user.
So - what do we think? As we're writing more filters, do we feel more comfortable with a more flexible design (it seems that way, but good to double check these things), or something that's a bit more opinionated?