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.
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.