DEV Community: Mayuresh Smita Suresh

Building GenAI-Powered Applications with PHP and CodeIgniter 4. A Complete Guide

Mayuresh Smita Suresh — Thu, 30 Jul 2026 02:48:54 +0000

Generative AI has largely become a Python-and-JavaScript conversation, but there's no technical reason PHP should sit this out. CodeIgniter 4 — lightweight, fast-booting, and still powering a huge number of production apps — is perfectly capable of integrating LLMs cleanly. This guide walks through a full, production-minded implementation: configuration, a reusable service layer, streaming responses, error handling, a basic RAG setup, security considerations, and testing.

Why CodeIgniter 4 for GenAI
Project Setup & Configuration
Building a Robust GenAI Service Layer
Controller & Routes
Frontend Integration (Form + Streaming)
Adding a Simple RAG Pipeline
Error Handling & Retries
Security & Rate Limiting
Caching Strategy
Testing the Integration
Deployment Considerations
Real-World Use Cases
Wrapping Up

1. Why CodeIgniter 4 for GenAI

CodeIgniter 4 has a few things going for it here:

Built-in HTTP client (CURLRequest) — no need for Guzzle or heavy SDKs.
Service container (Config\Services) — makes it trivial to swap providers (Anthropic, OpenAI, local models) behind one interface.
Fast boot time — matters if you're calling this from lightweight microservices or queued workers.
Mature caching layer — useful for reducing redundant LLM calls, which are often the most expensive part of the stack.

None of this requires abandoning your existing MVC structure. The LLM is just another external API — CI4 already knows how to talk to those.

2. Project Setup & Configuration

Install a fresh CI4 project if you don't already have one:


bash
composer create-project codeigniter4/appstarter genai-ci4-app
cd genai-ci4-app

Building a Zoho CRM AI Chatbot with Airbyte: Architecture for Anomaly Detection and Causal Analysis

Mayuresh Smita Suresh — Thu, 23 Jul 2026 04:29:24 +0000

Building a Zoho CRM Chatbot with Airbyte: Architecture for Anomaly Detection and Causal Analysis

Most "chat with your CRM" tools stop at natural language querying — you ask a question, it runs a lookup, you get an answer. That's useful, but it's not decision intelligence. The harder and more valuable problem is: why did this metric move, and what will happen if we don't act on it?

This article walks through an architecture for a Zoho CRM chatbot that goes past simple Q&A into anomaly detection and causal analysis — using Airbyte as the data movement layer.

Why Airbyte as the Ingestion Layer

Zoho CRM's native API is capable, but building a custom sync pipeline for every object (Leads, Deals, Contacts, Activities, Custom Modules) means handling pagination, rate limits, schema drift, and incremental sync logic yourself. Airbyte solves this with a pre-built Zoho CRM connector that handles:

Incremental syncs using Zoho's modified-time cursors, so you're not re-pulling the full dataset on every run
Schema normalization into a consistent format regardless of custom fields your Zoho instance has added
Destination flexibility — you can land data in Postgres, Snowflake, BigQuery, or a data lake without rewriting extraction logic

This matters because your chatbot and analysis layer are only as good as the freshness and structure of the underlying data. Airbyte turns "get Zoho data into a warehouse" into a configuration problem, not an engineering project.

High-Level Architecture

Zoho CRM API
    │
    ▼
Airbyte (Zoho CRM Source Connector)
    │
    ▼
Data Warehouse (Postgres / Snowflake / BigQuery)
    │
    ├──► Semantic Layer (business-friendly metric definitions)
    │
    ├──► Anomaly Detection Service (statistical + ML models)
    │
    ├──► Causal Analysis Engine (root-cause chain builder)
    │
    └──► Chat Interface (LLM + retrieval + tool calls)

Each layer has a distinct job, and keeping them separate is what makes the system maintainable as your Zoho instance grows more custom modules and fields over time.

Layer 1: Ingestion with Airbyte

Set up the Zoho CRM connector with these core streams:

Leads, Deals, Contacts, Accounts — the core CRM entities
Activities and Tasks — for behavioral/engagement signals
Custom_Modules — if your Zoho instance has non-standard objects (common in sales-heavy configurations)

Configure sync frequency based on how time-sensitive your alerting needs to be. Hourly syncs are usually sufficient for CRM data — deal stages and lead statuses don't need real-time streaming for most use cases, and hourly batches keep your warehouse costs predictable.

Land raw data in a staging schema first, untouched. Transform into cleaned, typed tables using dbt or a similar tool downstream. This separation means a Zoho schema change never corrupts your analysis layer — you fix the transformation, not the whole pipeline.

Layer 2: Semantic Layer

Before any AI touches the data, define your business metrics once, in one place: what counts as a "won deal," how "pipeline velocity" is calculated, what a "stalled lead" means for your sales process. This layer exists so the chatbot and the anomaly detector agree on definitions — without it, you'll get an alert that contradicts what the chatbot tells a user five minutes later, which destroys trust fast.

Layer 3: Anomaly Detection

This is where the system starts doing real work instead of just reporting numbers. Two approaches, used together:

Statistical baseline detection — rolling averages and standard deviation bands per metric (deal close rate, average deal size, lead response time). Flag anything outside expected bounds. Cheap, explainable, and a good first line of defense.

Model-based detection — for patterns too subtle for simple thresholds, such as a slow multi-week decline in lead quality from a specific source that wouldn't trip a single-day anomaly check. This is where a lightweight time-series model earns its keep over pure rule-based thresholds.

Every anomaly gets written back to the warehouse with metadata: which metric, which segment (region, rep, product line), severity, and timestamp. This log is what your causal engine and chatbot both draw from.

Layer 4: Causal Analysis

This is the differentiator over a plain BI dashboard. When an anomaly fires — say, deal close rate dropped 15% this week — the causal engine's job is to trace which upstream factor explains it, rather than leaving a human to dig through pivot tables.

A practical approach:

Build a metric dependency graph ahead of time (e.g., close rate depends on lead source quality, rep activity volume, deal stage duration).
When an anomaly fires on a downstream metric, walk the graph and check each upstream node for its own anomaly in the same window.
Rank candidate causes by correlation strength and time-lag alignment, not just co-occurrence.
Present the top 1-3 candidates with supporting evidence, not a single definitive answer — causal inference from observational CRM data is probabilistic, and the chatbot should represent it that way.

This step is what turns "close rate dropped" into "close rate dropped, most likely tied to a spike in leads from Channel X starting Tuesday" — the difference between a notification and an insight.

Layer 5: Chat Interface

The chatbot sits on top of everything below it — it should never touch raw Zoho data directly. Its job is to:

Translate a natural language question into a query against the semantic layer
Pull relevant anomaly and causal-chain records when a question relates to "why" something happened
Generate a response grounded in retrieved data, not model memory — this is critical for numeric accuracy
Route report or alert requests to a scheduling layer rather than answering ad hoc

Use retrieval-augmented generation here, not fine-tuning: the underlying CRM data changes daily, and RAG lets the chatbot stay current without retraining anything.

Alerts and Reports

Once anomaly detection and causal analysis exist as services, alerts and reports become a thin layer on top:

Alerts — push anomaly events above a severity threshold to Slack/email/webhook, including the top causal candidate if one was found
Reports — scheduled summaries pulling from the same semantic layer the chatbot uses, so numbers in a Monday report and numbers the chatbot gives on Tuesday never disagree

Practical Notes

Start with 3-4 core metrics, not full coverage. Anomaly detection tuned across every possible Zoho field produces noise, not insight, and noisy alerts get ignored within a week.
Keep the causal dependency graph human-editable. Automatically inferring causal structure from correlation alone is unreliable — let domain knowledge define the graph, and let data confirm or flag deviations within it.
Log every chatbot answer alongside the underlying query and data snapshot used to generate it. This audit trail matters both for debugging wrong answers and for any enterprise buyer who will ask "how do I know this is accurate."

Closing Thought

The gap between a basic "chat with your CRM" tool and a genuinely useful decision-intelligence system isn't the chat interface — it's the layers underneath it: clean ingestion, a shared semantic definition of your metrics, real anomaly detection, and a causal engine that can explain why, not just what. Airbyte handles the unglamorous but essential first step reliably, which frees up the harder engineering effort for the layers that actually create value.

Building AI Agents for Social Media with TypeScript and Hono.js

Mayuresh Smita Suresh — Sun, 19 Jul 2026 12:07:20 +0000

Everyone's talking about AI agents right now, but most tutorials stop at "call an LLM in a loop." If you actually want an agent that runs unattended — fetches data, thinks about it, writes content, and publishes it — you need a real backend, not just a prompt. This post walks through the architecture I use for exactly that: a scheduled agent that finds fresh data, drafts social posts with Claude, and publishes them, built entirely on Hono.js running on Cloudflare Workers.

I'll use "post finance news to LinkedIn/Reddit" as the running example, but the pattern generalizes to any "watch → think → act → publish" agent.

Why Hono.js for agent backends

Hono is a small, fast web framework that runs on Cloudflare Workers, Deno, Bun, and Node. For agent workloads specifically, three things make it a good fit:

Native Cloudflare Cron Triggers — agents that run on a schedule don't need a separate job scheduler or a always-on server.
Edge runtime, near-zero cold start — your agent wakes up, does its work, and disappears. You pay for execution, not idle uptime.
Middleware model — auth, logging, and rate-limiting for your own agent's admin routes come for free.

The architecture

Cron Trigger (Hono on Cloudflare Workers)
   │
   ├── 1. Fetch step   → pull raw data from an external API
   ├── 2. Reasoning step → Claude API decides what's worth posting
   ├── 3. Generation step → Claude API drafts platform-specific copy
   ├── 4. Dedup check   → Postgres/Neon, skip anything already posted
   └── 5. Publish step  → social API (or a unified posting provider)

Each step is a plain async function. No agent framework, no hidden state machine — just a pipeline you can read top to bottom and unit test.

Setting up the project

npm create hono@latest social-agent
cd social-agent
npm install

Pick the cloudflare-workers template when prompted. Then add what we need:

npm install @anthropic-ai/sdk drizzle-orm @neondatabase/serverless

Step 1: The cron trigger

In wrangler.toml, define when the agent wakes up:

[triggers]
crons = ["0 * * * 1-5"] # hourly, weekdays only

In your Hono app, handle the scheduled event separately from HTTP routes:

import { Hono } from 'hono'

const app = new Hono()

export default {
  fetch: app.fetch,
  async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext) {
    ctx.waitUntil(runAgentCycle(env))
  },
}

ctx.waitUntil is important — it tells the Worker runtime to keep the instance alive until your async work finishes, even though there's no HTTP response to wait on.

Step 2: Fetch fresh data

Keep this step dumb. It should return structured data, not decide anything.

interface RawEvent {
  id: string
  title: string
  payload: Record<string, unknown>
}

async function fetchLatestEvents(env: Env): Promise<RawEvent[]> {
  const res = await fetch('https://api.example.com/events?window=today', {
    headers: { Authorization: `Bearer ${env.SOURCE_API_KEY}` },
  })
  if (!res.ok) throw new Error(`Source fetch failed: ${res.status}`)
  const data = await res.json()
  return data.events
}

Step 3: Let Claude decide what's worth posting

This is the part people skip and regret. Don't auto-draft a post for every single item — have the model triage first. It's cheaper, and it keeps your feed from looking like a bot dump.

import Anthropic from '@anthropic-ai/sdk'

async function triageEvents(events: RawEvent[], env: Env) {
  const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY })

  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-6',
    max_tokens: 1024,
    system:
      'You triage events for social media worthiness. Only flag items with a genuinely interesting angle — a surprise, a pattern, a number that stands out. Return strict JSON, no prose.',
    messages: [
      {
        role: 'user',
        content: JSON.stringify(events),
      },
    ],
  })

  const text = message.content.find((c) => c.type === 'text')?.text ?? '[]'
  return JSON.parse(text) as { id: string; angle: string }[]
}

Asking for "strict JSON, no prose" up front saves you a fragile regex-strip step later.

Step 4: Generate platform-specific copy

LinkedIn and Reddit have different norms — LinkedIn rewards a confident, analytical voice; Reddit punishes anything that reads like marketing copy. Generate both in one call, but prompt for the difference explicitly rather than reusing one draft everywhere.

async function draftPosts(item: RawEvent, angle: string, env: Env) {
  const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY })

  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-6',
    max_tokens: 800,
    system: `Write two versions of a post about this event.
LinkedIn: 80-150 words, analytical tone, one soft mention of relevant context, no hashtag spam.
Reddit: framed as a discussion starter, no promotional language, ends with a genuine question.
Return JSON: { "linkedin": "...", "reddit": "..." }`,
    messages: [
      { role: 'user', content: `Event: ${item.title}\nAngle: ${angle}\nData: ${JSON.stringify(item.payload)}` },
    ],
  })

  const text = message.content.find((c) => c.type === 'text')?.text ?? '{}'
  return JSON.parse(text) as { linkedin: string; reddit: string }
}

Step 5: Dedup with Postgres

Nothing kills credibility faster than posting the same thing twice because a cron overlapped. Use Neon's serverless driver — it works over HTTP, which matters on Workers since you don't have a persistent TCP connection.

import { neon } from '@neondatabase/serverless'

async function alreadyPosted(env: Env, eventId: string) {
  const sql = neon(env.DATABASE_URL)
  const rows = await sql`SELECT 1 FROM posted_events WHERE event_id = ${eventId}`
  return rows.length > 0
}

async function markPosted(env: Env, eventId: string, platform: string, postId: string) {
  const sql = neon(env.DATABASE_URL)
  await sql`
    INSERT INTO posted_events (event_id, platform, post_id, posted_at)
    VALUES (${eventId}, ${platform}, ${postId}, now())
  `
}

Step 6: Publish

You have two real options here:

Native platform APIs. LinkedIn requires an approved Company Page and w_member_social scope; Reddit requires its own OAuth app and respects strict rate limits. Both are doable but slow to set up the first time.
A unified posting provider (e.g. Ayrshare) that abstracts multiple platforms behind one API. Much faster to ship an MVP with — worth it if you're validating the idea before investing in native integrations.

async function publish(platform: 'linkedin' | 'reddit', content: string, env: Env) {
  const res = await fetch('https://api.ayrshare.com/api/post', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${env.AYRSHARE_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ post: content, platforms: [platform] }),
  })
  if (!res.ok) throw new Error(`Publish failed on ${platform}: ${res.status}`)
  return res.json()
}

Wiring it together

async function runAgentCycle(env: Env) {
  const events = await fetchLatestEvents(env)
  const flagged = await triageEvents(events, env)

  for (const { id, angle } of flagged) {
    if (await alreadyPosted(env, id)) continue

    const source = events.find((e) => e.id === id)!
    const { linkedin, reddit } = await draftPosts(source, angle, env)

    const li = await publish('linkedin', linkedin, env)
    await markPosted(env, id, 'linkedin', li.id)

    // Reddit: hold for human review instead of auto-publishing — see note below
    await queueForReview(env, id, reddit)
  }
}

The guardrail that actually matters

Automating the fetch → draft pipeline is safe. Automating the publish step to Reddit is not, at least not at first. Most active subreddits have strict self-promotion rules, and an account that posts on a predictable schedule with promotional undertones gets flagged as a bot fast — sometimes shadowbanned entirely. Two things fix this:

Human-in-the-loop for Reddit specifically. Queue the draft (Slack, email, a simple admin route in the same Hono app) and require a manual approve before it publishes.
Keep the language descriptive, not advisory. For anything finance-adjacent, "revenue beat estimates by X%" is commentary; "you should buy this" edges into advice you don't want to be on the hook for.

LinkedIn is more forgiving of a consistent posting cadence, so it's the safer platform to fully automate first.

Where to go from here

This same skeleton — cron trigger, fetch, triage, generate, dedup, publish — works for far more than finance news. Swap the fetch step for GitHub releases, product reviews, conference CFPs, or your own product's usage metrics, and you have a different agent with the same reliability guarantees.

The part worth getting right early is the triage step. An agent that posts about everything is just noise with extra steps; an agent that only speaks up when there's a genuine angle is the one people actually follow.

If you're building something similar, I'd love to hear what you're automating — drop it in the comments.

Honoured to receive Google AI Badge. Awarded for publishing a top Google AI post. Thank you Dev team.

Mayuresh Smita Suresh — Fri, 20 Mar 2026 05:37:17 +0000

mcpnest.cloud Calling all dev to support my new platform, I am building a robust platform to deploy any MCP easily and manage it and scale it easy. Please join the waitlist your support matters a lot. Thank you.

Mayuresh Smita Suresh — Wed, 11 Mar 2026 07:00:34 +0000

https://mcpnest.cloud Calling all dev to support my new platform, I am building a robust platform to deploy any MCP easily and manage it and scale it easy. Please join the waitlist your support matters a lot. Thank you.

Mayuresh Smita Suresh — Wed, 11 Mar 2026 07:00:02 +0000

MCPNest | Deploy MCP Servers Instantly

Deploy, scale, and manage your Model Context Protocol servers in minutes.

mcpnest.cloud

Why MCP servers deployments are so hard?

Mayuresh Smita Suresh — Tue, 10 Mar 2026 13:39:06 +0000

MILP From Scratch in Pure Rust — No Dependencies, Full Branch and Bound

Mayuresh Smita Suresh — Wed, 04 Mar 2026 18:33:49 +0000

If you’ve ever seen terms like linear programming, integer optimisation, or Branch and Bound and felt lost — this post is for you.

We’ll build a complete MILP solver in pure Rust (zero external crates) that solves a real factory planning problem. Every term is explained from scratch. The code compiles and runs today.

By the end you’ll understand:

What MILP is and why it’s hard
The full mathematical formulation
What Branch and Bound actually does (with the real tree output)
Why this matters for quantum optimisation

The Problem: A Furniture Factory

A furniture factory makes two products:

Product	Profit	Machine hrs needed	Wood units needed
Table (x₁)	£50 each	3 hrs	4 units
Chair (x₂)	£30 each	2 hrs	3 units

Available resources:

Machine hours: 120 total
Wood: 160 units total
Market demand caps: max 30 tables, max 40 chairs

Question: How many tables and chairs to make to maximise profit?

You can’t make 16.7 tables. They must be whole numbers. That’s the key challenge — and it’s what makes this MILP.

What Is MILP? (Every Word Explained)

Linear → All relationships are proportional. Profit scales linearly with units. profit = 50 × tables + 30 × chairs — no powers, no curves, just straight lines.

Programming → Old term for “optimisation”. Nothing to do with coding.

Integer → Some variables must be whole numbers. You can’t produce 2.5 tables or hire 0.7 people.

Mixed → Some variables can be continuous (e.g. temperature, weight, price) while others must be integer (units, people, machines). Our problem has all integer variables, but MILP handles both.

Why is it hard?

Pure LP (without integers) is solvable in polynomial time — milliseconds even for massive problems. The moment you add integer constraints, the problem becomes NP-hard. You can’t just solve equations — you need to search through combinations. A factory with 100 products has more valid integer combinations than atoms in the universe.

The Mathematics

Decision Variables

x₁ = number of Tables to produce  (integer, ≥ 0)
x₂ = number of Chairs to produce  (integer, ≥ 0)

These are what the solver decides. Everything else is fixed input.

Objective Function

Maximise:  Z = 50·x₁ + 30·x₂

Every table adds £50 to profit. Every chair adds £30. We want Z as large as possible.

Constraints

3·x₁ + 2·x₂  ≤  120     ← machine hours: can't exceed 120 total
4·x₁ + 3·x₂  ≤  160     ← wood: can't exceed 160 units
      x₁      ≤   30     ← market can only absorb 30 tables
           x₂ ≤   40     ← market can only absorb 40 chairs
x₁, x₂       ≥    0     ← can't produce negative quantities
x₁, x₂       ∈   ℤ⁺    ← must be whole numbers (the "Integer" in MILP)

Matrix Form

Solvers work with matrices. Written as A·x ≤ b:

     A           x      b
[ 3  2 ]   [ x₁ ]   [ 120 ]
[ 4  3 ] · [ x₂ ] ≤ [ 160 ]

Objective vector c = [50, 30]
Maximise cᵀ·x  subject to  A·x ≤ b,  lb ≤ x ≤ ub,  x ∈ ℤ

What Does the Feasible Region Look Like?

Plot x₁ on the x-axis, x₂ on the y-axis. Each constraint is a line. The feasible region is the polygon where all constraints are satisfied simultaneously. The optimal solution always sits at a corner (vertex) of this polygon.

x₂ (Chairs)
40 |---.
   |    \   ← demand cap x₂ ≤ 40
   |     \
   |      ◆ ← OPTIMAL: (30, 13), Profit = £1890
   |      .\
   |      . \  ← Wood: 4x₁ + 3x₂ = 160
   |      .  \
   |      .   \__ Machine: 3x₁ + 2x₂ = 120
   |___________ x₁ (Tables)
   0           30

The Algorithm: Branch and Bound

This is how every serious MILP solver works at its core.

Step 1: LP Relaxation

First, forget the integer constraint. Solve as pure LP (allowing fractions). This gives the upper bound — the best profit achievable if fractions were allowed.

For our problem, LP relaxation gives: x₁ = 30, x₂ = 13.33, profit = £1,900.

But x₂ = 13.33 is fractional. We can’t make 13.33 chairs.

Step 2: Branch

Pick the fractional variable (x₂ = 13.33). Split into two sub-problems:

Branch A: x₂ ≤ 13   (round down)
Branch B: x₂ ≥ 14   (round up)

Push both onto the search stack. Now solve each one’s LP relaxation.

Step 3: Bound

For each sub-problem, the LP relaxation gives an upper bound. If that upper bound is worse than the best integer solution found so far — prune the branch (don’t explore further). This is what makes B&B efficient.

Step 4: Repeat

Keep branching on fractional variables, pruning hopeless branches, until every branch is either pruned or yields an integer solution.

Our Actual Search Tree (from the code output)

[Node  1] depth=0  LP=1900.0 → BRANCH x₂=13.33 (≤13 | ≥14)
[Node  2] depth=1  LP=1895.0 → BRANCH x₁=29.5  (≤29 | ≥30)
[Node  3] depth=2  → INFEASIBLE, pruned
[Node  4] depth=2  LP=1890.0 → BRANCH x₂=14.67 (≤14 | ≥15)
[Node  5] depth=3  LP=1887.5 → BRANCH x₁=28.75 (≤28 | ≥29)
[Node  6] depth=4  → INFEASIBLE, pruned
[Node  7] depth=4  LP=1880.0 → ✓ INTEGER (x1=28, x2=16) ★ £1880
[Node  8] depth=3  LP=1870.0 ≤ best=1880 → PRUNED
[Node  9] depth=1  LP=1890.0 → ✓ INTEGER (x1=30, x2=13) ★ £1890

Only 9 nodes to find the global optimum. Without B&B, brute force would check 30×40 = 1,200 combinations. For larger problems (1,000 variables), B&B reduces billions of checks to thousands.

The Rust Code

Pure Rust. Zero external dependencies. The full solver from scratch.

Data Structures

/// The LP problem in standard form: Maximise c·x subject to A·x ≤ b
#[derive(Clone, Debug)]
struct LpProblem {
    c: Vec<f64>,          // objective coefficients
    a: Vec<Vec<f64>>,     // constraint matrix
    b: Vec<f64>,          // rhs of constraints
    lb: Vec<f64>,         // lower bounds per variable
    ub: Vec<f64>,         // upper bounds per variable
    n_vars: usize,
}

/// One node in the Branch and Bound search tree.
/// Each node represents a sub-problem with tightened bounds.
#[derive(Clone, Debug)]
struct BbNode {
    lb: Vec<f64>,    // current lower bounds (tightened by branching)
    ub: Vec<f64>,    // current upper bounds (tightened by branching)
    depth: usize,    // depth in tree (for logging)
}

LP Relaxation Solver (Coordinate Ascent)

For each node we solve the LP relaxation — the same problem but without integer constraints.

We use coordinate ascent: move each variable as far as possible in its profit-improving direction while staying feasible. For small bounded problems like ours, this converges to the exact LP optimum.

fn solve_lp_relaxation(prob: &LpProblem, lb: &[f64], ub: &[f64]) -> LpResult {
    let n = prob.n_vars;
    // Start at lower bounds (always feasible when b ≥ 0)
    let mut x: Vec<f64> = lb.to_vec();

    for _iter in 0..10_000 {
        let mut improved = false;
        for i in 0..n {
            let dir = prob.c[i];           // gradient: improving direction for x[i]
            if dir.abs() < 1e-10 { continue; }

            // Find how far we can move x[i] before hitting a constraint
            let step = if dir > 0.0 {
                max_step_up(prob, &x, i, ub)    // move up
            } else {
                max_step_down(prob, &x, i, lb)   // move down
            };

            if step.abs() > 1e-9 {
                x[i] += step;
                if dot(&prob.c, &x) > dot(&prob.c, &x) + 1e-10 {
                    improved = true;
                } else {
                    x[i] -= step;   // revert if no improvement
                }
            }
        }
        if !improved { break; }  // converged
    }
    LpResult::Optimal(dot(&prob.c, &x), x)
}

max_step_up computes the maximum safe step by checking each constraint:

fn max_step_up(prob: &LpProblem, x: &[f64], i: usize, ub: &[f64]) -> f64 {
    let mut max_step = ub[i] - x[i];            // can't exceed upper bound
    for (k, &bk) in prob.b.iter().enumerate() {
        let a_ki = prob.a[k][i];
        if a_ki > 1e-10 {
            let lhs: f64 = dot(&prob.a[k], x);
            let step = (bk - lhs) / a_ki;       // slack / coefficient = max safe step
            if step < max_step { max_step = step; }
        }
    }
    max_step.max(0.0)
}

Branch and Bound

fn branch_and_bound(prob: &LpProblem, integer_vars: &[bool]) -> Option<MilpSolution> {
    let mut best_obj = f64::NEG_INFINITY;
    let mut best_x: Option<Vec<f64>> = None;
    let mut stack: Vec<BbNode> = vec![BbNode { lb: prob.lb.clone(),
                                               ub: prob.ub.clone(), depth: 0 }];

    while let Some(node) = stack.pop() {

        // 1. Solve LP relaxation for this node
        let (lp_obj, lp_x) = match solve_lp_relaxation(prob, &node.lb, &node.ub) {
            LpResult::Infeasible => continue,         // prune: infeasible
            LpResult::Optimal(o, x) => (o, x),
        };

        // 2. Prune if LP bound can't beat current best
        if lp_obj <= best_obj + 1e-6 { continue; }

        // 3. Find most fractional integer variable (closest fraction to 0.5)
        let branch_var = integer_vars.iter().enumerate()
            .filter(|&(i, &is_int)| {
                if !is_int { return false; }
                let frac = lp_x[i].fract();
                frac > 1e-6 && frac < 1.0 - 1e-6
            })
            .min_by(|&(i, _), &(j, _)| {
                let fi = (lp_x[i].fract() - 0.5).abs();
                let fj = (lp_x[j].fract() - 0.5).abs();
                fi.partial_cmp(&fj).unwrap()
            })
            .map(|(i, _)| i);

        match branch_var {
            None => {
                // All integer vars are integral → valid integer solution!
                if lp_obj > best_obj {
                    best_obj = lp_obj;
                    best_x = Some(lp_x);
                }
            }
            Some(vi) => {
                let floor_v = lp_x[vi].floor();
                let ceil_v  = lp_x[vi].ceil();

                // Child 1: x[vi] ≤ floor (round down branch)
                let mut ub2 = node.ub.clone();
                ub2[vi] = ub2[vi].min(floor_v);
                stack.push(BbNode { lb: node.lb.clone(), ub: ub2, depth: node.depth+1 });

                // Child 2: x[vi] ≥ ceil (round up branch)
                let mut lb2 = node.lb.clone();
                lb2[vi] = lb2[vi].max(ceil_v);
                stack.push(BbNode { lb: lb2, ub: node.ub.clone(), depth: node.depth+1 });
            }
        }
    }

    best_x.map(|x| MilpSolution { objective: best_obj, variables: x,
                                   nodes_explored: 0 })
}

Defining the Problem

fn main() {
    let prob = LpProblem::new(
        vec![50.0, 30.0],        // objective: max 50x₁ + 30x₂
        vec![
            vec![3.0, 2.0],      // 3x₁ + 2x₂ ≤ 120  (machine hours)
            vec![4.0, 3.0],      // 4x₁ + 3x₂ ≤ 160  (wood supply)
        ],
        vec![120.0, 160.0],      // rhs
        vec![0.0,   0.0  ],      // lower bounds: x₁, x₂ ≥ 0
        vec![30.0,  40.0 ],      // upper bounds: x₁ ≤ 30, x₂ ≤ 40
    );

    let integer_vars = vec![true, true];   // both must be integers
    let solution = branch_and_bound(&prob, &integer_vars);
}

Output

╔══════════════════════════════════════════════════════════╗
║     MILP Solver — Pure Rust, Zero Dependencies          ║
║     Factory Production Planning (Branch and Bound)      ║
╚══════════════════════════════════════════════════════════╝

BRANCH AND BOUND TREE:
──────────────────────────────────────────────────────────
  [Node   1] depth=0 obj=1900.0 → BRANCH x2=13.333 (≤13 | ≥14)
  [Node   2] depth=1 obj=1895.0 → BRANCH x1=29.500 (≤29 | ≥30)
  [Node   3] depth=2 → INFEASIBLE, pruned
  [Node   4] depth=2 obj=1890.0 → BRANCH x2=14.667 (≤14 | ≥15)
  [Node   5] depth=3 obj=1887.5 → BRANCH x1=28.750 (≤28 | ≥29)
  [Node   6] depth=4 → INFEASIBLE, pruned
  [Node   7] depth=4 obj=1880.0 → ✓ INTEGER (x1=28, x2=16)  ★ £1880
  [Node   8] depth=3 LP=1870.0 ≤ best=1880.0 → PRUNED
  [Node   9] depth=1 obj=1890.0 → ✓ INTEGER (x1=30, x2=13)  ★ £1890

╔══════════════════════════════════════════════════════════╗
║               ✅ OPTIMAL SOLUTION                       ║
╠══════════════════════════════════════════════════════════╣
║  Tables  (x₁) :    30 units                            ║
║  Chairs  (x₂) :    13 units                            ║
║  Max Profit   : £1890                                   ║
╠══════════════════════════════════════════════════════════╣
║  Machine hrs  : 116 / 120  (96.7% utilised)            ║
║  Wood used    : 159 / 160  (99.4% utilised)            ║
║  B&B Nodes    :    9 explored                          ║
╠══════════════════════════════════════════════════════════╣
║  CONSTRAINT CHECK:                                      ║
║  3(30)+2(13) = 116 ≤ 120  ✓                            ║
║  4(30)+3(13) = 159 ≤ 160  ✓                            ║
║  x₁=30 ≤ 30  ✓                                         ║
║  x₂=13 ≤ 40  ✓                                         ║
╚══════════════════════════════════════════════════════════╝

WHY NOT A SIMPLER GUESS?
──────────────────────────────────────────────────────────
  All tables (30, 0)         profit=£1500  ✓
  All chairs (0, 40)         profit=£1200  ✓
  Equal split (20, 20)       profit=£1600  ✓
  Optimal (30, 13)           profit=£1890  ✓  ← solver wins

The solver found £1,890 — significantly better than every naive guess, and it verified all constraints automatically.

Running It

cargo new milp_solver
# paste main.rs (link below)
cargo run --release

No Cargo.toml dependencies needed. Pure Rust standard library only.

Key Terms — Quick Reference

Term	Meaning
Decision variable	What the solver decides (x₁, x₂)
Objective function	What you’re maximising or minimising (Z = 50x₁ + 30x₂)
Constraint	A rule the solution must satisfy (3x₁ + 2x₂ ≤ 120)
Feasible region	All points satisfying every constraint
LP relaxation	Same problem without integer constraint — gives upper bound
Branch	Split a fractional variable into two sub-problems
Bound	Prune branches whose LP bound can’t beat the current best
Prune	Discard a branch — guaranteed to not contain the optimum
Integer solution	All integer variables have whole-number values

Why This Matters for Quantum Computing

Classical MILP solvers (HiGHS, Gurobi, OR-Tools) handle problems up to roughly 10,000–100,000 variables well. Beyond that, Branch and Bound’s exponential tree becomes intractable.

Quantum optimisation attacks this differently. Instead of sequentially searching the B&B tree, quantum algorithms explore combinations simultaneously via superposition. But to feed problems to a quantum computer, you need to convert them to QUBO (Quadratic Unconstrained Binary Optimisation):

MILP → convert integer vars to binary → add constraint penalties → QUBO

Once in QUBO form, quantum algorithms like QAOA or quantum-inspired algorithms like Simulated Bifurcation can solve it — and they scale better on large, dense combinatorial problems where classical B&B degrades.

This Rust implementation is the foundation. In the next post, we’ll convert this exact MILP into a QUBO matrix and run it through a Simulated Bifurcation solver — still in pure Rust.

What’s Next

Part 2: QUBO conversion — turning this MILP into a matrix a quantum solver can eat
Part 3: Simulated Bifurcation in Rust — quantum-inspired solver from scratch, no hardware needed
Part 4: Benchmarking against HiGHS on large-scale problems

I’m Mayuresh, Founder & CTO at AmbiCube. Building quantum-classical optimisation infrastructure in Rust. My vision is to build world’s best schedule solution company, if anyone is interested in learning something real computer science then get in touch and help me. Follow for posts on Rust, quantum algorithms, and applied AI systems

What do you think about my idea?

Mayuresh Smita Suresh — Sun, 01 Mar 2026 14:11:57 +0000

I built an app to help Elderly and Disabled people in my neighbourhood

Mayuresh Smita Suresh ・ Feb 28

#devchallenge #weekendchallenge #showdev

I built an app to help Elderly and Disabled people in my neighbourhood

Mayuresh Smita Suresh — Sat, 28 Feb 2026 10:46:22 +0000

This is a submission for the DEV Weekend Challenge: Community

My grandmother couldn't change a lightbulb, neither can take her dog on walk and I live 200 miles away, I cant be there every time.

Not because she was frail. Not because she lacked the will. But at 78, with arthritic hands and a second-floor flat with no elevator, climbing a stepladder to reach a ceiling fixture was genuinely dangerous. She lived alone. My family was two cities away. And she sat in a dim room for six days before she finally asked her neighbor — a stranger she'd shared a building with for three years — for help.

Six days in a dim room. Because she didn't know if it was okay to ask.

That's the problem NearbyHelp is built to solve. Not emergencies. Not disasters. The quiet, grinding, invisible difficulty of daily life for millions of elderly and disabled people who need small help — and have no idea who around them is willing to give it.

The Community

The community I built for is one that rarely gets built for: elderly individuals, disabled people, and anyone who lives alone and needs occasional help with day-to-day tasks that most of us take for granted.

We're talking about:

An 80-year-old who needs someone to carry a heavy box down from a shelf
A person with MS who needs a neighbor to pick up their prescription on the way back from the shops
A visually impaired resident who needs help navigating a council form online
Someone post-surgery who just needs their groceries picked up once

These aren't crises. There's no ambulance to call. There's no app for this. There's just... the hope that someone nearby is kind enough, and that you're brave enough to ask.

The second part of that equation — the willingness of neighbors to help — already exists in abundance. What's missing is the infrastructure to make that willingness visible. Right now, the goodwill is there. It's just invisible.

NearbyHelp makes it visible.

What I Built

NearbyHelp is a community-first web application where local volunteers register specific tasks they're willing to help with — and anyone nearby can open a map, see exactly who's available, how far away they are, and call them directly.

The philosophy is deliberate simplicity: one volunteer, one skill offer, one pin on the map.

No social network. No messaging layer. No karma points. Just a live map of willing neighbors, searchable by task type, sorted by distance.

Core Features

** Live Interactive Map**
Built on react-leaflet, the map shows every registered volunteer as a color-coded pin based on their task category. Tap a pin, see their name, what they can help with, and a direct call button. That's it. Designed specifically to be usable by elderly people on tablets — large tap targets, high contrast, no clutter.

** Haversine Proximity Sorting**
Every volunteer's distance from your location is calculated in real time using the Haversine formula — the same spherical geometry used in aviation navigation. It's not "roughly in your area." It's "0.4 km away." That specificity matters when you're deciding whether to ask someone for help.

** AI Skill Categorization (Google Gemini)**
Volunteers type what they can help with in plain English: "I can help move furniture and do heavy lifting" or "happy to help with tech stuff, phones, tablets, computers." Google's Gemini AI reads their natural language and maps it to a standardized tag: MAINTENANCE, TECH_HELP, ERRANDS, HOUSEWORK, TRANSPORT, COMPANIONSHIP. This means the map filter works reliably regardless of how different people describe the same task.

** One-Tap Direct Call**
Volunteers who opt in share a contact number. The app generates a native tel: link — on mobile, one tap opens the phone dialer. No messaging, no waiting for a reply. Direct human contact, immediately.

** Mobile-First List View**
A swipeable overlay on mobile showing volunteers as cards sorted nearest-first. Built specifically because many of the people looking for help are elderly tablet users who find maps cognitively harder to parse.

** Secure by Default**
Strict Row Level Security (RLS) in Supabase PostgreSQL. Users can only edit their own profiles. Volunteer visibility is opt-in. No one's location is stored with more precision than they choose to provide.

Demo

🔴 Live App: https://nearbyhelp.vercel.app

Sign in with Google, allow location access, and you'll see the map immediately populated with volunteers nearby. Use the filter panel to narrow by task type. On mobile, swipe up for the list view.

Screenshots:

The main map: color-coded pins by task category, live distance shown on each popup

Code

Github code

How I Built It

The Stack

Every technology choice was made with two users in mind simultaneously: the volunteer (typically a younger, tech-comfortable neighbor) and the person seeking help (often elderly, on a tablet, with limited tech confidence). The stack had to be fast to ship, reliable in production, and genuinely accessible.

Next.js 14 (App Router)
React Server Components for near-instant page loads. The map page is a protected route — unauthenticated users are redirected cleanly. API routes handle the Gemini integration server-side so API keys never touch the client.

Supabase — the backbone of the whole thing
Supabase does three jobs here that would have taken three separate services otherwise:

Authentication — Google OAuth, one provider, zero friction. First sign-in auto-creates a profile row via a PostgreSQL trigger. No separate user management.
Database — PostgreSQL with a custom get_nearby_profiles function that does bounding-box pre-filtering before Haversine calculation, keeping queries fast even at scale.
Row Level Security — Users can only update their own rows. Volunteer contact info is only exposed if they've explicitly opted in. Security is enforced at the database layer, not just the application layer.

The Supabase database trigger that auto-creates a profile on first Google login was one of the most satisfying pieces to build:

CREATE OR REPLACE FUNCTION public.handle_new_user()
RETURNS TRIGGER AS $$
BEGIN
  INSERT INTO public.profiles (id, display_name, avatar_url)
  VALUES (
    NEW.id,
    NEW.raw_user_meta_data->>'full_name',
    NEW.raw_user_meta_data->>'avatar_url'
  );
  RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

CREATE TRIGGER on_auth_user_created
  AFTER INSERT ON auth.users
  FOR EACH ROW EXECUTE FUNCTION public.handle_new_user();

Zero onboarding friction. Sign in, you exist in the database. Done.

The Haversine Formula
I implemented Haversine in pure TypeScript rather than relying on a library. I wanted to understand every line of the distance logic, and it's satisfying code to read:

export function haversineDistance(
  lat1: number, lng1: number,
  lat2: number, lng2: number
): number {
  const R = 6371 // Earth's radius in km
  const dLat = toRad(lat2 - lat1)
  const dLng = toRad(lng2 - lng1)

  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(toRad(lat1)) *
    Math.cos(toRad(lat2)) *
    Math.sin(dLng / 2) ** 2

  return R * 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a))
}

Every volunteer card on the map shows their distance to two decimal places. 0.4 km away. That specificity was important to me — vague proximity ("nearby") doesn't give someone the confidence to reach out. Exact distance does.

Google Gemini AI — the quiet magic
The AI feature is invisible to users, which is exactly how it should be. Volunteers type naturally. Gemini reads it and returns a standardized category. Here's the API route:

// app/api/categorize/route.ts
const TASK_TAGS = [
  'ERRANDS', 'HOUSEWORK', 'MAINTENANCE',
  'TECH_HELP', 'TRANSPORT', 'COMPANIONSHIP', 'OTHER'
]

const prompt = `
  You are a community volunteer task categorizer.
  Given this offer: '${skillText}'
  Return ONLY one tag from: ${TASK_TAGS.join(', ')}
  No explanation. Just the tag.
`

The constraint of returning only one tag from a fixed enum was deliberate. I don't want AI creativity here — I want consistency. Every "I can drive you to appointments" maps to TRANSPORT. Every "I'm good with computers" maps to TECH_HELP. The map filter relies on this being reliable.

react-leaflet + Custom Pins
No Google Maps API key required. Leaflet is open source, fast, and renders beautifully on mobile. Custom SVG pins are color-coded by task category so you can read the map at a glance without reading any text — important for elderly users who may have reduced vision.

Tailwind CSS v4
Glassmorphism-inspired UI with high contrast ratios throughout. WCAG AA compliance was a design constraint, not an afterthought. Every interactive element has a minimum 44×44px tap target for accessibility.

The Architecture Decision I'm Most Proud Of

I chose to put the Haversine calculation in JavaScript rather than SQL, but the pre-filtering (bounding box) in a Supabase PostgreSQL function. This means:

The database returns a small, geographically bounded set of profiles (fast)
JavaScript sorts them by exact spherical distance (precise)
The client renders cards in perfect nearest-first order (useful)

It's a clean separation: database does what databases are good at (filtering large datasets quickly), JavaScript does what it's good at (precise calculation on a small set).

What Was Hard

The mobile list view took longer than I expected. The UX challenge was real: elderly users navigating a swipeable overlay need smooth momentum scrolling, large text, and clear visual hierarchy. I went through four iterations before the swipe gesture felt natural enough that I'd be comfortable handing a tablet to my grandmother.

The other challenge was the Supabase RLS policies. Getting the policies right — where anyone can read volunteer profiles, but only the authenticated owner can write to theirs, and contact info is only exposed with explicit opt-in — required careful thinking. I've documented the full policy setup in the repo README for anyone who wants to fork it.

Why This Community. Why Now.

By 2030, 1 in 6 people in the world will be over 60. In many cities, over 30% of elderly people report feeling lonely. The infrastructure of community that used to exist — knowing your neighbors, looking out for each other — has eroded in modern urban life.

The solution isn't a government program or an expensive subscription service. It's already living three doors down from you. It's your neighbor who said "let me know if you ever need anything" and meant it — but never got the call because nobody had a way to make asking feel natural and safe.

NearbyHelp is that way.

It's not built for crisis. It's built for Tuesday afternoon when the jar won't open and there's nobody to call.

Built with Next.js 14, Supabase, Google Gemini AI, react-leaflet, and Tailwind CSS v4.

Live at https://nearbyhelp.vercel.app

Mathematical Optimisation in Rust: A Complete Guide to good_lp + HiGHS (Production Ready with Axum)

Mayuresh Smita Suresh — Sat, 21 Feb 2026 10:26:27 +0000

Modern backend systems often need to make optimal decisions under
constraints.

Examples:

Allocate limited resources
Minimize operational cost
Select optimal product mix
Plan logistics efficiently
Build smart pricing engines

This is where mathematical optimization becomes powerful.

In Rust, two tools make this practical:

good_lp → Modeling layer (DSL for optimization problems)
HiGHS → High-performance optimization solver

This guide covers:

Mathematical foundations
What good_lp and HiGHS are
When to use them
Rust examples
Production-ready Axum backend integration
Scaling considerations

1. Mathematical Optimization (Concept)

Optimization problems look like this:

Minimize or Maximize:

f(x)

Subject to:

g1(x) ≤ b1
g2(x) = b2
x ∈ feasible set

Where:

x = decision variables
f(x) = objective function
g(x) = constraints

2. LP vs MIP

Linear Programming (LP)

All expressions are linear.

Example:

Maximize: 3x + 2y

Subject to: x + y ≤ 10 x ≥ 0 y ≥ 0

LP problems are solved efficiently using simplex or interior-point
methods.

Mixed Integer Programming (MIP)

Some variables must be integers or binary.

Example:

x ∈ {0,1}

MIP is NP-hard.

Solvers use: - LP relaxation - Branch-and-bound - Cutting planes

3. What Is HiGHS?

HiGHS is a high-performance open-source solver written in C++.

It supports:

Linear Programming (LP)
Mixed Integer Programming (MIP)
Quadratic Programming (QP)

HiGHS is the computation engine.

4. What Is `good_lp`?

good_lp is a Rust modeling crate.

It: - Builds constraint matrices - Translates to solver format - Calls
backend solver (like HiGHS)

It does not solve problems itself.

Architecture:

Rust Code → good_lp → HiGHS → Optimal Solution

5. Installation

Cargo.toml:

[dependencies]
good_lp = "1.4"
highs = "0.8"
axum = "0.7"
tokio = { version = "1", features = ["full"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

6. Basic Optimization Example

Maximize: 3x + 2y

Subject to: x + y ≤ 10

use good_lp::{variables, variable, SolverModel, default_solver};

fn solve_lp() -> Result<(), Box<dyn std::error::Error>> {
    let mut vars = variables!();
    let x = vars.add(variable().min(0.0));
    let y = vars.add(variable().min(0.0));

    let solution = vars
        .maximise(3.0 * x + 2.0 * y)
        .using(default_solver)
        .with(x + y <= 10.0)
        .solve()?;

    println!("x = {}", solution.value(x));
    println!("y = {}", solution.value(y));

    Ok(())
}

7. Production-Ready Axum Backend Example

We now build a simple optimization API.

It solves:

Maximize: profit_a * A + profit_b * B

Subject to: A + B ≤ limit A, B ∈ {0,1}

main.rs

use axum::{routing::post, Router, Json};
use serde::{Deserialize, Serialize};
use good_lp::{variables, variable, SolverModel, default_solver};
use std::net::SocketAddr;

#[derive(Deserialize)]
struct OptimizeRequest {
    profit_a: f64,
    profit_b: f64,
    limit: f64,
}

#[derive(Serialize)]
struct OptimizeResponse {
    a: f64,
    b: f64,
    objective: f64,
}

async fn optimize(Json(payload): Json<OptimizeRequest>) -> Json<OptimizeResponse> {
    let mut vars = variables!();

    let a = vars.add(variable().binary());
    let b = vars.add(variable().binary());

    let solution = vars
        .maximise(payload.profit_a * a + payload.profit_b * b)
        .using(default_solver)
        .with(a + b <= payload.limit)
        .solve()
        .unwrap();

    let response = OptimizeResponse {
        a: solution.value(a),
        b: solution.value(b),
        objective: solution.eval(payload.profit_a * a + payload.profit_b * b),
    };

    Json(response)
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/optimize", post(optimize));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    println!("Server running at http://{}", addr);

    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

8. Running the API

Start server:

cargo run

Call endpoint:

POST http://localhost:3000/optimize

Body:

{ "profit_a": 10, "profit_b": 6, "limit": 1 }

Response:

{ "a": 1, "b": 0, "objective": 10 }

9. Production Considerations

Set solver time limits
Handle infeasible models gracefully
Log solver status
Separate optimization into service layer
Consider async worker if solve time is long

10. Scaling

To scale:

Partition large problems
Avoid symmetry
Use soft constraints carefully
Monitor solver time
Use time limits for MIP

Final Thoughts

Optimization is a powerful backend capability.

good_lp provides clean modeling. HiGHS provides industrial-grade
solving. Axum provides modern Rust web infrastructure.

Together, they form a production-ready optimization backend stack.

If your system needs:

Best possible decision under constraints

Then mathematical optimization in Rust is the correct architectural
choice.

Please ask me any questions you have in your mind I’ll be happy to guide you through

Thanks,
Mayuresh
About me

Create A Powerful Mobile App - Rust as the Brain, Flutter as the Face

Mayuresh Smita Suresh — Wed, 18 Feb 2026 13:43:53 +0000

Design beautiful interfaces in Flutter. Run serious logic in Rust.
Connect them like a pro.

Modern applications are evolving beyond simple UI rendering and API
calls. Today's apps handle heavy data processing, encryption, offline
computation, and performance‑critical operations. While Flutter is
exceptional for building beautiful cross‑platform interfaces, it is not
optimized for low‑level, high‑performance computation. That's where Rust
fits perfectly.

This article explains how to architect your application with Rust as the
"brain" and Flutter as the "face," and how they communicate efficiently.

Architecture Philosophy

Think of your app in two layers:

Flutter → Presentation Layer (UI)\
Rust → Core Logic Layer (Brain)

Flutter handles: - UI rendering - Animations - Navigation - State
management

Rust handles: - Heavy computation - Data processing - Encryption -
Parsing - Performance‑critical algorithms - Offline engines

Flutter does not need to understand internal logic. It simply calls Rust
functions and displays results. This separation keeps the system clean
and maintainable.

Why Rust Works So Well

Rust provides:

Near C‑level performance\
Memory safety without garbage collection\
Strong type guarantees\
Safe concurrency\
Cross‑platform compilation

Unlike putting heavy computation inside Dart, Rust gives you predictable
performance and control over memory behaviour. You can even reuse the
same Rust core across Android, iOS, desktop, or backend systems.

How Flutter and Rust Communicate

Flutter and Rust communicate using FFI (Foreign Function Interface).
Instead of writing raw FFI manually, you can use flutter_rust_bridge,
which generates safe bindings between Dart and Rust.

This eliminates: - Manual pointer management - Unsafe memory passing -
Complex native glue code

Basic Setup

1. Create a Rust Library

cargo new core_engine --lib

In Cargo.toml:

[lib]
crate-type = ["cdylib"]

2. Add flutter_rust_bridge

flutter_rust_bridge = "latest"

3. Write a Rust Function

lib.rs:

use flutter_rust_bridge::frb;

#[frb]
pub fn process_data(input: String) -> String {
    format!("Processed: {}", input)
}

4. Generate Bridge Code

flutter_rust_bridge_codegen

5. Call Rust from Flutter

final api = RustApi();
final result = await api.processData(input: "Hello");
print(result);

That's it. Flutter calls Rust. Rust processes the logic. Flutter renders
the result.

Streaming Data from Rust

For long‑running tasks, streaming is important.

Rust Side

use flutter_rust_bridge::StreamSink;

#[frb]
pub fn compute_stream(sink: StreamSink<String>) {
    for i in 1..=5 {
        sink.add(format!("Step {}", i));
    }
}

Flutter Side

api.computeStream().listen((message) {
  print(message);
});

This allows background processing while keeping the UI smooth.

Recommended Project Structure

project_root/
│
├── flutter_app/
│   └── lib/
│
└── rust_core/
    ├── src/
    │   ├── lib.rs
    │   ├── logic.rs
    │   ├── services.rs
    │   └── models.rs

Keep UI concerns inside Flutter and business logic inside Rust. The Rust
The core should be testable independently of Flutter.

Best Practices

Keep Flutter thin --- only UI and state.
Keep Rust pure --- no UI dependencies.
Avoid blocking calls --- use threads or streaming.
Design simple Rust APIs for Flutter to consume.
Test Rust independently via CLI before integrating.

When This Architecture Makes Sense

Use Flutter + Rust when:

You need high performance
You process large datasets
You require strong memory safety
You build offline‑first applications
You need shared core logic across platforms

For simple CRUD apps, this may be unnecessary. But for performance‑heavy
systems, this separation is powerful.

Final Thoughts

Flutter builds beautiful experiences. Rust builds powerful systems.

Together, they allow you to create applications that are fast, stable,
scalable, and maintainable, with a clear separation between
presentation and logic.

If you're building something beyond just screens, consider making Rust
Your brain and Flutter your face.

Mayuresh Smita Suresh
My work

DEV Community: Mayuresh Smita Suresh

Building GenAI-Powered Applications with PHP and CodeIgniter 4. A Complete Guide

Table of Contents

1. Why CodeIgniter 4 for GenAI

2. Project Setup & Configuration

Building a Zoho CRM AI Chatbot with Airbyte: Architecture for Anomaly Detection and Causal Analysis

Building a Zoho CRM Chatbot with Airbyte: Architecture for Anomaly Detection and Causal Analysis

Why Airbyte as the Ingestion Layer

High-Level Architecture

Layer 1: Ingestion with Airbyte

Layer 2: Semantic Layer

Layer 3: Anomaly Detection

Layer 4: Causal Analysis

Layer 5: Chat Interface

Alerts and Reports

Practical Notes

Closing Thought

Building AI Agents for Social Media with TypeScript and Hono.js

Why Hono.js for agent backends

The architecture

Setting up the project

Step 1: The cron trigger

Step 2: Fetch fresh data

Step 3: Let Claude decide what's worth posting

Step 4: Generate platform-specific copy

Step 5: Dedup with Postgres

Step 6: Publish

Wiring it together

The guardrail that actually matters

Where to go from here

Honoured to receive Google AI Badge. Awarded for publishing a top Google AI post. Thank you Dev team.

mcpnest.cloud Calling all dev to support my new platform, I am building a robust platform to deploy any MCP easily and manage it and scale it easy. Please join the waitlist your support matters a lot. Thank you.

https://mcpnest.cloud Calling all dev to support my new platform, I am building a robust platform to deploy any MCP easily and manage it and scale it easy. Please join the waitlist your support matters a lot. Thank you.

MCPNest | Deploy MCP Servers Instantly

Why MCP servers deployments are so hard?

MILP From Scratch in Pure Rust — No Dependencies, Full Branch and Bound

The Problem: A Furniture Factory

What Is MILP? (Every Word Explained)

The Mathematics

Decision Variables

Objective Function

Constraints

Matrix Form

What Does the Feasible Region Look Like?

The Algorithm: Branch and Bound

Step 1: LP Relaxation

Step 2: Branch

Step 3: Bound

Step 4: Repeat

Our Actual Search Tree (from the code output)

The Rust Code

Data Structures

LP Relaxation Solver (Coordinate Ascent)

Branch and Bound

Defining the Problem

Output

Running It

Key Terms — Quick Reference

Why This Matters for Quantum Computing

What’s Next

What do you think about my idea?

I built an app to help Elderly and Disabled people in my neighbourhood

Mayuresh Smita Suresh ・ Feb 28

I built an app to help Elderly and Disabled people in my neighbourhood

My grandmother couldn't change a lightbulb, neither can take her dog on walk and I live 200 miles away, I cant be there every time.

The Community

What I Built

Core Features

Demo

Code

How I Built It

The Stack

The Architecture Decision I'm Most Proud Of

What Was Hard

Why This Community. Why Now.

Mathematical Optimisation in Rust: A Complete Guide to good_lp + HiGHS (Production Ready with Axum)

1. Mathematical Optimization (Concept)

2. LP vs MIP

Linear Programming (LP)

Mixed Integer Programming (MIP)

4. What Is `good_lp`?