search

aws / aws-lambda-dotnet

Libraries, samples and tools to help .NET Core developers develop AWS Lambda functions.
Apache License 2.0
1.57k stars 478 forks source link

AWS Lambda and Blazor server side #528

Closed genifycom closed 2 years ago

genifycom commented 5 years ago

Once we have DotNet 3.0 or 3.1 LTS running in Lambda, how will we we support Server Side Blazor.

In AWS Lambda, WebSockets are not supported and can only be implemented via the WebSocket interface for API gateway.

Since the websocket piece is hidden, then in its current form it will not work.

Will there be any solution for running Server Side Blazor in AWS Lambda?

klaytaybai commented 5 years ago

Linking your old issue for some extra context: https://github.com/aspnet/AspNetCore/issues/9522

normj commented 5 years ago

That is a good question about Blazor but I don't have the answer. I hope to research that soon and any input would be greatly appreciated.

msimpsonnz commented 5 years ago

Server side Blazor uses SignalR under the hood, the client connection state is stored in memory on the server. If the client connection is lost the session would need to be resumed and state would be lost, you could build a SignalR server but this is getting away from the desire for this to be serverless.

galvesribeiro commented 5 years ago

Just dropping my 2c. I would say that isn't feasible at all for serverless stacks like lambda. You need the server to keep the state in memory. The only way is if you "serialize" the state on something like Redis and implement a whole set of internal blazor components to get this state from there. I'm not sure Blazor currently would support that case. It goes way beyond just having the serverless websockets for transport (i.e. SignalR). It is a matter of state management which I believe isn't something modular right now on Blazor...

For serverless blazor, you still have an option for the client-side/webassembly mode (still in preview) which you can host on S3 and then use lambda as a "webApi" for it.

ehartford commented 5 years ago

Fargate

dharmaturtle commented 4 years ago

To augment the Fargate answer: https://youtu.be/UfPGdYbtDTg?t=2599

Slides: https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Developing_serverless_.NET_Core_on_AWS_WIN308-R1.pdf

classifieds-dev commented 4 years ago

Expanding on the idea of using a backplane Mass Transit provides a SignalR backplane that can be used as a work-around.

https://masstransit-project.com/advanced/signalr/

I was using that before I moved from containers to serverless suing aws api gateway.

SignalR backplane integrates with Redis. So I think it can ~easily be hooked up to elastic cache. I was using it with RabbitMq before I made the serveless switch over.

classifieds-dev commented 4 years ago

Its probably worth mentioning that using containers with an application load balancer is going to be far more expensive than using the web socket api gateway with lambda. Even just using the alb with lambda targets will be more expensive. This is especially true for those able to use the free tier for api gateway and lambda.

github-actions[bot] commented 2 years ago

We have noticed this issue has not received attention in 1 year. We will close this issue for now. If you think this is in error, please feel free to comment and reopen the issue.