Is there a benefit to proxy_mode?

[markmandel]

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?

[luna-duclos]

100% agree we need to drop proxy_mode, it makes no sense to have it.
I think I have a slight preference towards also not specifying what the filter should do on send/receive, it should "just know", but I can see the value for some more complex filters than the one in this example.

[iffyio]

I didn't realise this was the original intent of proxy_mode, here's an example use case I think it limits in the compress scenario, where for some reason the gameserver has compression enabled and we wanted to place a proxy in front of it - that won't be possible since proxy_mode means we can only have the compress filter at the start of the filter chain whereas we might want to do:

input_packet from client => decompress | ... other filter transformations ... | compress => output_packet to gs

The issue isn't compression specific, I'm thinking proxy_mode will be too restrictive and that it doesn't simplify config enough to be worth it.

The compress filter config without proxy_mode shouldn't need to be configurable in both directions (local/endpoints) since that could be confusing because filters generally do the reverse transformation on payloads going in the opposite direction (which is why we'll invoke the filter chain in the opposite order as well).
We should only need to configure one direction and the filter infers the rest e.g

config:
  mode: SNAPPY
  on_input: COMPRESS # the filter compresses incoming, decompresses outgoing packets
                     # key and value can be something more descriptive

A default DECOMPRESS would have it work out of the box at least half the time and the other half's a one-line change which wouldn't be significantly more configuration than proxy_mode.

If we wanted to have the filter just know what to do, we could maybe have separate compress and decompress filters - they would both compress and decompress but only differ in the direction they do so - but that might be overkill

[markmandel]

I think I have a slight preference towards also not specifying what the filter should do on send/receive, it should "just know", but I can see the value for some more complex filters than the one in this example.

Can you expand on what you mean here by "just know" @luna-duclos ? Do you mean something specific to how configuration should occur in general? Just wondering if it's something we can generalise and document as standards for writing Filters.

Sounds like we all agree that Proxy mode is not a good idea, and should be removed 👍 Let's do that then.

I'll leave the specifics to how the Compress filter should be configured to #162 - but these sound like excellent ideas as well.

I didn't realise this was the original intent of proxy_mode,

Heh, sorry - apparently people can't just read my mind 🤦‍♂️

[luna-duclos]

Can you expand on what you mean here by "just know" @luna-duclos ? Do you mean something specific to how configuration should occur in general? Just wondering if it's something we can generalise and document as standards for writing Filters.

@iffyio already detailed out exactly what I had in mind, so I'll defer to his explanation :)