serverless example not working

I tried deploying the example exactly as it, but when I try to upload my instagram photo the wss connection is immediately terminated and I see no upload progress. I don’t think lambda can support wss connections?

Here is the error:

WebSocket connection to 'wss://m6g8yvhwt1.execute-api.us-east-1.amazonaws.com/development/api/7a20ec32-7504-477d-9781-e6c60bdc1d80' failed: Connection closed before receiving a handshake response

Has anyone been able to get this to work?

[kvz]

I see, we added the serverless example as a courtesy but it seems to be a source of ongoing issues and a bit of a timesink for our engineers. With finite resources and no use for it on our part, I can’t really justify that we keep debugging this example. I’m happy to accept community contributions to patch this up, but until then I think we’d better deprecate and remove this example from our repo. Thoughts @arturi ?

[joshmcarthur]

I’ve investigated this and found that while API Gateway does support websockets, it does not support proxying all matching URLs the same way that HTTP Lambda Proxies do.

API Gateway websockets expect one of four events:

• $connect
• $disconnect
• $default
• A custom selection expression that has to exactly match.

The problem seems to be that even if you get the websocket support into serverless.yml:

functions:
  uppy:
    handler: index.uppy
    events:
      - websocket: $default
      - http: ANY /
      - http: 'ANY {proxy+}'

…this will still not correctly route the websocket connection correctly, as the Uppy client attempts to connect to wss://{host}/api/{token}, when API Gateway is expecting a connection on wss://{host}, with the token provided in the JSON payload of the websocket message.

I don’t think there’s a super simple solution to this. The @uppy/aws-s3-multipart plugin would need to change where it connects to the socket URL to connect just to the host, not to a custom path. This code is also in the @uppy/tus package and the @uppy/xhr-upload package. Probably an appropriate change would be to connect with the token as a parameter, rather than as part of the URL. I believe Uppy uses Socket.io to provide websocket connectivity, so I think parameters can be provided in the call to connect.

The companion code would also need to change. It currently extracts the token from the fullpath of the websocket URL, and it would instead need to fetch the token from the response URL.

The companion change could probably retain backwards compatibility by looking for the token both in the connection payload parameters, and by extracting from the URL. I’m not so sure that the client code could remain compatible with an older version of @uppy/companion though.

Interestingly, I have not yet found a dependency on sockets existing in the normal @uppy/aws-s3 plugin. I am currently experimenting with the use of this plugin to see if it works with a serverless-deployed companion instance, and will report back here if I have any luck.