DEV Community: Alex G

Custom Polygons vs. Uber's H3: Building a High-Performance Geofencing Backend in Go

Alex G — Tue, 31 Mar 2026 18:46:59 +0000

When building logistics and telemetry platforms, processing thousands of GPS pings per second is just a regular Tuesday. The core challenge isn't just receiving the data; it's figuring out exactly where that data is in relation to your business logic. Is the truck inside the warehouse? Did it cross a restricted zone?

If you are building a geofencing architecture, you will inevitably face the dilemma: Should you use exact Custom Polygons (PostGIS) or spatial indexing grids like Uber's H3?

Spoiler alert: For a truly scalable and user-friendly system, you need both. Here is how we handle this hybrid architecture using Go and PostGIS.

The Reality: Users Don't Think in Hexagons

From a purely mathematical standpoint, Uber’s H3 is a masterpiece. But from a UX perspective, telling a warehouse manager to draw their loading dock using only rigid hexagons is a terrible idea. Real-world facilities (like a CEDIS or a distribution center) are irregular.

Users need to draw custom polygons on a map. In our Go backend, we typically store these directly in PostgreSQL using PostGIS.

The Standard Approach: PostGIS `ST_Contains`

When a GPS ping hits our Go server, the most straightforward approach is to ask PostGIS if the point is inside any stored polygon.

// A simplified example of checking a GPS ping against PostGIS polygons
package main

import (
    "database/sql"
    "fmt"
    "log"

    _ "github.com/lib/pq"
)

func checkGeofence(db *sql.DB, lat, lng float64) (string, error) {
    query := `
        SELECT fence_id, name 
        FROM geofences 
        WHERE ST_Contains(geom, ST_SetSRID(ST_MakePoint($1, $2), 4326));
    `

    var fenceID, name string
    err := db.QueryRow(query, lng, lat).Scan(&fenceID, &name)
    if err != nil {
        if err == sql.ErrNoRows {
            return "", nil // Not in any geofence
        }
        return "", err
    }

    return name, nil
}

The Catch: ST_Contains uses spatial math (like ray casting) to determine if a point is inside a polygon. Even with GiST indexes, running complex spatial intersections for 10,000 pings per second will melt your database CPU and spike your cloud bill.

The Scaling Secret: Enter Uber's H3

When we need to eliminate database latency and scale massively, we bring H3 into the backend.

H3 divides the world into a grid of hexagons. Instead of doing complex math, H3 converts a (latitude, longitude) pair into a simple string or integer (e.g., 8928308280fffff).

Why is this a game-changer? Because checking if a truck is in a zone goes from an expensive spatial calculation to an $O(1)$ Hash Map lookup.

The Hybrid Architecture: "Polyfill"

We don't force users to draw hexagons. We let them draw their precise custom polygons. Then, in the Go backend, we run an asynchronous worker that takes that polygon and "fills" it with H3 hexagons (a process called Polyfill).

We store these hexagon IDs in a fast key-value store (like Redis) or a simple indexed database table.

package main

import (
    "fmt"
    "github.com/uber/h3-go/v4"
)

func indexGeofenceWithH3(polygon []h3.LatLng, resolution int) []h3.Cell {
    // Create a GeoLoop from the user's custom polygon
    geoLoop := h3.NewGeoLoop(polygon)
    geoPolygon := h3.NewGeoPolygon(geoLoop, nil)

    // Fill the polygon with H3 hexagons at the desired resolution
    hexagons := h3.PolygonToCells(geoPolygon, resolution)

    return hexagons
}

func handleIncomingPing(lat, lng float64) {
    // 1. Convert incoming ping to H3 index instantly
    latLng := h3.NewLatLng(lat, lng)
    resolution := 9 // Roughly city-block size
    cell := h3.LatLngToCell(latLng, resolution)

    // 2. O(1) Lookup: Check if this cell ID exists in our Redis cache
    // cache.Exists(cell.String())
    fmt.Printf("Ping mapped to Hexagon: %s\n", cell.String())
}

The Best of Both Worlds

By using Go, PostGIS, and H3 together, you build a logistics engine that is both precise and brutally fast:

UX / Precision: Users draw exact custom polygons.
Storage: PostGIS acts as the source of truth for the exact geometries.
Real-Time Processing: Go converts incoming pings to H3 indexes and checks them against a cached set of Polyfilled hexagons in microseconds.

There is no silver bullet in software engineering, but for real-time logistics telemetry, combining PostGIS precision with H3 speed is as close as it gets.

Stop Configuring Nginx: The Easiest Way to Deploy Go & React with HTTPS

Alex G — Wed, 11 Feb 2026 01:19:16 +0000

The "It Works on My Machine" Trap

We have all been there. You spend weeks building a robust application. Your Go backend is blazing fast, your React frontend is snappy, and everything runs perfectly on localhost:8080.

But then comes the deployment phase.

Suddenly, you are dealing with VPS configuration, SSL certificates, Nginx config files that look like hieroglyphics, and the dreaded CORS errors.

I recently built Geo Engine, a geospatial backend service using Go and PostGIS. I wanted to deploy it to a DigitalOcean Droplet with a custom domain and HTTPS, but I didn't want to spend hours configuring Certbot or managing complex Nginx directives.

Here is how I solved it using Docker Compose and Caddy (the web server that saves your sanity).

The Architecture 🏗️

My goal was to have a professional production environment:

Frontend: A React Dashboard (Vite) on app.geoengine.dev.
Backend: A Go API (Chi Router + PostGIS) on api.geoengine.dev.
Security: Automatic HTTPS for both subdomains.
Infrastructure: Everything containerized with Docker.

Instead of exposing ports 8080 and 5173 to the wild, I used Caddy as the entry point. Caddy acts as a reverse proxy, handling SSL certificate generation and renewal automatically.

The "Magic" Caddyfile ✨

If you have ever struggled with an nginx.conf file, you are going to love this. This is literally all the configuration I needed to get HTTPS working for two subdomains:

# The Dashboard (Frontend)
app.geoengine.dev {
    reverse_proxy dashboard:80
}

# The API (Backend)
api.geoengine.dev {
    reverse_proxy api:8080
}

That’s it. Caddy detects the domain, talks to Let's Encrypt, gets the certificates, and routes the traffic. No cron jobs, no manual renewals.

The Docker Setup 🐳

Here is the secret sauce in my docker-compose.yml. Notice how the services don't expose ports to the host machine (except Caddy); they only talk inside the geo-net network.

services:
  # Caddy: The only service exposed to the world
  caddy:
    image: caddy:2-alpine
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
    networks:
      - geo-net
    depends_on:
      - dashboard
      - api

  # Backend API
  api:
    build: ./backend
    expose:
      - "8080" # Only visible to Caddy, not the internet
    environment:
      - ALLOWED_ORIGINS=https://app.geoengine.dev
    networks:
      - geo-net

  # Database
  db:
    image: postgres:15-alpine
    # ... config ...
    networks:
      - geo-net

networks:
  geo-net:
    driver: bridge

The Challenges (Where I Got Stuck) 🚧

It wasn't all smooth sailing. Here are two "gotchas" that cost me a few hours of debugging, so you don't have to suffer:

1. The "Orphan" Migration Container

I use a separate container to run database migrations (golang-migrate). It kept crashing with a connection error.

The Fix: I realized that even utility containers need to be on the same Docker network! I had forgotten to add networks: - geo-net to my migration service, so it couldn't "see" the database.

2. The CORS Villain 💀

On localhost, allowing * (wildcard) for CORS usually works. But once I moved to production with HTTPS, my frontend requests started failing.

Browsers are strict about credentials (cookies/headers) in secure environments. I had to stop being lazy and specify the exact origin in my Go code using the rs/cors library.

In Go:

// Don't do this in production:
// AllowedOrigins: []string{"*"} ❌

// Do this instead:
AllowedOrigins: []string{"https://app.geoengine.dev"} ✅

By matching the exact origin of my frontend, the browser (and the security protocols) were happy.

The Result

After pushing the changes, I ran docker compose up -d. In about 30 seconds, Caddy had secured my site.

You can check out the live demo here: https://app.geoengine.dev
Or explore the code on GitHub: Link GitHub

If you are deploying a side project, give Caddy a try. It feels like cheating, but in the best way possible.

Happy coding!

Flutter Security: Why `isMockLocation` Is Dead in 2026 (And How to Fix It)

Alex G — Wed, 04 Feb 2026 19:09:02 +0000

If you are building a logistics, ride-sharing, or field-attendance app in Flutter, you have likely written this line of code before:

if (location.isMock) {
  // Block user
}

Five years ago, this was enough. In 2026, this is security theater.

The truth is, if your business relies on accurate location data (delivery tracking, clock-in systems), relying solely on isMockLocation is costing you money.

Here is why the old methods fail and how to implement Device Integrity validation for a bulletproof solution.

The Problem: The "Cat and Mouse" Game

Standard location packages in Flutter usually check the android.location.Location.isFromMockProvider() flag.

However, modern spoofing tools have evolved. Users today utilize:

Rooted Devices with Magisk: Modules that hide the root status from the OS.
Smali Patcher: Tools that patch the Android framework to always return false for mock location checks.
Advanced Emulators: BlueStacks or custom Android builds that simulate physical GPS hardware signals.

In these scenarios, your app asks the OS: "Is this fake?"
The compromised OS replies: "No, trust me."
And your backend accepts the fraudulent data.

The Solution: Don't Trust the Device

To truly secure your geolocation flow, you cannot trust the device to validate itself. You need a higher authority.

Enter Google Play Integrity API (formerly SafetyNet).

Instead of a simple boolean check, the flow changes to a Challenge-Response architecture:

The Challenge: Your backend sends a unique random string (nonce).
The Attestation: Your Flutter app sends this nonce to Google's servers via the Play Integrity API.
The Token: Google analyzes the device binary, the bootloader, and the GPS hardware, returning an encrypted token.
The Verdict: Your app sends this token to your backend. Your backend decrypts it with Google's public key to verify:
Is the app binary unmodified?
Is the device physical and not an emulator?
Is the location likely genuine?

The Implementation Pain

While the theory is sound, implementing this in Flutter can be a headache. You need to:

Set up Google Cloud projects.
Handle platform channels for Android (Play Integrity) and iOS (DeviceCheck).
Manage token decryption on your backend (Node, Go, Python).
Handle timeouts and retry logic. ## The "Easy Button": Introducing Geo-Engine

After struggling with this implementation for a logistics project, I decided to wrap this entire complexity into a reusable SDK.

I created Geo-Engine, a specialized Flutter package that handles the integrity handshake natively.

It doesn't just check for mock providers; it validates the integrity of the device itself before allowing location tracking to start.

How it looks in code

Geo-Engine is designed to be non-invasive. You don't need to rewrite your entire location logic. It works alongside your existing location provider (like geolocator or location).

It acts as a secure "middleware" that buffers data offline, generates the Integrity Token automatically, and flushes data to the server only when the device is verified.

Here is a real-world implementation:

import 'package:geo_engine/geo_engine.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  // 1. Initialize the local buffer (Hive)
  await GeoEngine.initialize();

  runApp(MyApp());
}

// ... inside your service or controller ...

class LocationService {
  late GeoEngine _engine;

  void init() {
    // 2. Configure the Engine with your credentials
    _engine = GeoEngine(
      apiKey: "YOUR_PROJECT_API_KEY",
      // Crucial: This enables Google Play Integrity on Android
      androidCloudProjectNumber: "1234567890", 
      debug: true, 
    );
  }

  // 3. When you get a location update (e.g. from geolocator)
  void onLocationUpdate(double lat, double lng) async {
    // 4. Send it securely.
    // The SDK automatically handles:
    // - Offline buffering (if network is lost)
    // - Attaching the Integrity Token (X-Device-Integrity header)
    // - Batching updates to save battery
    await _engine.sendLocation(
      deviceId: "user_123", 
      latitude: lat, 
      longitude: lng,
    );
  }
}

Conclusion

If your app handles payments or sensitive operations based on location, relying on client-side flags like isMockLocation is a vulnerability.

Moving to Server-Side Integrity Validation is the industry standard for 2026. Whether you build the integration manually or use a package like geo_engine, upgrading your security layer is no longer optional—it's necessary.

📦 Check out Geo-Engine on Pub.dev: Link

Happy coding and stay secure!

Building a Serverless Geofencing Engine with Go & PostGIS (to replace expensive APIs)

Alex G — Thu, 29 Jan 2026 00:46:32 +0000

I recently started working on a logistics side project that required real-time geofencing—specifically, detecting when assets enter or exit defined polygon zones.

I looked at the market leaders (Radar, Google Maps Geofencing API, etc.), and while they are excellent, the pricing models usually charge per tracked user or per API call. For a bootstrapped project where I might have thousands of "pings" but zero revenue initially, paying for every spatial check wasn't viable.

So, I decided to engineer my own solution.

Here is a breakdown of how I built a serverless, event-driven Geo-fencing Engine using Go, PostGIS, and Cloud Run.

The Requirements

Real-time: The latency between a location ping and a webhook event needed to be sub-second.
Scalable to Zero: I didn't want to pay for a K8s cluster idling at 3 AM.
Stateless: The system needed to handle concurrent streams without sticky sessions. ## The Architecture

I chose Google Cloud Platform (GCP) for the infrastructure, managed via Terraform.

1. The Compute Layer: Go + Cloud Run

I wrote the ingestion service in Go 1.22. Go was the obvious choice for two reasons:

Concurrency: Handling thousands of incoming HTTP requests with lightweight goroutines.
Cold Starts: Since I'm using Cloud Run (serverless), the service scales down to zero when not in use. Go binaries start up incredibly fast compared to JVM or Node.js containers, minimizing the "cold start" latency penalty. ### 2. The Spatial Layer: PostGIS This is where the heavy lifting happens. I'm using Cloud SQL (PostgreSQL) with the PostGIS extension.

Instead of doing "Point-in-Polygon" math in the application layer (which is CPU intensive and complex to handle for complex polygons/multipolygons), I offload this to the database.

The core logic effectively boils down to efficient spatial indexing using GiST indexes and queries like:

SELECT zone_id
FROM geofences
WHERE ST_Intersects(geofence_geometry, ST_SetSRID(ST_MakePoint($1, $2), 4326));

3. The "Glue": The Client SDKs

Building the backend was only half the battle. The friction usually lies in the mobile app integration—handling location permissions, battery-efficient tracking, and buffering offline requests.

To solve this, I built (and open-sourced) client SDKs. For example, the Flutter SDK handles the ingestion stream and retries, acting as a clean interface to the engine.
Trade-offs & Decisions

Why not Redis (Geo)? Redis has geospatial capabilities (GEOADD, GEORADIUS), but it is primarily optimized for "radius" (point + distance) queries. My use case required strict Polygon geofencing (complex shapes). While Redis 6.2+ added some shape support, PostGIS remains the gold standard for robust topological operations.

Why Serverless? The traffic pattern for logistics is spiky. It peaks during business hours and drops to near zero at night. Cloud Run allows me to pay strictly for the CPU time used during ingestion, rather than provisioning a fixed server.
Open Source?

While the core backend engine runs internally for my project (to keep the infrastructure managed), I realized the Client SDKs are valuable on their own as a reference for structuring location ingestion.

I’ve open-sourced the SDKs to share how the protocol works:

Go SDK: View on GitHub
Flutter SDK: View on GitHub

What's Next?

I'm currently optimizing the "State Drift" issue in Terraform and looking into moving the event bus to Pub/Sub for better decoupling.

I’d love to hear feedback on the architecture—specifically if anyone has experience scaling PostGIS for high-write workloads!

Arquitectura Serverless en GCP con Terraform: Cómo ahorré costos y sobreviví al "State Drift"

Alex G — Thu, 22 Jan 2026 00:35:23 +0000

La historia de cómo conecté Cloud Run con Cloud SQL usando IP privada sin pagar el conector VPC, y cómo recuperé mi infraestructura cuando Terraform "olvidó" todo.

El sueño del MVP barato

Cuando empecé a construir Geo-Engine, mi SaaS de procesamiento geoespacial con Go, tenía una meta clara: quería una arquitectura profesional, pero no quería pagar cientos de dólares al mes mientras buscaba mis primeros usuarios.

La elección obvia fue Google Cloud Platform (GCP):

Cloud Run: Para escalar a cero (pagar solo por uso).
Cloud SQL (Postgres): Para tener una base de datos gestionada y sólida.
Terraform: Para tener todo como código (IaC).

Sonaba perfecto en papel, pero la realidad me golpeó con dos problemas que casi descarrilan el proyecto: Terraform queriendo borrar mi producción y una factura potencial innecesaria por conectividad de red. Aquí te cuento cómo solucioné ambos.

Problema 1: La Amnesia de Terraform (State Drift)

Desarrollo desde mi laptop (Fedora) y a veces desde la nube (Project IDX). Un día, al intentar desplegar desde el entorno nuevo, Terraform me dio el susto de mi vida:

Terraform will perform the following actions:
  # google_cloud_run_service.api will be created
  # google_sql_database_instance.master will be created
...
Plan: 5 to add, 0 to change, 0 to destroy.

¿Crear? ¡Pero si ya existían! Terraform quería duplicar todo (o borrar y recrear).

Lo que aprendí: El archivo terraform.tfvars (donde guardo mi project_id y variables sensibles) estaba en mi .gitignore. Al cambiar de entorno, Terraform usó valores por defecto, apuntó a un "limbo" y decidió que no había nada creado.

La Solución:

Recrear variables: Asegurarme de que el project_id en el nuevo entorno fuera idéntico al real.
Importar, no recrear: Usé el comando import para decirle a Terraform: "Oye, este recurso ya existe, mételo en tu memoria".

terraform import google_cloud_run_v2_service.default projects/MI_PROYECTO/locations/us-central1/services/geo-api

Esto sincronizó mi estado local con la realidad de la nube y el plan volvió a decir "No changes". Paz mental restaurada.

Problema 2: Conectar Cloud Run a SQL (La trampa de los $17 USD)

Por seguridad, mi base de datos solo tiene IP Privada. Pero Cloud Run vive "fuera" de mi VPC. La documentación oficial recomienda usar un Serverless VPC Access Connector. El problema: Ese conector cuesta mínimo ~$17 USD/mes porque mantiene instancias VM encendidas 24/7. Para un MVP sin ingresos, eso es un "impuesto" doloroso.

La Solución: Direct VPC Egress.

Descubrí que Cloud Run ahora soporta una conexión directa a la VPC sin intermediarios costosos. Solo necesitaba configurar correctamente el bloque de red en Terraform.

Aquí está el fragmento de código que me ahorró esos $200 dólares al año:

resource "google_cloud_run_v2_service" "default" {
  name     = "geo-api"
  location = "us-central1"

  template {
    # ... configuración del contenedor ...

    vpc_access {
      network_interfaces {
        network    = "default"
        subnetwork = "default" 
      }
      # ESTA ES LA CLAVE:
      egress = "PRIVATE_RANGES_ONLY"
    }
  }
}

Con PRIVATE_RANGES_ONLY, Cloud Run enruta el tráfico hacia mi base de datos (IP 10.x.x.x) a través de la red interna de Google, y el resto del tráfico sale a internet normalmente. Costo extra: $0.

Conclusión

Construir Geo-Engine me enseñó que la infraestructura como código es poderosa, pero requiere disciplina. Hoy tengo un stack corriendo Go, Postgres y Cloud Run que es:

Seguro: Todo en red privada.
Económico: Escala a cero y no paga conectores ociosos.
Reproducible: Gracias a Terraform (y a saber usar import).

Si te interesa ver el resultado final, puedes probar la beta de mi herramienta aquí: Geo-Engine.

🎁 Bonus: SDK de Node.js Oficial

Mientras ajustaba la infraestructura, me di cuenta de que necesitaba una forma fácil de consumir mi propia API. Así que aproveché para empaquetar y publicar el SDK oficial.

Usando tsup, logré generar un paquete híbrido que soporta tanto ES Modules (moderno) como CommonJS (legacy) automáticamente.

La estructura final quedó así de limpia:

geo-engine-node/
├── dist/
│   ├── index.js      (ES Modules - import)
│   ├── index.cjs     (CommonJS - require)
│   └── index.d.ts    (TypeScript Definitions)
└── package.json