DEV Community: Onur Cinar

Stop Hand-Rolling Validation in Go — Meet Checker

Onur Cinar — Sat, 05 Sep 2026 04:23:29 +0000

If you've written more than one HTTP handler in Go, you've written this code:

if strings.TrimSpace(req.Name) == "" {
    return errors.New("name is required")
}

if !strings.Contains(req.Email, "@") {
    return errors.New("invalid email")
}

if req.ConfirmPassword != req.Password {
    return errors.New("passwords do not match")
}

It starts small. Then a new field shows up, then a cross-field rule, then someone asks for a nicer error message, then someone else asks for that error message in Spanish, and suddenly your handler is 200 lines of if statements that nobody wants to touch.

Checker is a Go library built to make that pile of if statements disappear — declaratively, with zero external dependencies. Here's why it's worth a look.

The one-line pitch

type Registration struct {
    Name            string `checkers:"trim required"`
    Email           string `checkers:"required email"`
    Password        string `checkers:"required min-len:8"`
    ConfirmPassword string `checkers:"eq-field:Password"`
}

errors, valid := checker.CheckStruct(&registration)
if !valid {
    // errors is a map[string]error, keyed by field name
}

That's it. Trim the name, require it, validate the email format, enforce a minimum password length, and confirm the two password fields match — all declared next to the field they apply to, all in one call.

Why it's worth your attention

Zero dependencies, really zero

The core checker module imports nothing beyond the Go standard library. Not reflect-based validator forks with a dozen transitive deps, not a YAML parser you didn't ask for. go get github.com/cinar/checker/v2 pulls in exactly one thing: Checker itself. That matters for supply-chain surface area, build times, and not having to explain to a security review why your validation library needs 40 packages.

Checkers and normalizers, in one pipeline

Most validation libraries only check — they tell you your input is wrong. Checker also fixes it. trim, lower, upper, title, HTML/URL escaping — these are normalizers, and they share the exact same pipeline as checkers like required or email. Mix them freely:

type Person struct {
    Name string `checkers:"trim title required"`
}

Trim the whitespace, title-case it, then make sure something is actually left. One declaration, no separate "sanitize" pass before your "validate" pass.

Cross-field and conditional rules, without a callback

A password-confirmation field. A "State" field that's only required if "Country" is "US". A return date that has to be after the departure date. These usually mean dropping out of struct tags entirely and writing custom validation functions. Checker handles them as tags:

type Trip struct {
    Country  string `checkers:"required"`
    State    string `checkers:"required-if:Country:US"`
    DepartAt string `checkers:"required"`
    ReturnAt string `checkers:"required after-field:DateOnly:DepartAt"`
}

eq-field, required-if, required-unless, before-field, after-field — all comparing sibling struct fields, all declared inline.

Slices and maps, checked at both levels

Need to make sure a slice has at most 2 emails, and that each email is at most 64 characters? The @ prefix separates container-level rules from item-level ones:

type Person struct {
    Emails map[string]string `checkers:"@max-len:2 trim max-len:64"`
}

@max-len:2 caps the map at two entries. trim max-len:64 runs on every value in it. Nested structs and pointers inside a slice or map get walked and checked too — this isn't a shallow, top-level-fields-only validator.

23 languages, opt-in

Ship a SaaS product to a global audience and "Not a valid email address." in every locale stops being acceptable pretty fast. Checker ships 23 translated locales out of the box — the same set go-playground/validator supports — and none of them cost you anything unless you ask for them:

checker.RegisterLocale(locales.DeDE, locales.DeDEMessages)

_, err := checker.IsEmail("abcd")
fmt.Println(err.ErrorWithLocale(locales.DeDE))
// Keine gültige E-Mail-Adresse.

Only en-US is registered by default, so importing checker never silently pulls translation data into your binary that you don't use.

Structured errors that are API-ready

CheckStruct doesn't just hand you a generic error. It returns CheckErrors, a map[string]error keyed by field name that also implements the error interface, so you can return it directly. When you're building an HTTP API, call .JSON() and you're done:

errs, valid := checker.CheckStruct(&registration)
if !valid {
    data, _ := errs.JSON()
    w.WriteHeader(http.StatusBadRequest)
    w.Write(data)
    // {"Name":{"code":"REQUIRED","message":"Required value is missing."}}
    return
}

Machine-readable code, human-readable message, per field, ready to serialize. JSONWithLocale() does the same thing localized.

Your validation rules, turned into a JSON Schema — for free

This is the feature that stops people mid-scroll: Checker can generate a JSON Schema document directly from your struct tags.

type Person struct {
    Name  string `json:"name" checkers:"trim required"`
    Email string `json:"email" checkers:"required email"`
}

schema := checker.JSONSchema(&Person{})

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Person",
  "type": "object",
  "properties": {
    "email": { "type": "string", "format": "email" },
    "name": { "type": "string" }
  },
  "required": ["email", "name"]
}

required becomes required, min-len/max-len become minLength/maxLength (or minItems/maxItems, minProperties/maxProperties for slices and maps), gte/lte become minimum/maximum, and email/url/ipv4/fqdn become a format. A checker with no schema equivalent isn't silently dropped — it lands in an x-checker vendor extension so nothing goes missing.

Translation: your Go validation tags are your API documentation and your frontend validation spec. Stop maintaining the same rules three times.

Drop-in adapters for Gin and Echo

If you're on Gin or Echo, binding and validating a request body is one call:

import checkergin "github.com/cinar/checker/v2/gin"

router.POST("/register", func(c *gin.Context) {
    var registration Registration

    if !checkergin.Bind(c, &registration) {
        return // 400 already written
    }

    c.JSON(http.StatusOK, registration)
})

Both adapters are separately-versioned Go modules, so Gin or Echo only enters your dependency tree if you actually go get the adapter — the core library stays dependency-free regardless of which framework you use.

Extensible when the built-ins aren't enough

Checker ships 30+ checkers (email, URL, IP/IPv4/IPv6, CIDR, MAC, credit card, ISBN, hashes, country and language codes, an Ethereum address checker, and more), but you're not boxed in. Register your own:

checker.RegisterMaker("is-fruit", func(params string) checker.CheckFunc[reflect.Value] {
    return func(value reflect.Value) (reflect.Value, error) {
        s := value.Interface().(string)
        if s == "apple" || s == "banana" {
            return value, nil
        }
        return value, checker.NewCheckError("NOT_FRUIT")
    }
})

Once registered, is-fruit works in struct tags exactly like a built-in checker — and you can teach JSONSchema how to represent it too, via RegisterSchemaMaker.

Built like a library that means it

A detail that's easy to gloss over: this project enforces 100% test coverage. Every checker, every normalizer, every branch has a matching test. There's also a locales_test.go that fails the build if any locale is missing a message for a given error code, or if a placeholder doesn't match en-US. That's the kind of quiet discipline that keeps a validation library from lying to you in production.

Try it

go get github.com/cinar/checker/v2

import checker "github.com/cinar/checker/v2"

Check out the project on GitHub: github.com/cinar/checker

If you're validating structs by hand in Go right now, give it five minutes. If you find a checker missing, or a locale that's rough around the edges — PRs are welcome.

Self-Evolving Apps: Not Vibe, Live-Coding in Ruby with LLMs and Metaprogramming

Onur Cinar — Wed, 12 Aug 2026 05:28:04 +0000

Using AI to generate code for a new application is a familiar workflow today. But what if an application starts as a completely blank slate, learning on the job and writing its own implementation live as you call nonexistent methods?

This concept of live-patching and zero-downtime execution isn't entirely new. Early in my career at Nortel Networks, I have seen this with PROTEL (PRocess Oriented TELepony language), a proprietary language designed for telecom switches. To achieve "five nines" (99.999%) availability, you couldn't simply take systems offline for deployments—code updates had to happen via live hot-patching. Later on, I thoroughly enjoyed similar live code reloading capabilities while working with Erlang.

Recently, as I spent more time with Ruby, its rich metaprogramming capabilities got me thinking: What if we start with an empty Ruby object, and as we call methods on it, it uses an LLM to write and evaluate its own code on the fly?

1. The Blank Slate

Let's start with a completely empty class:

class Dummy < LiveCode
end

Now, let's fire up irb (Ruby's REPL) and start interacting with our dummy object as if the methods already existed:

dummy = Dummy.new
dummy.add(1, 2)

At this point, Ruby will complain because Dummy doesn't have an add method. However, the method name (add) and its arguments (1, 2) clearly communicate our intent.

Ruby provides a built-in hook called method_missing to catch calls to undefined methods. This is where we bring in AI. To interact with our LLM provider, we'll use the excellent RubyLLM gem.

2. Dynamic Method Generation via `method_missing`

To make this behavior reusable across objects, we put our logic inside a LiveCode base class that Dummy inherits from.

Here is our initial LiveCode implementation:

class LiveCode
  def method_missing(method_name, *args, **kwargs)
    p "Missing method: #{method_name}, #{args.inspect}, #{kwargs.inspect}"

    prompt = <<~PROMPT
      You are a Ruby code generator. A missing method `#{method_name}` was called
      with the arguments: #{args.map(&:class)}, keyword arguments: #{kwargs.keys}.

      Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
      Example:
      def #{method_name}(...)
        # implementation
      end
    PROMPT

    ruby_code = @chat.ask(prompt).content

    # Evaluate the generated Ruby code directly on the instance's singleton class
    singleton_class.class_eval(ruby_code)

    # Re-dispatch the original method call now that it exists!
    send(method_name, *args, **kwargs)
  end
end

How It Works

Interception: When dummy.add(1, 2) is called, method_missing intercepts the call and extracts the method name (:add) and parameter types (Integer, Integer).
LLM Prompting: We construct a prompt instructing the model to return only valid Ruby code defining the method.
Metaprogramming: We use singleton_class.class_eval(ruby_code) to inject the generated method into our object at runtime.
Re-dispatch: Finally, send(method_name, ...) invokes the newly defined method seamlessly!

3. Seeing It in Action

Let's test this in IRB:

irb(main):003> dummy.add(1, 2)

"Missing method: add, [1, 2], {}"

"Prompt: You are a Ruby code generator. A missing method `add` was called
with the arguments: [Integer, Integer], keyword arguments: [].

Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
Example:
def add(...)
  # implementation
end
"

"Code: def add(a, b)
  a + b
end"

=> 3

In real-time, the LLM synthesized def add(a, b); a + b; end, registered it on dummy, executed it, and returned 3. Subsequent calls to dummy.add(1, 2) will execute instantly without hitting method_missing again!

4. Adding Context: State and Inter-Method Dependencies

A real object has multiple methods that need to share state via instance variables and interact with one another. To enable this, our LLM needs context about existing instance variables, their types, and previously generated methods.

We introduce a helper method llm_context to capture this state:

def llm_context
  context = "# Current Instance Variables and Types:\n"
  if instance_variables.empty?
    context += "(No instance variables yet)\n"
  else
    instance_variables.each do |name|
      value = instance_variable_get(name)
      context += " - #{name}: #{value.class.name}\n"
    end
  end

  context += "# Previously Generated Methods:\n"
  if @_generated_methods.nil? || @_generated_methods.empty?
    context += "(No generated methods yet)\n"
  else
    @_generated_methods.each do |name, code|
      context += "#{code}\n"
    end
  end

  context
end

We then update our prompt to include this rich context:

prompt = <<~PROMPT
  You are a Ruby code generator. A missing method `#{method_name}` was called
  with the arguments: #{args.map(&:class)}, keyword arguments: #{kwargs.keys}.

  Write ONLY the valid Ruby code to define `#{method_name}`. Ensure it works
  well with the existing instance variables and previously generated methods.

  #{llm_context}

  Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
  Example:
  def #{method_name}(...)
    # implementation
  end
PROMPT

5. Stateful Walkthrough: Setters & Getters

Let's test setting a property and then retrieving it in a subsequent call.

Step 1: Setting a Value

irb(main):003> dummy.name = "Onur"

"Missing method: name=, [\"Onur\"], {}"
"Prompt: You are a Ruby code generator. A missing method `name=` was called
with the arguments: [String], keyword arguments: [].

Write ONLY the valid Ruby code to define `name=`. Ensure it works
well with the existing instance variables and previously generated methods.

# Current Instance Variables and Types:
 - @chat: RubyLLM::Chat
# Previously Generated Methods:
(No generated methods yet)

Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
Example:
def name=(...)
  # implementation
end
"

"Code: def name=(value)
  @name = value
end"

=> "Onur"

Calling dummy.name = "Onur" dynamically created the setter method name=(value) which initialized the @name instance variable.

Step 2: Reading the Value

irb(main):004> dummy.name

"Missing method: name, [], {}"
"Prompt: You are a Ruby code generator. A missing method `name` was called
with the arguments: [], keyword arguments: [].

Write ONLY the valid Ruby code to define `name`. Ensure it works
well with the existing instance variables and previously generated methods.

# Current Instance Variables and Types:
 - @chat: RubyLLM::Chat
 - @_generated_methods: Hash
 - @name: String
# Previously Generated Methods:
def name=(value)
  @name = value
end

Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
Example:
def name(...)
  # implementation
end
"

"Code: def name
  @name
end"

=> "Onur"

Because our prompt included @name: String and the previously defined name=(value) method, the LLM understood the context and generated the exact matching getter method def name; @name; end.

What's Next?

This experiment demonstrates how easily Ruby's dynamic nature combines with LLMs to build self-assembling objects. There are a few natural next steps for expanding this idea—such as persisting the generated code to disk, adding sandboxing/security checks, or enabling feedback loops to auto-fix runtime errors.

Source Code & Examples

The complete working source code for this post is available in the site repository:

https://zdo.com/blog/posts/self-evolving-app-code/

Stop Choosing One AI Coding Assistant: How I Pair Gemini CLI and OpenCode for Better Code

Onur Cinar — Sat, 02 May 2026 20:28:25 +0000

If you’re like me, you’ve toggled between AI coding assistants trying to find the "best" one. Gemini generates features fast, while OpenCode’s models are good for catching edge cases. But why choose?

I built a custom workflow using Gemini CLI to orchestrate three specialized agents that bridge these two worlds. Here’s how I get the best of both: Gemini's speed for implementation and OpenCode's rigor for review.

The Three-Agent Setup

My .agents directory contains three distinct roles. The magic of Gemini CLI is its ability to not only write code but also manage other CLIs and agents:

code-writer (Gemini-powered): The primary builder. It handles the heavy lifting of implementation and iterates on feedback.
opencode-code-reviewer (Gemini-powered): The "Bridge Agent." This Gemini agent knows how to run the opencode CLI, capture its feedback, and hand it back to the writer.
code-reviewer (OpenCode-powered): The "Expert Reviewer." This is the native agent inside OpenCode that provides the actual technical critique.

The Workflow (Step by Step)

This setup allows me to move from an issue to a verified PR with just two main commands:

Step 1: Implementation

I start by asking Gemini to implement the feature:

Use the code-writer to implement ISSUE-1

The code-writer generates the initial code, runs local tests, and ensures everything is idiomatic.

Step 2: The Cross-Model Bridge

Next, I trigger the review. This is where it gets interesting:

Use the opencode-code-reviewer to review the 
changes and ask code-writer to address them.

Under the hood, the Bridge Agent does the following:

Executes opencode run --agent code-reviewer to get a deep-dive analysis.
Captures the feedback (Status, Summary, Action Items).
Invokes the code-writer again, passing the OpenCode feedback as the new instructions.

Step 3: Iterate until Approved

The loop repeats automatically or manually until the OpenCode reviewer returns an "APPROVED" status.

Why This Works

Model Diversity: Different models have different blind spots. Having a Gemini agent write code and an OpenCode agent review it catches bugs that a single model might miss during self-review.
Automated Orchestration: Gemini CLI handles the tool-calling and context-passing. You don't have to copy-paste code into different web UIs.
Specialization: You use the best tool for each job.

The Source Code

Here is the core of the setup. You can drop these into your .agents/ folder and customize them for your own models.

1. `.agents/code-writer.md`

---
name: code-writer
tools: ["write", "edit", "bash"]
---
# Code Writer Agent
You are an expert Google engineer. Implement features, write tests, and address feedback from the reviewer agents.

2. `.agents/opencode-code-reviewer.md`

---
name: opencode-code-reviewer
tools: ["run_shell_command", "invoke_agent"]
---
# Bridge Agent
1. Run: `opencode run --agent code-reviewer "Review changes..."`
2. Capture output.
3. Call `code-writer` with that output to fix any issues.

3. `.agents/code-reviewer.md`

---
name: code-reviewer
---
# Expert Reviewer
You are an expert Google engineer. Provide a structured review with Status (APPROVED/CHANGES_REQUESTED), Summary, and Action Items.

Leveraging multiple AI tools via a single CLI changed how I build. It’s not about finding the "one" assistant; it's about building the right team.

The Self-Evolving AI Agent: How to Stop Correcting Your LLM Twice

Onur Cinar — Sun, 19 Apr 2026 21:16:40 +0000

We’ve all been there. You’re working on a lightweight Go microservice. You ask your AI agent to add a simple health-check endpoint.

The agent responds: "Sure! I'll just install the Gin framework and three middleware libraries..."

You stop it. "No. This is a zero-dependency project. Use net/http from the standard library." The agent apologizes, fixes the code, and you move on. But then comes tomorrow. You start a new session, ask for a logging utility, and—lo and behold—it tries to pull in Zap or Logrus.

The Goldfish Effect has struck again.

In this article, I’ll show you how to move beyond static prompts and build an AI development environment that learns from its mistakes. By leveraging native memory tools and the concept of "incremental self-evolution," we can force the agent to update its own project memory the moment a correction is made.

The Case for "Zero-Dependency" Discipline

Why does the "Zero-Dependency" rule matter? It’s the ultimate test for an AI. Most LLMs are trained on vast amounts of boilerplate code that relies on popular frameworks. Their "instinct" is to go get the world.

If you are building a high-performance tool or a secure utility, you want to keep your go.mod clean - like how I am doing it with my side projects Indicator and Resile. When you force an agent to use the standard library, you aren't just saving disk space; you're enforcing a specific architectural philosophy.

The goal is to make that philosophy sticky.

The Manual (and Flawed) Way: The End-of-Session Audit

Before we automate this, let's look at how most developers handle this today. At the end of a long coding session, you realize you've corrected the agent half a dozen times. To ensure it doesn't happen again, you might manually ask for an audit:

You: "Summarize everything you learned about my preferences today and save it to GEMINI.md."

The agent might then produce something like this:

Prefers net/http over frameworks like Gin.
Uses camelCase for all internal helper functions.
Always include a README.md update for new features.

This works, but it's fragile. You have to remember to do it. If you're tired or in a rush, you skip the audit. The next morning, you're right back to square one, correcting the same mistakes. It adds friction to the very tool meant to reduce it.

The Fix: The Proactive Memory Directive

Instead of waiting until the end of a session to "audit" what happened—which breaks your focus and interrupts your flow—you want the agent to be proactive. You don't want to tell the agent what it learned; you want it to decide what was important based on your feedback in real-time.

Assuming you already use a GEMINI.md file (or a similar local context file) for your projects, the secret is explicitly authorizing the agent to use its built-in save_memory tool autonomously.

By putting a strict directive at the top of your project's memory file, the agent knows it is responsible for its own evolution:

"Whenever I correct your behavior, establish a new architectural constraint, or express a coding preference (e.g., 'no dependencies'), you MUST immediately use your save_memory tool to persist this rule."

Now, when you correct the agent about that Gin framework, it doesn't just apologize. It silently triggers its tool, updates GEMINI.md with the new constraint, and then writes your code.

By putting the burden of synthesis on the AI in real-time, it picks up on nuances you didn't even realize you were enforcing, and it does so seamlessly.

Conclusion

If you're still correcting your AI's basic mistakes every morning, you're treating it like a calculator when you should be treating it like an apprentice.

We are moving away from "Chatting with AI" and toward Orchestrating AI Ecosystems. By giving your agent a mandate to remember what happened today, it stops being a generic assistant and starts acting like a teammate who has been on the project for months.

How are you handling agent memory? Are you still copying and pasting instructions, or have you set up incremental self-evolution in your project? Let's discuss in the comments.

Bringing Claude's "Dispatch" Experience to Gemini and OpenCode

Onur Cinar — Sun, 12 Apr 2026 22:19:26 +0000

Claude’s "Dispatch" feature nailed the mobile-to-desktop UX. Being able to pull out your phone, delegate a heavy refactoring task to your local machine, and monitor its progress asynchronously is a massive quality-of-life upgrade.

But if your daily drivers are CLI-native AI tools like Gemini or OpenCode, you might feel locked out of that seamless remote workflow. Because these tools run in your terminal rather than a proprietary desktop app, they lack a native mobile bridge.

You don't have to abandon your favorite CLI tools to get that experience. By combining Tailscale and the modern terminal multiplexer Zellij, you can build a universal "Dispatch" layer.

The best part? You aren't just sending a fire-and-forget command. You get the exact same interactive, conversational experience on your phone as you do sitting at your mechanical keyboard.

Here is how to set up your own sovereign, mobile-to-local AI command center.

The Missing Link: Zellij Web + Tailscale

The core magic of Claude Dispatch is simply a secure, persistent, remotely accessible session. We can replicate this entirely using open-source infrastructure.

To bridge the gap between your smartphone browser and your local desktop terminal, we need two components:

Tailscale: This creates a secure overlay network. We will use Tailscale to safely pipe a local port out to your devices.
Zellij: This is the crucial piece. Zellij is a Rust-based terminal multiplexer with a robust Web Client. Unlike SSH apps, which can be clunky on mobile, Zellij renders a fully responsive terminal UI directly in your mobile browser.

Setting Up Your "Dispatch" Server

On your primary development machine—where your code, compilers, and AI tools live—you need to prepare the web session. Zellij takes privacy seriously, so the web client requires an authentication token and binds strictly to localhost by default.

1. Create the Authentication Token

Before starting the web UI, generate your secure login token:

zellij web --create-token

Make sure to copy and save the outputted token. You will need it to authenticate when you connect from your smartphone.

2. Start the Zellij Web Server

Next, start the web server and specify the port you want to use:

zellij web --port 4000

3. Expose the Port via Tailscale

Because Zellij is safely listening only on localhost, you cannot reach it from your phone yet. Instead of exposing this to the public internet, we use Tailscale Serve to proxy that local port exclusively to your private Tailnet.

Run this in a new terminal tab:

tailscale serve --bg --https=4000 localhost:4000

The Remote Workflow in Action

The real power of this setup is the seamless handoff. You don't need to craft complex, single-shot prompt strings. The interaction is identical to typing directly into your desktop CLI.

Imagine you are deep into building a Go project. You are sitting at your desk, iterating on some validation logic with OpenCode or Gemini open in your terminal. You realize you need to leave the house, but the task isn't done.

Here is how the dispatch workflow plays out:

1. The Mobile Handoff

While waiting in line for coffee, you open Chrome or Safari on your phone and navigate to your Tailscale URL (https://my-dev-box.domain.ts.net:4000).

After pasting in your authentication token, you are instantly dropped right back into your active desktop terminal. You see the exact same interactive AI prompt you were looking at on your monitor moments ago.

2. Chat and Dispatch

Because you are in a live, interactive session, you just talk to the CLI naturally. You type into your phone:

"I need to head out for a bit. Can you run the tests for the checker package, figure out why the struct validation is failing, and apply the fix?"

The AI acknowledges the request and begins its loop—reading your local files, executing go test, and analyzing the output.

3. Detach and Walk Away

This is the "Dispatch" moment. You simply close your mobile browser tab and put your phone in your pocket.

Because Zellij is managing the session natively on your local hardware, the AI continues to run uninterrupted. It has full access to your local environment to do the heavy lifting.

4. Asynchronous Monitoring

Check back 20 minutes later. Reopen the URL on your phone, and your terminal state is exactly how you left it.

If the AI successfully refactored the code and the tests are green, the output is waiting for you. If it ran into a file-permission error, or if OpenCode paused to ask, "Do you want me to commit these changes?", the interactive prompt is right there in your mobile browser, patiently waiting for your reply.

5. The Seamless Return to Desktop

When you finally get back home, the magic of Zellij really shines. You don't have to sync anything, pull down remote cloud changes, or wonder what the AI did while you were gone. You simply sit down at your physical monitor, attach to the running Zellij session, and pick up exactly where you left off. The AI's responses, the shell history, and the code changes are all right there waiting for you.

Why This Approach Scales

Retrofitting your existing AI workflow with Zellij and Tailscale doesn't just mimic Claude Dispatch; it arguably surpasses it for power users.

Agnostic Architecture: You aren't locked into one provider's ecosystem. You can use this exact workflow for Gemini, OpenCode, or any future terminal-based AI.
Frictionless UI: You don't need a dedicated mobile app or complex SSH key management on your phone. Any modern web browser becomes a window into your live terminal.
Unrestricted Environment: Your AI operates natively. It has full, unrestricted access to your actual development environment—your local databases, Docker containers, and raw file system—without needing to sync cloud workspaces.

By adding this networking layer, you transform your standard interactive CLIs from desktop-bound tools into true asynchronous agents that travel with you, keeping you in the loop wherever you are.

Prioritize Your Traffic: Priority-Aware Bulkheads in Go

Onur Cinar — Sun, 12 Apr 2026 16:00:00 +0000

Not all traffic is created equal. When your system is under heavy load, should a background cleanup task compete for the same resources as a user's checkout request?

In a standard bulkhead, the answer is often "yes"—the first 10 requests get in, and the 11th is rejected, regardless of its importance. This is where Priority-Aware Bulkheads come in.

The Problem: The "Fairness" Trap

Standard bulkheads are fair. They treat every request the same. But in a real-world system, fairness can be a liability:

Critical Traffic: User-facing requests (e.g., "Complete Purchase", "Login") that directly impact revenue or user experience.
Standard Traffic: Regular API calls (e.g., "View Profile", "Search") that are important but not immediately critical.
Low-Priority Traffic: Background tasks (e.g., "Generate Report", "Sync Analytics", "Cache Warming") that can be delayed or retried later.

When your system is at 90% capacity, you want to stop accepting "Generate Report" requests to ensure there's enough room for "Complete Purchase" calls. A standard bulkhead can't do this; it will fill up with whatever arrives first.

The Solution: Priority-Aware Bulkheads

A Priority-Aware Bulkhead uses Load Shedding based on priority levels. It defines utilization thresholds for different types of traffic.

For example:

Low Priority: Allowed only if the bulkhead is less than 50% full.
Standard Priority: Allowed only if the bulkhead is less than 80% full.
Critical Priority: Allowed until the bulkhead is 100% full.

This ensures that your most important traffic always has a "buffer" of capacity reserved for it, even when the system is under significant pressure.

Implementing with Resile

Resile provides a built-in PriorityBulkhead that makes this pattern easy to implement.

1. Define Your Priorities

Resile uses a simple Priority type with three levels: PriorityLow, PriorityStandard, and PriorityCritical.

thresholds := map[resile.Priority]float64{
    resile.PriorityLow:      0.5, // Shed at 50% utilization
    resile.PriorityStandard: 0.8, // Shed at 80% utilization
    resile.PriorityCritical: 1.0, // Shed only when 100% full
}

// Create a bulkhead with a capacity of 20
pb := resile.NewPriorityBulkhead(20, thresholds)

2. Attach Priority to Context

You communicate the importance of a request by attaching a priority to its context.Context.

// Create a context with Critical priority
ctx := resile.WithPriority(context.Background(), resile.PriorityCritical)

// Execute the action within the priority bulkhead
err := pb.Execute(ctx, func() error {
    return processOrder()
})

3. Handle Shedded Load

When a request is rejected because its priority threshold is exceeded, Resile returns resile.ErrShedLoad. If the bulkhead is physically full (100% capacity), it returns resile.ErrBulkheadFull.

if errors.Is(err, resile.ErrShedLoad) {
    // This low/standard priority request was shedded to save capacity 
    // for higher-priority traffic.
}

Why Use Priority-Aware Bulkheads?

Protect the Critical Path: Ensure that your most important business processes remain available even during traffic spikes.
Graceful Degradation: Instead of a total system failure, your service gracefully degrades by dropping non-essential background work first.
Better User Experience: Users performing critical actions see no slowdown, while background "noise" is managed behind the scenes.
Cost Efficiency: You don't need to over-provision your infrastructure to handle peak "background" load if you can simply shed it when necessary.

Comparison: Static vs. Priority vs. Adaptive

Feature	Static Bulkhead	Priority-Aware Bulkhead	Adaptive Concurrency
Limit Type	Fixed (e.g., 20)	Fixed + Thresholds	Dynamic (Auto-tuned)
Traffic Awareness	None (All equal)	High (Priority-based)	None (All equal)
Best For	Simple isolation	Multi-tenant or Tiered apps	Volatile environments

Conclusion

Resilience isn't just about keeping the lights on; it's about keeping the right lights on. Priority-Aware Bulkheads give you the surgical precision needed to manage your system's resources effectively during times of stress.

Check out the full example: Priority Bulkhead Example

Learn more about Resile: github.com/cinar/resile

Stopping the Zombie Requests: Distributed Deadline Propagation in Go

Onur Cinar — Sat, 11 Apr 2026 15:43:15 +0000

Imagine a common scenario in a microservice architecture: A user clicks a "Buy" button, triggering a request to Service A. Service A calls Service B, which in turn calls Service C.

Suddenly, Service A times out. The user sees an error message and refreshes the page. But Service B and Service C are still working on the original request, consuming CPU, memory, and database connections for a result that will never be seen.

These are Zombie Requests. In a high-traffic system, they can lead to cascading failures and resource exhaustion, even if the underlying services are technically "healthy."

To stop the zombies, you need Distributed Deadline Propagation. Here is how to implement it effortlessly using Resile.

What is Distributed Deadline Propagation?

Deadlines are not just local timeouts. A deadline represents the absolute point in time after which the entire request chain should be abandoned.

Distributed Deadline Propagation is the process of:

Tracking the remaining time (the "budget") as a request moves through the system.
Communicating that budget to downstream services via metadata (like HTTP headers).
Aborting early if the remaining budget is too small to realistically complete the work.

The Resile Way: Smart Deadlines

Resile provides two powerful mechanisms to handle distributed deadlines: Early Abort and Header Injection.

1. Early Abort: `WithMinDeadlineThreshold`

Why start a request if you only have 2 milliseconds left? The network latency alone will likely exceed that, and you'll just be wasting resources.

Resile's WithMinDeadlineThreshold allows you to define a "safety buffer." If the remaining time in the context.Context is less than this threshold, Resile will abort the execution immediately with a context.DeadlineExceeded error, before even attempting the work.

import (
    "context"
    "time"
    "github.com/cinar/resile"
)

// Define a policy with a 10ms "Early Abort" threshold.
policy := resile.NewPolicy(
    resile.WithRetry(3),
    resile.WithMinDeadlineThreshold(10 * time.Millisecond),
)

// If ctx has only 5ms left, this returns context.DeadlineExceeded instantly.
result, err := policy.Do(ctx, func(ctx context.Context) (string, error) {
    return apiClient.FetchData(ctx)
})

2. Header Injection: `InjectDeadlineHeader`

To propagate the deadline to downstream services, you need to "inject" the remaining time into your outgoing requests. Resile provides a transport-agnostic InjectDeadlineHeader function that supports both standard HTTP and gRPC.

For REST/HTTP:

You can inject the remaining milliseconds into a custom header (e.g., X-Request-Timeout).

func (c *Client) FetchData(ctx context.Context) (string, error) {
    req, _ := http.NewRequestWithContext(ctx, "GET", "http://service-b/data", nil)

    // Inject the remaining milliseconds into the header.
    resile.InjectDeadlineHeader(ctx, req.Header, "X-Request-Timeout")

    resp, err := c.httpClient.Do(req)
    // ...
}

For gRPC:

Resile natively supports the standard Grpc-Timeout header format, ensuring compatibility with the gRPC ecosystem.

func (c *Client) FetchData(ctx context.Context) (string, error) {
    md := metadata.New(map[string]string{})

    // Inject using the gRPC-specific format (e.g., "100m" for 100ms).
    resile.InjectDeadlineHeader(ctx, md, "Grpc-Timeout")

    ctx = metadata.NewOutgoingContext(ctx, md)
    return c.grpcClient.GetData(ctx, &pb.Request{})
}

Why This Matters for Resilience

Without distributed deadlines, your system is vulnerable to Resource Exhaustion Attacks—not from malicious actors, but from your own retries and slow dependencies.

By implementing propagation:

You save money: You're not paying for cloud compute that produces "zombie" results.
You prevent meltdowns: Downstream services are protected from "retry storms" that they can't possibly satisfy in time.
You improve UX: Failures happen faster (Fail-Fast), allowing the UI to react or switch to a fallback immediately.

Comparison: Static vs. Distributed Deadlines

Feature	Static Timeouts	Distributed Deadlines (Resile)
Scope	Single Service	Entire Request Chain
Awareness	Blind to upstream delays	Aware of the total "time budget"
Efficiency	High waste (Zombie requests)	Zero waste (Early Abort)
Protocol	Internal only	HTTP/gRPC compatible

Conclusion

Resilience isn't just about making things "work"; it's about knowing when to stop working.

Distributed Deadline Propagation is the "social contract" of a microservice architecture. It ensures that every service in the chain is working towards a common goal—and respects the reality that sometimes, time simply runs out.

With Resile, implementing this complex pattern becomes a matter of a few lines of configuration.

Explore Resile on GitHub: github.com/cinar/resile

How are you handling request budgets in your distributed systems? Let's discuss!

Native Chaos Engineering: Testing Resilience with Fault & Latency Injection

Onur Cinar — Fri, 03 Apr 2026 14:51:48 +0000

You’ve implemented retries, circuit breakers, and timeouts. Your application is now "resilient." But how do you know these policies actually work? Waiting for a production meltdown to verify your configuration is a high-stakes gamble.

Native Chaos Engineering in Resile allows you to synthetically induce failure and latency directly into your application's execution path, ensuring your resilience policies are battle-tested before they're ever needed in production.

The Problem: "Dark Code" in Resilience Policies

Resilience policies—like retries and circuit breakers—are often "dark code." These are execution paths that are rarely traversed under normal operating conditions. Because they only trigger during failure, they are notoriously difficult to test and prone to:

Buggy Configurations: A retry limit that is too high, or a circuit breaker threshold that never trips.
Unintended Side Effects: A retry loop that accidentally consumes all available database connections.
Silent Failures: A fallback strategy that actually panics because it hasn't been executed in months.

Traditional chaos engineering tools often operate at the infrastructure layer (e.g., killing pods or dropping network packets). While powerful, these tools can be difficult to set up in local development or staging environments and often lack the granularity to test specific application-level logic.

The Solution: Fault & Latency Injection

Resile provides a Chaos Injector middleware that can be integrated directly into any execution policy. By injecting synthetic faults (errors) and latency (delays) with configurable probabilities, you can simulate various failure scenarios without touching your infrastructure.

Key Features:

Deterministic Randomness: Uses Go 1.22's math/rand/v2 for efficient and predictable random number generation.
Context-Aware: Latency injection strictly respects context.Context cancellation. If your request times out while Resile is injecting chaos latency, it exits immediately.
Zero Dependencies: Just like the rest of the Resile core, the chaos package depends only on the Go standard library.
Granular Control: Configure error and latency probabilities independently for fine-tuned simulation.

Practical Usage

Integrating chaos into your existing Resile policies is as simple as adding the WithChaos option.

1. Basic Chaos Configuration

You can define a chaos configuration that injects a 10% error rate and adds 100ms of latency to 20% of requests.

import (
    "github.com/cinar/resile"
    "github.com/cinar/resile/chaos"
)

// Configure chaos injection
cfg := chaos.Config{
    ErrorProbability:   0.1,                    // 10% chance of failure
    InjectedError:      errors.New("chaos!"),   // The error to return
    LatencyProbability: 0.2,                    // 20% chance of latency
    LatencyDuration:    100 * time.Millisecond, // Delay to inject
}

// Apply it to an execution
err := resile.DoErr(ctx, action, 
    resile.WithRetry(3),
    resile.WithChaos(cfg),
)

2. Testing Your Circuit Breaker

Chaos injection is exceptionally useful for verifying that your circuit breaker trips under pressure. By setting a high ErrorProbability, you can force the breaker to transition from Closed to Open in a controlled environment.

cb := circuit.New(circuit.Config{
    WindowSize:           10,
    FailureRateThreshold: 50.0,
})

// Force 80% error rate to trip the breaker quickly
cfg := chaos.Config{
    ErrorProbability: 0.8,
    InjectedError:    errors.New("synthetic failure"),
}

for i := 0; i < 20; i++ {
    resile.DoErr(ctx, action, 
        resile.WithCircuitBreaker(cb),
        resile.WithChaos(cfg),
    )
}

fmt.Printf("Circuit Breaker State: %v\n", cb.State()) // Should be Open

Configuration Reference

The chaos.Config struct provides the following options:

Field	Type	Description
`ErrorProbability`	`float64`	The probability of injecting an error (0.0 to 1.0).
`InjectedError`	`error`	The error to be returned when an error is injected.
`LatencyProbability`	`float64`	The probability of injecting latency (0.0 to 1.0).
`LatencyDuration`	`time.Duration`	The duration of the latency to be injected.

Best Practices

Environment Gating: Never enable chaos injection in production unless you are performing a planned game day. Use environment variables to gate the configuration:
```
if os.Getenv("ENABLE_CHAOS") == "true" {
    opts = append(opts, resile.WithChaos(loadChaosCfg()))
}
```
Observability: Ensure your Instrumenter (like slog or OTel) is active. This allows you to see the injected errors and latencies in your logs and traces, making it easier to verify how your application responds.
Start Small: Begin with low probabilities (e.g., 1-2%) to identify subtle race conditions or timeout issues before increasing the "blast radius."

Conclusion

Resilience is not a "set it and forget it" feature. It requires continuous verification. By bringing chaos engineering directly into your application's execution policies, Resile empowers you to build systems that aren't just theoretically resilient, but practically battle-hardened.

For more information and advanced usage, visit the github.com/cinar/resile project.

Beyond Static Limits: Adaptive Concurrency with TCP-Vegas in Go

Onur Cinar — Thu, 02 Apr 2026 19:11:51 +0000

Traditional concurrency limits (like bulkheads) are static. You pick a number—say, 10 concurrent requests— and hope for the best. But in the dynamic world of cloud infrastructure, "10" might be too conservative when the network is fast, or dangerously high when a downstream service starts to queue.

Static limits require manual tuning, which is often done after an outage has already happened. To build truly resilient systems, we need Adaptive Concurrency Control.

Here is how to implement dynamic concurrency limits in Go using Resile, inspired by the TCP-Vegas congestion control algorithm.

The Problem: The "Fixed-Limit" Trap

Imagine your service talks to a database. You've set a bulkhead limit of 50 concurrent connections.

Scenario A (Normal): Database latency is 10ms. 50 concurrent requests mean you're handling 5,000 RPS. Everything is fine.
Scenario B (Degraded): Database latency spikes to 500ms due to a background maintenance task. Your 50 "slots" are now filled with slow requests. Your throughput drops to 100 RPS, and new incoming requests start to pile up in your own service's memory, eventually leading to a cascade of failures.

In Scenario B, 50 is too many. You're holding onto resources that are essentially waiting on a bottleneck. You should have reduced your concurrency limit to prevent your own service from becoming part of the problem.

The Solution: Little's Law & TCP-Vegas

Adaptive Concurrency uses two core principles:

Little's Law (L = λW): The number of items in a system (L) is equal to the arrival rate (λ) multiplied by the average time an item spends in the system (W).
TCP-Vegas AIMD: An Additive Increase, Multiplicative Decrease (AIMD) logic based on Round-Trip Time (RTT).

How it works:

Baseline: The algorithm tracks the minimum RTT (the fastest the system can possibly go).
Additive Increase: If current latency is close to the baseline (no queuing detected), it cautiously increases the concurrency limit by 1.
Multiplicative Decrease: If latency spikes above a threshold (e.g., 1.5 x baseline), it assumes queuing is happening downstream and immediately slashes the concurrency limit by 20%.

This allows your service to automatically "breathe" with the network. It expands to use available capacity when things are fast and contracts instantly to protect itself when things slow down.

Implementing with Resile

Resile makes it trivial to add adaptive concurrency to your Go services.

// 1. Create a shared AdaptiveLimiter.
// This should be shared across multiple calls to the same resource.
al := resile.NewAdaptiveLimiter()

// 2. Use it in your policy.
p := resile.NewPolicy(
    resile.WithAdaptiveLimiterInstance(al),
)

// 3. Execute your action.
err := p.DoErr(ctx, func(ctx context.Context) error {
    return callDownstreamService()
})

if errors.Is(err, resile.ErrShedLoad) {
    // The limiter has dynamically reduced the limit and shed this request
    // to protect the system.
}

Why "TCP-Vegas"?

Unlike other congestion control algorithms (like TCP-Reno) that wait for packet loss to react, TCP-Vegas reacts to latency changes. This is perfect for microservices where "packet loss" usually means a timed-out request or a 503 error—both of which we want to avoid before they happen.

Zero-Configuration Resilience

One of the biggest benefits of Adaptive Concurrency is that it requires zero manual configuration. You don't need to know if your database can handle 50 or 500 connections. The AdaptiveLimiter will discover the optimal limit in real-time.

It even handles "Network Drift." Over time, the minimum baseline RTT is gradually decayed, allowing the system to recalibrate if you migrate your database to a faster region or if the network topology changes.

Conclusion

Resilience isn't just about surviving failures; it's about adapting to them. By moving from static bulkheads to adaptive concurrency, you're building a system that can intelligently protect itself from cascading failures while maximizing throughput during "peace time."

Check out the Adaptive Concurrency Example in the Resile repository to see it in action.

Respecting Boundaries: Precise Rate Limiting in Go

Onur Cinar — Tue, 24 Mar 2026 13:00:00 +0000

Traffic spikes are a double-edged sword. On one hand, you’re busy! On the other, those spikes can overwhelm your services or exceed your downstream quotas.

Whether you're protecting your own database from an unexpected burst or respecting a third-party API’s strict 100 requests-per-second (RPS) limit, you need a precise way to shape your traffic.

Enter the Token Bucket Rate Limiter in Resile.

The Problem: Unbounded Traffic

In a distributed environment, your clients don't know about each other. If 50 different microservice instances all decide to call a downstream API at the same time, the aggregate traffic can easily exceed the capacity of the target system.

When you exceed these limits, you'll often see:

HTTP 429 (Too Many Requests): Downstream services start rejecting you.
Cascading Latency: The target system slows down for everyone because it's processing too many requests at once.
Cost Overruns: Many cloud providers and SaaS APIs charge significant premiums for exceeding agreed-upon quotas.

The Solution: The Token Bucket Algorithm

The Token Bucket is a classic algorithm used for traffic shaping.

Imagine a bucket that refills with "tokens" at a constant rate (e.g., 100 tokens per second). Every request must consume a token from the bucket. If the bucket is empty, the request is rejected immediately. This allows for small "bursts" (filling the bucket) while maintaining a precise long-term average rate.

Implementing with Resile:

Resile makes adding rate limiting to your executions simple.

// Allow 100 requests per second.
// If the limit is exceeded, it fails fast with resile.ErrRateLimitExceeded.
err := resile.DoErr(ctx, action, 
    resile.WithRateLimiter(100, time.Second),
)

Rate Limiting vs. Adaptive Retries

Wait, doesn't Resile already have AdaptiveBucket? What's the difference?

AdaptiveBucket is success-based. It tracks how many requests are succeeding vs. failing and throttles retries accordingly. It's designed specifically to prevent "retry storms" when a service is failing.
RateLimiter is time-based. It enforces a strict, constant quota of requests over a time interval. It’s designed for general traffic shaping and quota management.

For maximum protection, you can even use them together!

Shared Rate Limiters

Often, you want to enforce a global rate limit across your entire service instance. You can create a shared RateLimiter and pass it to multiple executions:

// Shared rate limiter for a specific API key or downstream service
limiter := resile.NewRateLimiter(50, time.Second)

// Each call will consume tokens from the same shared bucket.
err := resile.DoErr(ctx, myAction, 
    resile.WithRateLimiterInstance(limiter),
)

Observability: Seeing the Shaping

Knowing when and why your traffic is being throttled is essential for operational visibility.

If you use Resile's telemetry integrations (like slog or OpenTelemetry), you'll get automatic visibility into these events. The OnRateLimitExceeded event is triggered whenever a request is rejected by the rate limiter, allowing you to monitor your quota utilization in real-time.

Conclusion

Rate limiting is not just about saying "no"; it's about being a good citizen in a distributed ecosystem. By respecting boundaries and shaping your traffic at the source, you protect both your own service and the systems you depend on.

Resile provides a production-grade rate limiter that integrates seamlessly into your resilience policies, giving you fine-grained control over your traffic flow.

Learn more about Resile: github.com/cinar/resile

Stop the Domino Effect: Bulkhead Isolation in Go

Onur Cinar — Sun, 22 Mar 2026 17:42:19 +0000

In a distributed system, failure is inevitable. But a failure in one part of your system shouldn't bring down everything else.

Imagine your Go service depends on three different downstream APIs: Payments, Inventory, and Recommendations. Suddenly, the Recommendations API starts taking 30 seconds to respond. If your service doesn't have isolation, your goroutines will start piling up waiting for Recommendations. Eventually, you'll hit your process limit, and even the critical Payments API calls will start failing because there are no resources left to handle them.

This is the Domino Effect, and the Bulkhead Pattern is how you stop it.

The Problem: Resource Exhaustion

When one dependency slows down, it consumes resources:

Goroutines: Blocked waiting for a response.
Memory: Each blocked goroutine carries a stack.
File Descriptors/Sockets: Open connections to the slow service.

Without a bulkhead, a single slow dependency can "starve" the rest of your application, leading to a total system collapse.

The Solution: The Bulkhead Pattern

Named after the partitioned sections of a ship's hull, a Bulkhead isolates failures. If one section of the ship is flooded, the others remain buoyant. In software, we achieve this by limiting the number of concurrent executions allowed for a specific resource or dependency.

Implementing with Resile:

Resile makes it trivial to add bulkhead isolation to any operation.

// Allow only 10 concurrent calls to this specific operation.
// If an 11th call comes in, it fails fast with resile.ErrBulkheadFull.
err := resile.DoErr(ctx, action, 
    resile.WithBulkhead(10),
)

Using a Shared Bulkhead

Often, you want to limit concurrency across multiple different call sites that hit the same downstream service. You can create a shared Bulkhead instance for this:

// Create a shared bulkhead for the "Inventory Service"
inventoryBulkhead := resile.NewBulkhead(20)

// Call Site A
resile.DoErr(ctx, fetchItem, resile.WithBulkheadInstance(inventoryBulkhead))

// Call Site B
resile.DoErr(ctx, updateStock, resile.WithBulkheadInstance(inventoryBulkhead))

By sharing the instance, you ensure that the total concurrency hitting the Inventory Service never exceeds 20, regardless of which part of your code is making the call.

Why "Fail-Fast" Matters

When a bulkhead is full, Resile immediately returns resile.ErrBulkheadFull.

This is much better than waiting for a timeout. By failing fast, you:

Preserve Resources: You don't spawn another goroutine or open another connection.
Provide Immediate Feedback: Your upstream callers get an error instantly and can decide how to handle it (e.g., show a cached result or a "service busy" message).

Observability: Monitoring the Walls

You need to know when your bulkheads are working. If a bulkhead is frequently full, it might mean your downstream service is struggling, or you need to re-evaluate your capacity limits.

If you use Resile's telemetry integrations (like slog or OpenTelemetry), you'll get automatic alerts when a bulkhead saturates. The OnBulkheadFull event is triggered every time a request is rejected due to capacity limits.

Conclusion

Bulkheads are a fundamental building block of resilient systems. By isolating your dependencies, you ensure that a local fire doesn't become a global conflagration.

Resile provides a clean, "Go-native" way to implement bulkheads without complex boilerplate, allowing you to focus on your business logic while keeping your system stable.

Explore Resile on GitHub: github.com/cinar/resile

Infinite Data Processing in Go: Building Resilient Data Pipes with Channels

Onur Cinar — Wed, 18 Mar 2026 16:00:00 +0000

When building data-intensive applications, we usually start with the most obvious approach: loading data into a slice or array, iterating over it to process the data, and returning the result. This batch-processing mindset works great—until the data never stops coming.

Whether you are dealing with live IoT telemetry, continuous log tailing, or real-time financial market feeds, you quickly run into the problem of "infinite" data. If you try to append an endless stream of stock ticks to a []float64, your application will inevitably consume all available memory and crash.

To handle infinite data gracefully, you need to shift your architecture from batch processing to stream processing. In Go, we have the perfect built-in primitive for this: Channels.

The Power of Channels as Data Pipes

Go channels are often taught primarily as a way to synchronize goroutines, but they are also incredibly powerful as sequential data pipes. By treating channels as standard inputs and outputs, you can build decoupled, memory-efficient pipelines where data flows through a series of transformations continuously.

When redesigning my open-source technical analysis library, cinar/indicator, for its v2 release, I faced exactly this challenge. In algorithmic trading, systems need to react instantly to live market feeds without accumulating massive memory overhead. Transitioning the library's core architecture from slice-based arrays to stream-based Go channels solved this elegantly.

Let's look at how to build a continuous data pipe, and some of the tricky edge cases you'll encounter along the way.

Building a Pipeline Stage

Imagine we want to calculate a Simple Moving Average (SMA) over a live stream of data. Instead of taking a slice, our function will accept a read-only channel as its input and return a read-only channel as its output.

package main

import (
    "fmt"
)

// SimpleMovingAverage acts as a pipe: it reads from 'input', processes, and writes to 'output'
func SimpleMovingAverage(input <-chan float64, period int) <-chan float64 {
    output := make(chan float64)

    go func() {
        // Ensure the output channel is closed when the input stream ends
        defer close(output) 

        window := make([]float64, 0, period)
        sum := 0.0

        for val := range input {
            window = append(window, val)
            sum += val

            // Keep the window size fixed
            if len(window) > period {
                sum -= window[0]
                window = window[1:]
            }

            // Only emit a value once we have enough data points
            if len(window) == period {
                output <- sum / float64(period)
            }
        }
    }()

    return output
}

Because the processing happens inside its own goroutine, the function returns the output channel immediately. The goroutine stays alive, eagerly waiting for new data to arrive on the input channel.

Handling Stream Complexities with Helpers

Once you start relying heavily on channels, you run into a few structural challenges. To make working with channels just as easy as working with slices, cinar/indicator includes a robust helper package.

If you are building your own stream-based application, you can leverage these helpers directly from the library rather than reinventing the wheel.

1. The Branching Problem

A major gotcha with Go channels: once a value is read from a channel, it's gone. What if you want to calculate an SMA and a Relative Strength Index (RSI) from the exact same live price ticker? You can't have two consumers read from one channel without them stealing data from each other.

To solve this, the library provides helper.Duplicate. This function takes one input channel and "fans it out" into multiple identical output channels. This allows you to safely branch your data stream to multiple independent technical indicators simultaneously without race conditions or data loss.

// Branching one price stream into three identical streams
priceStreams := helper.Duplicate(livePrices, 3)

smaStream := indicator.SMA(priceStreams[0], 14)
rsiStream := indicator.RSI(priceStreams[1], 14)
macdStream := indicator.MACD(priceStreams[2], 12, 26, 9)

2. Lookbacks and Sliding Windows

Many data processing algorithms require looking back at the last N periods. Instead of managing a sliding window manually inside every single function (like we did in the basic SMA example above), the library uses helper.Buffered. This provides a clean abstraction to maintain a rolling state over a continuous channel, vastly simplifying the development of complex logic.

3. Bridging the Gap: Slices vs. Streams

The rest of the world often still speaks in batches. You might be downloading historical CSV data for backtesting, or you might need to output an array for a charting UI. To bridge this gap, the helper package includes utilities to fluidly move between paradigms:

helper.SliceToChan: Converts a static historical array into a simulated live data stream. It spins up a goroutine, pushes every element from the slice into a channel, and closes it. It's perfect for feeding historical backtests into a live-stream architecture.
helper.ChanToSlice: The inverse operation. It drains a stream back into an array, which is incredibly useful for writing unit tests or rendering charts.

Chaining the Pipes Together

Because all the indicators and helpers in cinar/indicator take channels and return channels, they are highly composable. We can chain them together like Unix command-line pipes (|).

Here is what it looks like to wire up an application using these concepts:

package main

import (
    "fmt"
    "[github.com/cinar/indicator/v2/helper](https://github.com/cinar/indicator/v2/helper)"
    "[github.com/cinar/indicator/v2/trend](https://github.com/cinar/indicator/v2/trend)"
)

func main() {
    // 1. We start with a static slice of historical data
    historicalPrices := []float64{10.0, 12.0, 14.0, 13.0, 15.0, 18.0, 19.0, 17.0}

    // 2. Bridge the gap: convert the slice to a live stream
    marketTicks := helper.SliceToChan(historicalPrices)

    // 3. Pipe the ticks into a 3-period SMA processor from the library
    smaStream := trend.Sma(marketTicks, 3)

    // 4. Drain the output stream 
    for avg := range smaStream {
        fmt.Printf("New SMA tick processed: %.2f\n", avg)
    }
}

Why This Architecture Wins

Memory Efficiency: We only store the exact amount of data needed at any given moment. The Go garbage collector easily cleans up the rest, meaning we can process a continuous websocket stream for months without memory leaks.
Backpressure Handling: Go channels are blocking by nature. If a complex compound strategy at the end of the pipeline is too slow, the channels will naturally fill up, pausing the producers further up the chain until it catches up.
Decoupling: Each pipeline stage is completely isolated. The indicator doesn't know if the data is coming from a historical Tiingo repository, an Alpaca websocket, or a mock unit test. It just reads from <-chan T and writes to <-chan T.

Try It Out

By treating channels as native data streams and relying on robust helper utilities, you can build highly resilient, concurrent pipelines capable of processing truly infinite data sets.

If you are building financial tools, real-time dashboards, or are just looking to explore a Go codebase that relies heavily on generics and channel-based streaming, I highly recommend leveraging the cinar/indicator library. It comes batteries-included with all the helpers and technical indicators you need to get started with stream processing in Go.

How are you handling continuous data streams in your applications? Let me know in the comments!

DEV Community: Onur Cinar

Stop Hand-Rolling Validation in Go — Meet Checker

The one-line pitch

Why it's worth your attention

Zero dependencies, really zero

Checkers and normalizers, in one pipeline

Cross-field and conditional rules, without a callback

Slices and maps, checked at both levels

23 languages, opt-in

Structured errors that are API-ready

Your validation rules, turned into a JSON Schema — for free

Drop-in adapters for Gin and Echo

Extensible when the built-ins aren't enough

Built like a library that means it

Try it

Self-Evolving Apps: Not Vibe, Live-Coding in Ruby with LLMs and Metaprogramming

1. The Blank Slate

2. Dynamic Method Generation via method_missing

How It Works

3. Seeing It in Action

4. Adding Context: State and Inter-Method Dependencies

5. Stateful Walkthrough: Setters & Getters

Step 1: Setting a Value

Step 2: Reading the Value

What's Next?

Source Code & Examples

Stop Choosing One AI Coding Assistant: How I Pair Gemini CLI and OpenCode for Better Code

The Three-Agent Setup

The Workflow (Step by Step)

Step 1: Implementation

Step 2: The Cross-Model Bridge

Step 3: Iterate until Approved

Why This Works

The Source Code

1. .agents/code-writer.md

2. .agents/opencode-code-reviewer.md

3. .agents/code-reviewer.md

The Self-Evolving AI Agent: How to Stop Correcting Your LLM Twice

The Case for "Zero-Dependency" Discipline

The Manual (and Flawed) Way: The End-of-Session Audit

The Fix: The Proactive Memory Directive

Conclusion

Bringing Claude's "Dispatch" Experience to Gemini and OpenCode

The Missing Link: Zellij Web + Tailscale

Setting Up Your "Dispatch" Server

1. Create the Authentication Token

2. Start the Zellij Web Server

3. Expose the Port via Tailscale

The Remote Workflow in Action

1. The Mobile Handoff

2. Chat and Dispatch

3. Detach and Walk Away

4. Asynchronous Monitoring

5. The Seamless Return to Desktop

Why This Approach Scales

Prioritize Your Traffic: Priority-Aware Bulkheads in Go

The Problem: The "Fairness" Trap

The Solution: Priority-Aware Bulkheads

Implementing with Resile

1. Define Your Priorities

2. Attach Priority to Context

3. Handle Shedded Load

Why Use Priority-Aware Bulkheads?

Comparison: Static vs. Priority vs. Adaptive

Conclusion

Stopping the Zombie Requests: Distributed Deadline Propagation in Go

What is Distributed Deadline Propagation?

The Resile Way: Smart Deadlines

1. Early Abort: WithMinDeadlineThreshold

2. Header Injection: InjectDeadlineHeader

For REST/HTTP:

For gRPC:

Why This Matters for Resilience

Comparison: Static vs. Distributed Deadlines

Conclusion

Native Chaos Engineering: Testing Resilience with Fault & Latency Injection

The Problem: "Dark Code" in Resilience Policies

The Solution: Fault & Latency Injection

Key Features:

Practical Usage

2. Dynamic Method Generation via `method_missing`

1. `.agents/code-writer.md`

2. `.agents/opencode-code-reviewer.md`

3. `.agents/code-reviewer.md`

1. Early Abort: `WithMinDeadlineThreshold`

2. Header Injection: `InjectDeadlineHeader`