AddServerSizeBlazor should return a builder

This will make it more seamless to wire up scale out providers and other potential SignalR options. Today to wire up the service in preview 4 it looks like this:

services.AddServerSideBlazor().AddSignalR().AddAzureSignalR();

Alternatively, if we don’t want to expose the ISignalRBuilder then a more targeted builder might be useful if we want to add support for an AddAzureSignalR extension method anyways.

cc @rynowak @javiercn @SteveSandersonMS @danroth27 @bradygaster

[rynowak]

Discussed this in person with @davidfowl and we came up with the following plan.

This is a balance of:

• Having the correct branding
• Not leaking real implementation details
• Not hiding SignalR

note: The fact that we use SignalR isn’t an implementation detail. Users need to know about it and care about it. However the fact that we use a type named BlazorHub is an implementation detail and we intend to hide it and make it non-public.

ConfigureServices

We will keep AddServerSideBlazor() and make it return it’s own builder type. We’ll accept callbacks of HubOptions so you can configure the hub. Configuring options specific to the hub we use is valuable.

We won’t return the ISignalRServerBuilder. The other methods supported on that type are GLOBAL for all SignalR usage. We don’t want to give the impression that those options only affect Blazor. Those other options are also things like adding protocols or redis scaleout. It’s important that users understand SignalR to do that.

The AddAzureSignalR() gesture is the most important one, and it’s going away.

Examples:

Vanilla

services.AddServerSideBlazor();

With Hub Options

services.AddServerSideBlazor(options =>
{
    options.MaximumReceiveMessageSize = long.MaxValue; // #YOLO
});

With Redis

services.AddServerSideBlazor(options =>
{
    options.MaximumReceiveMessageSize = long.MaxValue; // #YOLO
});
services.AddSignalR().AddStackExchangeRedis();

Configure

We will add a marker interface to the convention builder returned by MapHub<>. SignalR and Server-Side-Blazor will each define it’s own concrete type that applies this marker interface. This allows us to define unique functionality via extensions for vanilla-hubs, all signalr, and the blazor hub.

app.UseEndpoints(endpoints =>
{
    endpoints.MapHub<ChatHub>("/foo").DoABarrelRoll();
    endpoints.MapServerSideBlazor().AddComponent<App>("app");
});

[SteveSandersonMS]

I’m not convinced that would help clarity. “SignalR Blazor” raises as many questions as it answers. It equally suggests “client-side Blazor that connects to a SignalR hub for whatever reason”.

There are lots of things that are different between the server and client hosting models. The term “server-side Blazor” encompasses all those and is the one thing customers have understood so far.

As for the Startup.cs code, I think either of Fowler’s options would be fine! I agree it’s good to maximise composability and not hide the SignalR config. Steve

---

From: Andrew Stanton-Nurse [e-mail] Sent: Saturday, April 13, 2019 4:07:33 AM To: aspnet/AspNetCore Cc: Steve Sanderson; Mention Subject: Re: [aspnet/AspNetCore] AddServerSizeBlazor should return a builder that derives from ISignalRBuilder (#9316)

SignalR Blazor

Ok, so maybe it’s because I’ve spent a lot of time working on it and have a fondness for it, but that really clicks for me.

[ideas are happening]https://camo.githubusercontent.com/0ce2cd0d27ed1c485743867b93e6753a65430ee5/68747470733a2f2f6d656469612e67697068792e636f6d2f6d656469612f64796445536576454f716f3962444f5342462f67697068792e676966

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/9316#issuecomment-482771136, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABDOMlC4kcdHuXXa4PgrQ-c7xNGPYvY0ks5vgUn1gaJpZM4crgJp.