Handoff cloud storage requests to server-less technology?

[crspybits]

There is a likely bottleneck currently with having all file requests routed through the SyncServerII server. Could we handoff long running cloud storage requests (e.g., file upload, file download) to something like AWS lambda? The suitable characteristic for using something like AWS lambda for this purpose is scaling-- any number of file uploads or downloads handled in this way should not interfere with the performance of the SyncServer.

I have a number of technical questions on this:

1) The reason I currently have these cloud storage requests routed through the SyncServerII is security-- e.g., I do not want to give person A's cloud storage creds to a mobile device being used by person B so person B can interact directly with person A's cloud storage. That could open up a world of hurt in terms of security-- if person B is a hacker and hacks out person A's creds. So, my question on this is: Can we handoff a request to AWS lambda in a secure manner? E.g., could set up AWS lambda so that it could only be accessed by SyncServerII?

2) Presumably requests have to be routed initially to SyncServerII (i.e., for basic user authentication from the client) with a subsequent handoff to the server-less system for long running cloud storage operations. I'm not sure how HTTP/HTTPS handles file uploads. Can we do this handoff to AWS lambda before the file data is completely transferred from the client to the server so we don't end up in the same bottleneck situation? E.g., does HTTP streaming support this? And vice versa for a download-- can we handoff the connection to the client to AWS lambda so that AWS lambda can download the file directly to the client?

3) In terms of development, programming and testing: Can you run a server-less architecture in something like Docker, purely for testing purposes? For example, I currently run SyncServer in a Docker container on my MacOS system to carry out test cases. I would want something similar, to run purely locally, for any server-less architecture addition.

4) Can you communicate from the server-less "instance" back to SyncServerII? SyncServer will need to trigger the call to AWS lambda-- e.g., to enable an upload from a client. Currently, after an upload completes SyncServer makes a change to the database (to mark the file as uploaded, or to deal with errors), before it responds to the client. So, either we need this after upload client communication, or we need to allow AWS lambda to communicate with the database, and respond to the client.

5) It would be simplest to use Swift. How to use that with Lambda?

See also: https://www.jeremydaly.com/10-things-to-know-when-building-serverless/ https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html https://github.com/jeremydaly/serverless-api-sample https://github.com/IBM-Swift/evolution/tree/master/Kitura https://gist.github.com/CMCDragonkai/6bfade6431e9ffb7fe88 https://theswiftdev.com/2018/02/21/how-to-build-server-side-swift-applications/

[crspybits]

Discussing this with Dany, it seems clear the concept of "handing off" an http request is ill-founded. HTTP requests will make use of an underlying TCP connection, which is a system object, which will not be transferrable from an EC2 instance to a lambda function.

[crspybits]

Dany has suggested using a technique to handle some download cases where we might get a short-lived and secure download URL from Google Drive. This would work if we can generate those URL's in an automated manner-- i.e., if there is a Google Drive API from which to generate such URL's.