This message was deleted.

⭐ Our official support hours are 6:30am - 5pm Pacific Time, Monday through Friday. You may occasionally hear from us outside of these hours. Your support request has been logged in our system. Our support team will get back to you very soon!

The legacy SDK webhooks are still the best solution for this right now. We are actively working on a replacement within the newer SDK Connections that should be available within the new few weeks.

I think the proxy is your best option. In this scenario, it serves as a smart wrapper around your Redis cache store and handles all the updating logic for you. It also unlocks some cool things like streaming changes to connected clients (React SDKs in your case)

@happy-autumn-40938 Using the cloud service and the proxy is what I was hoping to do. Having issues with the redis store not updating when a change is made. I am reaching straight into the redis store from our php application to reduce latency.

That's a less common use case (hitting Redis directly instead of the proxy). I wouldn't recommend it unless you're running into latency obstacles. The proxy already keeps a short-TTL in-mem cache in addition to using Redis on the backend, so it should be pretty fast in most scenarios. You could also consider a low-TTL memcached wrapper in PHP to reduce the hops.

We were trying to avoid maintaining a low TTL wrapper so we could get faster updates when we change a feature defintion. Especially with streaming changes to the React app, we want there to be minimal mismatch of evaluations if we are need to toggle something in React and PHP.

by avoid a low TTL wrapper, I assume you are talking about a custom memcached solution and not the proxy itself? The proxy should update just as fast (if not faster) than the streaming updates over CDN. Are you not seeing that?

Working on getting the proxy setup. I had been testing it locally, but never updated the proxy url on the sdk connection, which explains why I was not seeing any updates