Note that unlike FILE0, S3 not only charges for storage, but for write requests, read requests, network bandwidth, and some less obvious niche things.
So it's not a 1-1 comparison.
If you don't see the value in this extra convinience you should stay with your current service! The goal of FILE0 is not to replace these big players, but to provide an option to folks who just want to get things up and running quickly and don't want to think about infrastructure.
Lets say you become a huge hit and megaupload or vimeo or someone else with massive traffic (but not on the "we built our own datacenters and ISP CDN" level) start using your service. What then? Cloudflare will call you and demand you step up to an enterprise plan or pay for premium traffic.
Your pricing model assumes the pricing model of another pricing model that assumes pricing negotiation when usage increases. You will be the middle party in a discussion where you really don't control either party.
This is why I actually like AWS:es nickle-and-dime for every compute second and megabyte.
There are no docs. Once you create an account you will have a setup guide and will have a useful snippets section in your dashboard that contains everything you need to know about file0.
Yes. By default all your files are private and only you can access them. To make a public url you can use f0.publish('filename');
This returns a static url that you can share with anyone, and they can download the file.
This url will stay valid until the file is deleted or unpublished via f0.unpublish('filename');
If you call publish again, it will generate a new public URL.
FILE0 uses Cloudflare R2, and a thin layer of custom logic on top of that in form of CF workers.
The reasons for using R2 instead of S3:
- Pricing: S3 charges for everything you do. R2 is only for requests and storage. This enables FILE0 to only charge for storage-tiers which is much more understandable pricing model.
- Workers: Good fit for large-scale file-streaming. And the two works great together.
1. If you switch the default SDK you still need to understand S3 to some extent. At least creating buckets, bucket policies, IAM, CORS headers and a few more. The complexity of S3 comes from it's architecture, not the SDK. In fact I believe the v3 SDK of AWS does a good job at what it is.
2. Feature extensibility. This way FILE0 is not restricted by S3 API limitations. One example being: the AWS SDK doesn't support advanced filters for files (like ends with .png). This is a feature FILE0 has, but not supported by the s3 api.
3. If the goal is to provide a smooth DX, you cannot start with "Go to your aws account and create a bucket, and add this configuration to your bucket".
A package like this would be interesting but it's not what FILE0 aims to achieve.
Ends with .png is a bad heuristic though. If you want to be sure something is an image you should read it as an image, and then rewrite it as an image.
The webpage is a little bare-bones apologies. The setup instructions and tutorial appears when you create an account.
At the moment the client package is only for js/ts devs. The package is based on HTTP api calls so it shouldn't be a huge issue porting it to other languages, but obv it's challenging without public HTTP specs. If you're into implementing a wrapper I'd be happy to assist and share those details.
About costs. The is no information, because there is no egress fee. FILE0 is built on top of R2. They don't charge for egress, so neither you pay. File size limit is 5GB soft limit. This is set as a sensible default but can be increased on demand.
The main location is in us-east, and it's replicated around the globe. If the file already exists, it is overriden. Yes, all the setup guide and API-specific tutorials are visible in your dashboard after signup.
Assuming there wont be any egress fess forever on Cloudflare R2 is a bit risky IMHO if you read stuff like [0]. Especially if you build a product on top of it.
I was also reading this the other day, but right now they have the best offering on the market to serve as a base for FILE0. There are also alternatives out there, in case we get slapped with a 120k "offer".
The first step is to get to a scale where you piss off the Cloudflare sales team. FILE0 is far from that. Whenever that will be the case we can think about solutions, but this wouldn't be a good enough reason not to use them, and the free egress until we can.
But this library is supposed to also be a client-side library, right? I think as soon as you start doing all of the auth checks for CRUD, etc. it becomes almost as complex as the alternatives.
If the point is just a "everyone can do everything" bucket then that isn't too hard on any of the current blob storage providers.
I feel like the site is somewhat deceptive then... Using phrases like "Stop reading docs. Start shipping.", "As easy as using the localStorage." "Just 3 simple steps." implies something else.
What you are saying is that for actual usage I would need to
---
1. Read the docs for what access you provide by default (anonymous access, etc)
2. Build a backend api endpoint to do all AuthN/AuthZ checks, call your library to generate a token and then return that
3. (On the frontend) Make an API request to my backend, get the token. Call your library with the token to upload the file
4. (maybe think about revoking that token to disallow overwriting the file with the same token)
5. In other clients use your library to retrieve the file? Do I need to build a backend endpoint for tokens here too? If not do you have a way to handle non-public files?
---
My guess would be that whenever this service is used for real we actually need to deal with all of the details it supposedly abstracted away.
The hard part of blob storage has never been storage, it's all the parts that we imply when we say "blob storage". AuthN, AuthZ, permissions, versioning, backups, querying, partial updates, etc. etc. And for most "simple" use-cases you need one or more of those.
I'm not saying you could have made any of these parts any easier, but I think you pitch them as easier than they could be.
Cheers. The long-term plan of pricing is to only bill after storage-tiers.
The only reason there is no tiers, is because there are no customers with that need yet. But I hear you. I'm also sick of seat-based/bandwidth and a many other metrics providers charge us for.
Public API documentation is something many pointed out, so I consider adding some form of it. Appriciated.
Npm package is meant to be portable. It has 0 dependencies, and only utilizing API's that is widely available in any runtime.
And yes. you nailed it. It's backed by R2 and CF workers.
