Using Swagger in Angular [closed] - asp.net

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am new in Swagger and as far as I see it is used to generate API documents autotomatically. In addition to that, I think it is also used to generate frontend by using Swagger Codegen. AT this step, I am confused regarding to using swagger in my project properly.
I have created my backend using .NET Core and API methods are ready. Now, I need to integrate swagger to my project. I have an initial Angular frontend app, but as the code is mixed, I want to create frontend from stratch and then integrate Swagger to it. So;
1. Should I generate frontend using necessary Swagger tools? It does not seems to be good, but if it is used generally and will not be a problem as the project gets bigger, of course I can use that option.
2. If I create the Angular project from stratch, how can I integrate the swagger? Should I generate code by using the ts files of the related components?
3. If I add a new component to the frontend and corresponding API methods to the API where Swagger is already used. Which modification ahould I made? I gave a try and it geneartes a new swagger config file after building the project.

Answer 1

Going off on the comments I made below the question.
Just to clarify what swagger and openApi is, swagger is both a rest api specification (e.g. swaggerSpec.Json) and a set of tools to deal with the specification. For example, swagger codegen, swagger UI etc. Now at some point in time, the specification was renamed from swagger to OpenApi.
This means the specification is called OpenApi and swagger is a set of tools to deal with openApi.
Source: https://swagger.io/blog/api-strategy/difference-between-swagger-and-openapi/
Aside from swagger, there are a set of alternative tools like NSwag and Swashbuckle that can make working with the openApi specification easier.
There are 2 main parts:
Code generation for the openApi specification. You can generate code for the server (e.g. ASP.NET core rest controllers) from an OpenApi document and clients (e.g. C# rest clients, .TS rest clients, java you name it) from the OpenApi document. Or you can just generate the OpenApi specification (my SwaggerSpec.json) itself from e.g. your .net core project with some tooling.
(Web)Ui to easily host documentation. Swagger has webUI, NSwag, and even alternative tools like https://github.com/Redocly/redoc All of these include a way to easily test the Api endpoints you define. Generally these documentation sites are standalone things. They maybe configured style-wise but you generally leave them untouched. You can ofcourse roll your own - or clone any ui repos and alter that - but thats another topic.
I've investigated all 3 options (Swagger, SwashBuckle and NSwag) and i opted for NSwag because at the time a) it was the one i got working and b) it had the most features and c) the community was fairly active. This was about a year ago.
I shall explain my workflow and this should answer most questions you have. I feel like this Question is getting rather broad, so please do some digging around and try to get more specific questions tailored to your needs.
Like i said i use the NSwag toolchain:
I create Asp.Net controllers in my server app.
This contains some attributes to controller functions/endpoints so the swagger specification gets generated better:
I then use NSWag studio to create an openApi document file
Output:
At this point you could opt to use NSwag again to generate for example a typescript client which you can then use in your angular/react w/e frontend project:
I then add the swagger document to my asp.net server project, and enable the swagger UI:
Somewhere in Startup.cs:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env, IOptions<AppSettings> appSettingsAccessor, ILogger<Startup> logger, StaticFileConfigSection staticFileConfig)
{
// Add the openApi document and serve the swagger dashboard.
app.UseOpenApi();
app.UseSwaggerUi3(); // serve Swagger UI
...
And I can then go to /swagger to see the web ui:
And that's it. All these tools can be automated ofcourse - but i opted not to. Getting that to work can be a hassle and with NSwag studio i was always a button click away anyways. And this forced me to be more careful with my work.

Answer 2

Using Codegen is your choice. You can use the generated code as a boilerplate to have a straight start with your API integration. You may just copy the generated models and services and integrate them. It will save you a lot of coding time and also avoid human error in the coding of the services. But the rest of the frontend can be anything you like, not necessarily the generated project. You may use for example an Angular seed of choice and just integrate the services from Codegen.
As I've mentioned, you can copy the generated services and models from Cogeden, to have a head start. If you decide to go fully manual, you'll have to use Angular HTTP to make the requests to the server (https://angular.io/guide/http). You have to manually define the models and the services to operate with the entities. Swagger will only be a reference for the API in this case, no integration at all with Angular. I discourage this option unless the library generated by Codegen is insufficient. If the Swagger design is properly done (which sadly is uncommon to see), following all the standards and providing complete data models, you can trust the generated library.
This is advice and not objective guidance: if the updates to the API are minor, make them directly in your code and keep your Swagger updated with the new changes. If the changes are relevant, you need a new major API version, with a different endpoint. In that case, generating a new Swagger Codegen library and placing it in place of the old one will be a good idea. To be able to do this, you must avoid modifying the internals of the services of the generated library, using the library as much "as-is" as possible.