Uppy 1.0: Your best friend in file uploading

If you are a service selling a product targeted towards developers, I can't think of better marketing than something like this, where tons of users will use it for free, but many users (like me) who hadn't previously heard about your core product will find out about it through this.

EDIT: One thing to add about the marketing angle, another commenter mentioned that this was posted multiple times before reaching the front page, and some of the generic "Awesome! Will definitely try this!" comments here by low-karma users makes me think there is some astro-turfing going on. That said, I don't really mind it. Author created a useful tool, open sourced it, and I'm now glad I know about it. Kudos to him and if it helps more people become aware of his business (which obviously funded his creation of this open source tool) more power to him.

That could make our public coding efforts worthwhile financially. It’s a bit of a gamble. We’re believers/biased in part because we just enjoy working on oss, and in part because we’re quite a lean company and don’t need to make boatloads of money to make investors happy or anything (we’re bootstrapped since 2009, so no investors, and ramen profitable since 2012. Me and my cofounder are both devs and not in it to get yachts, but rather to have nice and rewarding work, basically)

Whether it really also becomes a financial success remains to be seen. 3y of devtime isn’t cheap so it'll be a bit sad if there is no ROI at all, but we'll comfort ourselves with the thought that we'll be able to provide a better and more reliable uploader to Transloadit's existing encoding customers (because going open has made these projects better thanks to exposure to more minds and environments), and making them very happy, even if there’s 100x more people that don’t make us money.

If you want to save money then yes, you could configure direct S3 uploading with Uppy, we do have better examples fot that these days (e.g. we now also show back-end code for signing the requests)

However it seems you got it working now so maybe no reason to change?

The Companion server used in the examples (companion.uppy.io) is really only meant for demo purposes and hence throws CORS errors if you'd try to use it for your own website.

You have three options:

1. Disable Instagram/Dropbox/Google Drive. Then you can use Uppy without any special server components (it'll just upload to your Apache server or S3 bucket)

2. Enable Instagram and friends but run Companion on your own server. It can be installed as middleware into an existing Express server, or run as a Standalone server on a different port than your webserver.

3. Use Transloadit's hosted Companion server. Requires a paid subscription (but also gets you hosted tus servers for upload handling, and our encoding platform, all of which are globally distributed)

I don't know if GCS is built into uppy at present (contrary to another comment, I don't believe GCS could be called "S3-compatible"), but I suspect there's a way to use uppy hooks to add it. As long as GCS also allows storage locations that allow upload only to signed time-limited URLs, the same approach could be used.

Where you put the file on the cloud storage and what you do with it is, I believe, not uppy's concern. But if you are for instance using the ruby shrine file attachment library (which is built out with examples to support uppy, and direct-to-S3, as a use case) -- shrine strongly encourages you to use a two stage/two location flow, where (eg) any front-end-uploaded things are in a temporary 'cache' storage, which on S3 you might want to use lifecycle rules to automatically delete things from if older than X. The files might only moved to a more permanent storage on some other event.

Once you get into it, it turns out all the concerns of file handling can get pretty complicated. But having the front-end upload directly to cloud storage can be a pretty great thing, depending your back-end architecture, for preventing any of your actual app 'worker' processes/threads from being taken up handling a file upload, dealing with slow clients, etc. Can make proper sizing and scaling of your back-end a lot more straightforward and resource-limited.

It's probably a happy problem if you end up worrying about S3 as a very DDoS-able part of your system.

Running up hosting bills is an scenario that can be addressed with various technical means (like a sibling comment explains). Many people seem to judge the risk * probability too small to put a lot of preemptive effort into it. It's basically a question of how much damage would be done until your monitoring catches it. AWS has also been known to "forgive" bills that were caused by malicious attackers in some situations.

1) You allow append-only access for the world, maybe in combination with an expiry policy. Indeed only useful for a few use cases I'd say

2) You deploy signing of requests, and you only sign for those who are logged in, or otherwise match criteria important to your app. A bit more hassle, and still requires server-side code (whether traditionally hosted or 'serverless'), but at least your servers aren't receiving the actual uploads, taking away a potential SPOF and bottle-neck.

That said, I'm not sure how serious you are about handling file uploads, but uploading directly to buckets often means uploading to a single region (on aws, a bucket may be hosted in us-east-1 for instance, meaning high latency for folks in e.g. Australia). This may or may not be problematic for your use case, but it did bring us complaints when we had that.

It would be nice if this can function as a point and click upload point and also a scriptable upload point for savvier users.

I'm afraid my Javascript is rather poor but I'll happily look at what it would take to create a plugin for Azure this weekend. Presumably the S3 multi-part uploader and associated companion server would be a good base to understand the flow?

[1]: https://docs.microsoft.com/en-us/azure/storage/common/storag...

This post was actually pretty interesting to read and I'm glad it finally made it to the front page.