4 ms·

(Background: nearly 2 years of working with GraphQL in production) I tend to think uploading files via GraphQL is an anti-pattern. The downsides outweigh the b

(Background: nearly 2 years of working with GraphQL in production) I tend to think uploading files via GraphQL is an anti-pattern. The downsides outweigh the benefits over just using presigned URLs. Advantages: * Possibly simpler to get a simple case up and running * No need to use a file store that supports presigned URLs * Can perform processing of files during upload. Disadvantages: * No progress events during upload, so you can't show a progress bar * A GraphQL server wants to be as lightweight as possible, and not keep requests open for long. The common resolution strategies tend to involve creating a lot of file descriptors, dealing with files in the form of base64 strings or attachments is asking for trouble. * Simplicity benefits don't last long. * Perceptively slower for clients.

mengledowl 9y ago
Do the downsides still outweigh the benefits when you consider having multiple clients, especially when they might include mobile apps? If something changes about how I'm doing file uploading (eg. moving to a different file hosting provider), I really don't want to have to deal with the implications of making that change in multiple places, especially when it comes to a mobile app where you can't control what version people are running.
- zackify 9y ago
  This isn't viable for large files. First uploading to your server, then through to S3. It will take a long time. Have your api return the upload url and then when you switch providers, instead use their signed url? AWS and Google you just PUT to the url, shouldn't change anything. Then hit your own api after it finishes
- andrewingram 9y ago
  The pattern i'm suggesting is how most mobile apps i'm familiar with work anyway. Though some have made the mistake using an AWS SDK in the client, rather than just using presigned URLs. Basic pattern is: Client: Hey API server, I want to upload a file API: Sure, here's a URL you can PUT the file directly to. It will expire in 10 minutes, you can always ask for another if you run out of time Client: Thanks! -- Client uploads file directly to URL --

mengledowl 9y ago

Do the downsides still outweigh the benefits when you consider having multiple clients, especially when they might include mobile apps? If something changes about how I'm doing file uploading (eg. moving to a different file hosting provider), I really don't want to have to deal with the implications of making that change in multiple places, especially when it comes to a mobile app where you can't control what version people are running.

zackify 9y ago
This isn't viable for large files. First uploading to your server, then through to S3. It will take a long time. Have your api return the upload url and then when you switch providers, instead use their signed url? AWS and Google you just PUT to the url, shouldn't change anything. Then hit your own api after it finishes
andrewingram 9y ago
The pattern i'm suggesting is how most mobile apps i'm familiar with work anyway. Though some have made the mistake using an AWS SDK in the client, rather than just using presigned URLs. Basic pattern is: Client: Hey API server, I want to upload a file API: Sure, here's a URL you can PUT the file directly to. It will expire in 10 minutes, you can always ask for another if you run out of time Client: Thanks! -- Client uploads file directly to URL --