Redacted DevWorks

The decision behind choosing a server side technology is never an easy one. Every single language has it's pro's and con's around each.

For me, this decision came down to a couple simple points:

1. Node is a web tech first class citizen, designed around handling web events, in a web technology world
2. Asynchronous

The thing about Python and Java is that they TOO can handle these, and handle these very well. Java for instance powers most of Twitter and Netflix's architecture. Where Python is what's behind giants like Instagram and Patreon. Certainly, you can't go wrong. Heck, Ruby powered GitHub and GitLab, and those things see HUGE traffic.

But this project is a web technology first. And node feels right at home as it itself is a web technology. This decision was more about homogeneous synergy than most anything else. I need it to be screaming fast, asynchronous, and play extremely well with web standards.

Node fits the bill on every front.

When I found out how powerful PostGIS was, I was gobsmacked. No matter how ridiculous that sample data I'd provide, the results would be fast and come back accurate and consistently.

The only other database engine that offered decent GIS indexing and searching, was ElasticSearch. But ES is not an ACID adhering engine, and is specifically designed to be a screaming fast fulltext search engine first, and everything else second. You never want ES to be your primary database engine (it's not designed for that anyways), it should always be a compliment to your more stable and consistent database solution.

Simply put, I could have stuck to a MySQL + ElasticSearch solution, but the operating costs around that get astronomical when you get down to ho HEAVY ElasticSearch is, and how expensive it is to operate in the any hosting solution.

PostGIS allows to me not need ES for geospatial indexing and querying, and to be really fast at it while doing it. A god send.

While there's been some very clever techniques that has allowed non-natively supported geo querying to be performed, it is incredibly slow in the long game and error prone at best.

MySQL finally introduced it's own GEO functions and special indexing operations for GIS type data. I prototyped with this, as MySQL is the most familiar database to me. But no matter what I did with it, how much tuning i'd give it, how much I played with it, the results would come back inconsistent.

It was very disappointing.

I figured, at this point, that SQL Server, being an enterprise solution authored by one of the biggest worldwide software developers in the world, Microsoft, might contain some decent GIS in it.

I was very disappointed.

Postgres is a Database solution i'm still getting familiar with, but I noticed it had no built in support for GIS. So I hilariously didn't pay it too much attention. That was until I stumbled upon PostGIS and my world changed forever.