Is the proxy preferred for all client-side/native apps? #2455
-
I haven't been working with Unleash for some time and today, when I returned, there is something called "Unleash Proxy" and I am confused a bit. I am preparing a desktop app in C#/.NET (WPF) and I was using regular .NET SDK previous time I was preparing something similar. This time, I see the usage of "proxy" is preferred for native/client apps. This is my use case, yet there is no .NET proxy SDK available (yet?), should I write it for myself or should I use "server-side" .NET SDK? I see that Unleash Proxy approach does not require usage of API token, instead using a client token, which is good, protecting data from users on their own computers is cumbersome a bit ;) Few years ago I made an experimental client of Unleash for Arduino, I think I should also switch to proxy API, it's a lot simpler (because everything is calculated on the proxy), which is nice for embedded platforms... |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Hey, @ktos and welcome back 🥳 That's a good question about the proxy. In terms of binaries that run on end-users' devices, we do generally recommend using the proxy, yeah. The reason is that if you use a server-side SDK, then it'll receive all toggles from Unleash when making API calls, which could potentially expose features and configuration you'd rather keep to yourself. This includes constraints, payloads, etc, that you send from Unleash, which could expose sensitive information. The proxy clients take a different approach where they only get the list of toggles that are enabled for the current user context, and therefore only know about what the user gets to see. Taking that into consideration, I think that using the proxy for client-side apps such as WPF applications does make sense. However, you're right: there's no .NET proxy client available, and it's not something we have planned. The primary use case for the proxy is web and mobile apps, but there's nothing stopping you from using the proxy in .NET. Luckily, the interface is fairly simple. There is some information in the API section of the proxy docs and if you have a running proxy, you can enable the OpenAPI spec too. But of course, you can use the server-side SDK in a WPF app too, but just be aware that if the user inspects incoming connections somehow, then they'll be able to see the entire configuration setup. So stuff like configuration for user ID strategies, constraints based on region, emails, and other identifying data. Does that answer your questions? |
Beta Was this translation helpful? Give feedback.
-
Thanks for answering, @thomasheartman! Everything is much clearer now. I've noticed there is OpenAPI available for the proxy so generating a client for it shouldn't be that hard. |
Beta Was this translation helpful? Give feedback.
Hey, @ktos and welcome back 🥳
That's a good question about the proxy. In terms of binaries that run on end-users' devices, we do generally recommend using the proxy, yeah. The reason is that if you use a server-side SDK, then it'll receive all toggles from Unleash when making API calls, which could potentially expose features and configuration you'd rather keep to yourself. This includes constraints, payloads, etc, that you send from Unleash, which could expose sensitive information. The proxy clients take a different approach where they only get the list of toggles that are enabled for the current user context, and therefore only know about what the user gets to see.
Taking that into con…