gkoos

This post runs three controlled chaos scenarios against the same endpoint to compare retry-only, Retry-After-aware retries, and hedging. One recurring result is that reliability gains can come with significantly worse p95/p99, while 429-aware retry behavior outperforms blind retries under rate limiting.

Why debouncing input reduces call volume but does not prevent stale-response race conditions.

I implemented atomic hot config reload in both Node and Go with the same external contract, then reran benchmarks on the same machine and methodology. In this setup, Go remains about 1.92x higher throughput, while both versions show steady-state overhead from reload-safe runtime design.

Summary: Explains backpressure as producer–consumer rate control in JS, covering Node.js streams (write()/drain, pipe()), Web Streams, and pitfalls with async/await and Promise.all().

I got tired of reimplementing timeout/retry logic, so I built a thin fetch() wrapper.

const client = createClient({ timeout: 5000, retries: 3, circuit: { threshold: 5, reset: 30000 } }) const response = await client('/api/data') // exactly like fetch()

Drop-in replacement, zero deps, ~2KB. Has lifecycle hooks for auth/logging, exponential backoff with jitter, respects Retry-After headers, and proper AbortSignal composition. Preserves all native fetch behavior.

https://github.com/gkoos/ffetch

Thoughts?

Hey, I write a tech blog and I need to create lots of diagrams for it. I like using Mermaid, but I quickly ran into the same frustrating pattern with most of the existing editors and renderers: the free options were either too limited or came with barriers that slowed me down. I wanted something simple: just open the page, paste/type in Mermaid code, preview the diagram, and export it without worrying about limits or accounts. Here are some concrete problems I ran into with other tools: - Mermaid Live Editor (the official one): Great for quick editing, but exporting diagrams is capped by a rate limit on their free tier. After a handful of exports, I’d get the dreaded “free tier limit exceeded” message. Kroki.io: Supports rendering, but running it online requires trusting a shared service with my diagrams. Hosting it myself means extra setup, Docker, and server resources — not ideal if I just want to save a few diagrams. - Excalidraw & Lucidchart: Both have nice UIs, but they’re general diagramming tools, not native Mermaid editors. Lucidchart especially locks useful features (like unlimited diagrams or high-quality export) behind a paid plan. - Other browser-based tools Almost all I tried had some kind of paywall, signup requirement, or watermark on exports. For something as text-based and simple as Mermaid, that felt unnecessary. So I built my own tool with a few core principles: - No limits: you can create, edit, and export as many diagrams as you want. - No signup: the tool works straight from the browser, nothing to install. - No tracking: privacy-friendly, just you and your diagrams. - Open source: https://github.com/gkoos/mermaid-editor Now this is a very simple v0.0.1 and needs a lot of refinement, but hopefully it can be useful to some even in its current state.

Some legal departments are against AGPL and that might affect adoption.

Looks neat. A few things though: 1. Deep equality checks on every dispatch may become expensive for large, deeply nested objects. 2. Auto-generated partial dispatchers can obscure what actually happens in updates. 3. Middleware API is Redux-like, but can't see support for async flows (like thunks or sagas).

These rules were developed in 2006 to strengthen static analysis of C code in high-stakes environments. I don't think they apply to many here.

Good start, covers the big GitLab pitfalls (auth, runners, vars, project config). The the fun part to be added: runner isolation/cleanup, built-in scans (SAST/dep/secret), logging/audit trails, push-rules (signed commits), and secret management practices. Solid so far tho.

Paywall saved me from a read rage but even the first couple of lines made me wanna do things to the author :D

In every JS/TS project, be it frontend or backend, you usually have to fetch some data. And when you go into production, you realise you need something more resilient than the native fetch.

There are some libraries on npm, but I found them either too dumb or doing too much, so I built my own.

- Timeouts - per-request or global - Retries - user-defined, defaults to exponential back-off + jitter - Circuit breaker - trip after N failures - Hooks - logging, auth, metrics, request/response transformation - Per-request overrides - customize behavior on a per-request basis - Universal - Node, Browser, Cloudflare Workers, React Native - Zero runtime deps - ships as dual ESM/CJS - Written in TypeScript

Any feedback is welcome, here or in the github repo (https://github.com/gkoos/ffetch).

Looks neat. When you detect anomalies, how can you tell whether it's the cloud provider or the public internet or a transient peer tho?

In Guix, packages are typically dynamically linked against libraries in the store. Static linking changes not just the configure flags, but also how dependencies are pulled in - you'd have to make sure every dependency is available as a static .a library for the target platform and many Guix packages aren't built with static artifacts at all.

I guessit's a mix of market size, monetization difficulty, and investor expectations: - a CLI or build tool can get huge love from devs but still serve a small, finite market - many devs will happily use a free open-source tool but won't pay unless it's mission-critical - funding is biased toward sales-driven models - successful paid devtools usually have enterprise-grade support - PH and X are cool but not for validating a sustainable business

Web bloat is coming from every angle, including - surprise - LLM's. So no, I don't think it's over. Also wdym AI companies rendering UI? You mean the chatgpt textbox?

Plivo, Vonage, Telnyx?

Oh another article that reveals the shocking news that spamming AI-generated Top 10 lists might not make you a millionaire? Yeah it might not.

There's quite a few, although LLM's are slowly creeping in: 1. everything with less data to train on: - Compiler / language toolchain development. - Specialized embedded robotics (industrial robotics, drones). - Scientific / high-performance computing

2. Low tolerance for LLM-induced errors: - Network protocols / telecom software - Medical software - Aerospace, automotive

3. Performance-critical code: - Game engine / graphics engine development (probably an area where we'll see them soon) - Kernels, drivers, microcontrollers.

etc. Not all is lost yet.

Some theory definitely comes in handy, but then you can focus on something like "AI + UI", ie. start building AI-powered interfaces:

- Chatbots, copilots, search assistants. - Image/audio/video tools that make sense to non-technical users. - Data visualization for AI outputs. - etc.

These can keep you in your comfort zone while you integrate AI.

Surprised they're not suspected to be behind Dominion

Save water for AI we can run for subscription

I see. And when everybody's fired, what will people be doing then?

I guess the more organised you are, the better off with just a textfile. I'm not, so I use layers: - postit notes - google (I know!) calendar if it's time sensitive - paper or text file notes - if it's a longer thing, maybe obsidian (I know!)

The point is, I don't think one app, any app can solve all mankind's all scheduling problems.

Yeah this might happen when you use your competitor's infrastructure

I mean most of it is legacy stuff even a sane company would kill off plus skype

Yep, what's the catch?

Looks like somebody is a tad bit over reliant on these tools but other than that there is a lot of value in this article

After a reread it's actually starting to make sense :D

Yes, pretty much most of these should have been done pre-AI too