using _storageId vs storing storage urls directly
How stable are the generated file storage URL´s, and could we rather than storing the _storage id field, just store the file storage URL from the start, like when a document is created and the file uploaded?
Asking this because, im wondering if we could simplify a bunch of enrichments we are doing when querying documents, and their related data?
13 Replies
@oscklm strongly recommend new projects implement their own http actions and don't rely on built-in storage urls
they have a lot of downsides, and we'll probably try to move away from them/deprecate them over time
biggest downsides are: (1) they are by design unauthenticated and they can't easily be retracted; (2) they can cause us (Convex) domain reputation issues when they're used to serve phishing content. this is bad for everyone b/c if
*.convex.cloud gets impacted by reputational issues, all convex customers can be affectedOhh that's very interesting, never thought about that.
So am i understanding correctly, that essentially we should make our own url endpoint, that resolves in some file ?? so we would expose our own convex httpAction endpoint like
domain.com/image/[_storageId].webp
But i actually have no clue how to implement something like that, like make a http endpoint that resolves a image.Serving Files | Convex Developer Hub
Files stored in Convex can be served to your users by generating a URL pointing
Awesome! Wow im very excited to check out this approach. Thanks for the quick reply 🙏
no problem
If #1 isnt a concern of the application, and the customer is on a paid plan with a custom domain setup, is #2 still a concern? Will the planned deprecation affect this use case or just shared convex.cloud customers?
yeah, we'll see -- it might be that as long as you set up domain aliasing and you're a paid customer, we don't limit this. it might be free accounts on
convex.cloud and possibly even convex.site
we haven't made hard decisions about this yet, and we'd definitely do it in a way that doesn't break any apps and/or gives an extended deprecation period etc
the slightly longer answer as to why http actions make a difference here (even without using a custom domain) is that convex.site is listed as a rehosting domain in some official registry, as is vercel.app things like that
so in theory we have better protection there in that if there is an abuse issue it's treated a little differently rather than "convex, inc. is serving this"
convex.cloud though is not
so serving arbitrary files there is a bit of a gotcha for us right nowThe position isnt unreasonable. I'm currently working on a file intensive application at the moment, so I'm interested in tracking your thinking and roadmap around this, as I'm debating where/how to host assets.
yeah, I think the whole game will reset in about 4-6 weeks when components come out
we have some CDN-wrapping components that are pretty sweet
Oh nice. I'll wait for that announcement.
@ballingt is actually building one internally that automatically gets your images into cloudflare and stuff
so all the APIs stay nice and convex centric, but the component takes care of relaying content into global cdns with resampling etc etc
Perfect. That's actually the direction I was leaning and was considering rolling my own.
Video is on my roadmap too, but can cross that bridge when i get there, as it has its own special pile of concerns.
Thats how I done it with Mongodb, upload to S3, and then generate url when requested by custom http endpoint, but it has its downside with few seconds delay, since it needs to request a url from AWS S3 and make the http redirection.