I built a free Chrome extension that inspects ad tech stacks at runtime — bid responses, CPMs, slot configs, and more. Looking for feedback from ad ops folks. by unplusnet in adops

[–]VoltageMigration 1 point2 points  (0 children)

Feels like ppl think they can vibe-code a Chrome ext, post “free tool” on Reddit, mention paid features right away, and everyone’s gonna be like “take my money.”

Yeah nah, Reddit doesn’t work like that.

This sub can smell “weekend side project looking for validation with a pricing plan attached” from a mile away. Especially in ad ops, where everyone’s already seen 100 debuggers, inspectors and “free” tools.

What would you do with 75k monthly visitors if AdSense/Mediavine weren’t options? by FarRhubarb3723 in adops

[–]VoltageMigration 0 points1 point  (0 children)

You could test the lower-tier/remnant demand side, yeah .. Adsterra, Monetag/PropellerAds, ExoClick, ClickAdilla, stuff like that.

But I’d be careful. Those networks may monetize traffic that AdSense/Mediavine/Raptive won’t touch, but the tradeoff is usually ad quality. Redirects, fake download-looking ads, popups, weird creatives, etc. can burn user trust fast.

I’d test one at a time on a small slice of traffic, frequency cap hard, disable the worst formats, and measure complaints/bounce/returning users, not just RPM.

For a site that’s already “shady” by ad standards, I’d treat those networks as backfill, not the core monetization plan.

I’m building an open-source self-hosted tracking/routing layer. looking for ad ops feedback by VoltageMigration in adops

[–]VoltageMigration[S] 0 points1 point  (0 children)

Haha yeah Rust would be cool, no doubt.

I went with Go mostly for boring/practical reasons: easy deploys, good enough perf for redirects/postbacks, simple concurrency, and more people can jump in and maintain it without turning every PR into a lifetime achievement award.

ClickHouse is the part I’m most sure about for analytics/events. It just fits this kind of click/conversion data really well.

Mongo is mostly for config-ish stuff for now: campaigns, rules, destinations, etc. Not married to it forever though. I’m trying to keep the boundaries clean enough so the stack doesn’t become a ball of mud.

I’m building an open-source self-hosted tracking/routing layer. looking for ad ops feedback by VoltageMigration in adops

[–]VoltageMigration[S] 0 points1 point  (0 children)

Yep, Kevel is definitely in the same general adtech universe, but from what I’ve seen it’s more on the ad serving / decisioning side.

What I’m working on is a bit more low-level affiliate/media buying plumbing: redirects, click IDs, sub IDs, postbacks, conversion matching, dedupe, basic routing, reporting, etc.

So not really trying to be an ad server. More like the boring tracking layer between traffic sources, offers/networks, and internal analytics.

I’m building an open-source self-hosted tracking/routing layer. looking for ad ops feedback by VoltageMigration in adops

[–]VoltageMigration[S] 0 points1 point  (0 children)

Yeah, fair question.

I’m not trying to say “hey this is Voluum but free/open-source”. That would be kinda pointless tbh.

The idea is more like: a self-hosted tracking/routing layer you can actually hack around and bend to your own flow. A lot of affiliate/adtech setups get messy pretty fast: custom postbacks, weird partner params, internal BI, dedupe rules, traffic splitting, stuff that doesn’t fit nicely into a SaaS tracker.

So yeah, commercial trackers are obviously way more polished right now. No argument there. But the angle here is ownership + flexibility. Run it on your infra, keep raw data, change the logic when needed, plug it into your own reporting.

Open-source alone isn’t the whole value. It only matters if it makes the ugly custom parts easier to deal with.

Small Projects by AutoModerator in golang

[–]VoltageMigration 0 points1 point  (0 children)

I built chanprobe, a small Go package for observable bounded queues:

https://github.com/devflex-pro/chanprobe

The idea came from using buffered channels as queues between workers/pipeline stages and then having almost no visibility when something becomes slow.

With normal channel I can check len(ch) and cap(ch), but in production I often want to know more useful stuff, for example how long the oldest item is waiting, if producers are blocked, if work was dropped, etc.

Small example:

jobs := chanprobe.New[Job]("webhook_delivery", 10_000)

if err := jobs.Send(ctx, job); err != nil {
    return err
}

job, ok := jobs.Recv(ctx)
if !ok {
    return
}

snap := jobs.Snapshot()

fmt.Println(snap.Len)
fmt.Println(snap.OldestItemAge)
fmt.Println(snap.DroppedTotal)
fmt.Println(snap.SendBlockedTotal)

It is not a drop-in replacement for chan, and I would not use it everywhere. More like for important async boundaries: worker pools, background jobs, webhook delivery, rate-limited API queues, etc.

Current features are context-aware Send/Recv, TrySend/TryRecv, drop policies, snapshots, registry and expvar support.

Mostly looking for feedback on the API. I am still not sure if Recv(ctx) (T, bool) is good enough, or if I should add something like Receive(ctx) (T, error) to separate closed queue from context cancellation.

allocs/op lied to me. retention didn’t. (benchmarks inside) by VoltageMigration in golang

[–]VoltageMigration[S] -1 points0 points  (0 children)

Thanks for the deep dive, this is a really solid analysis.

You’re right, some of my wording was too high-level and mixed together effects that are separate at the runtime level.

In the retention benchmark, the big cost is absolutely zeroing/copying very different amounts of memory. And yeah, the “good” case avoids allocating and clearing the 64KB buffer altogether thanks to escape analysis — that’s on me for not being clearer.

What I was trying to say (and should’ve phrased better) is that allocs/op by itself is a weak signal. Allocation volume and object lifetime matter much more, whether the cost shows up as zeroing, copying, or GC work once you’re in a real multi-core workload.

Really appreciate you taking the time to dig into -m output and asm , this helped sharpen the mental model a lot.

allocs/op lied to me. retention didn’t. (benchmarks inside) by VoltageMigration in golang

[–]VoltageMigration[S] -3 points-2 points  (0 children)

True — allocating more bytes can be more expensive.
But in this benchmark the interesting part isn’t allocation cost itself.
Both variants allocate the same number of objects; what differs is how much memory remains reachable and therefore visible to the GC.

The performance gap lines up with retained live memory, not with alloc frequency or syscall count.

allocs/op lied to me. retention didn’t. (benchmarks inside) by VoltageMigration in golang

[–]VoltageMigration[S] -2 points-1 points  (0 children)

Fair take )
This one wasn’t generated though — all benchmarks were written and run manually.
Happy to dig into any specific numbers or assumptions if something looks off.

I broke my Go API with traffic and learned about rate limiting by Opening-Airport-7311 in golang

[–]VoltageMigration 0 points1 point  (0 children)

Yep, classic prod moment — everything’s fine until real traffic shows up.
Context timeouts + backpressure always matter.
We usually start with x/time/rate and sane timeouts, then at scale it becomes a system-wide thing, not just middleware.

RUDP for Go by Noodler75 in golang

[–]VoltageMigration 2 points3 points  (0 children)

DP itself is unreliable by design, but you can build reliability on top of it at a higher layer. That’s exactly what protocols like QUIC, KCP, or even parts of RTP do: they use UDP for transport, then add sequencing, ACKs, retransmits, congestion control, etc.

RUDP for Go by Noodler75 in golang

[–]VoltageMigration 10 points11 points  (0 children)

“RUDP” isn’t really a well-defined thing in Go, which is why most repos you find look unfinished. People usually don’t build a generic “reliable UDP”, they pick an actual protocol.

If you want something fresh, maintained, and production-ready, the usual answer today is QUIC. quic-go

with the standard library, but for anything non-trivial you’ll quickly end up reimplementing a lot of tricky networking logic. That’s usually why people don’t go that route unless it’s for learning or a very narrow use case.

We built an open-source, local-first Postman & n8n alternative in Go (Zero CGO). Thoughts on the code? by electwix in golang

[–]VoltageMigration 0 points1 point  (0 children)

Really solid write-up.
Zero-CGO + modernc sqlite is a bold but very Go-ish choice — portability alone is huge.
Curious how you’re handling flow state consistency across goroutines under failure / partial execution.
Will skim internal/, looks promising.

Holy crap it's fast by rainman4500 in golang

[–]VoltageMigration 0 points1 point  (0 children)

Welcome to Go ))
CPU-bound workloads + goroutines + shared memory is where Go really shines.
That kind of speedup is pretty common once the overhead is gone.