Aspnetcore: "Api explorer" for SignalR

Created on 8 Mar 2019  路  9Comments  路  Source: dotnet/aspnetcore

Is your feature request related to a problem? Please describe.

In order to build tooling around SignalR - especially an API specification generator - we need access to the registered hubs and the paths. Currently there is no way to access this without wrapping the UseSignalR() call with an own method, e.g. UseSignalRWithSpecification() and "intercept" the MapHub() calls.

Is an "api explorer" feature planned for SignalR?

Describe the solution you'd like

As there can be only one SignalR registration I think there should be a singleton service/object in the DI system which can be retrieved to get the registered hubs, e.g. (all "pseudo code")

    public class SignalRHubConfiguration
    {
        private readonly Dictionary<string, Type> _hubs = new Dictionary<string, Type>();

        public IReadOnlyDictionary<string, Type> Hubs => _hubs;

        public void AddHub(string path, Type type)
        {
            _hubs[path] = type;
        }
    }

In AddSignalR() you'd register this config:

        public static IServiceCollection AddSignalR(this IServiceCollection serviceCollection)
        {
            serviceCollection.AddSingleton<SignalRHubConfiguration>();
        }

And in MapHub() you just register the hubs:

        public void MapHub<THub>(PathString path) where THub : Hub
        {
            ...
            _configuration.AddHub(path, typeof(THub));
        }

        public void MapHub<THub>(PathString path, Action<HttpConnectionDispatcherOptions> configureOptions) where THub : Hub
        {
            ...
            _configuration.AddHub(path, typeof(THub));
        }

After this, external libraries can get the list of registered hubs with just

serviceProvider.GetRequiredService<SignalRHubConfiguration>()

The code above is just to explain the requirements - naming and quality is bad :-)

Additional context

This will be used in a project like SigSpec and will provide Swagger-like experiences (e.g. generate an API spec on a HTTP route)

https://github.com/RSuter/SigSpec

area-signalr

Most helpful comment

All 9 comments

cc @bradygaster

@RSuter - with endpoint routing (3.0)+ you can enumerate anything that's routable by getting EndpointDataSource from DI. SignalR, MVC, grpc and more things plug in there.

It's not exactly API Explorer for signalR, but it provides what you're asking for.

@rynowak that is good. i'd be curious what details/metadata are available at that point. is it as descriptive about the request/response payloads and available endpoints as is OAI?

Nope! Nothing in life is free.

@rynowak With this EndpointDataSource I can also get the hub type? So it will be exposed and not just a generic handler around it?

To be clear, this whole SigSpec project is just a prototype/experiment I could quickly do because I already have all building blocks ready...

This whole api explorer stuff all feels like I'm doing the same mistakes as in NSwag again - namely implement everything reflection based and replicating the library's rules in the spec generator instead of using a proper api explorer... i.e. rules like this:
https://github.com/RSuter/SigSpec/blob/master/src/SigSpec.Core/SigSpecGenerator.cs#L77
or this:
https://github.com/RSuter/SigSpec/issues/5
should be provided by SignalR and not reimplemented in an external library...

Closing as the required scenario can now be supported in SigSpec.

Was this page helpful?
0 / 5 - 0 ratings