Earlier quoted context omitted.
I understand what you mean, but every other provider from the tests I've done comes in at double our speeds some even over plain HTTP. We only serve requests over HTTPS More importantly the performance is consistent and you'd get the same performance wherever you were in the world.
Why compare to another API endpoint? You should compare it against accessing a local database.
Show HN: IP Geolocation and Threat Data API
61–67 of 67 posts
Re: Show HN: IP Geolocation and Threat Data API
#62Earlier quoted context omitted.
Why compare to another API endpoint? You should compare it against accessing a local database.
Comparing a network call vs filesystem i/o wouldn't be a useful comparison for someone deciding between different third part API providers.
Re: Show HN: IP Geolocation and Threat Data API
#63Earlier quoted context omitted.
Comparing a network call vs filesystem i/o wouldn't be a useful comparison for someone deciding between different third part API providers.
Why not? I can load an IP database locally, so it's an option and a "competitor" to a 3rd party API. That's what I'm comparing it to, not against other APIs.
Re: Show HN: IP Geolocation and Threat Data API
#64Earlier quoted context omitted.
Why not? I can load an IP database locally, so it's an option and a "competitor" to a 3rd party API. That's what I'm comparing it to, not against other APIs.
It's pretty obvious that hitting your local disk is going to be a lot faster than making a network call. Make the right decision for your use case.
Today I'd say it depends upon exactly what your network data source latency measures out to. The answer could go either way.
Re: Show HN: IP Geolocation and Threat Data API
#65Earlier quoted context omitted.
It's pretty obvious that hitting your local disk is going to be a lot faster than making a network call. Make the right decision for your use case.
Maybe in this case. But historically, exactly this decision point has oscillated. It's caused reversals in distributed computer design for decades. First the networks were slow and disks were (relatively) fast - so each machine had one. Then networks went Ethernet, and disks started disappearing. Disks got down to a few ms access time and they came back. Then Gigabit came around. Then SSD. Today I'd say it depends up…
Re: Show HN: IP Geolocation and Threat Data API
#66Earlier quoted context omitted.
Let's say it like this: - https://api.ipdata.co/1.1.1.1 City name: Research - https://www.maxmind.com/en/geoip2-precision-demo?ip=1.1.1.1 City name: Research Oh, that must be a very coincidence. Nuh nuh nuh, nobody would ever want to launch a SaaS with a database they have stolen.
I wonder if Maxmind have put in some "Trap Streets" in their dataset. https://en.wikipedia.org/wiki/Trap_street
Re: Show HN: IP Geolocation and Threat Data API
#67Earlier quoted context omitted.
I've always had good luck with Maxmind's local database [1] offering. It bewilders me how many companies today create SaaS offerings and refuse to offer on-prem versions. It's like they intentionally want to avoid customers with serious needs (speed and security being the most common need for on-prem) who are willing to pay serious amounts of money. [1] https://www.maxmind.com/en/geoip2-databases
Let's say it like this: - https://api.ipdata.co/1.1.1.1 City name: Research - https://www.maxmind.com/en/geoip2-precision-demo?ip=1.1.1.1 City name: Research Oh, that must be a very coincidence. Nuh nuh nuh, nobody would ever want to launch a SaaS with a database they have stolen.