Prerendering:

In prerendering, the HTML is fully generated on the server and sent to the client’s browser. This mode improves initial load times by providing a static snapshot of the content, which is later enhanced with interactivity once the Blazor app runs on the client side (WebAssembly) or re-establishes a connection with the server (SignalR).

WebAssembly means running code efficiently in web browsers. It provides a way for developers to run compiled code, making it possible to execute performance-intensive tasks directly within the browser. With Blazor, WebAssembly allows Blazor applications to run entirely in the browser, enabling client-side execution of .NET code without needing a server for every interaction.

Server-Side Rendering (Blazer Server):

HTML is rendered on the server. User interaction with the user interface is sent back to the server, new rendered HTML sent back to the client. Real-time client server connection is done using SignalR. Social media platforms thrive on real-time updates and interactions, such as likes, comments, and live feeds. Blazor Server’s real-time communication model, powered by SignalR, makes it well-suited for building applications that require immediate user feedback and updates without the need for page refreshes. This aligns well with the dynamic and interactive nature of social media platforms.

Client-Side Rendering (Blazer WebAssembly):

Blazor application and the components are downloaded in the client’s browser. The component’s logic and HTML are processed directly in the browser using WebAssembly. For client-side interactivity, there is no need for continuous server connection.

• Advantages:
  
  • Full interactivity with offline capabilities.
  • Leverages the client’s processing power, reducing server load.
• When to use:
  
  • For rich, interactive user experiences that require immediate feedback.
  • When offline functionality is needed.

Interactive Server-Side Rendering Mode:

It is about real-time interactivity, where the entire lifecycle of the component, from rendering to user interaction, is managed by the server. This mode is typically used in Blazor Server applications where interactivity is critical.

• Advantages:
  
  • Real time interactivity.
  • Reduces client requirements
  • Easier to manage state and logic on the server side
• When to use:
  
  • Interactive applications where maintaining state on the server is beneficial
  • Minimize client-side resources and complexity.
  • When real-time updates are essential, leveraging the server’s processing power
• Considerations
  
  • Latency in case poor network connectivity
  • Deployment: Azure SignalR Service

Automatic Rendering

This mode starts by rendering the page on the server for fast loading, then switches to WebAssembly-based client-side rendering in the background.

• Advantages:
  • Combines fast initial load of server rendering and rich interactivity and offline capabilities of client-side rendering.
  • Flexibility: Automatically adapts the rendering mode to optimize for performance and user experience.
  • Provides a smooth transition from server to client rendering without noticeable changes to the server.

• When to use:
  
  • Balance between server and client processing, optimizing load times and interactivity.

Interactivity type: none

Static server rendering: but no websocket connection and no webassembly downloaded.  Html will be built on the server and client gets the finished html.  Button clicks or events will not be handled. 

Interactivity type: Server

Interactivity via SignalR (websocket connection).No interactivity when offline.

Interactivity type: Web Assembly

Interactivity via WebAssembly. Handlers in code downloaded to the client’s browser. Interactivity even when offline

WebAssembly Standalone App

Interactivity via WebAssembly. Handlers in code downloaded to the client’s browser. Interactivity even when offline.

Interactivity type: Auto

Interactivity starts via websockets, while in the background the wasm files will be downloaded. When page is visited again, the wasm files will be detected and used instead of websockets.

Deployment

Blazor Server:

• Azure App Service:
  
  • Can be more resource-intensive due to per-user server-side memory usage (50KB – 500KB per user).
  • Example: A 16GB server with average 100KB per user memory usage. Assume 5GB is reserved for OS and other services, leaving 11GB available.
    
    • Calculation: 11GB / 100KB per user = 110,000 users supported.
• Azure SignalR Service:
  
  • Offloads hosting of SignalR connections from the server, allowing for easier scaling of the application.
  • Provides serverless connections for cost-efficient, on-demand scaling.
  • Automatically handles session stickiness.
  • Offers connection management and auto-reconnect features.