Open Spiral1401 opened 4 years ago
RicoSuter
commented
4 years ago Correct, it’s like this to keep the complexity of the templates as low as possible. If this is a performance issue we should optimize the templates. But that’s not easy - for example what if one response (200) is json and another (eg 500) is binary? Then the request must be blob to cover both etc...
Spiral1401
commented
4 years ago Yeah I'm not sure what the solution would be, but I do think that there is room for a configuration option maybe. From what I am seeing in my application, forcing json response type has no downsides - I haven't had to change anything else about how I do things, and I'm seeing a noticeable performance improvement. Tested one of my API's throwing a 500 and the error came through no problem in my subscribe's error block. Any file download/upload I do is done outside of NSwag, though.
I just think this might be one of those things that those using NSwag may have not even noticed - the convenience of not having to write what interfaces with the backend kind of covering up that it might not be all that quick. Once people become accustomed to it, as long as anything isn't tremendously slow, and it's not immediately obvious where the slowdown is coming from - that just becomes the new "normal speed".
Is it a more common use case that people need the "handle any response" methodology? I'm not really sure how many people are in the same position I am. Just asking that the implications of doing it this way are considered. I know your library is very widely used and so it is probably difficult to design for everybody's use case. I definitely don't have the "big picture" insight of why everything in NSwag is the way it is.
And if the way I am forcing json is just the officially supported way, then that's OK. It just feels slightly hacky (based on the advice to not overwrite core templates) and so I wanted to discuss it and see if there are any obvious holes in what I am doing.
I'll attach the templates I am using for completeness (changed to txt to allow upload) - but there's not much to them. Thank you for your time.
So I've been troubleshooting some performance issues in my application (NG9 front, WebAPI back), and ultimately landed on the processing that happens by Nswag between the return of my API call (as seen in dev tools network tab) and my .subscribe({}) block as being a significant contributor. I'm not sure if it's the FileReader, or what part of the processing exactly is slow (though it feels like there's not a whole lot else happening, but I am not as familiar with the flow of that code).
So I ran through a few old Nswag tickets about this (#1692, #1497) and came up with two templates:
to convert my generated .ts services to use json responseType, and I have noticed a large performance improvement in the particular form that I had zeroed in on for testing, but also seemingly application-wide (harder to say because I wasn't really benchmarking the whole app, but it does "feel" faster). The time in between the network tab showing my call returning, and the data loading into my form is reduced noticeably. Response is not large, content length around 800-1000.
If I understand correctly, the idea with using blob is to streamline and simplify the generated code to handle any possible response type. But has there been any considerations toward the performance overhead of doing this? I sort of never even considered, until now, that there would be any noticeable overhead to it, but now I'm a little worried that this has a lot more impact than I would have expected.
Should I have any concerns about the methodology I am using to force json responseType? Aside from like... updates to the core templates not being transferred to my overwritten versions, and not supporting non-json (we don't really use anything other than json). Is there a preferable way to do this?