Search for a command to run...
System-level engineer building reliable backend systems with a focus on performance, correctness, and real-world constraints. I work across APIs, databases, networking, and infrastructure, enjoy understanding how systems behave under load and failure, and write to break down complex backend and distributed-systems concepts through practical, real-world learnings.
No comments yet. Be the first to comment.
I document what I learn, build, and reflect on during weekends and free time. This is a progress log, not tutorials—just honest notes on engineering, mistakes, and growth as a software engineer.
Today, I was working on an admin panel feature. Simple task.One button.One API. 👉 “Create Policy” I clicked the button. Policy created ✅Clicked again (by mistake)…Another policy created ❌Clicked again (slow network)…Boom — three duplicate records. N...
Building an AI agent that deploys Cloudflare Workers with LangChain.js, and the Redis circuit breaker that keeps it running after the free tier dies.
How AxioDBCloud went from an open TCP socket to a TLS-encrypted, authenticated, pooled, and AI-drivable system in seven days. There is a specific kind of discomfort that comes from looking at your ow
Most Node.js tutorials stop at "it works on my machine." Production is where the interesting failures live, and they rarely show up in your logs. Memory climbs for no visible reason. One endpoint pegs
Recently, I got invited to mentor at HackArena 2.0 - Kolkata Zonals, held at Jadavpur University. Honestly, when the invite landed in my inbox from the Ignite Room team, I wasn't sure what to expect.
The pricing problem that would not leave me alone I have been working with Cloudflare Workers for a long time now. I have contributed to a few open source tools in the Workers ecosystem, deployed Work
AnkanHub
20 posts
When I first built ReviewBuddy, it started as a simple GitHub Action written in Shell Script. At that time, the goal was straightforward:
👉 get something working fast, validate the idea, and ship.
And shell scripting did its job.
But as ReviewBuddy started evolving—from a basic PR commenter to a configurable AI-powered code review tool—the cracks started showing. That’s when I made a deliberate decision to rewrite the core architecture in Node.js.
This post explains why that switch was necessary, what broke with shell, and what Node.js unlocked.
Shell scripts are great for:
Quick automation
CI/CD glue code
Lightweight GitHub Actions
Simple curl-based workflows
For ReviewBuddy v1, Shell Script made sense because:
GitHub Actions runs bash natively
Easy to parse env vars
Fast to prototype
Minimal setup
At that stage, ReviewBuddy:
Read PR metadata
Sent code to an AI API via curl
Posted comments back on PRs
Simple. Effective. Done.
Once users started asking for more control and customization, shell became a bottleneck.
Supporting things like:
Review tone (professional, roast, funny)
Language (Hinglish, English, Hindi, etc.)
File filtering
Conditional logic
In shell, this quickly turned into:
Fragile string parsing
Hard-to-debug edge cases
unreadable if-else chains
Shell scripts don’t scale well when logic grows.
AI APIs fail. Networks fail. Inputs break.
In shell:
Error handling is primitive
No structured exceptions
Debugging failures inside GitHub Actions is painful
Logs become noisy and unclear
For an AI-based reviewer, reliability matters.
As features increased:
Code readability dropped
Contributions became harder
Refactoring was risky
Testing was almost non-existent
Shell is not meant to be a long-term application language.
Future plans included:
Re-running reviews via PR comments
Better diff parsing
Multiple AI providers
Smarter context handling
Metrics & usage tracking
Doing this in shell would’ve been technical debt from day one.
Switching to Node.js wasn’t about trends—it was about control and scalability.
With Node.js:
Modular codebase
Clear separation of concerns
Easier refactoring
Real abstractions (not hacks)
This matters when a project grows beyond a weekend experiment.
GitHub APIs and AI APIs speak JSON.
Node.js gives:
Native JSON handling
Clean request/response parsing
Structured error handling
Better logging
No more brittle sed | awk | grep pipelines.
For both me and contributors:
Familiar ecosystem
Easier onboarding
Linting, formatting, testing
Clear stack traces
If people are going to use or contribute, DX matters.
Node.js unlocked:
Multi-language review support
Configurable review styles
Cleaner PR diff processing
Future support for GitHub App integration
Serverless backends (if needed later)
The action stopped being “just a script” and became a real product.
Short answer: Yes, absolutely.
Shell Script helped me:
Validate the idea
Ship fast
Learn what users actually wanted
Node.js helped me:
Build something sustainable
Move faster long-term
Avoid unmanageable tech debt
Think like a product, not a hack
This wasn’t a rewrite for perfection—it was a rewrite for survival and growth.
Shell scripts are fantastic tools.
But not everything should live in bash forever.
ReviewBuddy outgrew its initial constraints, and switching to Node.js was the natural next step—not because shell is bad, but because the problem evolved.
If you’re building GitHub Actions or developer tools:
Start simple
Validate early
But don’t hesitate to switch architecture when reality demands it
That’s not overengineering—that’s engineering.
