Spec generator integration

[alexdresko]

Would it be a good next step to write an ASP.NET Core middleware that generates the JSON spec file at a URL like /signalr_spec.json? You could them point the console application at the spec URL and it would spit out the TS.

I don't particularly care about Swagger documentation right now. I'm just looking for the .TS generator stack.

[RicoSuter]

To be clear: This whole project has nothing to do with Swagger or OpenAPI - it uses a new spec format which like Swagger/OpenAPI also uses JSON Schema to describe DTO schemas

[RicoSuter]

Yeah, I'd say we could add a new project SigSpec.AspNetCore with a middleware (like in NSwag.AspNetCore) which serves the spec JSON

[RicoSuter]

The question is if this is really needed or do we just need a packaged CLI with all this (like the NSwag CLI packages) so that you can process assemblies + produce TS

[alexdresko]

Sorry, I updated my original post. I meant /signalr_spec.json. I know it's not related to OpenAPI.

But the question about the middleware remains. If the middleware was added after app.UseSignalR, we'd possibly have all the configuration information we need.

[alexdresko]

The question is if this is really needed or do we just need a packaged CLI with all this (like the NSwag CLI packages) so that you can process assemblies + produce TS

I'm not super familiar with the nswag CLI. Are you referring to using reflection to pull the hub information? If so, I'm not sure that's all the information needed. Don't you need the "chat" in

            var document = await generator.GenerateForHubsAsync(new Dictionary<string, Type>
            {
                { "chat", typeof(ChatHub) }
            });

If so, I think the middleware might be required.

[RicoSuter]

If the middleware was added after app.UseSignalR, we'd possibly have all the configuration information we need.

I think SignalR still does not expose or register configuration (unlike ASP.NET Core which has the API Explorer).

So I think you'd still need to define the hub types + their names manually... maybe we can create a PR in SignalR to register/expose a SignalR metadata service (i.e. to enumerate hubs, etc.). I once checked and this shouldnt be much effort to implement...

[alexdresko]

I just spent a few minutes digging into the SignalR code and I don't know enough to determine the best insertion point for the change you're suggesting. It definitely doesn't look like they're exposing the configuration data, though.

Would you be interested in probing the ASP.NET team for the best approach? That'll save us from wasting effort. If you don't have time, I can create the issue.

Alternatively, here's my first thought... Technically, UseSignalRWithSpecGenerator (actual name TBD) could perform the app.UseSignalR configuration, eliminating the duplicate code here.

            app.UseSignalR(builder => {
                builder.MapHub<LogHub>("/logs");
                builder.MapHub<BadgeLogHub>("/badgelogs");
                builder.MapHub<DashboardHub>("/dashboard");
                builder.MapHub<AgentHub>("/agents");
                builder.MapHub<ReaderHub>("/readers");
                builder.MapHub<ReadPointHub>("/readPoints");
            });

            app.UseSignalRWithSpecGenerator(new []
            {
                new SpecHub<LogHub>("/logs"),
                new SpecHub<BadgeLogHub>("/badgelogs"),
                new SpecHub<DashboardHub>("/dashboard"),
                new SpecHub<AgentHub>("/agents"),
                new SpecHub<ReaderHub>("/readers"),
                new SpecHub<ReadPointHub>("/readPoints")
            });

[RicoSuter]

Yes, this would be the most pragmatic way to do it. UseSignalRWithSpecGenerator should also have a lambda parameter with a builder and the builder just inherits from the signalr builder + plus provide spec generator settings + output route settings

app.UseSignalRWithSpecification(builder => {
    builder.MapHub<LogHub>("/logs");
    builder.MapHub<BadgeLogHub>("/badgelogs");
    builder.MapHub<DashboardHub>("/dashboard");
    builder.MapHub<AgentHub>("/agents");
    builder.MapHub<ReaderHub>("/readers");
    builder.MapHub<ReadPointHub>("/readPoints");
});

[alexdresko]

Oooooo good idea.

[RicoSuter]

/cc @alexdresko created an issue in the SignalR repo: dotnet/aspnetcore#8320

[alexdresko]

Awesome, thanks! I hate I didn't do this earlier, but your depiction of what needs to be done is far better than mine. I gave the new issue some thumbs up, so let's see what happens.

[RicoSuter]

WIP: #15

[RicoSuter]

This would also be part of this
#21 (comment)

[RicoSuter]

For core 3.0 this can now be implemented, see also

dotnet/aspnetcore#8425