uppy: serverless example not working

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 ?

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.

@kvz I don’t think it’s solved, the example runs < 1.0 @uppy/companion package, and seems not to work with default configuration. In particular:

• external providers (Google, Dropbox) always return Forbidden at the end of the authentication process (but this might be also configuration errors - in these case probably some docs would be helpful)
• url package returns error: “Socket.js:11 WebSocket connection to ‘wss://tgt7qn1t68.execute-api.eu-west-1.amazonaws.com/dev/api/bf40aaeb-8dbd-4b2b-9edb-90436dbff87a’ failed: Error during WebSocket handshake: Unexpected response code: 404”. This seems related to what @joshmcarthur reported: ws address is different with AWS lambda

ServiceEndpoint: https://tgt7qn1t68.execute-api.eu-west-1.amazonaws.com/dev ServiceEndpointWebsocket: wss://7jneezqms3.execute-api.eu-west-1.amazonaws.com/dev

@kiloreux @superandrew213 I am facing the same issue with companion + API Gateway + AWS Lambda. Despite trying to add the websocket event in the serverless declaration, I keep getting the wss socket error; with the difference that the error is thrown during handshake.

WebSocket connection to 'wss://upload.dev.kabiar.com/api/49af61ab-ceeb-4740-b497-d4559e756ed2' failed: Error during WebSocket handshake: Unexpected response code: 404

Is there any update on this? Thanks for your help.