JavaScript API pricing is dangerous. Here is why

dokeeno.com

11 points·arunoda··5 comments

Mixpanel authorized person has answered to this in the blog post. Here it is ----------

I'm glad you like Mixpanel! This is certainly something we've considered, but (at least for us) the usage-based api makes the most sense. Unfortunately you can't avoid this kind of thing once you go the usage-based path, but it hasn't been an issue in practice.

We've never had a malicious user manipulate someone's data (and it would be pretty obvious if they did). If it did happen, we wouldn't charge them for it.

I know what you mean, and I understand your concern, but as an API, the API provider is meant to handle these [D]DOS attacks / miscounting (e.g. Google Analytics hardly ever miscounts).

Alternatively, if you understand the consequences of using an unofficial API, and your web service has the bandwidth to do so, you can trigger the API by manually stimulating server-side REST requests identical to what the JS API does.

yes. You are correct. This is not a new thing. But the difference here is with the (D)DOS. Customer has to pay for it. Not mixpanel. That is the concern I'm making. It is huge

Doesn't seem huge. Most people pay for bandwidth. Standard web DOS attacks cost money too. Same thing with linking to S3. The fix is as it's always been, email your provider and explain the situation. Most likely they'll revert your usage. Presumably if it becomes a big problem they'll set up something like rate limiting by IP.

Yes You might argue that. But the vendors should do some kind preventive mechanism on doing this. I don't know what. If they need to serve there customers well, they need to focus on that. What we need is a preventive mechanism and if they don't do this. This will be the next generation viruses. And extreamly dangerous.

Reply on news.ycombinator.com