Next.js - loading feature toggles server-side #2190
-
Hi there, I'm trying to integrate unleash into our next.js app using the react proxy client. We previously found that it was unsuitable for use as it didn't support SSR, and recent releases have added some form of SSR support, so I gave it another go. However I ran into problems when it comes to fetching feature toggles server-side (with context fields), and passing the result down into the client side code. In order for the page content to be the same across server and client, we need to have the server-fetched toggles available in the initial render of the app - this can be done by passing the server-fetched toggles into the
With method 1, we're going to increase page load times significantly so this isn't really an option unless anyone else has other suggestions. Method 2 works, but the unleash proxy client has no way of checking if a toggle is enabled with context unless you set the context on the client instance. This is opposed to the node SDK where you can do So I'm pretty stuck here, and I was wondering if I was missing something, or if anyone had better suggestions for how to fetch server-side toggles? From what I can tell, in order to get full SSR support, we need one of 2 things:
Like I say, I could be missing something here, so if anyone has better suggestions, please let me know! Thanks :) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hey, @jebax! Thanks for the question and for the amount of research you've put into it. I might have a suggestion for you, but let me add additional context for you. tl;dr: You might be able to use the Unleash proxy and its On SSRWe don't have a complete story for SSR at the moment, but we're seeing questions about it more and more frequently, so it's probably something we'll devote more resources to in the somewhat near future. On your solutions and options (additional context)Regarding your two options, I agree that instantiating a new Unleash client with every request would incur prohibitive load times. Regarding option two:
That is a good point. I think the reason the proxy clients don't accept a A potential solution: the Unleash proxy
As mentioned previously, I don't think there's any plans to add a context parameter to the proxy client at the moment (though if that turns out to be the best solution for something , then it's definitely worth evaluating ☝🏼). For your second point, though, that is doable: In fact, that is exactly what the Unleash proxy is. It is a wrapper around the node SDK that formats toggle data for proxy clients. It's not very well documented at the moment, but the Unleash proxy does export its You'll need to import the client from the proxy package and construct an instance of it. Like with Node and other SDKs, you need to provide it with an Unleash URL, API keys, etc. When you have constructed the client, you should be able to call its The Proxy constructor takes an argument of type So it'd be something like: const { Client, createProxyConfig } = require('@unleash/proxy');
const proxyConfig = createProxyConfig({
unleashUrl: "",
unleashApiToken: "",
clientKeys: ["placeholder"] // just`[]` might work, but I'm not sure
// ... you might also want to disable metrics or perform other config here
})
const proxy = new Client(proxyConfig)
// whenever you want to check toggles:
const proxyClientToggles = proxy.getEnabledToggles(context); How does that sound? Would you be willing to check that out? |
Beta Was this translation helpful? Give feedback.
Hey, @jebax! Thanks for the question and for the amount of research you've put into it. I might have a suggestion for you, but let me add additional context for you.
tl;dr: You might be able to use the Unleash proxy and its
getEnabledToggles
method.On SSR
We don't have a complete story for SSR at the moment, but we're seeing questions about it more and more frequently, so it's probably something we'll devote more resources to in the somewhat near future.
On your solutions and options (additional context)
Regarding your two options, I agree that instantiating a new Unleash client with every request would incur prohibitive load times.
Regarding option two: