Earlier quoted context omitted.
This is classic feature bloat of a product that's been around for a while. Some customer wants a really niche feature so product adds a new option for it. It's just one new option so the experience isn't that different. Rinse and repeat hundreds of times and nobody stops the think of the cumulative effect on the 99% of customers who don't need those features.
> Rinse and repeat hundreds of times and nobody stops the think of the cumulative effect on the 99% of customers who don't need those features. Does it cost anything to not use features you do not need? Last time I checked, all the so-called niche features were stashed in hierarchical option lists, outside of the happy path. You need to purposely want to dig into, say, file access, bucket access metrics, storage stra…
Show HN: File0 – An easier way to manage files in serverless apps
81–90 of 158 posts
Re: Show HN: File0 – An easier way to manage files in serverless apps
#82But you don't need to master bucket policies, ACL, CORS, multi part uploads, content headers, CDN, or pre-signed URLs for what this is doing. There's a bit more boilerplate to set everything to the "I don't care whatever" settings, but that's because the "I don't care whatever" approach is usually not what you want for anything serious. I'm not sure how to use this from my Java or Rust projects. I also don't see any…
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…
Re: Show HN: File0 – An easier way to manage files in serverless apps
#83This looks sick! Thanks for building this!
Re: Show HN: File0 – An easier way to manage files in serverless apps
#84You're mixing up server side and client side.
Re: Show HN: File0 – An easier way to manage files in serverless apps
#85Earlier quoted context omitted.
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…
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. [0]: https://news.ycombinator.com/item?id=40481808
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.
Re: Show HN: File0 – An easier way to manage files in serverless apps
#86Why should this be a whole new product and not just a library around S3 sdk? You're mixing up server side and client side.
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.
Re: Show HN: File0 – An easier way to manage files in serverless apps
#87I like the part where you bulked up the S3 part unnecessarily and hid the extra stuff you needed for yours that S3 doesn’t need. Sorry, but your code examples are a flat out lie.
I disagree. Only an import statement is missing from both examples. Which parts is missing in your opinion?
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
Really? C'mon. It's YOUR examples on YOUR site.Regardless, that's not even what I'm worried about.
The part where you need a key for this service and don't need any of that for S3.
Sorry, but now that means I have to handle credentials with this service, which is something I like to avoid as much as possible.
Let's put it this way.
I can spin up an AWS instance right now and do
await s3lib.set('image.png');
and it works.But if I do:
await f0.set('image.png');
I also need to find a way to properly handle this extra token.And my issue with that is this:
const s3 = new S3Client({
region: region,
credentials: {
accessKeyId: accessKeyId,
secretAccessKey: secretAccessKey
}
});
You don't need that.But here is the fun part. Here is the AWS code you need to upload a file and have it available.
await s3.send(new PutObjectCommand({Bucket: 'my-bucket',Key: 'image.png',Body: myFile}));
And that's it. Full stop. No key to muck about with.versus
await f0.set('image.png', myFile);
But..., you also need to set the key, so.... SOME_ENV_VAR_FOR_YOUR_SERVICE=howeverlongthisisyouneedtomakesureitgoessomewhere node app.js
And, honestly, we know that's not even the same thing as what I have up there for AWS.Or...
const f0 = new File0({secretKey="howeverlongthisisyouneedtomakesureitgoessomewhere"})
await f0.set('image.png', myFile);
Or... const config = {
secretKey: "howeverlongthisisyouneedtomakesureitgoessomewhere"
};
const f0 = new File0();
await f0.set('image.png', myFile);
await f0.publish('image.png');
Listen, whatever. I'm tired of people being deceptive to try and sell products to programmers. I get it. You are after the lowest common denominator. Someone who actually doesn't know AWS, S3, or anything about Roles. Someone who could set that up in minutes. Fine, I get it. Convenience is real. Just own up to the fact that your examples are purposely bloated on one end and shamelessly thinned on the other end.You literally add extra stuff on the AWS side and remove needed stuff on your side. To me, that's a lie.
Re: Show HN: File0 – An easier way to manage files in serverless apps
#88Re: Show HN: File0 – An easier way to manage files in serverless apps
#89It suffers the usual effect as seen in eg. Wayland. You think the problem is simple and make a new protocol that's simple. Then you find complexity in the problem and solve it with complexity in the solution. Then your protocol becomes as complex as the one you're replacing. There are reasons S3 does all these things. ACLs, for example? How do you control who can access a file you uploaded? Also, it costs about 20 ti…
Is that really true about Wayland? I'm no expert on the subject matter, just a regular Linux user. From skimming the discussions, however, Wayland is touted as a simpler alternative to X because it comes without 25 years of baggage and bolted on things that turned X11 into a complex beast. Also, the security model of Wayland is often praised. All in all, I had the impression that while a lot of things are WIP, Waylan…
Re: Show HN: File0 – An easier way to manage files in serverless apps
#90Like the concept. Are you using S3 to store the file but abstracting the complexities and making it easier to use?
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.