Large response bodies cause hanging

[shockey]

Q	A
Bug or feature request?	Bug
Which Swagger/OpenAPI version?	2.0
Which Swagger-UI version?	3.4.0
How did you install Swagger-UI?	local dev server
Which browser & version?	Chrome 61
Which operating system?	macOS High Sierra

Demonstration API definition

Swagger 2 Petstore is sufficient.

Configuration (browser query string, constructor, config.yaml)

Default.

Current Behavior

As an example, GET /pet/findByStatus in the Petstore currently returns 1.8MB of JSON when all statuses are selected. This is a pretty big chunk of data, but Swagger-UI insists on rendering the entire body, which is neither performant or useful. The main thread of the application is locked for upwards of 20 seconds on my machine.

Possible Solution

Truncate or refuse to display large textual response bodies.

Context

GET /pet/findByStatus is my favorite operation to use when testing UI enums, so this is something that impedes me pretty regularly.

[shockey]

cc @webron, would appreciate a priority assignment

[heldersepu]

This is strange!
I swear I've used larger responses without any issues, let me see if I can make one up...

[heldersepu]

Here is my test:
http://swashbuckletest.azurewebsites.net/swagger/ui/index?filter=Huge#/HugeResponse/HugeResponse_Get
Yes we have a problem, even with 100000 it generates a 378K response that takes way too long

[heldersepu]

a quick fix could be not to display such a large responses, instead show something like github does on diff:
Large diffs are not rendered by default.

or truncate the body to 20000:

<ResponseBody content={ body.substring(0,20000) }
        contentType={ contentType }
        url={ url }
        headers={ headers }
        getComponent={ getComponent }/>

If we truncate the response will show: can't parse JSON. Raw result:

[heldersepu]

Profile-20171028T214335.zip
Attached is my performance profile I hope that can help troubleshooting.
something in react is taking too long
webpack:///./~/react-dom/lib/DOMChildrenOperations.js?568f

function removeChild(parentNode, childNode) {
  if (Array.isArray(childNode)) {
    var closingComment = childNode[1];
    childNode = childNode[0];
    removeDelimitedText(parentNode, childNode, closingComment);
    parentNode.removeChild(closingComment);
  }
  parentNode.removeChild(childNode);
}

[webron]

As @heldersepu suggested, I believe it's fair to limit the size that's being rendered, and if it's larger, make a link to download the result separately. This is not perfect though, as it means running the call again, and for some APIs it won't necessarily return the same result.

[shockey]

@webron, we'd be able to store the response string we already received, and allow the user to download it as a file - no second request needed.

As a proof of concept, see the Save as JSON/Save as YAML options in Swagger-Editor: we take the current editor content as a string and download it as a file, all from the client side.

[webron]

That's perfect then.

[heldersepu]

@shockey & @webron Love the solution! the download link will be awesome!

...but someone should try looking into why the slowdown
You guys don't know any react guru that can truly get to the bottom of the issue?

[webron]

In the past, we had issues with the syntax highlighter and large responses, but that doesn't seem to be the issue. I've tested the same API call in both Nightly and Chrome, and they both render fairly quickly (~3 seconds) when the format is JSON. When the format is XML though... that's when it explodes.

[shockey]

Okay, I dug into this a bit more, and @webron's note about XML is spot on.

When rendering XML, React spends a ton of time in the ResponseBody render function:

Everything else looks performant, so the good news is that our problem is contained to one component.

Doing a traditional profile on call stack times between clicking Execute and seeing the body revealed the true issue:

More than 95% of the main thread's time is spent parsing the whitespace-stripped XML that comes from the server into a pretty™ XML string. Even more specifically, this line appears to be the bottleneck: https://github.com/swagger-api/swagger-ui/blob/master/src/core/utils.js#L222

TL;DR: it's the formatXml(xmlStr) prettifier function in utils.js

[heldersepu]

I was looking at the formatXml function and that code smells funny...
Inside that function there is a section where we:

• create an array types
• loop over types populating results
• finally get the first one of result

It might be late and I'm missing something ...
...or that can be simplified, I'm sending you guys a PR