WebMap for Blazor
  • WebMap Blazor
    • Modernization
      • Overview
      • Modernization Challenges
      • Our solution
      • What is Blazor?
      • How does Blazor Work?
      • Windows Forms in Blazor
      • Deployment
      • Interfacing with hardware devices
    • Research for Blazor
      • Handling Reference Parameters in Async Methods with Ref<T>
      • Alternatives to Async Properties in C#
      • Issue with using "MessageBox.Show" in Blazor
    • Assessment Tool
    • Conversion Tool
      • Getting Started
      • Modals and Dialogs
      • Static Service Management
      • ImageListStreamer
      • Solution and Project Structure
        • Solution Generator
    • DCP: Desktop Compatibility Library
      • API Documentation
        • Blazor DCP: Gap.Blazor.Application Class Reference
      • Components Information
        • Button Component
        • Application Data Component
        • GroupBox Component
        • Label Component
    • Post Conversion
      • How To?
        • Create a new WebMap Window?
        • Create a new WebMap Component?
        • Create a native Blazor Window in a WebMap app?
        • Create a native Blazor Component in a WebMap Window?
        • Change the default WebMap visual layout?
    • WebMap: Angular vs Blazor
      • Footprint
      • Binaries size
      • Chatiness
      • Performance
      • Extensibility
      • Maintainability
      • Debugging
      • Project Structure
    • WebMap for Blazor Release Notes
      • Beta version
    • FAQ
    • Errors and Troubleshooting
    • License
Powered by GitBook
On this page
Export as PDF
  1. WebMap Blazor
  2. Modernization

Deployment

PreviousWindows Forms in BlazorNextInterfacing with hardware devices

Last updated 6 months ago

It is important to note that Blazor Server operates as a stateful service, where all session data is maintained in the server's memory. In scenarios with multiple users, horizontal scaling may become necessary. Since Blazor utilizes persistent WebSocket connections, the scaling infrastructure must be capable of maintaining these connections and correctly routing messages to the appropriate instances that manage the user sessions. Additionally, the system must handle reconnection logic to ensure session continuity when disruptions occur.

Session Affinity

Session affinity, or "sticky sessions," is a crucial routing mechanism in Stateful server-side applications that ensures all requests from a specific user are consistently directed to the same server instance, particularly when scaling out.

Session affinity guarantees that all SignalR messages are routed to the same instance. This approach also automatically manages reconnections when necessary.

The following diagram outlines the services that offer WebSockets session affinity, along with the deployment options for scalable back-end infrastructure across the major cloud providers (AWS, Azure, GCP). Service selection should be driven by your specific technical requirements:

Deployment options