Few use cases?

[gijo-varghese]

Seems like an interesting project? Can you pls post some use cases?

In my case:
While making a coding test/interview its easy to give them an endpoint and tell them easily create a todo app, show a map from existing lat/lng in that json etc..

Any other ideas? What made you think to create this project?

Again, thanks for such amazing project. Make sure people won't misuse it. I've seen many projects like this closed due to hosting charges

[moeenio]

Building a simple networking site or anything, without paying and taking long time setting a database.

[millette]

It's pretty good for ephemeral services. For instance, I begun a meeting scheduler (where people vote on a best date and time), you can see an example here:
https://millette.github.io/kyucan/#evenement

With source: https://github.com/millette/kyucan

Basically, you setup the instance with a random endpoint. The first user creates an event with dates and we store that at a random endpoint (a subset of the instance endpoint), replacing the last 8 characters of the endpoint. Next, the first user can share a private URL containing those 8 characters (so we're sharing a smaller link). Finally, other users make their vote and it's all written to the same endpoint.

As the site admin, I don't know what events are created or even how many. I could probably iterate the whole space (the app endpoint and testing the final 8 chars) with some effort. Actually, anybody could do the same once they reach my instance since the endpoint is public (all client-side js).

Users could easily destroy or read all data for an event (they have the complete endpoint, no need to search) but only for the event they know about.

While not 100% secure, it still has its use.

Other measures to take would be to have the whole endpoint know only to a back-end so users can't guess it. And if that's not enough, you can run your own instance of jsonstore at a private URL and adapt it further if required.

[bluzi]

I personally feel like my own use case is not important, and I'm much more interested in reading stories of project maintainers who actually use jsonstore in their project, but I'll share the story of what made me came up with jsonstore anyway:

I was maintaining one of my other projects, TravisBuddy (https://github.com/bluzi/travis-buddy), which is a service that integrates TravisCI and GitHub by commenting on PRs if their build fails.

When the community complained about issues in TravisBuddy, I always found it hard to debug, mainly because it integrates two different services and I needed information from both of those services to see what went wrong, so at some point I decided to add intrusive logs, basically to keep the payloads from both services so I can review them later in case something goes wrong, so I looked for a logging service but all I found was paid services (I'm currently using logdna) and they never really suited my needs of well-presenting large chunks of JSON data (TravisCI's build payload) and persisting logs for a long while (mostly those services save your data for a week)

I was frustrated since I knew that all I really needed was a free/cheap JSON-based database, and that seemed pretty much trivial to me, and it took me hours and tons of registrations to find one that kinda suited my needs (Heroku MongoDB), so I decided it's too trivial and too easy to implement and I had to do it.

TravisBuddy doesn't relay on jsonstore after all, since I've found Heroku's solution before I made jsonstore, but if jsonstore existed then, it could save me hours, I could've just sent those payloads to jsonstore via simple HTTP request and that's it.

[GeorgeWL]

Basically should be only used for vanity projects where the data didn't really matter.

Or maybe for a quick throwaway way to fake a real API using fake data if you're mocking up an app.