Allow "Blazor Web App" to run in Interactive Render Mode Webassembly in Lambda

[genifycom]

Describe the feature

In .Net 8 if you create a "Blazor Web App" with Interactive Render Mode WebAssembly you will get two projects. The Server side rendered project (SSR) and the client WebAssembly project (CSR).

If you convert this to a Lambda Application, then it runs correctly locally. When deployed to Lambda, the SSR part works correctly (as it is all generated on the server) but the Client Webassembly part does not (CSR).

This is because the Client tries to download the WASM files and runs into an issue.

In Chrome Dev tools -> Network -> WASM

It downloads 27 wasm files correctly but when it gets to dotnet.native.wasm it fails with a 500 error.

This file is in the wwwroot/_framework directory and dotnet.native.wasm is 2.78 MB (2,917,966 bytes) in size.

I supposed it is possible that this WASM file when converted to base64 exceeds what lambda can supply in a payload.

But after this 500 error, the rest of the WASM files do not download so the client web assembly application fails.

This is hugely disappointing since this only allows Blazor Web App SSR to run in lambda which is very limiting.

Use Case

Want the lambda function to use both SSR and CSR pages so that Webassembly can be leveraged from Lambda.

Proposed Solution

Increase the lambda payload to allow Blazor CSR rendering to run correctly.

Other Information

NOTE: This is not using Blazor Server at all. Only Server side rendering and Webassembly rendering. There are no web sockets involved at all.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS .NET SDK and/or Package version used

All most recent non-preview version.

Targeted .NET Platform

NET 8

Operating System and version

Windows 11

[genifycom]

Do you need any further information on this item?

[genifycom]

This really is a huge problem for us.

Blazor CSR can only be deployed in an S3 bucket which means we do not have the control over it like a Lambda process.
Blazor SSR Interactive is a non-starter because we cannot supply a websocket from the lambda function (and do not want to).
Blazor SSR is limited because we still need client side items for any interactivity.

AWS Lambda has been the most successful deployment strategy and we really do not want to have to give it up!

[genifycom]

Any further questions?

[genifycom]

I have finally been able to publish a Webassembly Dotnet application to Lambda but there are additional issues.

1. Using the standard {proxy} API Gateway resource, the .wasm files for the Blazor webassembly project all have the wrong SHA-256. I assume because the {proxy} route does not have pass through set correctly?

Here is an example Console log
Failed to find a valid digest in the 'integrity' attribute for resource 'https://xxx.execute-api.us-east-1.amazonaws.com/Prod/_framework/Microsoft.Extensions.Logging.wasm' with computed SHA-256 integrity 'LoFWSPAifjI8QJ1u07C0q1vuvKxs401ZPgwCc1xQS2Q='. The resource has been blocked.
The correct SHA-256 is '8BH+kQfjYuZWxprOICXJ4+tU0OdJOYDKN7G0S3zYYHI='
I assume because of no passthru, the return .wasm file is byte64 encoded and thus the SHA-256 is wrong? Any help here?

API Gateway does return the correct Content-Type as application/wasm

2. Probably because of 1, the Dotnet CLR wasm gets a too large message
   https://xxx.execute-api.us-east-1.amazonaws.com/Prod/_framework/dotnet.native.wasm
   "errorMessage": "Response payload size exceeded maximum allowed payload size (6291556 bytes).",
   "errorType": "Function.ResponseSizeTooLarge"
   This dotnet.native.wasm file is actually 2,663 KB and with passthrough this should not exceed 6291556 bytes

3. Additional files from Microsoft in the Lambda function such as
   https://xxx.execute-api.us-east-1.amazonaws.com/Prod/_framework/icudt_EFIGS.dat
   Gets a 404.
   For these .dat files, the Content-Type is application/json but it should be application/octet-stream

Can anyone suggest how to workaround these issue?

Thanks

[normj]

This was solved by adding wasm extension to the list of default content types for base 64 encoding by the Lambda function. #1794

[github-actions]

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.