Skip to content
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

Open
Liero opened this issue Mar 22, 2017 · 39 comments
Open

NSwag for SignalR #691

Liero opened this issue Mar 22, 2017 · 39 comments

Comments

@Liero
Copy link

Liero commented Mar 22, 2017

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

@RicoSuter
Copy link
Owner

At least the DTOs can be generated for the hub API. But the operations (swagger) and clients (ts) must be different...

@Liero
Copy link
Author

Liero commented Mar 23, 2017

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

@Liero Liero closed this as completed Mar 23, 2017
@Liero Liero reopened this Mar 23, 2017
@RicoSuter
Copy link
Owner

RicoSuter commented Mar 23, 2017

I think swagger is not the correct format - and also it cannot be misused for that... But these endpoints are not really RESTful callable...

@RicoSuter
Copy link
Owner

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).

@Liero
Copy link
Author

Liero commented Mar 24, 2017

Well, I guess this specification should be done by microsoft. What do you think? Should we request it on uservoice?

@RicoSuter
Copy link
Owner

Did you create a uservoice?

@Liero
Copy link
Author

Liero commented Jul 17, 2017

Not yet. Would you? I will vote for it. Your voice may be louder than mine :)

@RicoSuter
Copy link
Owner

@RicoSuter
Copy link
Owner

Are you/anyone still interested in this?

@sandord
Copy link
Contributor

sandord commented Oct 21, 2017

Yes, I definitely am.

@sandord
Copy link
Contributor

sandord commented Oct 21, 2017

Though I'm not 100% convinced this would fit within the Swagger scope.

@RicoSuter
Copy link
Owner

Nope, would be a new spec. But we could share a lot of code...

@RicoSuter
Copy link
Owner

RicoSuter commented Oct 21, 2017

Something like:

{
    "hubs": { // the server side hubs => implemented on server, generated as ChatHub for client
        "Chat": { 
            "description": "Foo",
            "operations": {
                // dictionary of name/operation
            }
        }
    }, 
    "callbacks": { // the client side callbacks (dictionary of name/operation) => implemented as handlers on client
        "Send": {
            "parameters": {
                "a": {
                    "description": "First parameter.",
                    // ...JSON Schema
                    "type": "string"
                }, 
                "b": {
                    // ...JSON Schema
                    "$ref": "#/definitions/Foo"
                }
            },
            "result": {
                // ...JSON Schema
            }
        }
    }
    "definitions": {
        ...
    }
}

@RicoSuter
Copy link
Owner

This would be only for SingnalR Core. My open questions:

  • Are the callbacks per hub or global (as in the sample)
  • How can we determine the callbacks - is there an interface for them on the server?

@RicoSuter
Copy link
Owner

I've created an experiment: https://github.com/RSuter/SigSpec
Just start SigSpec.Console...

I dont like the name, do you have a better name for it?

@sandord
Copy link
Contributor

sandord commented Oct 24, 2017

I'm afraid I don't have the time at the moment to delve into this. I would really love to though.

@MgSam
Copy link

MgSam commented May 21, 2018

I'm interested in this as well. Has there been any further work done?

@RicoSuter
Copy link
Owner

There was no more work on this, but i'm open to push this further (SigSpec)

@Liero
Copy link
Author

Liero commented May 24, 2018

I dont like the name, do you have a better name for it?

SignalR Spec?

BTW, I hope this will work with new SignalR for .NET Core (2.1) that will be released soon

@RicoSuter
Copy link
Owner

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...

@RicoSuter
Copy link
Owner

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...

@MgSam
Copy link

MgSam commented May 24, 2018

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.

@RicoSuter
Copy link
Owner

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?

@Liero
Copy link
Author

Liero commented May 25, 2018

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:

public class MyCustomDesignTimeServices : IDesignTimeServices
{
    public void ConfigureDesignTimeServices(IServiceCollection services)
    {
        services.AddSingleton<IPluralizer, HumanizerToIPluralizerAdapter>();
    }
}

@RicoSuter
Copy link
Owner

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).

@Liero
Copy link
Author

Liero commented May 25, 2018

@RSuter: Is it a problem to define the assemblies in CLI argument? (Yes, i'm talking about the same problem)

@MgSam
Copy link

MgSam commented May 25, 2018

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?

@RicoSuter
Copy link
Owner

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

@MgSam
Copy link

MgSam commented May 25, 2018

Ah, gotcha. Well two steps is not the end of the world.

@RicoSuter
Copy link
Owner

Is it a problem to define the assemblies in CLI argument?

Should be doable... (we need an assembly param anyway to load setting extensions)

@RicoSuter
Copy link
Owner

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...

@Dorin-Mocan
Copy link

Hi everyone!
If anyone still interested in this topic, please take a look at this solution for generating Swagger documentation for SignalR hubs(.NETsupport only):
https://github.com/Dorin-Mocan/SignalRSwaggerGen/wiki
https://www.nuget.org/packages/SignalRSwaggerGen/

@truthz03
Copy link

Hi
Is this feature dead?
It would be really nice to get SignalR Hubs inside the an ui like the SwaggerUI to be able to test SignalR connections

@Dorin-Mocan
Copy link

@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.

@truthz03
Copy link

@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.
Is your link above for NSwag because there is no "services.AddSwaggerGen" method available?

"services.AddSwaggerGen" is only available if I use "Swashbuckle.AspNetCore"

@Dorin-Mocan
Copy link

@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!

@truthz03
Copy link

@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".
I don't want to use "Swashbuckle.AspNetCore" because I use "NSwag.AspNetCore" and call "services.AddOpenApiDocument".
If I add both packages "Swashbuckle.AspNetCore" and "NSwag.AspNetCore" both will serve the web ui on "/swagger" so I have to use 2 different paths. One for the RestApi and "NSwag.AspNetCore" and another for "Swashbuckle.AspNetCore" where I will see ther SignalR Hubs and all RestApis

Or did I missunderstood something?

@Dorin-Mocan
Copy link

@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.

@Varorbc
Copy link

Varorbc commented Nov 17, 2023

Is there any latest news?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants