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?
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 :-)
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)
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.
FYI we have https://github.com/aspnet/AspNetCore/issues/7783 for the metadata
@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...
@RSuter take a look at https://github.com/aspnet/AspNetCore/pull/8425
Closing as the required scenario can now be supported in SigSpec.
Most helpful comment
FYI we have https://github.com/aspnet/AspNetCore/issues/7783 for the metadata