Introduction
Technologies like Next.js and ASP.NET Core Blazor are modern full-stack frameworks that enable developers to build both server-rendered and client-rendered web applications within a single project, using a unified programming language. These frameworks also allow hosting the entire application as a single service.
- Server rendering is beneficial for SEO, while client rendering enhances interactivity.
- Embedding a client-rendered component within a server-rendered page is a common practice.
- Running a complex client-rendered application as an SPA (Single Page Application) is also widely adopted.
Both server-rendered and client-rendered applications can be feature-flagged. Developers typically use feature flags in the following ways:
- Separating client and server rendering, with each using its own feature flag SDK.
- Using a server-side feature flag SDK and passing the flag values to the client-rendered components.
This article explores which SDK (server or client) should be used in different scenarios:
- A page with complex business logic, such as a single application subpage.
- A fully server-rendered page.
- A simple client component page or multiple client components embedded in a server-rendered page.
Business-Heavy Client Page (Single Page Application)
If a project includes a single-page application (SPA) with complex business logic where users frequently interact with the interface, using a client-side feature flag SDK can be a good practice. This approach allows:
- Downloading all feature flags at the start of the application, maintaining a WebSocket (or SSE) connection to update feature flags in real time when necessary.
- Reducing network requests and improving user experience when navigating between components.
- Enabling real-time feature flag updates without requiring a page refresh for specific use cases (e.g., airport announcement apps).
- Decreasing the number of server-side feature flag evaluation requests, thereby improving server performance.
However, using a server-side feature flag SDK in an SPA can also be a viable approach, which will be discussed in a later section.
Server-Rendered Page
If a page is server-rendered, using a server-side feature flag SDK is the obvious choice. The SDK can be integrated into the middleware to evaluate feature flags and render the page accordingly or used within the server-side component rendering process.
However, there are some critical requirements for a server-side SDK:
- It should be able to synchronize with feature flag configurations in real-time.
- The evaluation process should not involve network requests to maintain high performance.
- The evaluation process should avoid excessive CPU resource consumption to ensure efficiency.
- The evaluation process should be thread-safe.
For example, FeatBit's server SDK meets all these requirements.
If your implementation does not meet these criteria, you should minimize the impact as much as possible. For instance, Vercel operates on a strict serverless architecture, and to reduce network latency while ensuring real-time updates, it utilizes the "Vercel Edge Config" mechanism to address these challenges.
Note: FeatBit, as a feature flag provider, integrates seamlessly with the Vercel Flag SDK.
Simple Client Component Page
In most full-stack frameworks, client-side rendering is used for simple business logic, such as handling forms, lists, tables, or other lightweight UI elements. A server-rendered page may contain multiple client-rendered components, each performing a minimal business task.
In this case, the client-rendered component should rely on feature flag evaluations performed on the server side. Here’s why:
- These types of pages are frequently refreshed, making real-time updates less critical.
- Loading feature flags on the client side introduces extra network requests and can delay page rendering.
- Managing a client-side SDK in a server-rendered page with multiple client components can be complex.
- As Vercel’s CEO Guillermo stated, "Otherwise, you overload the client with too many variants, delay rendering, or, at worst, cause layout shifts."
- And more.
Real-Time Updates Without a Client SDK
In a full-stack framework project, we can establish a WebSocket connection between the client component and the server to enable real-time updates. For example, in ASP.NET Core Blazor, we can create a SignalR hub between the browser and the server to send updated feature flag values to the client component whenever they change.
This approach requires additional implementation effort, depending on the technology stack used. For instance, since Vercel does not support WebSockets when hosting Next.js applications, this method is not suitable for Next.js.
Conclusion
In a full-stack framework project:
- A server feature flag SDK should be used in server-rendered pages.
- A client feature flag SDK is preferable for client-rendered pages with complex business logic.
- For simple client components embedded in a server-rendered page, the server feature flag SDK should be used.
This article will be updated as new technologies and methods become available. Stay tuned!