Now you could track your JSON store with much more control. We are working on developing newer features which will allow you to block users with specific IPs, User Agents, etc.
You don't, but it makes it easier to integrate in to some existing code. Usually these libraries are written for personal reasons (eg needing it yourself) and then open sourced. If you're making a React app at the time then it ends up being a React library.
One day I'm going to 'un-React' Neon (see my other comment), but until then it 'needs' it.
Just want to drop a big thumbs up for making the project open source unlike mine. It will really help developers who are looking for an API and want to host it themselves. I'll try to contribute to your project in the best possible way I can. Cheers.
JSONbin.io developer here. Tracked the thread using GA after unusual spike in the traffic.
Good point. We cannot trust any random service. It takes some amount of investment, dev time & server costs to keep the service up and running. The reason I developed this service is to ease the storage process for the developers developing mobile or small scale apps, so that they can focus on the app rather than spending time setting up the database. Just to keep the website up and running, I'm going to introduce nominal amount plans which developers can afford and it pays my server bills. I'll ensure that I've SLA in place when am introducing pricing. The only reason I've not introduced pricing on the website is I don't want to charge for something basic what am providing for now. Will add it when I provide more powerful features which are already under development.
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.
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.
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.
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.
> 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.
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.
So, my first thought is that I'd set up a service like yours primarily because I'd be fascinated by the data provided. While that might not result in malicious use of said data (it'd not be my intention), it's quite possible the resulting data might provide interesting opportunities.
Now, I'd consider it unlikely that I'd setup such a service without being a peeping Tom, so if something interesting were to come my way, I'd probably notice it.
How do you deal with this? A firm resolve not to, at the very least, check out shady avenues of information? Giving in to that urge but not using it for profit?
The reason I'm wondering about this is that I'm part of multiple IRC channels where with some regularity people will link to a service such as yours with code that exposes private keys, and while usually the people helping out in those channels will be quick to point out the privacy leakage, it struck me that all of it is still available to the hoster. And in fact, switft removal of said code my ping the hoster that this might be interesting data.
Sorry, not trying to be a d*ck here but I don't get the point.
You said you don't like the NodeJS eco system as you need to install thousands of packages to get your work done whereas on the other hand, your find CRA which uses tons of NodeJS packages to get the work done.
Secondly, code splitting, Babel, bundling has nothing to do with CRA, they are just standalone packages which works well together.
Third, "What’s more, updates are great. It’s just a yarn install away.", Isn't this something which NPM does as well?
Syntax - Again, nothing to do with ReactJS, it's babel which comes with polyfills.
So am just curious here to understand that how exactly CRA changed your mind where 90% of what you are doing is pure JS and has nothing to do with ReactJS?
