DEV Community: Mothilal M

365 Days of Consistency: What My 1-Year GitHub Streak Taught Me

Mothilal M — Mon, 27 Jul 2026 12:50:11 +0000

Today I crossed one of the most meaningful milestones in my developer journey: a 1-year GitHub contribution streak.

It is not just a number on a calendar.

It represents a year of showing up, writing code, fixing bugs, learning new tools, building projects, and staying consistent even on the days when motivation was low.

Why this streak matters to me

A streak is easy to measure, but consistency is hard to build.

For me, this year was not only about committing code. It was about developing a habit.

A habit of:

learning something new every day
pushing small improvements instead of waiting for perfect ones
staying connected to my projects
not letting gaps break momentum

That mindset changed how I work.

What I learned in one year

1. Small work still counts

Not every day is about massive features or big releases.

Some days it was a tiny fix.
Some days it was documentation.
Some days it was refactoring.
Some days it was just improving one small part of a project.

But all of it added up.

2. Consistency beats intensity

There were days when I felt highly productive and days when I did not.

The key was not to be perfect every day.

The key was to stay present.

Even small progress kept the streak alive and kept my mind in building mode.

3. Momentum is powerful

Once consistency becomes a habit, it starts working for you.

You think more clearly.
You start building faster.
You recover from breaks sooner.
You stop overthinking and start shipping.

What kept me going

A few things helped me stay consistent:

having real projects to work on
tracking progress visually
making code a daily routine
enjoying the process of building
reminding myself that progress compounds

What this year looked like

This streak was not limited to one language or one stack.

It included learning, building, debugging, experimenting, and improving across different parts of my workflow.

What mattered most was showing up.

Final thoughts

A 1-year streak is not the finish line.

It is proof that consistency works.

It taught me that real growth comes from repeated effort, not occasional bursts of motivation.

One year later, I can say this clearly:

showing up every day changes you.

And I am excited to keep building from here.

If you are trying to build a streak of your own, start small.
Commit something meaningful.
Repeat it tomorrow.
Then keep going.****

We Built an AI Coding Assistant That Refuses to Finish Your Code

Mothilal M — Sun, 26 Jul 2026 15:06:19 +0000

A student finished our twelve-week backend course with near-perfect assignment scores.

In a mock interview two days later, he couldn't write a loop that summed a list of numbers. Not "wrote it inefficiently" — couldn't start. He sat there waiting for something to autocomplete.

He hadn't cheated. He'd used ChatGPT and Copilot exactly the way we all do at work: describe the problem, accept the suggestion, move on. Twelve weeks of that. Every assignment passed. Nothing learned.

That's when it clicked for us. For a working developer, an AI that finishes your code is a productivity tool. For a student, it's a machine that removes the struggle — and the struggle was the entire point.

So we built the opposite.

The rule: do the plumbing, stop at the lesson

Every coding exercise has two kinds of code in it.

There's the part that is the lesson — the recursion, the reducer, the SQL join, the async coordination. Whatever the module is actually teaching.

And there's everything else. Imports. Reading the CSV. The if __name__ == "__main__" block. Wiring up the router. Error handling around the bit that matters. Boilerplate the student has already done fifteen times, or won't be tested on, or that's just noise between them and the concept.

A tutor who does the second kind for you is helpful. A tutor who does the first kind for you is stealing your education.

So that became the rule our assistant follows:

Write the scaffolding in full. Stop dead at the learning-critical part. Say what you did and what they must finish.

In practice a response looks like this:

import csv
from collections import defaultdict

def generate_report(csv_filepath: str):
    aggregated = defaultdict(int)

    try:
        with open(csv_filepath, newline="", encoding="utf-8") as f:
            reader = csv.DictReader(f)
            for row in reader:
                # TODO(student): Implement the core aggregation logic here.
                # Each `row` is a dict like {'Category': 'A', 'Value': '100'}.
                # Update `aggregated` based on what you're reporting.
                pass

        for key, value in aggregated.items():
            print(f"{key}: {value}")

    except FileNotFoundError:
        print(f"Error: '{csv_filepath}' not found.")

I've scaffolded the CSV reader and the output formatting. You need to implement the aggregation inside the loop.

The file opens in their editor. It runs. It just doesn't do anything yet — and the one thing standing between "runs" and "works" is precisely the thing the module is teaching.

Building it on AgentFlow

We built this on AgentFlow, our own Python framework for AI agents. It's MIT licensed and on PyPI:

pip install 10xscale-agentflow

Why not LangGraph? We started there. We like the graph mental model — that part AgentFlow keeps. What we kept rebuilding by hand was everything after the graph compiled: an API server, streaming that didn't fall over, persistence that survived a restart, a TypeScript client for the frontend. And we didn't want LangChain in the dependency tree.

So AgentFlow ships the production stack in the box: graph orchestration, a REST + SSE server, a TypeScript SDK, three-layer memory (Redis cache, Postgres, vector store), native MCP, and parallel tool execution. It's LLM-agnostic — OpenAI, Gemini, Anthropic, or any OpenAI-compatible endpoint.

The tutor itself is a small graph:

from agentflow.graph import StateGraph

graph = StateGraph(TutorState(), container=container)
graph.add_node("tutor", tutor_agent)
graph.add_node("tools", tool_node)
graph.set_entry_point("tutor")

graph.add_conditional_edges("tutor", should_continue, {"tools": "tools", END: END})
graph.add_conditional_edges("tools", route_after_tools, {"tutor": "tutor"})

app = graph.compile(checkpointer=checkpointer, store=store)

The checkpointer is the part that matters more than it looks. Conversation threads live in Postgres, so a student can close the laptop mid-exercise, come back the next evening, and the tutor still knows which milestone they're stuck on and what they already tried. No re-explaining.

The interesting bit: the agent's hands are in your editor

Here's the architectural problem. The agent runs on our server. The student's code lives in their editor. How does a model on a server read a selection, or write a file, or highlight the three lines where the bug is?

AgentFlow solves this with remote tools, and it's my favourite feature in the framework.

You register a tool from the client — in our case, the VS Code extension:

client.registerTool({
  node: 'tools',
  name: 'read_code',
  description: "Read the student's code. Use want='selection' for what they've " +
               "highlighted, 'error_context' for the file plus last terminal output.",
  parameters: {
    type: 'object',
    properties: {
      want: { type: 'string', enum: ['file', 'selection', 'range', 'error_context'] },
    },
    required: ['want'],
  },
  handler: async (args) => {
    // runs inside VS Code, with the full editor API available
    const editor = vscode.window.activeTextEditor;
    return editor.document.getText(editor.selection);
  },
});

await client.setup();   // publishes the schemas to the server

The model sees the tool schema and calls it like any other tool. But the server doesn't execute it — it returns a RemoteToolCallBlock, the SDK spots it, runs your handler in the editor, and sends the result back as a tool message. The graph picks up exactly where it left off.

The model gets eyes and hands inside VS Code without a single line of code leaving the student's machine unless the agent explicitly asks for it. No shipping the whole file on every message. No stale context.

The same mechanism drives the writing side — write_file, highlight, open_file, propose_edit. The agent decides what should happen; the editor decides how.

The pedagogy is a markdown file, not an if-statement

The thing I'd most want another team to steal: none of the teaching rules live in Python.

AgentFlow has a skills system — playbooks in markdown, loaded per turn based on what the student is doing. Ours reads like guidance to a human tutor:

## The Hardest-Part Boundary

Learning-critical core -> coach, never solve.
Boilerplate and plumbing -> write it freely.

Milestone is "fetch and display data"?
  - Stuck on the fetch -> that IS the lesson. Scaffold around it, hand it back.
  - Stuck on the loading spinner CSS -> not the lesson. Just write it.

## Understanding Gate

Before marking anything complete, ask WHY they chose their approach.
Ask what happens at [edge case]. Passing tests is not understanding.

Our instructional designers edit that file. They don't open a Python file, they don't wait for a deploy, they don't file a ticket. When a cohort struggles with a module, the person who understands why changes the rules directly.

That separation — orchestration in code, pedagogy in markdown — has been worth more than any individual feature.

Measuring who actually wrote the code

Here's the part I think most AI-in-education tools are missing.

If your AI can write code into a student's file, you have created a brand new way to cheat, and you have an obligation to measure it. Otherwise "completed the assignment" becomes meaningless.

So every AI-originated edit in our extension goes through exactly one function, and that function records the event before it writes:

async function applyBlock(block) {
  record('ai_applied', block.file, block.code.length);   // ledger first
  await vscode.workspace.fs.writeFile(target, buffer);   // then the write
}

Student keystrokes get counted from onDidChangeTextDocument. The ratio between them is displayed live in the panel header — a small typed 78% badge that both the student and their trainer can see.

Two hard-won lessons on this:

It has to be a single choke point. The moment one code path writes to a file without going through it, the number silently becomes fiction — and a fiction that looks like data is worse than no data.

Build it on day one. You cannot retrofit authorship tracking. The edits you didn't record are gone forever.

A high AI-ratio isn't automatically bad, by the way. It's a signal. It tells the tutor to probe harder before marking a milestone complete, and it tells a trainer which students to check on before the mock interview, not after.

What we've seen so far

[FILL IN — replace this section with your own numbers before publishing.]
Good things to include if you have them: how many students are using it, change in
mock-interview pass rate, average authorship ratio per module, or a direct student
quote. If you don't have hard data yet, say so plainly — "we're one cohort in and
still collecting data" is more credible than a number you can't defend, and readers
on dev.to will absolutely ask.

Try it

AgentFlow is open source and MIT licensed:

GitHub: github.com/10xHub/Agentflow
Docs: 10xhub.github.io/agentflow-docs
Install: pip install 10xscale-agentflow 10xscale-agentflow-cli

If you're building anything that puts an AI inside an editor, the remote-tools pattern is worth an hour of your time even if you use a different framework entirely. Being able to run a tool handler in the client while the graph stays on the server unlocks a category of product that's genuinely painful to build otherwise.

The question I keep going back and forth on: should a student be able to override the tutor and just get the full answer? There's a real argument that fighting a tool teaches nothing but resentment, and adults should get to choose. There's an equally real argument that the override becomes the default within a week.

We landed on "no override, but unlimited explanations." I'm genuinely not certain we got it right. What would you have done?

I Built My Own VS Code Server in 5 Minutes, Now My IDE Lives in a Browser Tab

Mothilal M — Sat, 25 Jul 2026 17:41:34 +0000

I have a confession: I own three machines and none of them agree on anything.

The desktop has my Node version. The laptop has the Python environment. The old ThinkPad in the corner has the one Docker setup that actually works. Every time I switch, I lose twenty minutes to nvm install, missing extensions, and a settings.json that drifted apart three months ago.

So last week I fixed it. Not with dotfile syncing, not with a $20/month cloud IDE subscription. I put VS Code itself in a browser tab.

Real VS Code. Real terminal. My extensions. Running at localhost:8080 in a Docker container.

It took about five minutes. Here's exactly how.

The 30-second version

If you have Docker, you are one command away:

docker run -it --rm \
  -p 8080:8080 \
  -e PASSWORD="demo1234" \
  codercom/code-server:latest \
  --bind-addr 0.0.0.0:8080 --auth password

Open http://localhost:8080, type demo1234, and you're staring at VS Code.

Not a Monaco editor in a box. Not a "code playground." The actual workbench — activity bar, file explorer, tabs, command palette (Ctrl+Shift+P), settings UI, extension marketplace.

Now hit Ctrl+`.

A real terminal. Bash, running inside the container. apt install, npm install, python3 — it's a full Linux box, and you're driving it from a browser.

That's the moment it clicked for me. This isn't a toy.

Wait — what is this thing?

It's code-server, built by the team at Coder. It takes the open-source core of VS Code and runs it as a web server. Your browser is the window; everything else happens in the container.

It's MIT licensed. It's free. There is no account, no telemetry you didn't ask for, and no monthly bill.

Making it survive a restart

The command above uses --rm, which means the moment you stop it, everything vanishes. Extensions, settings, files — gone. Fine for a test drive, useless for real work.

For a setup you'll actually use, you want three things to persist: your projects, your settings, and your extensions.

Make a folder and drop in a docker-compose.yml:

services:
  code-server:
    image: codercom/code-server:latest
    container_name: code-server
    restart: unless-stopped
    user: "1000:1000"
    environment:
      PASSWORD: "pick-something-better-than-this"
    volumes:
      - ./projects:/home/coder/projects   # your code
      - ./config:/home/coder/.config      # settings.json, keybindings
      - ./local:/home/coder/.local        # installed extensions
    command:
      - "--bind-addr=0.0.0.0:8080"
      - "--auth=password"
      - "--disable-telemetry"
      - "/home/coder/projects"
    ports:
      - "8080:8080"

Then:

mkdir -p projects config local
docker compose up -d

Back to localhost:8080. Install your extensions, tweak your theme, write some code. Now docker compose restart — or reboot your machine entirely — and it all comes back exactly as you left it.

The bug that ate 20 minutes of my life

Here's the part most tutorials skip, and it's the part that will actually bite you.

My first attempt used Docker named volumes instead of folders. Looked cleaner. The container immediately went into a crash loop, and the logs said this, over and over:

[error] EACCES: permission denied, mkdir '/home/coder/.config/code-server'

Here's what's happening. code-server runs as the coder user — UID 1000 — not as root. When Docker creates an empty named volume for a path that doesn't already exist in the image, that volume comes up owned by root. So code-server boots, tries to create its config directory, gets slapped by the filesystem, and dies. Restart policy brings it back. It dies again. Forever.

Two ways out:

Use bind mounts and pin the user — that's the user: "1000:1000" line in the compose file above. On most Linux systems your own account is UID 1000, so the folders you create are already owned correctly and everything just works. Check with id -u.

Or chown the volume first, if you'd rather keep named volumes:

docker run --rm -v code_config:/data alpine chown -R 1000:1000 /data

I went with bind mounts. Beyond dodging the bug, I can ls into ./config and see my actual settings.json sitting there in plain sight, which is worth something on its own.

What you actually get

A few things surprised me:

Extensions work. Themes, language support, formatters, GitLens — install them from the built-in marketplace like normal.

Port forwarding is automatic. Start a dev server inside the terminal on port 3000 and VS Code notices and offers to forward it. Your Vite app shows up in another tab.

It runs beautifully on a tablet. This was the unexpected win. An iPad with a keyboard case is suddenly a genuinely usable dev machine. Not "usable in an emergency" — actually fine.

It's a clean room. Every project can have its own container with its own toolchain. No more version conflicts bleeding across projects, no more "which Python is this."

The honest limitations

I'd rather you hear this from me than discover it at 1am.

Some Microsoft extensions will not work. Pylance, C# Dev Kit, Remote Development, Live Share — these are proprietary, and their licenses restrict them to official Microsoft products. code-server pulls from the Open VSX registry instead. For Python you'll fall back to Jedi or basedpyright. They're fine. They're not Pylance.

Browser keyboard shortcuts fight you. Ctrl+W closing your entire tab instead of the editor is a rite of passage. Installing it as a PWA fixes most of this.

It's as fast as the machine it runs on. On localhost that's instant. Put it on a $5 VPS and you'll feel every keystroke.

Where this actually earns its keep

One environment, every device. Desktop, laptop, tablet — same tab, same state, same everything.
Onboarding that takes a minute. Hand someone a compose file instead of a three-page README.
Teaching and workshops. Everyone gets an identical environment. No more "it doesn't work on mine."
Reviewing a PR from a borrowed laptop. Just log in.

Try it

Seriously — go run the one-liner at the top. It costs you thirty seconds and one docker pull, and the moment you hit Ctrl+` and a real shell opens inside a browser tab, you'll get why I bothered writing this.

docker run -it --rm -p 8080:8080 -e PASSWORD="demo1234" \
  codercom/code-server:latest --bind-addr 0.0.0.0:8080 --auth password

localhost:8080. Go.

If you end up running this on a machine other people can reach, treat it seriously — that terminal is a full shell on your box. Put it behind a real password at minimum, and ideally behind HTTPS and a VPN or an auth proxy. That's a whole post of its own, and I'll write it if there's interest.

What would you use this for? I'm curious whether the tablet thing lands for anyone else, or if that's just me.

We Finished Our AI Chess Coach: Meet Chaturanga ♟️

Mothilal M — Sun, 07 Jun 2026 17:37:48 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge.

What We Built

Chaturanga (चतुरङ्ग) is an AI-powered chess learning app for iOS & Android, built with Flutter. The idea is simple but stubborn: playing chess and understanding it should happen in the same place.

You play real games against an on-device Stockfish engine, and a grandmaster-style AI coach named "Acharya" sits with you the whole time — you can ask "why that move?" or "what would a GM do here?" and get a clear, human explanation instead of a raw engine evaluation. After the game, a debrief shows your best move, your biggest blunder, and the one concept to take away.

It's named after chaturanga, the ancient Indian game that modern chess descends from — chess was born in India, and this app helps it teach.

What's actually in it:

♟️ Play vs Stockfish — on-device engine, adjustable skill (1–20), with a pure-Dart fallback engine on desktop.
🧠 AI coach (Acharya) — context-aware (gets the live FEN + move history), supports OpenAI and Google Gemini, streams replies token-by-token, and works with the built-in proxy or your own API key (stored only in the device's secure storage).
🔍 Post-game debrief — evaluation chart, best/worst move detection, and a "My Mistakes" trainer that resurfaces your blunders to fix later.
📚 Learn & Quizzes — interactive lessons with arrows/highlights and tactical puzzles, with a streak + daily-challenge loop.
🏆 Gamification — XP and 7 progression tiers (Pawn → Grandmaster), daily streaks, and unlockables.
🎨 Make it yours — 16 piece styles, 4 board themes, sound effects, and smart local notifications.
📦 Offline-first & private — the engine runs fully offline and all progress is stored locally (Hive); there is no cloud account and no tracking.

Tech: Flutter · Riverpod · go_router · Stockfish (FFI) · bishop · squares · Hive · dio · flutter_secure_storage.

🔗 Repo: https://github.com/Mothilal-M/Chaturanga

Demo

https://drive.google.com/file/d/1MgDVRSBaVmaM3h-yf7VK43ELnAL8dAGw/view?usp=drive_link

The Comeback Story

This is exactly the kind of project this challenge was made for.

Before: Chaturanga was an ambitious side project I got most of the way through and then stalled. The hard parts were actually done — the Stockfish integration, the AI coaching loop, the board UI, the lessons/quizzes engine — but it was stuck in "almost":

It still had half-removed backend plumbing (leftover Firebase/Remote-Config references) from an architecture I'd abandoned.
The Learn/Quizzes engines worked, but the content was third-party data I couldn't legally publish, so the app couldn't go public.
There was no real README, no license, no public release — it lived only on my machine.

I stopped because the app was maybe 90% done and everything left was the un-fun 10% — licensing the lesson content, ripping out a backend I'd outgrown, and writing docs — so it quietly sat on my drive for months. This challenge was the deadline-shaped nudge I needed to finally clear those blockers and put it in front of people.

After (what I finished for this challenge):

🧹 Cleared the dead backend — removed the Firebase/Remote-Config remnants so the codebase honestly reflects what it is: a private, local-first app.
✍️ Replaced the unpublishable content with my own — wrote an original starter set of lessons and tactical puzzles in the app's JSON format, so Learn & Quizzes work out of the box and the whole thing is safe to open-source.
📖 Made it a real project — proper README, MIT license, repo description/topics, and a clean public history.
🚀 Shipped it — Chaturanga is now public on GitHub for the first time.

The "almost-done project gathering dust" finally became a finished, shippable app. That's the arc.

My Experience with GitHub Copilot

Copilot was the thing that got me over the "last 10%" hump — the unglamorous finishing work that's easy to procrastinate on.

Repo-wide context that paid off. I added a .github/copilot-instructions.md describing the architecture (Riverpod, go_router, Hive, local-only, the AI-coach flow). After that, Copilot's suggestions actually fit my conventions instead of generic Flutter boilerplate.
Regenerating the content. The biggest blocker was replacing the third-party lesson/quiz data. I used Copilot to scaffold new JSON in the exact schema the app expects — lesson trees (root + variations) and puzzles (fen + solutionUcis) — and to sanity-check positions.

The biggest blocker was replacing the third-party lesson/quiz data. I used Copilot Chat to scaffold new JSON in the exact schema the app expects — for example: "Using the lesson/quiz schema in copilot-instructions.md, generate a beginner back-rank-mate puzzle with a fen and solutionUcis." It got the structure right immediately, so I could focus on verifying the chess instead of the JSON.

Cleanup & consistency. Copilot helped me hunt down and remove the stale Firebase references and keep doc comments consistent across files.
Docs at the finish line. It sped up writing the README and this very post structure.

Once Copilot had that instructions file, it stopped guessing and started writing code that fit the project — five minutes of setup paid for itself within the hour. The flip side: it happily produced chess puzzles with illegal or non-mating positions, so I still verified every fen by hand. A good reminder that it accelerates the work but doesn't replace your judgment.

Team @shudiptotrafder and @mothilal

Thanks for reading! If you want to try it or read the code, it's all here: https://github.com/Mothilal-M/Chaturanga ⭐

A note on the repo: this is a brand-new public repository. The original lessons and puzzles, I don't want to distribute the data, so I stripped that out and shipped a small original starter set in its place — Learn and Quizzes now run entirely on my own content, which is what made it safe to open-source.

We Built a Typesense Dashboard with an AI Brain and It's Lowkey Insane 🧠⚡

Mothilal M — Sat, 28 Feb 2026 16:56:37 +0000

TLDR for the scroll-addicted 📱

We built Typesense UI — an open-source, fully interactive dashboard for Typesense with a built-in AI assistant powered by Gemini 2.0 Flash. You can literally talk to your search data in plain English.

It's free. It's open source. It slaps.

👉 GitHub: github.com/Mothilal-hire10x/typesense-ui
👉 Run it instantly: npx typesense-ui

The Origin Story (a.k.a. why we rage-built this) 😤

If you've ever used Typesense, you know it's an absolute beast of a search engine — blazingly fast, typo-tolerant, and open source. But let's be real... managing collections and documents through cURL commands and JSON payloads?

That's giving 2015 energy.

We wanted something that looks like it belongs in 2026. Something with dark mode (obviously), smooth animations, and — here's the plot twist — an AI that actually understands our data and can query it for us.

So we built it. And honestly? It ate and left no crumbs. 🍽️

What Makes This Different? (It's Not Just Another CRUD App)

🤖 AI Assistant That Actually Understands Your Data

This is the main character energy of the whole project.

The built-in AI chat (powered by Gemini 2.0 Flash) doesn't just answer generic questions — it has full Typesense tool-calling capabilities. It can:

List and inspect your collections
Search documents with complex filters
Create, update, and delete documents
Show results in beautifully formatted tables
Ask for confirmation before destructive operations (it's responsible bestie fr fr)

Just type something like:

"Show me all users who signed up last month sorted by name"

And it literally queries your Typesense instance and returns the results. In a table. With pagination. WHAT.

⚡ The Landing Page Goes STUPID Hard

Not gonna lie, we may have gone a little overboard with the landing page. It features:

3D scene built with React Three Fiber & Three.js
GSAP animations with scroll-triggered reveals
Lenis smooth scrolling (that butter-smooth feel)
Magnetic hover effects on CTAs
Fully responsive, dark-themed, cinematic vibes

It's giving Apple product page energy and we're not apologizing for it.

🎨 The Dashboard Itself (Where the Real Work Happens)

Once you connect to your Typesense server, you get:

Feature	What It Does
Collections Sidebar	Browse all collections with doc counts, search/filter
Advanced Table View	Paginated, sortable, with column picker
Live Search	Instant full-text search across all fields
Dynamic Filters	Auto-generated from schema — text, range, boolean
Document Editor	Create, edit, delete docs with JSON editor
Dark/Light Mode	Because we respect the vibe check
Schema Inspector	View full collection schemas at a glance

Everything is real-time. Type a search query, toggle a filter, click a column header — instant response. No loading spinners holding your life hostage.

How to Get Started (It's Embarrassingly Easy)

Option 1: The One-Liner 🏎️

npx typesense-ui

That's it. That's the tweet. It spins up a local server and opens the dashboard. Done.

Option 2: Clone & Vibe

git clone https://github.com/Mothilal-hire10x/typesense-ui.git
cd typesense-ui
npm install
npm run dev

Open http://localhost:3000, enter your Typesense server details, and you're locked in. 🔐

Option 3: Install Globally

npm install -g typesense-ui
typesense-ui

Setting Up the AI Assistant

Click the ✨ sparkle button in the bottom-right
Enter your Gemini API key (get one free here)
Start chatting with your data like it owes you money

The AI in Action — Some Wild Prompts That Just Work

Here are some things you can literally just say to the AI:

🗣️ "What collections do I have?"
→ Lists all collections with doc counts and schemas

🗣️ "Find products cheaper than $50 sorted by price"
→ Searches with filter_by and sort_by, returns a formatted table

🗣️ "Delete the document with ID abc123 from the users collection"
→ Shows a confirmation dialog first (safety first bestie)

🗣️ "What fields does the orders collection have?"
→ Returns the full schema breakdown

🗣️ "Create a new document in products with name 'Widget' and price 29.99"
→ Creates the doc after your confirmation

The AI has function calling — it doesn't just hallucinate answers, it actually executes real Typesense operations. It's like having a senior dev who never sleeps and never complains. We love to see it.

Why Typesense Deserves Better Tooling

Typesense is genuinely one of the best open-source search engines out there. It's:

⚡ Blazingly fast (sub-millisecond searches)
🔤 Typo-tolerant out of the box
🧠 Easy to setup compared to Elasticsearch
💰 Free & open source

But the ecosystem around it — especially for visual management — has been lacking. The official dashboard is decent, but we wanted something that feels modern, powerful, and has AI baked in.

Typesense UI is our attempt to give Typesense the visual experience it deserves.

What's Next? 🔮

Some things on the roadmap:

[ ] Multi-server support — switch between Typesense instances
[ ] Collection creation wizard — visual schema builder
[ ] Export/Import — bulk operations with CSV/JSON
[ ] Query playground — test search queries with syntax highlighting
[ ] Analytics dashboard — search metrics and insights
[ ] More AI models — OpenAI, Claude, local LLMs

If any of these get you hyped, drop a ⭐ on the repo and open an issue with your ideas!

Show Some Love ❤️

If this project saved you time, made you smile, or just impressed you a little bit:

⭐ Star the repo: github.com/Mothilal-hire10x/typesense-ui
🐛 Report bugs: Issues
🤝 Contribute: PRs are always welcome!
📢 Share this post: Help other devs discover it

Wrapping Up

Building this was genuinely one of the most fun projects we've worked on. The intersection of search technology, modern frontend, and AI is such a vibe right now, and we think we're only scratching the surface.

If you're using Typesense (or thinking about it), give Typesense UI a spin. It's free, it's open source, and it might just change how you interact with your search data.

Now go touch some grass. Or don't. We're not your mom. 🌱

Built with React, TypeScript, and an unhealthy amount of caffeine ☕

Follow us for more open-source drops and dev content that doesn't put you to sleep.

Stop Wiring Dependencies by Hand - Meet InjectQ, Python DI Done Right

Mothilal M — Sun, 22 Feb 2026 12:36:40 +0000

You've been there.

A service that needs a database, which needs a config, which needs an env variable that someone hardcoded three months ago and nobody remembers where. You're passing objects down ten layers of constructors. Testing means faking half your app.

It's messy. And it doesn't have to be.

Dependency Injection is the fix - but most Python DI libraries feel like they were designed for a different language. Overly complex, decorator-heavy, or magical in ways that make debugging a nightmare.

So we built InjectQ.

"We wanted DI that feels like Python - not like a Java framework that got lost on its way to PyPI."

What is InjectQ?

InjectQ is a modern, lightweight Python dependency injection library focused on:

✅ Clarity and simplicity
✅ Type safety (works with mypy, pyright)
✅ Async-first APIs
✅ Seamless FastAPI & Taskiq integration
✅ Production-grade performance (270ns per bind)

Links:

📦 PyPI
🐙 GitHub
📖 Docs

Install in one line

pip install injectq

For framework integrations:

pip install injectq[fastapi]   # FastAPI support
pip install injectq[taskiq]    # Taskiq support

Quick Start - Zero config, maximum clarity

from injectq import InjectQ, inject, singleton

container = InjectQ.get_instance()

# Bind a value — dict-style, no ceremony
container[str] = "Hello, World!"

@singleton
class UserService:
    def __init__(self, message: str):
        self.message = message

    def greet(self) -> str:
        return f"Service says: {self.message}"

@inject
def main(service: UserService) -> None:
    print(service.greet())

main()  # → Service says: Hello, World!

That's it. @singleton = one instance app-wide. @inject = auto-resolve from type hints. No XML, no 500-line config, no magic.

Core Features

🔧 Dict-like API

The simplest mental model possible:

from injectq import InjectQ

container = InjectQ.get_instance()

# Bind anything
container[str] = "config_value"
container[Database] = Database()

# Retrieve
db = container[Database]

🎯 Decorator + Type-based Injection

@inject
def process(service: UserService, db: Database):
    # Both auto-resolved from the container
    ...

Also supports Inject[T] for inline type annotations that work with static type checkers.

🔄 Scopes and Lifetimes

from injectq import singleton, transient, scoped

@singleton
class Database: ...       # One instance, lives forever

@transient
class Validator: ...      # New instance every resolution

@scoped("request")
class RequestContext: ... # One per request scope

# Async scopes work too
async with container.scope("request"):
    ctx1 = container.get(RequestContext)
    ctx2 = container.get(RequestContext)
    assert ctx1 is ctx2  # Same instance ✓

🆕 Hybrid Factories - The Feature That Changes Everything

This is new in v0.4 and it's genuinely great.

The problem: You have a factory that needs a database (DI-managed) and a user ID (runtime value). Old way is verbose:

# ❌ Old way — manually resolve everything
db    = container[Database]
cache = container[Cache]
svc   = container.call_factory("user_service", db, cache, "user123")

New way with invoke():

def create_user_service(db: Database, cache: Cache, user_id: str):
    return UserService(db, cache, user_id)

container.bind_factory("user_service", create_user_service)

# ✅ Auto-inject db and cache, you only pass what you know
svc = container.invoke("user_service", user_id="user123")

# Async version
svc = await container.ainvoke("async_service", batch_size=100)

InjectQ resolves what it knows from the container. You provide only the runtime-specific values. Clean.

🚀 FastAPI Integration

from typing import Annotated
from fastapi import FastAPI
from injectq import InjectQ, singleton
from injectq.integrations.fastapi import setup_fastapi, InjectFastAPI

app       = FastAPI()
container = InjectQ.get_instance()
setup_fastapi(container, app)

@singleton
class UserService:
    def get_user(self, user_id: int) -> dict:
        return {"id": user_id}

@app.get("/users/{user_id}")
async def get_user(
    user_id: int,
    user_service: Annotated[UserService, InjectFastAPI(UserService)],
):
    return user_service.get_user(user_id)

🧪 Testing — Mocking Without the Pain

from injectq.testing import override_dependency, test_container

# Override a specific dep for the duration of a block
with override_dependency(Database, MockDatabase()):
    service = container.get(UserService)
    # UserService gets MockDatabase here ✓

# Fully isolated test container — no global state bleed
with test_container() as tc:
    tc.bind(Database, MockDatabase)
    # Clean slate for each test

Pro tip: Use InjectQ.test_mode() with pytest fixtures to auto-reset your container between tests.

🏗️ Modules and Providers

For larger apps, organize your bindings into modules:

from injectq.modules import Module, SimpleModule, ProviderModule, provider

class AppModule(Module):
    def configure(self, binder):
        binder.bind(Config, Config())
        binder.bind(Database, Database)

class Providers(ProviderModule):
    @provider
    def make_notifier(self, db: Database, cfg: Config) -> Notifier:
        return Notifier(db, cfg)

container = InjectQ(modules=[AppModule(), Providers()])

🛡️ Abstract Class Validation

InjectQ validates at bind time, not at resolution time:

from abc import ABC, abstractmethod
from injectq.utils.exceptions import BindingError

class PaymentProcessor(ABC):
    @abstractmethod
    def process_payment(self, amount: float) -> str: ...

# ❌ Raises BindingError immediately — no surprises at runtime
container.bind(PaymentProcessor, PaymentProcessor)

# ✅ Correct — bind the concrete implementation
container.bind(PaymentProcessor, CreditCardProcessor)

Fail fast. Debug less.

Performance Benchmarks

InjectQ isn't just clean — it's fast.

Operation	Speed
Basic bind / get	270–780 nanoseconds
Dependency resolution	~1 microsecond
10-service web request simulation	142 microseconds
1,000+ concurrent operations	Sub-millisecond

Thread-safe by default. Production-ready from day one.

Why InjectQ Over Alternatives?

Feature	InjectQ	dependency-injector	injector
Dict-like API	✅	❌	❌
FastAPI integration	✅ Built-in	✅	❌ Manual
Hybrid factories (invoke)	✅	❌	❌
Async scope contexts	✅	⚠️ Limited	❌
Testing utilities	✅ Built-in	✅	❌ Manual
Taskiq integration	✅	❌	❌
Abstract class guard	✅ Bind-time	❌ Runtime	❌ Runtime

TL;DR

If you're tired of:

Manually wiring dependencies
Global state leaking into tests
Framework integrations that require 200 lines of glue code

InjectQ is for you.

pip install injectq

Built with ♥ by the 10xHub team. MIT Licensed. Contributions welcome.

Have questions or feature requests? Drop them in the comments or open an issue on GitHub. We read everything.