swagger-ui-bundle.js (~1MB) file too big for hosting in AWS Lambda behind ALB

[DamianKedzior]

Q&A (please complete the following information)

• OS: client Windows / server: Amazon Linux 2, AWS Lambda
• Browser: all affected (it's a server issue)
• Version: N/A
• Method of installation: via Swashbuckle.AspNetCore
• Swagger-UI version: 3.25.0
• Swagger/OpenAPI version: N/A

Describe the bug you're encountering

This issue is related to size of the swagger-ui-bundle.js file. Currently it's close to 1MB which makes it not possible to host in AWS Lambda (behind AWS ALB - Application Load Balancer).
AWS ALB + AWS Lambda has a limit for files it can transfer which is set to 1MB which has been already reached when trying to serve swagger-ui-bundle.js file from version 3.25.0

This issue is to open the discussion about how we could potentially solve it, e.g.:

• is there a chance to decrease size of swagger-ui-bundle.js file?
• could we split this file into smaller chunks?

Expected behavior

SwaggerUI can be hosted in AWS Lambda.

[webron]

@DamianKedzior what size _would_ work?

[DamianKedzior]

@webron I am pretty sure current size of 974KB just passed the treshold. I used some older version where file size was around 956KB it was working fine.

[DamianKedzior]

So if there is a chance to add some additional minification or remove some not needed code it could make it work again.

[webron]

Thanks @DamianKedzior. Our general size check is for the bundle to be < 1MB (as part of our CI). However, it's been long enough since we last did a manual size audit, so it's probably time to do one again.

[DamianKedzior]

Hi @webron,
just wanted to follow up with you and ask if you have a plan in mind to address this issue?

[ronl]

Workaround - enable gzip response compression for mime type application/javascript. This will compress the bundle js file within .net core, thus greatly reducing the size and getting under the 1mb lambda limit. We do this also for json and other mime types in order to be able to provide much larger responses to our api clients than we could without it. They are required to specify the accept-encoding gzip, deflact request header.

Chrome and I assume other modern browsers will automatically specify the accept-encoding header when retrieving content. You can see in the response headers that the bundler js comes back as gzip and reduced to around 350kb.

services.AddResponseCompression(options => { options.Providers.Add<GzipCompressionProvider>(); options.EnableForHttps = true; options.MimeTypes = new[] { "application/json", "text/tab-separated-values", "application/javascript", "text/csv", "text" }; } );

[tim-lai]

@DamianKedzior I think @ronl has a good answer, and probably the most reliable long term answer. That said, there has been effort to reduce the bundle size as well as offer an es2015 bundle. The most recent release of [email protected] is ~960KB

[DamianKedzior]

Actually we did the same thing @ronl suggested some time ago and I forgot to post the workaround here :)

[rschiefer]

Added the startup code from @ronl but its not gzipping the file. Anything else others had to do?

[ronl]

Added the startup code from @ronl but its not gzipping the file. Anything else others had to do?

What browser are you using? If you watch in the developer tools, is it sending the request header "accept-encoding" with gzip and deflate?

[rschiefer]

yes

[ronl]

@rschiefer , on the IAppLIcationBuilder app, try ...

app.UseResponseCompression()

to enable