Notes on current guidelines about libraries

[coderholic]

So you think we should build a different wrapper around the popular web frameworks?

Yeah, I think we should have one at the language level that doesn't make any assumptions about the use case, and then one for popular web frameworks that extends the language library, and assumes an incoming http request is where you want to do the lookup.

What about languages that essentially have the framework built into them?

Good question. We could write a single library that has 2 ways of calling it (eg. lookup(ip), and lookup(http_request)), or we could write 2 libraries, one called ipinfo (that doesn't assume the use case) and one called ipinfo-http (that assumed the http request). Thoughts? We should probably do some research and see if there are any parallels with how other services have successfully done this.

I guess the question is what do we mean by generic filtering?

Maybe the user wants to block all their dev IPs, or block their dev client or something, or who knowns what else. If we make the filtering generic then they could just pass this function to block bot traffic:

filter = (context) ->
   context.user_agent.match(/bot|spider/i)

Something like this to block their dev IPs:

dev_ips = [...]
filter = (context) ->
   dev_ips.contains(context.ip)

etc. Not sure how feasible this would be in all languages, but in most of them it should be fairly straightforward.

[aaomidi]

If we plan to open this up for external audiences, should we have the field just for future compatibility?

Will change the caching value!

Right now in the GoLang version of the library I use the http.Request (which is part of the standard library) to handle user agents. I think it'd make sense to support them for the standard libraries of languages but for languages that don't have a standard library for http we shouldn't include it. What do you think about that?

[coderholic]

If we plan to open this up for external audiences, should we have the field just for future compatibility?

No, I think we can do something different for external libs, maybe IPInfoClient-Vendor, or maybe a different UA completely.

I think it'd make sense to support them for the standard libraries of languages but for languages that don't have a standard library for http we shouldn't include it. What do you think about that?

I guess it depends on usage patterns. Some people might want to use the library to lookup details for an incoming HTTP request, and in that scenario you'd have a http request object and access to the user agent etc. That's only one use case though. People might also be looking up IPs from a CSV file or access logs, or they might be building a service where the user can enter IPs, or a bunch of other things. In those scenarios we don't want them to have to create a fake http request object. Therefore for the language specific libraries I think it makes sense to only require an IP address (or ASN), because that supports all the use cases.

Maybe the same library can also support http request objects, but my sense is that's better supported by a separate library, probably at the framework level. Eg. our node.js/ruby/python libraries will only require IPs and doesn't offer any bot filtering, but we should have express/rails/django libraries that do have full http object handling and automatic bot filtering etc, because the use case is obviously around the http request there.

Does that make sense? What are your thoughts?

[aaomidi]

Fair point on the UA.

So you think we should build a different wrapper around the popular web frameworks?

What about languages that essentially have the framework built into them? For example the new Java will have an http client built in. Or in the case of GoLang we have the http client built in (and from my understanding nearly all libraries just extend that instead of making their own from scratch).

I guess in the case of looking up bots, we can just filter on strings instead of using objects? Also I guess the question is what do we mean by generic filtering?

[przmv]

LGTM with just one minor note the language is called Go no GoLang.