Websocket support
Since maintainers probably won't get notifications for closed issues, here's a new issue.
Why doesn't SAM CLI support APIGateway websockets?
https://github.com/aws/aws-sam-cli/issues/896
@seshubaws Could we get an acknowledgement from AWS about this? This is a big deficiency in development tooling for using AWS. Have any product managers taken a look at #896 since it was closed 2.5 years ago? Thank you for anything you can do to help the cause!
Hi @adamdicarlo0, thank you for reaching out! I will send this over to a product manager so they can help us take a look and prioritize. I will update you with any info I get back.
Hi @adamdicarlo0 , thank you for reaching out. We will look into the request and follow up with more details as soon as we have an update.
A question about this request @adamdicarlo0 . Currently WebSockets APIs are not supported as SAM resources, so the only way to have WebSocket APIs is to define them manually using CloudFormation resources (AWS::ApiGatewayV2:: resources, not AWS::Serverless:: resources).
When you ask for support for Websockets: do you mean just local testing support for the WebSocket APIs defined with AWS::ApiGatewayV2 resources? Or do you expect to have a AWS::Serverless::WebSocketApi resource first? (and to support that use case to test locally)
@valerena I don't think I've ever used CloudFormation. I use SAM's experimental Terraform integration to define resources. So all I can say is, I want the WEBSOCKET APIGateway I've defined in Terraform to be emulated by sam local start-api (or even by a separate command, like sam local start-websocket-api).
It’s really frustrating that this still isn’t supported, and we haven’t even received an update on whether it’s coming. What makes it worse is that this should’ve been a relatively simple implementation. The real issue stems from the team's reliance on Python.
The HTTP API should have been deployed as a container system, and this component should be as well. Emulating the gateway directly in Python was a mistake—it should’ve just handled setup tasks like generating config files, then launched a Docker container or a Kubernetes service to handle the actual workload.
I just wanted to comment here as another engineer running into this issue and address the specific question @valerena asked a few weeks ago. I admit I'm not a CloudFormation expert and I'm still a little unclear on what makes the AWS::Serverless namespace treated differently from others. In my case, I am trying use the same YAML template for both local development with sam local and my actual deployments. For my websocket, I am defining it currently using AWS::ApiGatewayV2::Api simply because AWS::Serverless::Api doesn't support websockets.
So for me, if either sam local supports the AWS::ApiGatewayV2 namespace or AWS::Serverless::Api supports websockets, doesn't really matter much. As long as, whichever way it is, that same configuration could be used when actually deploying to AWS with sam deploy, that would work perfectly.