Forem: daCoder

IP to Geolocation with Python

daCoder — Sun, 04 Sep 2022 12:00:49 +0000

OR - My Own Headless SAAS - Part 2

In my previous post I described how I began developing my own SAAS and the different decisions I had to make.

Here I want to show you how I (and you can too!) develop an IP-to-geo service using Python.

Background

Before going in deep, we must realize that translating an IP address into a geolocation is a tricky business. IPs are commonly allocated by ranges (i.e. sets of hundreds or more IPs) to large organizations and associations, governments, ISPs, and large companies.

Those organizations then allocate those IPs as they see fit, either internally, or for publicly accessible resources, and sometimes even to users (e.g. ISPs may allocate IP to an internet consumer, and one can purchase a fixed IP from cloud providers).

However IP allocation tend to change with time, making it difficult to maintain an accurate mapping of IP to organization or IP to location.

This is why there're several businesses out there that specialize in that exclusively - maintaining a constantly updated map of IPs, allocations and locations.
Among those firms are Maxmind, IP2Location, DP-IP, and more.

On this piece I'll use Maxmind's IP free database, and I'll show you how to read is using Python.
Note that the GeoLite database is a free, limited and inaccurate version of Maxmind's full database, which requires a license.

Code it!

If you're lazy, you can also checkout my notebook.

Lets get started:

Register to MaxMind
Once you're in, go ahead to the "download database" section:
Next, scroll down and download the "GeoLite City" database. Make sure to download the GZIP and not the CSV file.
Extract and put the .mmdb file somewhere next to your code.

Next we do some simple coding.

To read this database we'll use Maxmind's own python library:

$ pip install geoip2

My geo.py file looks as follows, and I guess it's quite straightforward:

import geoip2.database

# Open the database file, the location of the database needs to match your setup
with geoip2.database.Reader('./files/GeoLite2-City.mmdb') as reader:

    # Query for a specific IP
    response = reader.city('90.190.169.0')
    print(f"Continent: {response.continent.names['en']}")
    print(f"Country: {response.country.names['en']}")
    print(f"City: {response.city.names['en']}")
    print(f"Coordinates: Lat {response.location.latitude} Long {response.location.longitude}")
    print(f"Timezone: {response.location.time_zone}")

In the above example I merely print out some data returned from Maxmind's database, but I can do much more, such as keeping it into my DB, use it for logging, user verification, cyber prevention, etc.

Are you considering to add IP-to-location capabilities to your app?
If so, you can definitely go ahead and purchase Maxmind's (or any other firm's) IP-to-geo database file, and implement it into your code.
The advantages for this approach is that you get a robust and independent app.
The disadvantages for this approach is that you'll need to purchase a license regardless of your usage, and you'll forever need to make sure that the database file is being constantly updated into your codebase.
This takes another (micro)service to develop, maintain and monitor.

Another wise alternative is to use an API service to query for IP-to-location.
If you're considering this approach, make sure to check out my own tooltap.app service.

I'm still adding users as design partners with exclusive early-bird benefits. Contact me if you wish to enjoy this opportunity.

My own Headless SAAS - Part 1: Where I begin

daCoder — Tue, 30 Aug 2022 16:08:32 +0000

In my previous post I described the background and reasons that lead me to begin developing my own SAAS: Tooltap.

Here I want to describe on my first steps and how I decided to focus my effort.

Decision #1 - Main business domain

Or in other words - what do I want to develop?
This was my first area to consider, and it did take me a while, but finally i fixed my mind on Headless SAAS that delivers a set of common-usage APIs.

The reasons for that are:

I wanted something within my skillset and passion, and APIs have always been there for me
I do frontend, but I really prefer not to. and;
During years of leading dev teams, I was walking through so many stylish SAASs, spending my time on understanding their interfaces, registrations and more registrations, just to finally get to the API and take my API keys. I want to create a service that doesn't need all that.
I can get to a Headless SAAS MVP within days, not months.
The demand for APIs is always increasing, as more SAAS and new software comes to light.

Decision #2 - My minimum viable product

My requirements from an MVP are to be usable and valuable, meaning a user should be able to use it without contacting me, and immediately gain value.
To achieve that I realized I need to build:

Basic user management with a Sign up and a method to retrieve auth keys - all based on APIs
The actual API service itself - which must be simple but valuable (touch on that later)
Documentation - API docs which adhere to OpenAPI standard and manuals to quickly get the developer set up and working with my service.

Decision #3 - The service itself

I was seeking for a service that is an API by nature, relatively easy for me to implement (MVP within days!!) and with a high market demand.
Scrolling through RapidAPI's list of most common APIs, I realized the one answering my requirements is the IP-to-Geolocation API.

IP-to-Geolocation is one of the most commonly used APIs out there, merely because every SAAS or web app with users traffic needs it.
Developers who're required to add IP-to-geo functionality to their apps can develop it in-house, but the better choice is to consume it as a service since it's cheap to consume but expensive to maintain.

Yeah I know. There're gazillion IP-to-Geo services out there.
But again, the demand is always rising, it's classic for an MVP, and I do sincerely believe that once I get more services in, then also this one will gain traffic.

Decision #4 - Tools & Framework

Here the decision was the easiest for me.
A non-popular opinion ahead: Javascript is ugly, node makes me a headache, Python is my true love <3.
There I said it.
I know people like to fancy their React, Vue, Node.js skills nowadays. But as someone who's been here since native JS, through Prototype.js, jQuery, underscore, backbone, handlebars and so on. And then seeing the development of PHP frameworks since PHP3, Ruby and RoR, and so many others...
I have to break this to you once and for all: Django got it spot-on since 2010.
So you guessed it, I'm proudly building on the wonderful Django framework with Python3.9.

Decision #5 - Website and documentation

I'm focusing on building it headless, so to begin with I decided on a no-website.
However, I still need to host some API docs and manuals, and for that I decided on having a documentation repository on Github, and by using github-pages it translates into a website under my own domain.
To ease up the API docs experience I created a workspace on Stoplight, which's hosting my OpenAPI docs.

Next post: On the IP-to-Geo API and my roadmap

I'm still adding users as design partners with exclusive early-bird benefits. Contact me if you don't want to miss this opportunity.

Developing my own Headless API service - Part 0

daCoder — Sun, 28 Aug 2022 14:18:12 +0000

So I decided to use my own skills and open my own self-sustainable business.

Hello readers, I call myself daCoder, and my story begins far back, since MS-DOS and Basic, when I was developing for fun and study.

Then at the break of Web2.0 I even started my own business, a web B2B e-commerce service. I developed, team-lead, VP-R&D and CTO'ed.
And it was a booming...
But then it wasn't about development anymore, it was management, planning, strategies... and other managers... and business and more business.
And then the spark slowly faded away. 😔

So finally I retired...

but now what?

As a developer, I have 20+ years expertise in:

Backend - PHP, Python, Java, C (CGI and stuff), Perl
Frontend - since the happy days of native JS to nowadays React
Devops - from before it was called devops.

But I've always been drawn to backend, architecture, and scaling systems.
Thats my passion 🤩

So I decided to use my own skills and open my own self-sustainable business, focusing on API services and developers.

Yeah, I know. There're soooo many services alike.

In fact, for each of the APIs I'm writing and about to add there're numerous well-established and deeply focused businesses.

However, my orientation is to focus on simplicity, minimalism, and as much as accurate as possible.

This means that

Services should be API first, with consumable OpenAPI documentation.
It should be Developer readable first, UI later
Deliver APIs that will solve the your development tasks faster and more sustainable than adding a library in your code
Fairness & transparency - you get what you pay for, and you pay for what you get. No hidden fees, no "subscriptions" when it doesn't make sense.
Put it all under one umbrella, so you don't have to seek and partner with so many vendors

So hi again :-)
I'm daCoder, this is my new Headless SAAS and this is the story of building it

Next: The beginning