|
| 1 | +--- |
| 2 | +title: "Blazor Rendering modes" |
| 3 | +date: 2020-09-10T08:22:12+02:00 |
| 4 | +weight: 10 |
| 5 | +--- |
| 6 | + |
| 7 | +Blazor supports [several rendering](https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-9.0#render-modes) modes: |
| 8 | +* **Static Server** - Static server-side rendering (static SSR) |
| 9 | +* **Interactive Server** - Interactive server-side rendering (interactive SSR) using Blazor Server. |
| 10 | +* **Interactive WebAssembly** - Client-side rendering (CSR) using Blazor WebAssembly. |
| 11 | +* **Interactive Auto** - Interactive SSR using Blazor Server initially and then CSR on subsequent visits after the Blazor bundle is downloaded. |
| 12 | + |
| 13 | +While these options give a lot of flexibility on how sites and components are rendered, it also provides some complexity. |
| 14 | + |
| 15 | +It's important to understand that, if you use a rendering mode that uses WebAssembly (so InteractiveWebAssembly or Auto), that you're effectively building two applications. One is a server process that renders HTML, the other is a WASM application that runs in the browser. |
| 16 | + |
| 17 | +If you have a component that's rendered both on the server AND on the client, then you effectively need to make sure that all the services it requires are available both on the server AND on the client. |
| 18 | + |
| 19 | +## Fetching data from local APIs |
| 20 | + |
| 21 | +If your BFF application can directly access data (for example from a database), then you have to decide where this information is rendered. |
| 22 | + |
| 23 | +For server side rendering, you'll typically abstract your data access logic into a separate class (such as a repository or a query object) and inject this into your component for rendering. |
| 24 | + |
| 25 | +For web assembly rendering, you'll need to make the data available via a web service on the server. Then on the client, you'll need a configured HTTP client that accesses this information securely. |
| 26 | + |
| 27 | +When using auto-rendering mode, you'll need to make sure that the component get's a different 'data access' component for server rendering vs client rendering. Consider the following diagram: |
| 28 | + |
| 29 | + |
| 30 | + |
| 31 | +In this diagram, you'll see the example **IDataAccessor** that has two implementations. One that accesses the data via a HTTP client (for use in WASM) and one that directly accesses the data. |
| 32 | + |
| 33 | +The data is also exposed (and secured by the BFF) via a local api. |
| 34 | + |
| 35 | +Below is an example of registering an abstraction |
| 36 | + |
| 37 | +``` csharp |
| 38 | +// Setup on the server |
| 39 | +
|
| 40 | +// Register the server implementation for accessing some data |
| 41 | +builder.Services.AddSingleton<IDataAccessor, ServerDataAccessor>(); |
| 42 | + |
| 43 | +// Register an api that will access the data |
| 44 | + app.MapGet("/some_data", async (IDataAccessor dataAccessor) => await dataAccessor.GetData()) |
| 45 | + .RequireAuthorization() |
| 46 | + .AsBffApiEndpoint(); |
| 47 | + |
| 48 | +// Create a class that would actually get the data from the database |
| 49 | +internal class ServerWeatherClient() : IDataAccessor |
| 50 | +{ |
| 51 | + public Task<Data[]> GetData() |
| 52 | + { |
| 53 | + // get the actual data from the database |
| 54 | + } |
| 55 | +} |
| 56 | + |
| 57 | +``` |
| 58 | + |
| 59 | +``` csharp |
| 60 | +// setup on the client |
| 61 | +
|
| 62 | +// Register a http client that can access the data via a local api. |
| 63 | +builder.Services.AddLocalApiHttpClient<DataAccessHttpClient>(); |
| 64 | + |
| 65 | +// Register an adapter that would abstract between the data accessor and the http client. |
| 66 | +builder.Services.AddSingleton<IDataAccessor>(sp => sp.GetRequiredService<HttpClientDataAccessor>()); |
| 67 | + |
| 68 | +internal class HttpClientDataAccessor(HttpClient client) : IDataAccessor |
| 69 | +{ |
| 70 | + public async Task<Data[]> GetSomeData() => await client.GetFromJsonAsync<Data[]>("/some_data") |
| 71 | + ?? throw new JsonException("Failed to deserialize"); |
| 72 | +} |
| 73 | + |
| 74 | +``` |
| 75 | + |
| 76 | +## Fetching data from remote APIs |
| 77 | + |
| 78 | +If your BFF needs to secure access to remote api's, then your components can both directly use a (typed) **HttpClient**. How this HttpClient is configured is quite different on the client vs the server though. |
| 79 | + |
| 80 | + |
| 81 | +* On the **Client**, the http client needs to be secured with the authentication cookie and CORS protection headers. This |
| 82 | +then calls the http endpoint on the server. |
| 83 | + |
| 84 | +* On the **Server**, you'd need to expose the proxied http endpoint. This then uses a http client that's configured to send access tokens. These may or may not contain a user token. |
| 85 | + |
| 86 | +This diagram shows this in more detail: |
| 87 | + |
| 88 | + |
| 89 | + |
| 90 | +``` csharp |
| 91 | +// setup on the server |
| 92 | +
|
| 93 | +app.MapRemoteBffApiEndpoint("/remote-apis/user-token", "https://localhost:5010") |
| 94 | + |
| 95 | +builder.Services.AddUserAccessTokenHttpClient("callApi", |
| 96 | + configureClient: client => client.BaseAddress = new Uri("https://localhost:5010/")); |
| 97 | + |
| 98 | + |
| 99 | +``` |
| 100 | + |
| 101 | +``` csharp |
| 102 | +// setup on the client |
| 103 | +builder.services.AddRemoteApiHttpClient("callApi"); |
| 104 | +``` |
0 commit comments