DEV Community: arif

I Benchmarked 7 LLMs on Cross-Domain MCP Orchestration. All 7 Found the Same Gap.

arif — Mon, 09 Mar 2026 03:38:02 +0000

The Problem

The Model Context Protocol (MCP) has 106 official servers and 50+ academic papers. But every single study evaluates one server at a time. Nobody has asked: what happens when you compose multiple MCP servers for cross-domain tasks?

I decided to find out.

What I Did

Experiment A: Real MCP Tool Calls

I connected 6 MCP servers simultaneously:

arXiv (academic preprints)
PubMed (biomedical literature)
Firecrawl (web search and scraping)
Context7 (library documentation)
Memory (persistent knowledge graph)
Filesystem (file operations)

Then I ran 3 cross-domain case studies with 17 real tool calls and 0% failure rate.

The key discovery: insights that are impossible within any single server become visible when you combine them. For example, arXiv papers on AI mental health chatbots and PubMed clinical trials on the same topic turned out to be two disconnected research communities working on the same problem with zero cross-citations. This gap was only visible by querying both databases and linking the results through a knowledge graph.

Experiment B: 7-Model Benchmark

I took the data collected from those MCP servers and sent identical prompts to 7 different LLMs:

Model	Latency	Tokens	KG Entities	KG Relations
GPT-5.4	54.7s	2,352	14	15
DeepSeek R1	33.9s	4,296	6	4
Mistral Large 3	6.5s	1,857	9	8
Llama 4 Maverick	3.0s	1,374	3	3
Gemini 2.5 Flash	15.6s	4,592	12	11
Claude Sonnet 4.5	21.3s	2,411	13	11
Claude Haiku 4.5	9.3s	2,136	8	6

Every model successfully produced 5 cross-domain insights. But the depth varied wildly: GPT-5.4 built a knowledge graph with 14 entities and 15 relations, while Llama 4 Maverick produced only 3 entities in 3 seconds.

The Finding All 7 Models Agreed On

Here is the most interesting part. Without being told what to look for, all 7 models independently identified the same research gap:

LangChain provides MultiServerMCPClient (the mechanism). Benchmarks evaluate individual tool calls. But nobody documents composition patterns for how to effectively orchestrate multi-server workflows.

I call this the mechanism-pattern gap. It is like how HTTP existed for years before REST patterns told people how to use it effectively.

5 Composition Patterns

From my experiments, I identified 5 recurring patterns:

Sequential Pipeline - Server A output feeds Server B query
Parallel Fan-Out - Same query to multiple servers at once
Cross-Reference Verification - Validate findings across servers
Iterative Refinement - Cross-server context narrows queries
Domain Bridging - Synthesize insights from unrelated domains

Domain Bridging is the most valuable. It produces insights that exist in neither source alone.

Try It Yourself

All servers are open source and require no API keys:

uvx arxiv-mcp-server
npx @cyanheads/pubmed-mcp-server
npx @modelcontextprotocol/server-memory
npx firecrawl-mcp
npx @upstash/context7-mcp
npx @modelcontextprotocol/server-filesystem

The benchmark script and full results are on GitHub:

github.com/doganarif/mcp-bench

Paper: Zenodo DOI

If you are an arXiv endorser for cs.SE and this seems reasonable, I would appreciate the help: endorsement link

I am Arif Dogan, a software engineer and independent researcher in Berlin. I build things with Go, Python, and LLMs. arif.sh | GitHub

AI Agent Failures Are Distributed Systems Failures. Here's the Complete Mapping.

arif — Fri, 20 Feb 2026 01:57:01 +0000

A few months into building an AI agent pipeline for a fintech client, we had a silent failure that cost us three days.

The agent processed a document. Returned a confident-looking response. No error, no exception, no log entry that suggested anything was wrong. That output went into the next step, which used it to write a decision record. The decision record went downstream. Three steps later, a human reviewer flagged something that did not add up.

The root cause was a hallucinated intermediate field. One field. The model had made up a plausible-sounding value for something it should have extracted from the document. Everything downstream had treated that invented value as real.

I had seen this failure mode before. Not in AI. In distributed systems.

The microservice that returns 200 OK while writing corrupted data. The queue consumer that marks a message processed before finishing the work. The retry that fires twice because the ACK never arrived.

Same pattern. Different worker.

The mental model that changes everything

An AI agent is not a program that figures things out. It is a graph of tasks, each processed by a nondeterministic worker. The worker is expensive, slow, and occasionally wrong in ways that look correct. Everything else about the system, including how it should be built, is a distributed systems problem.

Here is the complete mapping:

Distributed systems concept	AI agent equivalent
Message queue	Task buffer between agent steps
Dead letter queue	Failed tasks awaiting human review
Idempotency key	Deterministic task ID preventing duplicate LLM calls
Circuit breaker	Model fallback when primary LLM degrades or rate-limits
Saga pattern + compensation	Multi-step workflow rollback when a step fails midway
Two-phase commit	Human approval gate before any irreversible action
Distributed tracing	Per-step observability across agent execution
Backpressure	Concurrency limits on parallel LLM calls
Bulkhead pattern	Cost and rate isolation between tenants or features

Every one of these concepts exists because engineers got paged at 3am when they did not have it. AI agent engineers are getting paged for exactly the same reasons. They are building the same workarounds and calling them new things.

The people writing most of the content about AI agents come from ML backgrounds. They have never been responsible for a distributed system that split-brained in production. They are reinventing concepts that have names.

Problem 1: Silent failures that compound across steps

This is the issue nobody who writes tutorials has actually experienced in a high-stakes system. LLM workers do not fail loudly. They return well-formed, confident-looking output that is semantically wrong. In a single-step system a human catches it. In a multi-step agent, the wrong output becomes the input to the next step.

By the time you see the problem, the causal chain is four steps long and the original error is buried.

The distributed systems answer: validate at every step boundary. Do not pass raw LLM output downstream. Treat every LLM response as untrusted input until it passes a validation check.

type StepResult struct {
    Raw      string
    Valid    bool
    Schema   string
}

type Validator interface {
    Validate(output, schema string) error
}

func (w *Worker) processStep(ctx context.Context, input string, schema string) (*StepResult, error) {
    raw, err := w.llm.Complete(ctx, input)
    if err != nil {
        return nil, err
    }

    if err := w.validator.Validate(raw, schema); err != nil {
        // self-correction: one retry with the validation error in context
        corrected, err2 := w.llm.Complete(ctx, fmt.Sprintf(
            "Your previous response failed validation: %s\n\nOriginal task: %s\n\nTry again.",
            err.Error(), input,
        ))
        if err2 != nil {
            return nil, err
        }
        if err3 := w.validator.Validate(corrected, schema); err3 != nil {
            return nil, fmt.Errorf("validation failed after correction: %w", err3)
        }
        raw = corrected
    }

    return &StepResult{Raw: raw, Valid: true, Schema: schema}, nil
}

Self-correction on first validation failure recovers about 90% of cases in practice. The remaining 10% go to a dead letter queue, not to the next step in the pipeline.

Problem 2: Idempotency, the hardest problem in agent systems

This is the one I underestimated the most.

In standard distributed systems, idempotency is straightforward: assign a key, deduplicate on that key, retry safely. In agent systems, there is a complication. The LLM worker is nondeterministic. Retry with the same input and you may get a different output.

This creates a genuine design question: what does it mean to retry an agent step idempotently?

The answer that works in practice: record the output the first time the step runs. On retry, return the recorded output rather than calling the LLM again. The task ID becomes the idempotency key.

type TaskStore interface {
    Get(ctx context.Context, taskID string) (string, bool, error)
    Set(ctx context.Context, taskID string, result string) error
}

func (w *Worker) run(ctx context.Context, task Task) (string, error) {
    // check if already completed
    if result, ok, err := w.store.Get(ctx, task.ID); err != nil {
        return "", fmt.Errorf("store get: %w", err)
    } else if ok {
        return result, nil
    }

    result, err := w.processStep(ctx, task.Input, task.Schema)
    if err != nil {
        return "", err
    }

    if err := w.store.Set(ctx, task.ID, result.Raw); err != nil {
        return "", fmt.Errorf("store set: %w", err)
    }

    return result.Raw, nil
}

This also makes your workflows resumable. A pipeline that crashes midway can restart from the last completed step rather than from scratch. In the fintech system this was essential: reprocessing a document from scratch on retry risked producing a different decision record.

The one place this pattern breaks down: when you want a fresh LLM response on retry because the recorded one failed validation. The solution is to record the output only after validation passes. Failed attempts do not get persisted.

Problem 3: Multi-step workflows need a rollback plan

Here is a scenario that forced me to think about this properly.

A four-step pipeline: extract data from a document, validate it against business rules, write a decision record, trigger a downstream system. The first three steps succeed. Step four fails. What do you do?

Without explicit design, you are stuck. The decision record exists. Retrying the whole pipeline from the start would write a duplicate. Doing nothing leaves the system in a broken intermediate state.

The Saga pattern from distributed systems has a direct answer: every step that has side effects needs a compensating action that undoes it.

type Step struct {
    Name       string
    Execute    func(ctx context.Context, state *State) error
    Compensate func(ctx context.Context, state *State) error
}

type Saga struct {
    steps    []Step
    executed []int
}

func (s *Saga) Run(ctx context.Context, state *State) error {
    for i, step := range s.steps {
        if err := step.Execute(ctx, state); err != nil {
            log.Printf("step %s failed, rolling back %d completed steps", step.Name, len(s.executed))
            for j := len(s.executed) - 1; j >= 0; j-- {
                if cerr := s.steps[s.executed[j]].Compensate(ctx, state); cerr != nil {
                    log.Printf("compensation for step %s failed: %v", s.steps[s.executed[j]].Name, cerr)
                }
            }
            return fmt.Errorf("step %d (%s) failed: %w", i, step.Name, err)
        }
        s.executed = append(s.executed, i)
    }
    return nil
}

Applied to the document pipeline: if the downstream notification fails, the compensation for the decision-record step deletes it. The system returns to a clean state and the whole workflow can safely retry.

Most agent frameworks do not give you this. They give you a chain of steps and leave failure handling as an exercise for the reader.

Problem 4: Human-in-the-loop as blast radius management

One of the cleanest mental models I have encountered for human review in agent systems: scope the human-in-the-loop requirement to the blast radius of the action.

A read-only action that retrieves data: no approval needed, just log it.
A write action that can be undone: soft approval, allow with logging and rollback capability.
An irreversible action (sending an email, triggering a payment, deleting a record): hard approval gate, requires explicit human confirmation before execution.

This is not a safety net. It is an architecture decision about which operations an automated system is permitted to take unilaterally.

type BlastRadius int

const (
    BlastRadiusRead        BlastRadius = iota // read-only, no approval
    BlastRadiusReversible                     // can be undone, soft approval
    BlastRadiusIrreversible                   // cannot be undone, hard approval
)

type ActionGate interface {
    Request(ctx context.Context, action Action, radius BlastRadius) (Approval, error)
}

type Action struct {
    ID          string
    Description string
    Params      map[string]any
    Radius      BlastRadius
}

In the German government system, any output below a confidence threshold and any action classified as irreversible went to a human review queue. Not because we lacked confidence in the model, but because the downstream consequences of an error had legal weight. The auditors asked specifically about this control. Having it designed explicitly made the audit straightforward.

The engineers I see struggling most with this are the ones trying to automate 100% of cases. A more honest design goal: automate the 90-95% the system can handle confidently, and escalate the rest with full context attached.

Problem 5: Circuit breakers for model failures

LLM APIs have bad days. Rate limits, degraded performance, elevated error rates. You need a circuit breaker.

type State int

const (
    StateClosed   State = iota // normal operation
    StateOpen                  // failing fast
    StateHalfOpen              // testing recovery
)

type CircuitBreaker struct {
    mu          sync.Mutex
    state       State
    failures    int
    threshold   int
    lastFailure time.Time
    timeout     time.Duration
}

func (cb *CircuitBreaker) Allow() bool {
    cb.mu.Lock()
    defer cb.mu.Unlock()

    switch cb.state {
    case StateOpen:
        if time.Since(cb.lastFailure) > cb.timeout {
            cb.state = StateHalfOpen
            return true
        }
        return false
    default:
        return true
    }
}

func (cb *CircuitBreaker) Record(err error) {
    cb.mu.Lock()
    defer cb.mu.Unlock()

    if err != nil {
        cb.failures++
        cb.lastFailure = time.Now()
        if cb.failures >= cb.threshold {
            cb.state = StateOpen
        }
    } else {
        cb.failures = 0
        cb.state = StateClosed
    }
}

In a multi-model setup, combine the circuit breaker with a fallback: primary model trips the circuit, requests route to a cheaper backup. This keeps the system available during provider incidents. It also gives you a cheap escape valve when costs spike unexpectedly.

Speaking of costs.

Problem 6: Observability and cost attribution

In the summer of last year, a team publicly shared that they had spent $47k running AI agents in production before understanding where the money was going. The number got attention because people recognized the scenario.

LLM costs are invisible until they are not. A feature that costs nothing at 100 users is a real number at 100,000. An edge case that you never hit in testing might consume 40x the tokens of a typical case.

You cannot find this without logging every call with the context you need to understand it.

type CallTrace struct {
    TraceID          string
    FeatureName      string
    StepName         string
    Model            string
    PromptTokens     int
    CompletionTokens int
    CacheHit         bool
    LatencyMs        int64
    ValidationPassed bool
    Attempt          int
    Timestamp        time.Time
}

func tokenCost(model string, prompt, completion int) float64 {
    rates := map[string][2]float64{
        "gpt-4o":              {0.0000025, 0.000010},
        "gpt-4o-mini":         {0.00000015, 0.0000006},
        "claude-3-5-sonnet":   {0.000003, 0.000015},
        "claude-3-5-haiku":    {0.0000008, 0.000004},
    }
    r, ok := rates[model]
    if !ok {
        return 0
    }
    return float64(prompt)*r[0] + float64(completion)*r[1]
}

Store the traces. Aggregate costs by feature, by step, by user. Build a dashboard before the bill surprises you, not after.

The secondary value: when something fails in production, you have the full execution trace. Input, intermediate steps, output, validation result. In a regulated environment this is not optional. Auditors ask for it. In any environment it makes debugging tractable instead of theoretical.

What this means for frameworks

The popular agent frameworks optimize for developer experience. They make it fast to connect LLM calls, experiment with different prompting strategies, and ship a demo.

That is genuinely useful. I have used some of them for prototyping.

The problem is they tend to abstract away exactly what matters in production: queue semantics, idempotency, compensation flows, circuit breakers, cost attribution. You end up responsible for a system you do not fully understand, where the hard parts live inside library code you cannot easily inspect.

The pattern that works: use a framework to figure out what your workflow should do. When you are ready to ship, write the orchestration layer with infrastructure primitives. Keep the LLM integration logic. Replace the framework's queue and retry machinery with something you control.

This sounds like more work. It is less work in practice, because when something goes wrong at 2am you can actually find the problem.

The Germany constraint that turned out to be good engineering

The German government clients had a requirement I initially saw as a handicap: every decision made by the system had to be explainable to a civil servant who had no background in AI.

That requirement killed several architectural ideas that would have worked fine in a consumer product. It forced the system toward a design where every step is logged with its inputs and outputs, the LLM is one component in a documented process rather than a black box, and there is always a human review path for anything below a defined confidence threshold.

The resulting system is more verbose. It is also significantly easier to debug, trivial to audit, and more reliable under real load.

The explainability requirement is coming for regulated industries whether teams are ready for it or not. Financial services, healthcare, legal, government. Design for it now and you get better engineering as a side effect.

Where to start

If you are building an agent system and currently thinking mainly about prompts, here is a concrete sequence:

Define your task schema first. What does a valid output look like at each step? What validation rules apply? This determines your circuit-break conditions and your dead letter queue trigger.
Add idempotency before you add features. Assign a deterministic task ID to every step. Store results. Make it safe to retry.
Design your Saga before you wire up the steps. For every step that writes something, know what the compensation action is.
Set your blast radius policy. Which actions require human approval before execution? Write it down as code, not documentation.
Add the cost trace from day one. Not later. The cost dashboard is significantly harder to retrofit than to build initially.

The prompt engineering is the interesting part. The infrastructure is what makes it shippable.

If you are working on production AI systems and want to compare notes, I am at arif.sh/work.

Building Production LLM Pipelines in Go: Lessons From the Field

arif — Tue, 17 Feb 2026 23:56:33 +0000

I've spent the last two years integrating LLMs into production systems - a fintech platform processing millions of transactions and a document processing pipeline for government-scale workloads. Go is not the obvious choice for AI work. Python gets all the attention. But for production backends where reliability, cost, and latency actually matter, Go has been the better call every time.

Here's what I've learned.

Why Go for LLM pipelines?

The Python AI ecosystem is rich but chaotic. LangChain adds abstractions on top of abstractions. Dependency conflicts are constant. Async code that works in a notebook falls apart under real concurrency.

Go gives you:

Predictable memory usage under load
Goroutines for cheap, real concurrency (not async/await workarounds)
Compile-time errors that catch the stupid mistakes before they hit production
A single binary that deploys anywhere

The tradeoff is you write more code. There is no LangChain equivalent in Go. But in my experience, that is a feature. You understand exactly what your pipeline is doing.

The architecture that works

After iterating on several production systems, I keep coming back to this structure:

Request → Validator → ContextBuilder → LLMClient → ResponseParser → Cache → Response

Each stage is a function that takes input and returns output. No magic, no framework. Just functions.

type Pipeline struct {
    validator      Validator
    contextBuilder ContextBuilder
    llmClient      LLMClient
    parser         ResponseParser
    cache          Cache
}

func (p *Pipeline) Run(ctx context.Context, req Request) (Response, error) {
    if err := p.validator.Validate(req); err != nil {
        return Response{}, fmt.Errorf("validation: %w", err)
    }

    context, err := p.contextBuilder.Build(ctx, req)
    if err != nil {
        return Response{}, fmt.Errorf("context: %w", err)
    }

    cacheKey := p.cache.Key(req, context)
    if cached, ok := p.cache.Get(cacheKey); ok {
        return cached, nil
    }

    raw, err := p.llmClient.Complete(ctx, context)
    if err != nil {
        return Response{}, fmt.Errorf("llm: %w", err)
    }

    result, err := p.parser.Parse(raw)
    if err != nil {
        return Response{}, fmt.Errorf("parse: %w", err)
    }

    p.cache.Set(cacheKey, result)
    return result, nil
}

Simple. Each component is testable in isolation. Swap the LLM client without touching anything else.

The mistakes that cost real money

1. Not caching aggressively enough

LLM calls are expensive. In a document processing pipeline, the same context gets rebuilt and sent to the model repeatedly for similar inputs. We added a two-layer cache: in-memory for hot keys, Redis for warm keys. Cost dropped 40% overnight.

The key insight: you do not need semantic similarity matching for most caching. A hash of the normalized input is enough for 80% of cache hits.

func (c *PipelineCache) Key(req Request, ctx PipelineContext) string {
    h := sha256.New()
    h.Write([]byte(req.NormalizedInput()))
    h.Write([]byte(ctx.SystemPrompt))
    return hex.EncodeToString(h.Sum(nil))
}

2. Treating LLM errors like HTTP errors

LLMs fail in ways HTTP servers do not. You get:

Rate limit errors (back off and retry)
Malformed JSON responses (retry with a stricter prompt)
Responses that are technically valid but semantically wrong (detect and escalate)
Context window overflows (truncate and retry)

Each failure mode needs a different response. A generic retry loop handles none of them well.

func (c *LLMClient) Complete(ctx context.Context, req CompletionRequest) (string, error) {
    var lastErr error
    for attempt := 0; attempt < c.maxRetries; attempt++ {
        resp, err := c.call(ctx, req)
        if err == nil {
            return resp, nil
        }

        var rateLimitErr *RateLimitError
        var contextErr *ContextWindowError

        switch {
        case errors.As(err, &rateLimitErr):
            wait := time.Duration(rateLimitErr.RetryAfterSeconds) * time.Second
            select {
            case <-time.After(wait):
            case <-ctx.Done():
                return "", ctx.Err()
            }
        case errors.As(err, &contextErr):
            req = req.WithTruncatedContext(contextErr.MaxTokens)
        default:
            lastErr = err
            time.Sleep(backoff(attempt))
        }
    }
    return "", fmt.Errorf("max retries exceeded: %w", lastErr)
}

3. Building prompts with string concatenation

It starts fine. Then someone adds a special case. Then another. Then you have a 200-line function full of if/else building a string and nobody knows what the model is actually seeing.

Treat prompts like templates. Keep them in separate files. Version them.

type PromptTemplate struct {
    System string
    User   string
}

func (t *PromptTemplate) Render(vars map[string]any) (CompletionRequest, error) {
    systemTmpl, err := template.New("system").Parse(t.System)
    if err != nil {
        return CompletionRequest{}, err
    }
    // ... render both templates
}

When a prompt changes, it is a code change with a diff. Not a hidden string mutation buried in a function.

4. No observability until something breaks in production

Add structured logging from the start. Log the input hash, model, token counts, latency, and cache hit/miss on every call. When costs spike or latency degrades, you need this to debug.

c.logger.Info("llm_call",
    "input_hash", req.Hash(),
    "model", c.model,
    "prompt_tokens", usage.PromptTokens,
    "completion_tokens", usage.CompletionTokens,
    "latency_ms", latency.Milliseconds(),
    "cache_hit", false,
)

I use this to build a cost dashboard per feature, per user, per day. Without it you are flying blind.

RAG in Go: keep it boring

Retrieval-augmented generation does not need a vector database for most use cases. I have seen teams spin up Pinecone or Weaviate for a use case that would work fine with Postgres and pgvector.

Start with pgvector. It is boring. It works. You already have Postgres. The query looks like:

SELECT content, 1 - (embedding <=> $1) AS similarity
FROM documents
WHERE 1 - (embedding <=> $1) > 0.7
ORDER BY similarity DESC
LIMIT 5;

Migrate to a dedicated vector store when you have a real performance problem. Not before.

For generating embeddings in Go:

type EmbeddingClient struct {
    httpClient *http.Client
    apiKey     string
    model      string
}

func (e *EmbeddingClient) Embed(ctx context.Context, text string) ([]float32, error) {
    // standard HTTP call to your embedding endpoint
    // returns float32 slice ready for pgvector
}

No SDK needed. The API is a POST request. Write the 30 lines and move on.

Structured output without the drama

Getting JSON out of an LLM reliably is harder than it looks. Models hallucinate keys, nest objects incorrectly, or return valid JSON wrapped in markdown code blocks.

What works in production:

Use a model that supports native JSON mode or function calling
Define your schema explicitly in the prompt with an example
Validate with a strict parser, not json.Unmarshal directly
Retry on parse failure with a self-correction prompt: "Your previous response was not valid JSON. Here is the error: {error}. Please try again."

The self-correction step recovers 90% of parse failures without a human in the loop.

Cost math before you build

Before writing a line of code, do the math:

daily_requests * avg_input_tokens * input_price
+ daily_requests * avg_output_tokens * output_price
= daily_cost

Then ask: what is the cache hit rate I can realistically achieve? What is the monthly cost at 10x scale?

I have seen products that were profitable at 100 users become unprofitable at 1000 because nobody did this calculation. LLM costs scale linearly. Your pricing needs to account for it.

What I would do differently

If I were starting a new LLM-heavy Go service today:

Build the cache layer before the LLM integration, not after
Log token usage from day one, not when the bill arrives
Keep prompts in files, not code
Write an LLM interface with a mock implementation for tests
Do the cost math before committing to a feature

The patterns that work in Go for LLM pipelines are not exotic. They are the same patterns that work for any external API integration: encapsulate, cache, observe, handle errors explicitly. The LLM just has a few extra failure modes.

If you are building something that needs a production AI backend and want to talk through the architecture, I am available for contracts. arif.sh/work

The Real Deal Behind EngageCraft.io’s Creation

arif — Wed, 28 Feb 2024 09:03:00 +0000

Hello World! I’m here to pull back the curtain on how EngageCraft.io went from a sketch on a napkin to a live SaaS platform in the span of a single weekend. No fluff, just the straight-up journey of building my first indie project.

The Spark and the Sprint

The idea? Simple yet ambitious: create a tool where users feed in their product URL, and out pops ready-to-use social media content for platforms like Twitter and Reddit. The catch? I wanted to see it live by Monday morning. Why wait, right?

Choosing Laravel: No Regrets

Laravel was my weapon of choice for this sprint. I needed something that would let me move fast without breaking things (too much). Laravel Forge and Breeze weren’t just tools; they were my lifelines to a smooth deployment and an MVP that didn’t look like it was held together by duct tape. I chose Laravel because it promised—and delivered—a way to develop quickly and deploy smoothly, a non-negotiable for my crazy deadline.

Marketing: The Unexpected Journey

With EngageCraft.io built, I stared down my next challenge: marketing. I was a developer stepping into a marketer’s shoes, and it felt like learning to walk all over again. But here’s the thing—I was building EngageCraft.io for people like me, and who better to sell it to them than one of their own? So, I dove headfirst into marketing with the same gusto I applied to coding.

The Takeaway

Building EngageCraft.io on a weekend was a wild ride. There were moments of doubt, sure, but also moments of pure adrenaline. It was more than just coding; it was about bringing a vision to life, learning new skills on the fly, and pushing beyond what I thought was possible.

Looking Forward

This isn’t just the end of a weekend project; it’s the beginning of something bigger. EngageCraft.io is live, but it’s also evolving. I’m on a mission to refine it, scale it, and see it become the go-to tool for social media content generation.

So, what’s the moral of the story? Don’t wait. If you’ve got an idea, chase it. Build it. Launch it. The world needs more creators who are willing to leap, especially over a weekend.

Embarking on 2024: Dreams, Challenges, and Adventures

arif — Sun, 31 Dec 2023 23:34:09 +0000

Happy New Year, everyone! As we step into 2024, I am filled with a mix of excitement and anticipation. This year, I am determined to create new habits and reinvent myself. There is something about the start of a new year that gives me hope and ignites the urge to chase my dreams.

I am incredibly grateful to have my wife by my side on this journey. Her constant encouragement and unwavering belief in the power of pursuing our dreams have been contagious. She reminded me that it is never too late to set new goals and turn our aspirations into reality.

Here is my ambitious game plan for 2024:

European Escapades : This year, I have promised myself to finally explore the vibrant streets of Europe. From the historical alleys of Rome to the scenic beauty of the Swiss Alps, I am eagerly looking forward to immersing myself in the diverse cultures and landscapes.
A Year of Books : My bookshelf is overflowing with titles that have been waiting to be read. This year, I am committed to finally giving those pages the attention they deserve. I aim to delve into a wide range of genres, from classic literature to modern tech manuals.
Fitness Journey : It is time for me to prioritize my health. I will start with a few mornings of exercise each week. I understand that this won't be an easy journey, but I am fully committed to making it a part of my lifestyle.
Coding Mastery : As a programmer, I recognize the importance of continuously improving my skills. To achieve this, I am setting a goal to tackle three LeetCode problems daily. This will undoubtedly be challenging, but I am ready to embrace the task and grow as a developer.

To make all of this happen, I will focus on taking small, consistent steps. I understand the value of building habits gradually and not overwhelming myself with too much at once.

Additionally, reflection will be a vital part of my journey. I will use this blog to not only share my triumphs but also to document the inevitable setbacks that come along the way. After all, personal growth is not a linear path.

I am incredibly excited to share these experiences with all of you. I hope that my journey will inspire you to chase your own dreams, no matter their size. I am also eager to hear about your plans and aspirations – let's support and motivate each other!

So, here's to an unforgettable year in 2024! We have dreams to chase, habits to form, and adventures to embark on. This year will be a time of discovery, learning, and undoubtedly, a lot of fun. Let us make the most of it together!

Cheers to a year of turning dreams into reality. I cannot wait to embark on this adventure with all of you. Let the journey begin!

Creating Real-Time WebSockets with Go and WebAssembly

arif — Thu, 09 Nov 2023 12:21:07 +0000

Writing WebAssembly with Go was always something I wanted to do, but finding examples or tutorials was hard, so I decided to shuffle through pages.

In this post, I'll share with you my learnings and some code examples.

This project is an exciting exploration into the world of real-time web communication. We're delving into connecting a WebSocket directly from WebAssembly (Wasm) code, enabling dynamic interactions within the web page. By leveraging WebSocket events, we can manipulate the Document Object Model (DOM) in response to live data, creating an interactive and responsive user experience.

Project Outline

In this project, we will create a WebSocket service (using Gorilla WebSocket), a WASM service, and an index.html (this is solely to see what we've done).

Folder Structure

In this basic project, we're keeping the folder structure straightforward to avoid complexity. All that's required is a wasm/ directory for the WebAssembly files, a pkg/socket/ directory for the socket service logic, and a public/ directory to house our frontend assets.

So project will look like this.

main.go
wasm/
pkg/socket/
public/
Makefile

Let's Code!

public/index.html

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <title>Go WASM Button Example</title>
  <script src="wasm_exec.js"></script>
  <style>
    #btn {
      position: absolute;
      top: 50%;
      left: 50%;
      transform: translate(-50%, -50%);
    }
  </style>
</head>

<body>
  <p id="text"></p>
  <button id="btn">Click me</button>
  <script>
    const go = new Go();

    WebAssembly.instantiateStreaming(fetch("main.wasm"), go.importObject).then((result) => {
      go.run(result.instance);
    });

    document.getElementById("btn").addEventListener("click", () => {
      onButtonClick();
    });
  </script>
</body>

</html>

Our HTML layout is intentionally minimalistic, featuring a single button centrally placed on the screen. When clicked, this button activates a 'click' event, which in turn calls the buttonClick() function.

Additionally, positioned at the top of the screen is a <p> tag with id text, which we will dynamically manipulate from our WebAssembly code.

pkg/socket/manage.go

package socket

import (
    "log"
    "math/rand"
    "net/http"
    "sync"

    "github.com/gorilla/websocket"
)

// Pre-configure the upgrader, which is responsible for upgrading
// an HTTP connection to a WebSocket connection.
var (
    websocketUpgrader = websocket.Upgrader{
        ReadBufferSize:  1024,
        WriteBufferSize: 1024,
    }
)

// NotifyEvent represents an event that contains a reference
// to the client who initiated the event and the message to be notified.
type NotifyEvent struct {
    client  *Client
    message string
}

// Client represents a single WebSocket connection.
// It holds the client's ID, the WebSocket connection itself, and
// the manager that controls all clients.
type Client struct {
    id         uint32
    connection *websocket.Conn
    manager    *Manager

    writeChan chan string
}

// Manager keeps track of all active clients and broadcasts messages.
type Manager struct {
    clients ClientList

    sync.RWMutex

    notifyChan chan NotifyEvent
}

// ClientList is a map of clients to keep track of their presence.
type ClientList map[*Client]bool

// NewClient creates a new Client instance with a unique ID, its connection,
// and a reference to the Manager.
func NewClient(conn *websocket.Conn, manager *Manager) *Client {
    return &Client{
        id:         rand.Uint32(),
        connection: conn,
        manager:    manager,
        writeChan:  make(chan string),
    }
}

// readMessages continuously reads messages from the WebSocket connection.
// It will send any received messages to the manager's notification channel.
func (c *Client) readMessages() {
    defer func() {
        c.manager.removeClient(c)
    }()

    for {
        messageType, payload, err := c.connection.ReadMessage()

        c.manager.notifyChan <- NotifyEvent{client: c, message: string(payload)}

        if err != nil {
            if websocket.IsUnexpectedCloseError(err, websocket.CloseGoingAway, websocket.CloseAbnormalClosure) {
                log.Printf("error reading message: %v", err)
            }
            break
        }
        log.Println("MessageType: ", messageType)
        log.Println("Payload: ", string(payload))
    }
}

// writeMessages listens on the client's write channel for messages
// and writes any received messages to the WebSocket connection.
func (c *Client) writeMessages() {
    defer func() {
        c.manager.removeClient(c)
    }()

    for {
        select {
        case data := <-c.writeChan:
            c.connection.WriteMessage(websocket.TextMessage, []byte(data))
        }
    }
}

// NewManager creates a new Manager instance, initializes the client list,
// and starts the goroutine responsible for notifying other clients.
func NewManager() *Manager {
    m := &Manager{
        clients:    make(ClientList),
        notifyChan: make(chan NotifyEvent),
    }

    go m.notifyOtherClients()

    return m
}

// otherClients returns a slice of clients excluding the provided client.
func (m *Manager) otherClients(client *Client) []*Client {
    clientList := make([]*Client, 0)

    for c := range m.clients {
        if c.id != client.id {
            clientList = append(clientList, c)
        }
    }

    return clientList
}

// notifyOtherClients waits for notify events and broadcasts the message
// to all clients except the one who sent the message.
func (m *Manager) notifyOtherClients() {
    for {
        select {
        case e := <-m.notifyChan:
            otherClients := m.otherClients(e.client)

            for _, c := range otherClients {
                c.writeChan <- e.message
            }
        }
    }
}

// addClient adds a new client to the manager's client list.
func (m *Manager) addClient(client *Client) {
    m.Lock()
    defer m.Unlock()

    m.clients[client] = true
}

// removeClient removes a client from the manager's client list and
// closes the WebSocket connection.
func (m *Manager) removeClient(client *Client) {
    m.Lock()
    defer m.Unlock()

    if _, ok := m.clients[client]; ok {
        client.connection.Close()
        delete(m.clients, client)
    }
}

// ServeWS is an HTTP handler that upgrades the HTTP connection to a
// WebSocket connection and registers the new client with the manager.
func (m *Manager) ServeWS(w http.ResponseWriter, r *http.Request) {
    log.Println("New Connection")

    conn, err := websocketUpgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println(err)
        return
    }

    client := NewClient(conn, m)
    m.addClient(client)

    go client.readMessages()
    go client.writeMessages()
}

Our WebSocket service is powered by a Go file that relies on the gorilla/websocket library. It begins with setting up an Upgrader from the library, which transitions an HTTP connection to the WebSocket protocol, allowing for real-time communication.

The code defines a NotifyEvent type that encapsulates messages from a client (an active WebSocket connection) and a Client type that keeps track of individual connections and their communication with the server through channels.

The Manager type oversees all Client instances, managing incoming and outgoing messages with the help of ClientList, a map that keeps track of all active connections.

Clients are created with a unique ID and are tied to their WebSocket connections and the managing system. They have two main routines: readMessages listens for incoming messages and forwards them to the manager, and writeMessages sends outgoing messages from the server to the client's WebSocket.

The Manager is also responsible for broadcasting messages to all clients except the sender, ensuring that messages are propagated in real-time to all connected users.

Lastly, ServeWS is a function that handles new WebSocket connections by upgrading HTTP requests to WebSocket and initiating the message reading and writing routines.

This structure allows us to manage multiple clients and their interactions efficiently, forming the backbone of our WebSocket-based real-time communication service.

main.go

main.go, in this file we need to serve our index.html and some websocket stuff. ill use net/http package for this.

package main

import (
    "log"
    "net/http"

    "github.com/doganarif/wasm/2/pkg/socket"
)

func main() {
    setupAPI()

    // Serve on port :8080, fudge yeah hardcoded port
    log.Fatal(http.ListenAndServe(":8080", nil))
}

// setupAPI will start all Routes and their Handlers
func setupAPI() {
    manager := socket.NewManager()

    // Serve the ./public directory at Route /
    http.Handle("/", http.FileServer(http.Dir("./public")))
    http.Handle("/ws", http.HandlerFunc(manager.ServeWS))
}

Our web service has a simple starting point, a file where everything kicks off. It sets up our web server and tells it to listen for visitors on port 8080 (the classic spot for web development testing).

We call a setupAPI() function that does a bit of behind-the-scenes work. It taps into our socket package to create a Manager, which is like the director of a play, coordinating all our WebSocket connections.

We also set up a special /ws route for WebSocket connections, where our Manager starts handling the real-time chat.

wasm/wasm.go

package main

import (
    "context"
    "fmt"
    "log"
    "syscall/js"

    "nhooyr.io/websocket"
)

// Conn wraps a WebSocket connection.
type Conn struct {
    wsConn *websocket.Conn
}

// NewConn establishes a new WebSocket connection to a specified URL.
func NewConn() *Conn {
    c, _, err := websocket.Dial(context.Background(), "ws://localhost:8080/ws", nil)
    if err != nil {
        fmt.Println(err, "ERROR")
    }

    return &Conn{
        wsConn: c,
    }
}

func main() {
    // Channel to keep the main function running until it's closed.
    c := make(chan struct{}, 0)

    println("WASM Go Initialized")
    // Establish a new WebSocket connection.
    conn := NewConn()

    // Register the onButtonClick function in the global JavaScript context.
    js.Global().Set("onButtonClick", onButtonClickFunc(conn))

    // Start reading messages in a new goroutine.
    go conn.readMessage()

    // Wait indefinitely.
    <-c
}

// onButtonClickFunc returns a js.Func that sends a "HELLO" message over WebSocket when invoked.
func onButtonClickFunc(conn *Conn) js.Func {
    return js.FuncOf(func(this js.Value, args []js.Value) interface{} {
        println("Button Clicked!")
        // Send a message through the WebSocket connection.
        err := conn.wsConn.Write(context.Background(), websocket.MessageText, []byte("HELLO"))
        if err != nil {
            log.Println("Error writing to WebSocket:", err)
        }
        return nil
    })
}

// readMessage handles incoming WebSocket messages and updates the DOM accordingly.
func (c *Conn) readMessage() {
    defer func() {
        // Close the WebSocket connection when the function returns.
        c.wsConn.Close(websocket.StatusGoingAway, "BYE")
    }()

    for {
        // Read a message from the WebSocket connection.
        messageType, payload, err := c.wsConn.Read(context.Background())

        if err != nil {
            // Log and panic if there is an error reading the message.
            log.Panicf(err.Error())
        }

        // Update the DOM with the received message.
        updateDOMContent(string(payload))

        // Log the message type and payload for debugging.
        log.Println("MessageType: ", messageType)
        log.Println("Payload: ", string(payload))
    }
}

// updateDOMContent updates the text content of the DOM element with the given text.
func updateDOMContent(text string) {
    // Get the document object from the global JavaScript context.
    document := js.Global().Get("document")
    // Get the DOM element by its ID.
    element := document.Call("getElementById", "text")
    // Set the innerText of the element to the provided text.
    element.Set("innerText", text)
}

Our wasm.go file, once compiled into a .wasm executable, is the client-side counterpart to the WebSocket service we discussed earlier. It's set to run within the web browser, interfacing directly with the DOM.

The file’s responsibility starts with establishing a WebSocket connection to the server endpoint we've set up—ws://localhost:8080/ws. This is the communication channel our web service listens to, we already detailed.

In parallel, we're attentive to the server’s response. Incoming messages from our WebSocket server are caught and used to update the webpage dynamically.
This is where the full circle of client-server interaction completes—our Go code receives server messages, then reflects changes directly in the user's view (<p id="text").

Makefile

.PHONY: build buildwasm run clean serve

# Variables
WASM_DIR := ./wasm
PUBLIC_DIR := ./public
SERVER_FILE := main.go
WASM_SOURCE := $(WASM_DIR)/wasm.go
WASM_TARGET := $(PUBLIC_DIR)/main.wasm
GOOS := js
GOARCH := wasm

# Default rule
all: run

# Run the server
run: serve

# Serve the project
serve: buildwasm
    go run $(SERVER_FILE)

# Build the WebAssembly module
buildwasm:
    GOOS=$(GOOS) GOARCH=$(GOARCH) go build -o $(WASM_TARGET) $(WASM_SOURCE)

# Clean the built artifacts
clean:
    rm -f $(WASM_TARGET)

Conclusion

We've gone through the ropes of creating a real-time application using Go and WebAssembly. The project's setup is simple: a WebSocket server in Go, a basic HTML page, and some Go code compiled to WebAssembly that runs in the browser. We've covered how to send and receive messages through WebSockets and how to reflect those messages in the web page by updating the DOM.

From setting up the project structure to handling real-time communication between the client and server, the provided code examples aim to give you a clear starting point for building your own applications with Go and WebAssembly. It's a straightforward setup, but it lays the foundation for more complex projects.

Hope this helps you kickstart your own adventures in WebAssembly with Go. Keep building, keep learning, and most importantly, keep it simple.

Github Repo : https://github.com/doganarif/go-wasm-socket

Dockerizing Django with Numpy and Gunicorn

arif — Thu, 14 Jan 2021 10:19:47 +0000

Hi all.

Actually theres lot of tutorial about dockerizing django on web. But at the project i working on we using libraries like Numpy and Pillow and alpine linux cannot compile this because missing dependencies.

Our Stack;

Django
Numpy
Pillow
Postgresql

First of all let create basic Dockerfile

FROM python:3.6.4-alpine

ADD . /app

WORKDIR /app

RUN pip install -r requirements.txt

EXPOSE 8000

CMD ["manage.py", "runserver"]

Its basically works if you not using c compiled libraries like Numpy.

The thing is we need to add compilers to alpine i have big layer on there because running this proccesses on one layer is better i think.

Full Dependency install Layer :

RUN apk add --no-cache jpeg tiff-dev openjpeg-dev postgresql-dev && \
    apk add --no-cache \
    --virtual=.build-deps \
    g++ zlib-dev freetype-dev lcms2-dev \
    gcc libc-dev linux-headers tk-dev tcl-dev harfbuzz-dev \
    fribidi-dev build-base py-pip rsyslog cython file binutils \
    musl-dev python3-dev cython && \
    ln -s locale.h /usr/include/xlocale.h && \
    pip install --upgrade pip && \
    pip install -r requirements.txt --no-cache-dir && \
    rm -r /root/.cache && \
    find /usr/lib/python3.*/ -name 'tests' -exec rm -r '{}' + && \
    find /usr/lib/python3.*/site-packages/ -name '*.so' -print -exec sh -c 'file "{}" | grep -q "not stripped" && strip -s "{}"' \; && \
    rm /usr/include/xlocale.h && \
    apk --purge del .build-deps

Compilers for Alpine

I installed some packages like g++ and linux-headers virtual and cleaned them after pip install because i just need this packages for post scripts of some dependencies and size is matter on container.

  -t, --virtual NAME    Instead of adding all the packages to 'world', create a new 
                        virtual package with the listed dependencies and add that 
                        to 'world'; the actions of the command are easily reverted 
                        by deleting the virtual package

What that means is when you install packages, those packages are not added to global packages. And this change can be easily reverted. So if I need gcc to compile a program, but once the program is compiled I no more need gcc.

I can install gcc, and other required packages in a virtual package and all of its dependencies and everything can be removed this virtual package name. Below is an example usage

apk add --virtual mypacks gcc vim
apk del mypacks

The next command will delete all 18 packages installed with the first command.

Postgres

Im running Postgresql on my local machine not docker. And i need to connect it. You can use host.docker.internal this mapping is directly routes your machines localhost

So i added this env variable

ENV DB_HOST=host.docker.internal

and used this on `settings.py`

Gunicorn

I decided to use Gunicorn for running processed with n workers. So i added gunicorn to my requirements.txt and added this two lines for run processes

ENV WORKER_COUNT=2

CMD ["sh", "-c", "gunicorn --bind :8000 --workers ${WORKER_COUNT} project.wsgi:application"]

Using WORKER_COUNT env variable for default value. Im overriding this value everytime i need.

Running

I decided to create makefile for run this container with n workers.
So i created Makefile with this command.


docker-run:
    docker run -e worker_count=${worker} -p 127.0.0.1:8000:8000 project${version}

Full Dockerfile

FROM python:3.6.4-alpine

ADD . /app
WORKDIR /app

# Need to Update at Settings.py
ENV DB_HOST=host.docker.internal

# Default Worker Count is 2
ENV WORKER_COUNT=2

# Install dependencies layer.
RUN apk add --no-cache postgresql \
                        jpeg tiff-dev openjpeg-dev \
                        libpq postgresql-libs postgresql-dev && \
    apk add --no-cache \
    --virtual=.build-deps \
    g++ jpeg-dev zlib-dev freetype-dev lcms2-dev \
    gcc libc-dev linux-headers tk-dev tcl-dev harfbuzz-dev \
    fribidi-dev zlib-dev build-base py-pip rsyslog cython file binutils \
    musl-dev python3-dev cython && \
    ln -s locale.h /usr/include/xlocale.h && \
    pip install --upgrade pip && \
    pip install -r requirements.txt --no-cache-dir && \ 
    rm -r /root/.cache && \
    find /usr/lib/python3.*/ -name 'tests' -exec rm -r '{}' + && \
    find /usr/lib/python3.*/site-packages/ -name '*.so' -print -exec sh -c 'file "{}" | grep -q "not stripped" && strip -s "{}"' \; && \
    rm /usr/include/xlocale.h && \
    apk --purge del .build-deps  


EXPOSE 8000

CMD ["sh", "-c", "gunicorn --bind :8000 --workers ${WORKER_COUNT} project.wsgi:application"]

I hope you found this article useful.

Thanks.

Im Looking For Product Manager For My Own Project

arif — Wed, 30 Dec 2020 22:07:38 +0000

Project Description

Basically Take-Away eCommerce Mobile Application and BackEnd Services.

Status

I only developed %50 of Back End Project with Django. For example developed pricing, basically customer logic etc.

Stack

Im developing Back-End Web Services with Django. Also for mobile apps im thinking develop with flutter or react-native.

Requests

I need one product manager for develop product and business. For now im funding this project myself. So i can share stock. If you can accept please message me :)