-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NSwag for SignalR #691
Comments
At least the DTOs can be generated for the hub API. But the operations (swagger) and clients (ts) must be different... |
Maybe also interfaces? public class ChatHub : Hub
{
public void Send(string name, string message)
{
// Call the broadcastMessage method to update clients.
Clients.All.broadcastMessage(name, message);
}
public IEnumerable<Message> GetAllMessages()
{
return _messages;
}
} [GeneratedCode("NSwag")]
interface IChatClient
{
public Task SendAsync(string name, string message, CancellationToken token = nulll);
public Task<Message> GetAllMessagesAsync(CancellationToken token = nulll);
} not sure however, how the operations could be described in swagger file |
I think swagger is not the correct format - and also it cannot be misused for that... But these endpoints are not really RESTful callable... |
The optimal solution would be to define a new specification (ie SignalRSpec) and write a new library which generates this spec and code for it using NJsonSchema (like NSwag does). |
Well, I guess this specification should be done by microsoft. What do you think? Should we request it on uservoice? |
Did you create a uservoice? |
Not yet. Would you? I will vote for it. Your voice may be louder than mine :) |
Are you/anyone still interested in this? |
Yes, I definitely am. |
Though I'm not 100% convinced this would fit within the Swagger scope. |
Nope, would be a new spec. But we could share a lot of code... |
Something like:
|
This would be only for SingnalR Core. My open questions:
|
I've created an experiment: https://github.com/RSuter/SigSpec I dont like the name, do you have a better name for it? |
I'm afraid I don't have the time at the moment to delve into this. I would really love to though. |
I'm interested in this as well. Has there been any further work done? |
There was no more work on this, but i'm open to push this further (SigSpec) |
SignalR Spec? BTW, I hope this will work with new SignalR for .NET Core (2.1) that will be released soon |
Yep, we have to upgrade the project to ASP.NET Core 2.1 but i dont see why it wouldn't work with the latest versions with some minor fixes... |
The bigger part is building all the tooling around that (CLI, etc.) but maybe we can just integrate it into the NSwag tooling so we can share all this infrastructure... |
I agree it should just be part of NSwag tooling. We use SignalR side by side with a Web API so generating client code for the whole API at once would be ideal. |
At once will not be possible as a web api is described by a swagger spec and a signalr endpoint by something else (eg signalr spec). Is it a requirement to share dtos? |
Sharing DTO could be achieved by feature known from good old WCF "Reuse type in referenced assemblies" what do you think? Or maybe we could optionally specify other spec files, whose DTO will be excluded, or included Alternatively, most powerful approach is the one used in EF Core, where you can specify assembly which will be used to scan for customizations, e.g. something like this:
|
The main problem is that we mostly dont know the referenced assemblies, but atm you can manually exclude dtos (ExcludedDtoTypes and AdditionalNamespaceUsages). I’m talking about the problem that the api and signalr endpoint might expose the same dto and thus it is generated twice (we have two independent specs). |
@RSuter: Is it a problem to define the assemblies in CLI argument? (Yes, i'm talking about the same problem) |
We don't need to reuse DTOs. I understand the underlying specs would be different, but if both were defined in the the same .nswag config file then the nswag tool should be able to generate clients for both in a single step, no? |
The problem is that ATM the .nswag file can contain only one pipeline and it is swagger based (swagger gen -> swagger spec -> code gen). So it has to be enhanced with multiple pipelines with support for other spec types... lot of work and possible breaking changes |
Ah, gotcha. Well two steps is not the end of the world. |
Should be doable... (we need an assembly param anyway to load setting extensions) |
I’d suggest to first upgrade the project to core 2.1 and improve the client generators, rename project and test it in a custom cli... |
Hi everyone! |
Hi |
@truthz03 , check out my comment from above. I have created a package that can help you just DISPLAY your hubs in SwaggerUI, not interact. As for the interaction with hubs via UI, my package does not offer this feature. |
Thanks for your answer. Yes I only need to display my hubs. "services.AddSwaggerGen" is only available if I use "Swashbuckle.AspNetCore" |
@truthz03 , it's a complementary package for Swagger. You need to install both Swagger and my package. Check out the documentation. And please toss a star for my repo on GitHub in order to support my work. Thank you! |
But to use your complementary pacakge I have to install "Swashbuckle.AspNetCore" otherwise I can't call "services.AddSwaggerGen". Or did I missunderstood something? |
@truthz03 , SignalRSwaggerGen works in combination with Swashbuckle.AspNetCore, so yes, you'll need to use it as well. You could configure it on a different path and have both Swashbuckle.AspNetCore + SignalRSwaggerGen and NSwag.AspNetCore. Please test if this works for you. I have never tried such scenario. |
Is there any latest news? |
metadata generation for SingalR hubs got some traction here: https://stackoverflow.com/questions/32638158/swagger-like-tool-for-signal-r-hub
I believe that at least the methods that can be invoked on the SignalR hub can be described by swagger, simmilar to WebApi.
Update by @RSuter: You can find a prototype for a SignalR generator here: https://github.com/RSuter/SigSpec
The text was updated successfully, but these errors were encountered: