Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serving server-side-only feature flags from edge-proxy #129

Open
MCPx opened this issue Nov 13, 2024 · 5 comments
Open

Serving server-side-only feature flags from edge-proxy #129

MCPx opened this issue Nov 13, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@MCPx
Copy link
Contributor

MCPx commented Nov 13, 2024

We're looking to reduce our calls to the Flagsmith API from our backend services by running the Flagsmith edge proxy alongside them in the same cluster, but it looks like features that are marked as server-side only are filtered out by the edge proxy? Are there any plans to make this configurable or alternative suggestions for proxying server-side only flag queries?

@matthewelwell
Copy link
Contributor

@MCPx thanks for raising this. I certainly think it makes sense to include this functionality. I can slot this into our backlog, but equally, if you're willing to submit a PR, we'd gratefully receive it.

I think a short term solution to the issue would be to handle server side keys in the Edge Proxy logic. So, for example, here - instead of just blanket filtering out the server side features, we could first check if the key is a server key. Then, a work-around to avoid writing more code to modify the caching behaviour, would be to just add 2 entries into the environment_key_pairs object in the config - one for the client side key, and one for the server side key. Something like this:

  ...
  "environment_key_pairs": [
    {
      "client_side_key": "abc123",
      "server_side_key": "ser.def456"
    },
    {
      "client_side_key": "ser.def456",
      "server_side_key": "ser.def456"
    }
  ],
  ...

The more advanced implementation would expand the caching logic to allow look ups based on both the server key and the client key, but this probably could be done as a secondary piece of work.

@matthewelwell matthewelwell added the enhancement New feature or request label Nov 13, 2024
@MCPx
Copy link
Contributor Author

MCPx commented Nov 13, 2024

we could first check if the key is a server key.

@matthewelwell just to confirm, do you mean check that the client side key matches the server side key for the pair, or that the received environment key is a server key (i.e. starts with ser.)?

@matthewelwell
Copy link
Contributor

Well, that depends I think on what we're planning to do regarding the rest of the implementation. If we're planning on the workaround solution, we can just rely on key.startswith("ser.") as you can see us doing here.

If we're going with a solution where we modify the cache, then yes, I think we could match the key to the cache and verify that it was added as a server key, yes.

@MCPx
Copy link
Contributor Author

MCPx commented Nov 13, 2024

Thanks @matthewelwell I put up a PR for the workaround you mentioned, along with tests to confirm it works as expected. Let me know if you're happy with that or require any changes.

@matthewelwell
Copy link
Contributor

Great, thanks @MCPx - We'll take a look and get back to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants