Uppy: serverless example not working

[mikestaub]

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?

[kiloreux]

Hey there,

How are you deploying this exactly?

[mikestaub]

I simply followed the direction verbatim in the repo.

[superandrew213]

It won't work out of the box. Serverless just recently added API Gateway websocket support: https://serverless.com/framework/docs/providers/aws/events/websocket/#websocket

[superandrew213]

@kiloreux has anyone gotten uppy companion with serverless (api gateway + lambda) to work? Or was this just added as an example but not tested?

Websockets won't work with the current implementation. API Gateway also has a 30 sec timeout.

[kiloreux]

@superandrew213 I haven't seen anyone use it successfully AFAIK. Looking into it now.

[ricms93]

@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.

[dvins]

@kiloreux Are there any updates on this?

[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.

[joshmcarthur]

An update on this - @uppy/aws-s3 extends the XHR upload component which _does_ require websockets, so I deadended on this.

I briefly looked into the necessary patching to support websockets without requiring a particular URL structure (e.g. sending the token as part of the message rather than deriving it from the URL), but I couldn't make much progress.

I realise this isn't helpful, but I ended up making my own serverless function to accept a URL, fetch it, and add it to an S3 bucket, since this was the only use case my application needed to support.

[kiloreux]

Hey @dvins

It was fixed in https://github.com/transloadit/uppy/pull/1408

[kvz]

Since this was fixed I'll be closing this issue, do let us know if you disagree, then we can take a closer look

[apuntovanini]

@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

[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 ?

[dvins]

Just my two cents, but foregoing the reality of serverless adoption is inherent with its own risk. Moreover, in general we see something is amiss with the authentication pipeline given the errors we see from third party storage providers.

[kvz]

Valid concerns for sure, I'm sorry I was a bit brief earlier. I do hope to have a working serverless example, and i also agree if there are auth problems it might be telling of some underlying problem. On the other hand at least the long-running processes that companion requires might make it less suitable for many serverless environments.

But it really mainly comes down to resource constraints on our part, we have a handful of engineers working on Uppy, already allocating 80% of our revenue on open source, and we don't currently have a usecase for an uppy serverless example which proves to be a bit of a timesink for the already overworked crew. It's just hard to justify keep spending on that while there are still plenty other issues out there hurting our customer base/community users.

Hope you understand. We're a small bootstrapped company and while we often try, we can't always spend in all directions, even if all of those are valuable. And so I also don't mean to say serverless is useless, it's just probably not the thing we should spend money on _right now_. I'd be very grateful if the community would gather behind this and get it to a good place, but i don't want to keep advertising a broken example in the meantime so i'd rather officially deprecate it, maybe with the note that we're happy to accept community PRs to get it to a good place(?)