DEV Community: Stephen Jarso

Moving Beyond CRUD: Building a Geofenced Network Engine from Scratch

Stephen Jarso — Sun, 19 Jul 2026 19:34:36 +0000

Why I am Leaving Simple Web Apps Behind

Let’s be completely honest: There are only so many Todo apps, e-commerce clones, and standard REST/CRUD dashboards you can build before you start craving real engineering depth.

Lately, I have been shifting my focus toward networking, lower-level protocols, and infrastructure security. I wanted my next portfolio project to be a massive learning journey something that forced me to think about raw binary parsing, kernel-space performance, cryptographic handshakes, and data pipeline observability.

So, I decided to bypass standard application-level programming and design a Software-Defined, Geofenced Mesh Network with an AI Anomaly Detection Layer.

Here is the architectural blueprint of how I am combining custom socket programming, cryptographic spatial data, and neural networks into an omniscient, real-time "God-View" system.

The Architectural Vision

Imagine a secure private network overlay where data routing is strictly bound by physics and geography. Devices acting as nodes connect to an edge broker and transmit real-time telemetry. However, data packets are cryptographically verified based on physical coordinates.

If a malicious actor steals credentials and attempts to access the network from an unauthorized region, or uses an automated script to spoof their GPS, the infrastructure detects it instantly. A neural network constantly evaluates the physical location claim against raw network characteristics (like latency jitter and packet transit variations). If a discrepancy is found, the connection is instantly severed.

To monitor this entirely stateful environment, the central control server pipes live infrastructure logs over WebSockets to a web-based "God-View" dashboard. This top-down view visualizes real-time data tunnels lighting up, global traceroute paths, and localized security flags mapped over an interactive geographical grid.

The High-Performance Tech Stack

To manage thousands of concurrent streams without high latency or packet drop, the architecture skips generic web frameworks in favor of system-level technologies:

The Core Network Engine (Go): I chose Go (Golang) for the ingestion engine. Go’s native network stack (net package) paired with ultra-lightweight concurrent goroutines allows it to manage thousands of open TCP/UDP sockets out of the box using minimal memory. The engine’s primary job is to strip framing headers, parse raw binary payloads, and handle connection lifecycles.
The Cryptographic Tunneling Layer (WireGuard): Instead of routing sensitive telemetry through slow, user-space proxy code, the application interfaces directly with WireGuard. WireGuard handles state-of-the-art, kernel-level encrypted virtual interfaces. This allows us to dynamically spin up, configure, and tear down secure tunnels between edge IoT devices and the backend infrastructure programmatically.
The Security Brain (Python + PyTorch): How do you catch a bad actor faking their GPS coordinates? You use a neural network. I am building a lightweight Anomaly Detection Autoencoder in PyTorch hosted behind a high-speed gRPC interface. The Go engine streams network telemetry metrics such as round-trip time (RTT), Time-to-Live (TTL) changes, and network jitter—to the Python model. The neural net determines if the physical location claim perfectly correlates with the physical realities of the network packet’s transit path.
Telemetry Storage (Redis & VictoriaMetrics): Standard relational databases (like MySQL) or document stores (like MongoDB) will choke under thousands of streaming location writes per second. I am utilizing Redis for sub-millisecond coordinate caching and geographical command filtering (GEOADD/GEORADIUS), alongside VictoriaMetrics to aggregate long-term time-series network health data.

Defining the Protocol Data Blueprint

To optimize performance, we don't send heavy JSON payloads over the raw sockets. Instead, we use a compact, structured binary frame format to keep our network footprint small and predictable.

Each device telemetry packet is exactly 24 bytes:

Offset (Bytes)	Field Name	Data Type	Description
`0x00 - 0x03`	`DeviceID`	`uint32`	Unique tracking identifier for the node.
`0x04 - 0x11`	`Latitude`	`float64`	Encoded high-precision GPS latitude coordinate.
`0x12 - 0x1F`	`Longitude`	`float64`	Encoded high-precision GPS longitude coordinate.
`0x20 - 0x23`	`Timestamp`	`uint32`	UNIX epoch timestamp of packet transmission.

Let’s Discuss!

This project is taking me completely out of my comfort zone, and I am bound to run into significant architectural hurdles especially when trying to keep serialization latency low while piping network metrics into Python for evaluation.

Have you ever designed a custom binary packet system or handled live geospatial multi-node streaming? What tricks do you use to manage persistent state safely across asynchronous networking platforms?

Let me know your thoughts, tips, or architecture critiques in the comments below!

Confessions of a Dev #2:The Interview Answer That Haunts Me

Stephen Jarso — Thu, 23 Apr 2026 03:44:43 +0000

You know that feeling — walking out of an interview, and by the time you hit the elevator, your brain already starts replaying that one question.

The one where you said something… fine. Acceptable. Professional.

But deep down, you know you had a killer answer in you. The honest one. The clever one. The one that would've made the interviewer lean in and say, "Tell me more."

Instead, you played it safe. You gave the textbook response. You talked about "process improvement" and "team collaboration" like a LinkedIn post come to life.

And now, days later, you're still thinking about what you should have said.

Not because you lied. But because you held back.

Here's mine.

I was interviewing for a Flutter role. Everything was flowing — architecture, state management, animations. Then came the question:

"What do you use for the backend?"

What I said:
"Dart."

Just… Dart. Like it's a backend. Like that's a normal thing a reasonable person would say.

What I should have said:
"Firebase. Or if I need more control, a custom API with Node or Go. But Dart? Only if I'm using Serverpod or Dart Frog — and even then, I'd clarify that's not the same as 'Dart by itself.'"

The interviewer paused. Typed something. Moved on.

And me? I sat there, smile frozen, already replaying the horror in slow motion.

So here's where I leave you hanging:

Did I get the job?

…That's for Dev Confessions #3.

Now your turn — drop in the comments:
What's one thing you said in an interview that still makes you cringe? And what should you have said instead?

Confessions of a Dev #1:I Went Blank When Asked "What's an API?"

Stephen Jarso — Wed, 15 Apr 2026 02:39:43 +0000

Last week, a friend asked me something so basic, so fundamental that i should have been able to answer it in my sleep.

"Hey, quick question...what exactly is an API?"

Not a trick question. Not an interview. Just two devs talking.

And I went blank.

I’ve built REST APIs. I’ve authenticated with JWT.

But in that moment? Nothing.

So I did the thing we all do when our brain short-circuits:

"I mean… I know how they work? Or what they do? You know."

We both laughed. He nodded like he understood. But I knew: I had failed the simplest test of all.
The Problem (It’s Worse Than You Think)

When a non-technical person asks “what’s an API?”, you can use a waiter or a mailman analogy. They’ll be happy.

But when a technical person asks, they’re not looking for a metaphor. They already know what a server is, what HTTP is, what JSON is. They’re asking for the essential definition – the crisp, precise, almost philosophical answer.

And that’s way harder.
Because APIs are so obvious to us that we’ve never actually articulated them. We just… use them. The definition lives in our fingertips, not our tongue.

So after that humiliating moment, I went home and forced myself to answer properly. Here’s what I came up with.
What I Should Have Said (Technical Edition)
The One-Sentence Definition (Crisp & Precise)

“An API is a defined interface that specifies how one software component can interact with another – including valid requests, expected responses, and the underlying protocol (usually HTTP).”

That’s the technical answer. No fluff. No waiter.
The Slightly More Technical Answer

“An API is a contract between a client and a server. It says: ‘If you send me a request in this shape, to this URL, with these headers, I’ll send you back a response in this shape – and here are the status codes to tell you what happened.’”

The “Ah, Right” Analogy (Still Technical)

“Think of a database query language like SQL. You send a SELECT statement, you get a result set. An API is the same idea, but over HTTP – and instead of tables, you work with resources (users, orders, products).”

The Shortest Possible Answer

“An API is a layer that abstracts an implementation behind a set of publicly accessible operations.”

That one would have made me sound smart. But I didn’t say it. I said “uh… you know.”
Why Technical People Go Blank on Basic Definitions

It’s not because we don’t know. It’s because:

We think in use cases, not definitions – “An API is what I call to get user data” is not a definition, it’s an example. But that’s how our brains store it.
We confuse “how it works” with “what it is” – I could have explained the HTTP request cycle, JSON serialization, status codes, rate limiting, and authentication. But that’s not what an API is. That’s how you use one.

3.We’ve never had to define it – In school, they teach you syntax, not definitions. In work, you just build things. No one ever says “define API” in a sprint planning meeting.

The Real Lesson (For Devs, By a Dev)

Knowing how to build something is not the same as knowing how to define it.

The best developers can do both. They can talk about implementation and they can zoom out to the 10,000-foot definition without stumbling.

So here’s my challenge to you, fellow dev:

Without looking it up, define these terms in one sentence – out loud, right now:

    HTTP

    JSON

    JWT

    DOM

    TCP

If you can’t, welcome to the club. Let’s practice together.
Call to Action (Your Confession)

Now it’s your turn.

What basic technical question made you go blank in front of another developer?

Drop your confession in the comments. No judgment. Just devs being honest.

This is Confessions of a Dev. We’ve all been there.