Hacker News new | ask | show | jobs
by ransackdev 1121 days ago
> That kind of increase in traffic costs me money I've never had to plan for.

https://getjsonip.com/#plus

  Going further with jsonip Plus
  With the upcoming Plus service, you get special features and 
  even more information about your users.

    - All of the free service features
    - IP geo location - Country and city to within best available accuracy
    - ISP Info
    - Time zone data
    - Full referer data
    - Browser and OS info
https://web.archive.org/web/20200811215649/https://getjsonip...

A paid service has been "upcoming" since at least August 2020, which would subsidize the free tier usage you allow on your site. Aside from the ISP and geo data, everything else is given to you in the request headers or can be determined with the ip address (geo can get tz).

If it's costing you money, shipping the Plus features might offset your out of pocket expenses.

This is a failure of growth/capacity planning and lack of a proper TOS that clarifies "unlimited within reason and at our sole discretion with no SLA or warranty of any kind for non-paying users", as well as failure to ship any monetizing features 3 years after announcing it.

Contacting them to have them stop wouldn't solve your problems. What happens when the next million devices get random updates from literally anybody that starts doing it again? Try to implement rate limiting, optimize your hot code paths, watch out for slow clients (buffered reverse proxies), needless header parsing, slow template rendering, etc. Any language capable of concurrency should be able to handle 100s of thousands of requests on a cheap vm. The client ip is coming to you in the request headers and all you do is print it back to them... A go handler would be a few lines of code to do this and that's including dealing with reverse proxy real-ip type stuff. You don't need to allocate an actual struct and serialize into a json object, just printf a hardcoded string with a replacement for the ip from the header, or better yet benchmark the fastest solution.

I'll do it for you, I'm looking for a job ;)

1 comments

You assumed the issue relates only to compute costs. Even with a small payload, bandwidth fees can add up quickly when millions of clients are polling.
Building the paid features announced 3 years ago would pay for compute as well as bandwidth. If the service runs at a loss after that, shut it down or start reaching out to these companies that have integrated it into their products and ask them to sponsor the service, which will certainly be cheaper for the company compared to the cost of dev time to change to some other service that can shutdown just as quick, QA the updates, iterate, approve, ship, wait for adoption, triage bugs, manage all the people doing those things, etc.

Or better yet update the TOS to be free and unlimited for non-commercial use, and to contact sales for commercial use with an estimate of request volume, then sign a phat enterprise contract and rest easy

This. It's mainly bandwidth costs that are the issue. Dealing with cpu is easy and cheap. Bandwidth is the mind killer.