Looks useful. I really dislike the "Download Postman and then you will have documentation" approach. Documentation lives on the web, and there are better alternatives to Postman anyway.
I'm so excited to finally be able to share this with you!
Pantry is a free cloud storage service that I've been building for the past few weeks. You can use the API to store & retrieve data for you and your users online for free.
Looking forward to seeing what you all think of it, and please feel free to post suggestions or AMA.
You are right, and all of your points are valid. I will definitely be looking into drafting some documents revolving around data integrity and privacy.
As for the prevention of misuse, I've added a data limit per basket and a limit of baskets per Pantry.
If you have any ideas or suggestions - I'm all ears.
I shared a free JSON API with parse.com with a bunch of friends to develop a set of FOSS CLI apps we communicated over.
It was all open and fun and funny.
Then parse.com shutdown. https://en.wikipedia.org/wiki/Parse_(platform) -- What started out as fun project for several developers turned into a dead project for us all, which by then had hundreds of users around the world, who were now getting errors instead of fun.
We all used different programming languages, nobody was able to re-engineer all of our clients into a new endpoint/api. My takeaway -- any one of us could have hosted the JSON api, but we made the mistake in thinking we would use a free 3rd party service. That decision killed the project.
One thing I'd express, is many people launch cool things without a monetization plan, become popular largely because their free, and then lose everything they built when they realize to monetize effectively they have to "alter the deal".
Beware of Vadering your project: Figure out what you can charge for early, and never offer it for free.
I’d say don’t over think it and don’t quit your day job. But I also assume you’re not pouring money into this. Stay free as long as you can, it gives you data so build out some usage stats, talk to the highest volume users. Figure out what threshold they become willing to pay and how much. Then, ask them to pay because they might have just lied to you.
- How would you sell me on Pantry vs. AWS S3? (You can use S3 in much the same way ... throwing up JSON at a path and fetching it. The cost some would argue is neglible)
- How do you deal with CORS?
- How do you deal with authentication?
Is this intended to be like the take a penny leave a penny jar? You put stuff here knowing anyone could come and destroy it at any time?
I did not sign up, I am only going off your API docs.
Is this question really appropriate? The developer is sharing a pro bono offering, where does selling anyone on it against a commercial service even come into play?
It looks like a project that must have been fun to make and could be useful for storing non-sensitive data with very little hassle. Long bucket IDs appear to leave little chance for name collision.
If you are building a piece of software that deals with anything remotely like PII or has specific availability requirements, I sincerely hope this is not something you are seriously considering (otherwise, pardon me, I hope I won’t be your user or customer), starting from the fact that you aren’t paying for it and there is no SLA.
Of course it’s appropriate! From the docs this service doesn’t even meet the “viable” part of MVP! Ok a user can post some json that’s public (no authentication) and doesn’t even work across domains (CORS).
Suppose adding those things and targeting “mobile backend as a service” or even more general “backend as service” there is still a lot to be desired. Like static html, ok you’re competition is Firebase.
We’re talking welcoming a stranger sharing the result of their work with “but what are the benefits of your free solution over megacorp Z’s paid offering Y?”.
This is definitely been a learning experience for me, and I'm really not sure what the future holds for the project.
CORS was/is an issue that I've yet to fully figure out, if you have any ideas please share - I'd love to learn.
Authentication is something that I've delebratly avoided as I feel Pantry should not be used to store sensitive data, nor should it be ever used in production. It's for POC's, hackathon projects, and should be used as a development tool for rapid prototyping.
Please let me know if you have any suggestions, and please feel free to submit PR's if you'd like!
Let the user register a site when they create a UUID (Account). You are not storing private data. Let the user make cors request using the UUID as an authorization token. If the website and the UUID match, the server responds with the content.
Hi, found an earlier comment of yours mentioning you changed to being a hotel owner. We make a free hotel PMS -- would you like to get in touch and see how we can make it better for you? https://hoteliera.com/
I've done something similar for some of my students to test restful apis at http://mockrest.com.
It is quite similar to this although you just write your own data on a textarea, and get/post/put/delete to modify it.. Then you can copy-paste the result json from the backend to a text file or something like that..
It dynamically finds your objects (even nested ones) and you can CRUD them..
Currently, the PantryID (uuidv4) is the only form of security, I am thinking that in a future release perhaps another form of authorization may be required.
Yeah, I imagine this is okay for testing, since UUIDs are fairly impossible to guess, however, you probably want a slightly more elaborate "authenticated session" based structure to ensure someone malicious who has obtained the UUID does not have an unlimited time window to exploit it.
Very cool! I was looking for something like this about a month ago when I was building an example web application for firmware developers. Firmware engineers aren't expected to know anything about databases and usually don't, so I just wanted some dumb JSON store in the cloud that didn't need any provisioning.
In the end, I went with Heroku and it's included PostgreSQL offering and stomached the complexity, but along the way I found https://jsonbox.io/, which I thought was neat and seems very similar.
Project/Article turned out very well. It was more of a proof of concept with the code open-sourced so people can have something to start with to track firmware binary sizes on a commit-by-commit basis.
Unsure if their minds were blown, but I at least know that mine would have been if I showed it to myself a couple of years ago. During that time, I had never touched databases, migration files, or devops in general. Now that's changed, but I still try put myself in those shoes.
Some API requests get a JSON response (Retrieve Account, Get Basket). Others get a plain text response (Create Account, Create Basket). Errors seem to get an HTTP response with an HTML page. Is this documented anywhere?
Ouch that is confusing. And no, I haven't added these details to documentation yet. This is a bit of an issue at the moment, having everything return in one format is the right thing to do.
Will be addressing this in the near future - thanks!
I love the graphics and web design! It looks like a simple service, and more alternatives in the space are welcome!
Full-disclosure, I also develop a "competing" (if you can call it that) service: https://kvdb.io - my landing page isn't as nice. Our buckets offer some atomic operations on keys and Lua-based scripting (you can spit out arbitrary text or HTML and handle basic GET/POST requests with parameter parsing), which might be useful for prototyping.
You should figure out how to sustain this kind of service on $FREE. In my experience, I've found a lot of people sign up but don't use it for anything serious. One of my first customers signed up and demanded a refund immediately after he discovered "oh, your simple key-value store doesn't support SQL queries?"