[FEATURE] SSR Support

[RedbackThomson]

Requirements

The existing OpenFeature React SDK relies solely on the @openfeature/web-sdk package, intended to run client side (in the browser). When attempting to use the React SDK inside a NextJS application with SSR enabled, NextJS fails to render the page on the server and in the best case causes the page to stutter as it hydrates but in the worst case causes the application to fail to render at all.

Today, in order to support SSR, our code needs to conditionally disable the use of the React SDK hooks (and the Web client) and replace them with the same call to the NodeJS SDK when it detects the code is executing within an SSR context (by checking window === undefined).

Ideally the React SDK would have an option to natively support SSR in which it would:

• Detect that it was running within an SSR context
• Switch to a @openfeature/server-sdk client
• Automatically bootstrap the web client provider with the resolved flags, for instant hydration

[beeme1mr]

Hey @RedbackThomson, thanks for kicking off this conversation. As I mentioned on Slack, I've run into similar challenges in the ToggleShop. I'd love to find a way to support SSR and possibly SSG seamlessly.

Do you think we should create a dedicated SDK for NextJS that adds Next-specific features? It would be nice to avoid supporting another SDK, but that may not be feasible.

@toddbaert @lukas-reining, do either of you have an opinion on this?

[beeme1mr]

Here's some additional resources that may be useful while researching this topic:

• https://blog.devcycle.com/feature-flagging-with-next-js-lessons-learned-from-developing-devcycles-sdk/
• https://blog.devcycle.com/devcycles-new-next-js-sdk-elevating-feature-flagging-in-next-js-apps/

[lukas-reining]

In #1157 we discussed (#1157 (review)) that our approach of using the OpenFeatureApi singleton for setting providers in a Next.js App can create race conditions or even security issues.

In Next.js even "client components" will initially be rendered on the server. When OpenFeature.setProvider is called in the code, the OpenFeature singleton can be the same for every client because it is in the global "server state". After the initial render, it will be on the client state which is only global in the users browser.
When the static context is set by client 1 and client 2 on the provider is set, it could happen, that this is evaluated on the server (e.g. initial render) which can lead to both clients getting the same context.
This is similar to what TanStack Query is writing in their docs:

// _app.tsx
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'

// NEVER DO THIS:
// const queryClient = new QueryClient()
//
// Creating the queryClient at the file root level makes the cache shared
// between all requests and means _all_ data gets passed to _all_ users.
// Besides being bad for performance, this also leaks any sensitive data.

export default function MyApp({ Component, pageProps }) {
  // Instead do this, which ensures each request has its own cache:
  const [queryClient] = React.useState(
    () =>
      new QueryClient({
        defaultOptions: {
          queries: {
            // With SSR, we usually want to set some default staleTime
            // above 0 to avoid refetching immediately on the client
            staleTime: 60 * 1000,
          },
        },
      }),
  )

  return (
    <QueryClientProvider client={queryClient}>
      <Component {...pageProps} />
    </QueryClientProvider>
  )
}

Am I overseeing anything here or can you confirm this observation @beeme1mr @toddbaert @RedbackThomson?

If this is true, I think we should add a warning to the React SDK that it should not be used with Next.js.

Do you think we should create a dedicated SDK for NextJS that adds Next-specific features? It would be nice to avoid supporting another SDK, but that may not be feasible.

The issue I just described should be mitigable by not using a global OpenFeature API but having one provided through a React context, basically as TanStack proposes.
If we only keep state in a React context it might be possible to still only use the static context paradigm in the Next SDK.