[toomuchtodo]

What's your take on developers not putting the effort forth to use their own object store (ie S3) for this?

I'm not against developer velocity (disclaimer: not a dev), but this seems to be a cycle where hosted tool comes out, people rely on it, tool becomes too expensive to run, neglected, etc, and then tool goes dark one day. Would time be better spent on client libraries that ease the difficulties of using existing durable storage systems? Or open source javascript frontends you can drop into your S3 bucket to provide a GUI for manipulating JSON in the same object store?

I am seeking enlightenment, not an argument. In tech for almost 20 years now, and have seen my fair share of the cycle.

[sowbug]

I believe your question is equivalent to the question of solving the tragedy of the commons, which suggests it's indeed a tricky problem.

As a strawman proposal, we could take some of Elinor Ostrom's suggestions for a non-governmental solution (https://en.wikipedia.org/wiki/Tragedy_of_the_commons#Non-gov...) and apply them:

1. Introduce the concept of an API key to allow users to voluntarily segregate the traffic into accounts. API keys are only voluntary because it's easy to extract someone else's key from a client binary and masquerade as that person.

2. Issue API keys only to users who agree to a set of community standards.

3. Nontrivial usage that still complies with the community standards requires payment. The payment should be structured so that it's reasonable for medium-traffic users to stay, but more economical for heavy-traffic users to leave the community and start up their own clone of the service. For style points, the community standards should have specified that anyone who starts with the free community service and graduates to hosting a clone must also host low-traffic free users, basically causing the service to become federated. Maybe the original service replies with 301 redirects to the new service so that old clients keep working.

I think all of this can be fully automated, and if you're cool accepting Bitcoin for usage above the free tier, then you don't even have to worry about how to handle payments. There are plenty of VPS providers that accept Bitcoin these days, so the system is even closed-loop from the perspective of the service operator.

[jsondata]

I built essentially what you describe a while back (jsondata.io if you're interested, though the certificate has expired and I've turned off the actual service for now). The idea was to make an infinitely scalable (within reason) solution that works well as a pastebin-style, no-setup-required data store for hacking on projects, but also as something that can scale with the needs of a business.

The architecture is built on AWS Lambda and DynamoDB, along with a small Ruby Sinatra service to handle payments and access control.

After running it for a while and getting some limited feedback from potential users/customers, I ultimately abandoned the project due to an apparent lack of interest. For hobby projects, it's fairly easy to spin up a self-hosted data store for low volume needs (or use one of the other free services). For anything more than that, a business is probably going to spend the necessary time/money to maintain a full DBMS or use something like Firebase.

I might be missing an opportunity (I've had thoughts about resurrecting the project), but for the time being, I'm just not convinced there is enough demand on the paying side.

[sowbug]

Part of the fun of prototyping is setting up your own service; at least, I always find that part fun. That likely eliminates some of the target market.

If the service API were fully standardized, and users paid for their own database, and signing up for a new website meant that the user granted controlled DB access to the site, then that might be enough impetus for developers to use a provider of the service. Maybe it could follow a Dropbox model where the first N bytes/month are free per user, and service providers pay affiliate fees to sites that recruit lots of paying users.

See also Attic Labs (https://techcrunch.com/2018/01/08/salesforce-acquires-attic-...).

[balls187]

> What's your take on developers not putting the effort forth to use their own object store (ie S3) for this?

Services like these are really geared towards the hacker mentality of getting prototype built as quick and dirty as possible. As the parent wrote--to focus on the app.

Using a durable source like S3 sounds good, but now you have the additional requirement of having an AWS Account. Granted the barrier to getting an AWS account is minor, but it is still is a barrier.

[mr_ali3n]

It's not just about efforts but it's more like the developer needs to maintain another piece of a service. I agree that uploading a simple Json file doesn't sound too complez to maintain but at a cost of you paying for S3 service with limited amount of features.