Question: is unleash-client-php compatible with unleash-proxy?
carlosas opened this issue · 4 comments
We want to have a unique source of truth both in our frontend (JS) and backend (PHP), specially regarding cache, so we are considering using the Unleash Proxy.
However, I can only see in UnleashBuilder
options to configure a client to connect directly with GitLab (withAppUrl, withInstanceId). I also can not see any reference to the proxy on the documentation of this project.
I'm a bit lost. How should we instantiate a client that would perform a curl https://unleashproxy.example.com/ -H "Authorization: 123456123456"
?
The Unleash proxy is mainly intended for frontend frameworks. To make it fast Unleash sends the whole state as a json document and it's actually the job of all the client SDKs to make some meaning of the raw json data. In a frontend framework that would mean any user of your app can see your whole feature flag configuration and that could leak some data you might not want to. It doesn't matter on backend because no end-user can see the state of your feature flags.
That's where the Unleash proxy comes in - you point your frontend app to the proxy which is in turn connected to your Unleash instance and the proxy returns a response where only the flags that evaluated to true are returned, meaning you don't leak any data that the user shouldn't know about.
So the single source of truth is your Unleash instance (which you connect directly to using backend SDKs like the php one), you only use the proxy on frontend to hide potentially sensitive information.
So you should use the example right from the beginning of the README to connect directly to Unleash instance and use the proxy only for the frontend.
<?php
use Unleash\Client\UnleashBuilder;
$unleash = UnleashBuilder::create()
->withAppName('Some app name')
->withAppUrl('https://unleash.example.com') // the unleash instance, not the proxy
->withInstanceId('Some instance id')
->withHeader('Authorization', '123456123456')
->build();
Let me know if that clarifies how Unleash works or if you need any further assistance.
Hi. Thanks for the quick reply.
The problem is the cache. If you want to cache for 15 min, you would have the proxy's cache for the frontend and this client's cache for the backend. Then when you enable/disable a flag, there will be potentially up to 15 minutes where the frontend and the backend will have different versions of the flag.
That's why I would like to connect the backend to the proxy, and only use the proxy's cache as source of truth (I don't care about how instant the change gets applied, but I do about the consistency between BE and FE)
Hey @carlosas,
Can you unpack a little bit what you're trying to achieve here? It sounds a little like you're trying to force a front end system and a backend system to remain in lockstep with each other for their toggle states. If so, I would strongly recommend not trying to do that for two reasons:
Firstly, because it isn't really possible with a distributed system, you're always going to burned by CAP at some point here, even if you make it less likely. Secondly because Unleash isn't really designed for this, it's an AP system. The flag states are always resolved from cache so that resolving a flag doesn't result in network call. Even outside of forcing the backend and frontend to have the same states, there's always a risk that a flag gets flipped during the course of the network call.
Usually when I see this kind of question, it's because someone is trying to check a flag state on the frontend and then double check that state on the backend. What we'd recommend in that case is either resolving that flag once on the front end and passing that flag state to the API or using the flag on the frontend to call a different endpoint. I.e. flags should be checked once and only once for the lifetime of a request.
I may very well have misunderstood your use case or problem here so please poke me if I'm wrong!
As an aside, I would strongly recommend using Edge (https://github.com/Unleash/unleash-edge) over the Proxy today, so long as you're comfortable with the caveats. It's a lot lighter, faster and much nicer to work with when using a backend SDK (you mention Gitlab, if that's your use case here then Edge won't work here and Proxy is what you want)
Usually when I see this kind of question, it's because someone is trying to check a flag state on the frontend and then double check that state on the backend. What we'd recommend in that case is either resolving that flag once on the front end and passing that flag state to the API or using the flag on the frontend to call a different endpoint. I.e. flags should be checked once and only once for the lifetime of a request.
Yes, this is what it's happening. We don't want the FE calls to make the BE behave as enabled or disabled at will, I think we will go backend->gitlab
and frontend->proxy->gitlab
with 1 second cache and just accept a 1 second unpairment.
Thank you a lot