Application Models

This page is the architectural decision point before you start application setup with RecroGrid Framework.

What is an application model?

An application model describes how the user interface, authentication, API access, and the RecroGrid Framework server runtime are divided between applications and runtime boundaries. It does not refer to a single project or technology.

The same functional solution can contain multiple applications. This page describes each model from three viewpoints:

Deployment view: the separately deployed and operated applications.
Development view: the projects or client-side and server-side parts developers work with.
Request flow: how browser requests reach the RecroGrid Framework backend.

The two modern Blazor-based models both use a separate backend API application. They differ in whether the browser reaches that API through a Blazor host or directly.

Comparison

Application model	Deployment shape	Authentication	How the client reaches the RGF backend	Main server-side runtime location	Recommended usage
Server-side Application	Blazor host application + backend API application	OIDC at the host + SessionAuth in the interactive client	Through the host-side proxy	Backend API application	Recommended for new applications
Blazor WebAssembly Application	WebAssembly client application + backend API application	OIDC in the client / bearer token flow	Directly from the browser	Backend API application	Standalone and existing WebAssembly applications
ASP.NET Core MVC	One integrated MVC application	Server-side integration	Inside the MVC application	MVC application	Legacy compatibility path

Server-side Application

Recommended

What it is

This model places a Blazor host application in front of a separate backend API application. The host owns the browser-facing application, authentication session, and API proxy. The backend API application owns the main RecroGrid Framework server runtime and data responsibilities.

Deployment view

Two applications are deployed and operated:

flowchart TD
    browser[Browser]
    host[Blazor host application]
    api[Backend API application]
    db[(Database)]

    browser --> host
    host --> api
    api --> db

The interactive Blazor client is delivered by the Blazor host. It is not a third independently deployed application in this model.

Development view

The two deployed applications contain the following development-time parts:

flowchart TD
    subgraph hostApp[Blazor host application]
        subgraph hostPart[Host/server part]
            oidc[OIDC sign-in and authenticated session]
            sessionEndpoints[SessionAuth endpoints]
            proxy[API proxy]
        end
        subgraph clientPart[Interactive Blazor client part]
            ui[UI and client-side routes]
            sessionClient[SessionAuth client behavior]
        end
    end

    subgraph backendApi[Backend API application]
        runtime[RecroGrid Framework server runtime]
        business[Business logic]
        ef[Entity Framework]
        dbAccess[Database access and operations]
    end

The host/server part and the interactive client part may be separate projects in the solution, but they form one browser-facing Blazor application and are deployed together. The backend API remains a separate application and deployment unit.

Request flow

The browser opens the Blazor host application.
The host performs the OpenID Connect sign-in and maintains the authenticated cookie-backed session.
SessionAuth keeps the interactive client aligned with that host-managed session.
Client API requests return to the host origin.
The host-side proxy forwards authorized requests to the backend API application.
The backend API executes the RecroGrid Framework server runtime, business logic, and data operations.

The browser therefore does not need to manage downstream API bearer tokens directly.

Why choose it?

It keeps OpenID Connect sign-in, session ownership, and downstream API access under central host control.
It avoids direct browser management of downstream API bearer tokens.
It separates the browser-facing application from the backend API application that owns business logic and data access.
It fits integrated business applications where client and server behavior should stay closely aligned.

Trade-offs

It requires two server-side deployment units: the Blazor host application and the backend API application.
The Blazor application has both host/server and interactive client parts, which adds development-time structure.
Getting Started > Server-side Application

Blazor WebAssembly Application

What it is

This model uses a standalone browser-hosted Blazor WebAssembly client that calls a separate backend API application directly. There is no Blazor host acting as an authentication and API proxy between the browser and the backend.

Deployment view

Two applications are deployed and operated:

flowchart TD
    client[Browser / Blazor WebAssembly client application]
    api[Backend API application]
    db[(Database)]

    client --> api
    api --> db

The WebAssembly client is normally published as static browser assets, while the backend API is a separate server application.

Development view

flowchart TD
    subgraph wasmClient[Blazor WebAssembly client application]
        ui[UI and client-side routes]
        oidc[OIDC client and bearer-token handling]
        directClient[Direct API client]
    end

    subgraph backendApi[Backend API application]
        runtime[RecroGrid Framework server runtime]
        business[Business logic]
        ef[Entity Framework]
        dbAccess[Database access and operations]
    end

Unlike the Server-side Application model, the client application has no associated ASP.NET Core host part that owns its session and proxies its API traffic.

Request flow

The browser loads the Blazor WebAssembly client.
The client performs authentication with the configured OIDC provider.
The client obtains and manages the bearer token required by the API.
The browser calls the backend API application directly.
The backend API executes the RecroGrid Framework server runtime, business logic, and data operations.

Because the browser reaches the backend directly, bearer-token support, API exposure, and CORS are part of this application model.

Why choose it?

It provides a direct browser-to-API flow.
It is a natural fit for standalone WebAssembly applications and existing direct-access solutions.
It keeps the browser client and backend API as clearly separated applications.

Trade-offs

The client is responsible for the OIDC and bearer-token flow.
Direct browser-to-API communication makes CORS and API exposure part of the application architecture.
Getting Started > Blazor WebAssembly Application

Modern Blazor-based models in practice

Both modern models use a dedicated backend API application for the RecroGrid Framework server runtime, most business logic, Entity Framework integration, and database operations.

The difference is the browser-facing boundary. In the Server-side Application model, the browser uses a Blazor host that manages authentication and proxies API requests. That Blazor application also has distinct host/server and interactive client parts during development. In the WebAssembly model, the standalone client handles authentication and calls the backend API directly.

ASP.NET Core MVC

What it is

ASP.NET Core MVC is a legacy compatibility path for existing applications. Unlike the modern Blazor-based models, it keeps UI hosting and the RecroGrid Framework server runtime in one integrated server-side application.

Deployment view

One application is deployed and operated:

flowchart TD
    browser[Browser]
    mvc[ASP.NET Core MVC application]
    db[(Database)]

    browser --> mvc
    mvc --> db

Development view

flowchart TD
    subgraph mvcApp[ASP.NET Core MVC application]
        ui[UI hosting]
        runtime[RecroGrid Framework server runtime]
        business[Business logic and data access]
        dbAccess[Database access and operations]
    end

There is no separate backend API application in this model.

Request flow

The browser reaches the MVC application, which handles the UI request and runs the required RecroGrid Framework server and data operations inside the same application boundary.

Why choose it?

Use this model to maintain an existing MVC application that already uses the integrated RecroGrid Framework runtime.

Trade-offs

It does not provide the client/backend separation used by the modern Blazor-based models.
It is a compatibility path and is not recommended for new applications.
Legacy ASP.NET Core MVC Integration

How to choose

Start with the Server-side Application model for a new application. Choose the Blazor WebAssembly model when the browser must remain a standalone direct API client. Use the MVC model only when maintaining an existing integrated MVC application.

Table of Contents

Application Models

What is an application model?

Comparison

Server-side Application

What it is

Deployment view

Development view

Request flow

Why choose it?

Trade-offs

Blazor WebAssembly Application

What it is

Deployment view

Development view

Request flow

Why choose it?

Trade-offs

Modern Blazor-based models in practice

ASP.NET Core MVC

What it is

Deployment view

Development view

Request flow

Why choose it?

Trade-offs

How to choose

Next step