Swagger-editor: Swagger editor slow for swagger json with > 10000 lines

[niculistana]

| Q | A
| ----------------------------------- | -------
| Bug or feature request? | Bug
| Which Swagger/OpenAPI version? | 2.0
| Which Swagger-Editor version? | v3.1.8
| How did you install Swagger-Editor? | npm install
| Which broswer & version? | Chrome Version 61.0.3163.100
| Which operating system? | Mac OSX 10.11.6

I can't post my swagger configuration here since it's really long (over 10k lines).

[shockey]

Hi @niculistana!

You can use http://gist.github.com/ to share your definition, or email it to me (email is in my profile). Without it, there's not much to work with.

[cabbonizio]

Hey guys I did notice some the same thing for our Swagger spec which has just under 10K lines. We have a lot of different model objects and since the models are expanded by default it stresses out the browser trying to scroll through documentation in the Swagger Editor. Once I'm able to scroll down to the models section and collapse it, scrolling through the API operations is much faster. For starters, it would be nice to collapse things by default or introduce configuration to allow the editor to do so for models and for operations or both. I believe something similar was done with Swagger UI.

[shockey]

@cabbonizio, you can pass any valid Swagger-UI configuration item to Swagger-Editor, and it will hand off the value to the underlying Swagger-UI instance :smile: Setting docExpansion: "none" or defaultModelExpandDepth: 0 should help with your specific issue.

[cabbonizio]

Thanks @shockey will give it a shot! This would be very helpful

[cabbonizio]

@shockey works perfect! I have a devOps team member who is going to spin up a local version of the editor at our company, is there some parameters we can pass in the Docker file to set the docExpansion?

[shockey]

@cabbonizio, let's continue this discussion in #1547 😄 I left some notes about the current state of Docker configuration there.

[cabbonizio]

@shockey sure thing. See you over in the new issue just opened :)

[niculistana]

@shockey Let me ask around if I can send over the swagger spec to you. In the meantime would you be able to share how to profile or optimize a swagger spec?

[shockey]

@niculistana, profiling is mostly done by using JavaScript and React.js performance tools to analyze the application. If you're interested in going that route, I can point you in the right direction.

As for optimizations... you _could_ make your definition less complex by minimizing $ref usage.... but that makes for a bad user experience.

There's a lot of moving parts in the Editor (which also uses Swagger-UI and Swagger-Client under the hood), so performance debugging could turn into quite the rabbit hole. The best way to speed up your definition, IMO, is to help us reproduce the issues you're facing. We're aware of many things we could do to improve performance, but with our limited resources we prioritize based on what users report.

If your definition is proprietary, you can email the definition to @webron and I privately. Alternatively, you could provide us with a link to a secret Gist you control that includes the definition. I understand sharing it may be out of your control, but without a definition there's not much we can do from our end.

[niculistana]

@shockey I e-mailed you and @webron our swagger spec. Most of our swagger 2 spec is autogenerated by springfox. By design our spec requires a lot of refs, which does cause the performace bottleneck. An approach that I came up with was to separate our swagger definitions in many different (and smaller) files which is rendered as separate api groups. This may be the best move moving forward without having to remove refs.

[shockey]

@niculistana my apologies! I have seen that email, I just didn't put two and two together here 😄

As Ron mentioned, we did look at your definition, and found the bottleneck to be in Swagger-Client's dereferencing plugin, which takes ~30 seconds to run. This appears to be the source of the lion's share of the slowness you're seeing.

We do know of ways to improve that area of Swagger-Client, and the level of slowness there puts it pretty high on our performance todo list, but I can't give an ETA on it being fixed.

In the meantime, reducing your $ref density and splitting your definition into parts is a good stopgap measure.

[niculistana]

@shockey Thanks for the input. In the meantime I will experiment with ReDoc, convert our spec to Open Api/ Swagger 3, and try to remove refs. Cheers!

[shockey]

Update: https://github.com/swagger-api/swagger-js/issues/1150 is likely a fix for your issues, @niculistana 😄

[shockey]

Closing due to inactivity.

This is simply to keep our issue tracker clean - feel free to comment if there are any further thoughts or concerns, and we'll be happy to reopen this issue.