DEV Community: Renato Silva

Why I Started Rejecting My Own Giant PRs on a Solo Project

Renato Silva — Thu, 20 Aug 2026 09:28:25 +0000

I don't have teammates on this project. No one is waiting on my PRs, no one is blocked by my branch, and technically I could just push straight to main and call it a day. For about eight months, that's exactly what I did. Then I started opening pull requests against myself, refusing to merge them until they passed a checklist, and my bug count dropped hard enough that I'm never going back.

This isn't a productivity larp. It's a direct response to something I kept doing on a Node.js backend for a side project that grew into something people actually pay for: writing 1,200-line PRs that touched routing, database schema, auth middleware, and a new queue system all at once, then merging them at 1am because "it works locally."

🔧 The Problem

Here's an actual PR title from my own history, from back when I didn't bother with PRs at all, just commits:

commit 4a9f2c1
Author: me

add subscription billing, refactor user model, switch to bullmq, fix cors bug

One commit. Four unrelated concerns. When something broke in production three weeks later — turned out the user model refactor silently changed how email uniqueness was enforced — I had no way to bisect it cleanly. git bisect pointed at a commit that also happened to introduce a queue system, so I spent an hour reading unrelated BullMQ code before I found the actual bug in a Mongoose schema change two files away.

The mega-PR problem people are complaining about on GitHub right now — the 4,000-line diff nobody can meaningfully review — isn't really a GitHub problem. It's a batching problem. Solo devs get it too, we just don't call it a "review bottleneck" because there's no reviewer to bottleneck. The cost shows up later, as debugging tax instead of review tax.

🧩 What Changed

I started treating my own future self as the reviewer. Concretely, that meant three habits, in order of how much they actually helped.

1. One deployable concern per PR

Not one file. One concern. A PR can touch six files if they all serve the same change. It cannot touch six unrelated changes even if it's technically "one file."

Before:

feat: subscription billing, user model refactor, bullmq, cors fix

After, same work, split into four PRs merged over two days:

fix: cors origin whitelist for staging subdomain
refactor: normalize email field before uniqueness check
feat: add BullMQ queue for email jobs (behind flag)
feat: enable Stripe subscription billing on user model

Each of those is independently revertible. When the queue system had a memory leak two weeks later, git revert on one commit fixed it without touching billing.

2. Feature flags instead of long-lived branches

The old instinct was to keep a branch alive for a week while I built something big, then merge it all at once — the exact mega-PR pattern. Now I merge small, working pieces behind a flag, even when the feature isn't done.

javascript
// config/flags.js
const flags = {
QUEUE_EMAIL_JOBS: process.env.FLAG_QUEUE_EMAIL_JOBS === 'true',
};

module.exports = flags;

javascript
// services/emailService.js
const { QUEUE_EMAIL_JOBS } = require('../config/flags');

async function sendWelcomeEmail(user) {
if (QUEUE_EMAIL_JOBS) {
await emailQueue.add('welcome', { userId: user.id });
} else {
await mailer.sendNow(user.email, 'welcome');
}
}

This let me merge the BullMQ integration in small pieces — queue setup, worker process, retry logic — over four separate PRs, none of which changed production behavior until I flipped FLAG_QUEUE_EMAIL_JOBS to true in one final, tiny, easy-to-review PR:

diff

FLAG_QUEUE_EMAIL_JOBS=false
FLAG_QUEUE_EMAIL_JOBS=true

If that broke something, the rollback was a one-line env change, not a git revert across four commits with merge conflicts.

3. A self-review checklist before I hit merge

This is the part that actually changes behavior, because it forces a pause. Mine lives in .github/pull_request_template.md and I fill it out even though I'm the only one who reads it:

markdown

Self-review checklist

[ ] This PR does ONE thing. If I can't summarize it in one sentence, split it.
[ ] No schema change and feature logic in the same PR.
[ ] New code path is behind a flag if it touches billing, auth, or queues.
[ ] I ran this against the staging DB dump, not just local seed data.
[ ] Rollback plan: revert commit / flip flag / neither needed.
[ ] Diff is under ~300 lines, or I have a good reason it isn't.

That last checkbox alone killed most of my mega-PRs. "Under 300 lines" isn't a magic number — it's just small enough that I can actually reread the whole diff in one sitting and notice the thing I got wrong, instead of skimming because I already know what I meant to write.

📉 Before / After, With Real Numbers

I pulled stats from my own git log across a 3-month window before and after adopting this.

	Before	After
Avg lines changed per PR	640	145
Production incidents traced to a merge	6	1
Time to `git bisect` a regression	~45 min avg	~8 min avg
PRs reverted in full	3	0 (partial reverts only)

The incident count matters most. Five of those six "before" incidents were bugs sitting quietly inside a large diff, unrelated to the actual thing I thought I was shipping. Smaller diffs didn't make me a better programmer overnight — they just made my mistakes smaller and easier to isolate.

🚦 Where I Still Cut Corners

I'm not going to pretend this is pure discipline. Genuine one-off scripts, migrations I'll run exactly once, or throwaway debug endpoints still go straight to main sometimes. The checklist is for anything touching auth, billing, data integrity, or anything a customer would notice if it broke. Applying full ceremony to a typo fix in a README would just be theater.

🙋 Your Turn

If you're a solo dev or work on a small team with light review culture — do you actually PR your own work, or is main still your review process? I'm curious whether feature flags feel like overhead to people working on smaller CRUD apps versus something like billing or queues where the blast radius of a bad merge is bigger.

Drop your workflow in the comments, especially if you've got a better checklist item than mine — I'm always looking to steal a good one.

Your API Doesn't Have an AI Problem, It Has a Design Problem

Renato Silva — Wed, 19 Aug 2026 19:48:44 +0000

Every week there's a new post about "adding AI to your API" — a chat endpoint, a summarization feature, an autocomplete widget. And every week, teams discover the same thing: the AI feature isn't the hard part. The hard part is that their API was never designed to answer real questions in the first place.

AI doesn't create bad architecture. It just puts a spotlight on it and asks it to perform live, in front of an audience.

🔥 The Pattern Nobody Wants to Admit

Here's the usual sequence:

Team builds a CRUD API around whatever tables were easiest to model.
Product asks for an AI feature — "summarize customer sentiment," "suggest a response," "cluster similar feedback."
Engineering discovers the API can't answer "similar to what?" or "sentiment over what time window, grouped how?" without a pile of N+1 queries, ad hoc joins, or a background job nobody wants to own.
Someone ships a /ai/summarize endpoint that quietly does three database round trips, a Python script, and a prayer.

The AI didn't break the system. The AI just needed the system to answer real, compositional questions — and it turns out the system was only ever designed to answer "give me row 42."

🧩 Case Study: minimalist-feedback-api

Let's make this concrete with a small, honest example — a feedback API that looks totally reasonable at first glance.

sql
CREATE TABLE feedback (
id SERIAL PRIMARY KEY,
message TEXT NOT NULL,
rating INTEGER,
submitted_at TIMESTAMP DEFAULT now(),
user_email TEXT
);

And the API surface:

http
GET /feedback
GET /feedback/:id
POST /feedback
DELETE /feedback/:id

This is fine for a v1. It's minimal, it's CRUD, it ships fast. The problem is what it's missing: there's no concept of a category, no tags, no source (web, mobile, support ticket), no status (new, triaged, resolved), and no relationship to a product area or feature. rating is a bare integer with no scale documented anywhere except a Slack message from eight months ago.

Nobody complained, because the only client was an admin dashboard doing SELECT * FROM feedback ORDER BY submitted_at DESC LIMIT 50.

🤖 Where the AI Feature Broke Everything

Then someone asks for: "Can we get an AI summary of feedback trends by feature area, this week vs. last week?"

Suddenly every missing modeling decision becomes a blocking issue:

There's no feature_area, so the LLM prompt starts doing keyword matching on free text ("if message contains 'checkout'...") — which is just a worse, slower, non-deterministic version of a foreign key.
rating isn't validated or scaled consistently, so "average sentiment" is comparing 1–5 stars against some rows where someone typed -1 two years ago and it never got caught.
There's no submitted_at index strategy for range queries, so "this week vs last week" becomes two full table scans through a text-heavy table, on every request, because there's no caching layer and no aggregation endpoint either.
The endpoint that gets built to serve this, /ai/summary, ends up doing the query, the grouping, the prompt construction, and the LLM call all inline, with no separation between "fetch relevant data" and "generate summary," which means you can't cache the first part or test it independently of the model.

http
GET /ai/summary?range=week

{
"summary": "Feedback improved slightly...",
"note": "best effort, based on keyword matching, may be wrong"
}

That note field is the tell. It's an apology baked into the response schema.

🛠 The Actual Fix: Model the Domain, Not the Table

The fix has almost nothing to do with AI. It's the modeling work that should have happened before anyone typed CREATE TABLE.

sql
CREATE TABLE feedback (
id SERIAL PRIMARY KEY,
message TEXT NOT NULL,
sentiment_score NUMERIC(3,2), -- normalized -1.0 to 1.0, computed once
source TEXT NOT NULL, -- 'web', 'mobile', 'support'
feature_area_id INTEGER REFERENCES feature_areas(id),
status TEXT NOT NULL DEFAULT 'new',
submitted_at TIMESTAMP NOT NULL DEFAULT now(),
user_id INTEGER REFERENCES users(id)
);

CREATE INDEX idx_feedback_submitted_at ON feedback (submitted_at);
CREATE INDEX idx_feedback_feature_area ON feedback (feature_area_id);

And the endpoint set stops being pure CRUD and starts modeling actual questions people ask:

http
GET /feedback?feature_area=checkout&since=2024-05-01&until=2024-05-08
GET /feedback/aggregate?group_by=feature_area&range=week
GET /feature-areas/:id/trend?window=30d

Notice what changed: the aggregation is a first-class resource (/feedback/aggregate), not something invented inline inside an AI endpoint. Now the AI feature is almost boring:

python
def generate_weekly_summary(feature_area_id: int) -> str:
trend = api.get(f"/feature-areas/{feature_area_id}/trend?window=7d")
prompt = build_summary_prompt(trend) # deterministic, testable
return llm.complete(prompt)

The LLM call is now the last step, operating on well-shaped, pre-aggregated, already-correct data. If the summary is wrong, you can tell immediately whether it's a data problem or a prompting problem — because they're separated.

📐 What Good Looks Like

A few concrete rules that fall out of this case study, not as abstract principles but as things you can check in a PR review:

If an AI feature needs a join your API can't express, that join was always missing. The AI request just made it visible faster than a human analyst would have.
Aggregation endpoints are not optional sugar. /resource/aggregate or /resource/:id/trend should exist before anyone builds a summarization feature on top, not as a side effect of building one.
Free text fields are where schema debt hides. message being a TEXT blob is fine; using string matching against it as a substitute for a feature_area_id is a design smell wearing an AI costume.
Normalize before you summarize. If rating or sentiment_score isn't validated at write time, no amount of prompt engineering downstream will make the aggregate trustworthy.
Keep the retrieval and the generation separate, and testable separately. If your only way to verify the LLM's output is to eyeball it, you've merged two very different failure modes into one.

None of this is AI-specific advice. It's just API design discipline that AI features are unusually good at exposing, because they demand compositional answers instead of row lookups.

💬 Over to You

If you added an AI feature to an existing API recently — what actually broke first? Was it the schema, the missing aggregation layer, or something in how endpoints were shaped around CRUD instead of around the questions people actually ask?

The uncomfortable version of this post is: if the AI feature made your API look bad, the API was already bad. AI is just an unusually blunt code reviewer.

Rate Limiting Lessons From a 100K-Request Meltdown

Renato Silva — Fri, 14 Aug 2026 20:05:16 +0000

🔥 The Story That Made Every Backend Dev's Stomach Drop

You probably saw it: a developer shipped a React component with a useEffect that had a missing dependency array (or a state update that retriggered itself), and it quietly hammered their API with over 100,000 requests before anyone noticed. No malicious actor, no botnet — just a bracket in the wrong place and a hook that fired on every render.

The internet had a good laugh, but every backend dev reading that thread had the same intrusive thought: "my API would've just... died."

That's the uncomfortable truth. A self-inflicted traffic spike from a buggy client is functionally indistinguishable from a DDoS if your server has no defenses. The fix isn't "tell frontend devs to be careful" — it's "assume they won't be, and build accordingly."

This post walks through the three layers I now consider non-negotiable for any Node/Express API: token-bucket rate limiting, circuit breakers, and defensive defaults. I'll also talk about a real (much smaller, thankfully) spike that hit my side project, minimalist-feedback-api, and what actually saved it.

🪣 Why Token Bucket Beats Fixed Windows

Most people's first rate limiter is a fixed window: "100 requests per minute per IP." It's easy to reason about and easy to implement badly. The problem is the boundary. If your window resets at :00, a client can send 100 requests at 11:59:59 and another 100 at 12:00:01 — 200 requests in two seconds, technically "within limits."

Token bucket fixes this by modeling capacity as a continuously refilling resource instead of a hard reset:

js
// tokenBucket.js
class TokenBucket {
constructor({ capacity, refillRatePerSec }) {
this.capacity = capacity;
this.tokens = capacity;
this.refillRate = refillRatePerSec;
this.lastRefill = Date.now();
}

_refill() {
const now = Date.now();
const elapsedSec = (now - this.lastRefill) / 1000;
const refillAmount = elapsedSec * this.refillRate;
this.tokens = Math.min(this.capacity, this.tokens + refillAmount);
this.lastRefill = now;
}

tryConsume(cost = 1) {
this._refill();
if (this.tokens >= cost) {
this.tokens -= cost;
return true;
}
return false;
}
}

module.exports = TokenBucket;

Then the Express middleware, keyed per client (IP, API key, whatever identifies the caller):

js
// rateLimitMiddleware.js
const TokenBucket = require('./tokenBucket');

const buckets = new Map();

function getBucket(key) {
if (!buckets.has(key)) {
buckets.set(key, new TokenBucket({ capacity: 20, refillRatePerSec: 2 }));
}
return buckets.get(key);
}

function rateLimit(req, res, next) {
const key = req.ip; // swap for API key if you have auth
const bucket = getBucket(key);

if (bucket.tryConsume(1)) {
return next();
}

res.status(429).set('Retry-After', '1').json({
error: 'Too many requests. Slow down.',
});
}

module.exports = rateLimit;

The key insight: capacity 20 with a refill rate of 2/sec means a client gets a burst allowance (handles legitimate rapid-fire usage like a form autosave) but can't sustain more than 2 requests/sec indefinitely. That's exactly the shape of a runaway useEffect loop — it doesn't send 100 requests once, it sends them in a tight, sustained burst. Token bucket catches that pattern where a naive fixed window might not, depending on where the boundaries land.

For anything beyond a single process, don't keep buckets in memory — use Redis (via something like rate-limiter-flexible) so limits survive restarts and work across horizontally scaled instances. In-memory Map is fine for a single-instance side project; it's a liability the moment you run two replicas behind a load balancer, because each instance tracks its own bucket and your effective limit doubles per replica.

🧯 Circuit Breakers: The Second Line of Defense

Rate limiting protects your API from too many incoming requests. Circuit breakers protect your API (and its downstream dependencies) from cascading failure once something's already struggling — usually a database, a third-party API, or an internal service call that's gone slow or unresponsive.

Here's the pattern with opossum, a solid circuit breaker library for Node:

js
const CircuitBreaker = require('opossum');
const db = require('./db');

async function fetchFeedback(id) {
return db.query('SELECT * FROM feedback WHERE id = $1', [id]);
}

const breakerOptions = {
timeout: 3000, // fail fast after 3s
errorThresholdPercentage: 50, // trip if 50% of requests fail
resetTimeout: 10000, // try again after 10s
};

const breaker = new CircuitBreaker(fetchFeedback, breakerOptions);

breaker.fallback(() => ({ error: 'Feedback service temporarily unavailable' }));

app.get('/feedback/:id', async (req, res) => {
const result = await breaker.fire(req.params.id);
res.json(result);
});

Without this, a slow database under load doesn't just cause slow responses — it causes request pileup. Every incoming request holds a connection open waiting on a query that's never coming back fast enough, you exhaust your connection pool, and now healthy requests fail too. The circuit breaker trips, starts returning fast fallbacks immediately, and gives the database room to recover instead of getting buried under retries.

Rate limiting stops the flood at the door. Circuit breakers stop one struggling dependency from taking the whole system down with it. You want both — they solve different failure modes.

🛡️ Defensive Defaults I Now Bake Into Every Express API

Beyond the two big patterns above, there's a checklist of small things that cost nothing to add and save you on a bad day:

js
const express = require('express');
const helmet = require('helmet');
const compression = require('compression');

const app = express();

// Cap body size — don't let a malformed client send you a 500MB payload
app.use(express.json({ limit: '100kb' }));

// Basic security headers
app.use(helmet());

// Compress responses to reduce bandwidth under load
app.use(compression());

// Global request timeout so nothing hangs forever
app.use((req, res, next) => {
res.setTimeout(10000, () => {
res.status(503).json({ error: 'Request timed out' });
});
next();
});

// Always have a catch-all error handler, even if it feels redundant
app.use((err, req, res, next) => {
console.error(err);
res.status(500).json({ error: 'Something went wrong' });
});

None of this is exciting. That's the point — defensive defaults are boring on purpose. The bracket-typo story went viral precisely because the API had no boring safety net, and 100,000 requests met zero resistance.

📈 The Day minimalist-feedback-api Got Hit

minimalist-feedback-api is a small feedback-collection service I built as a learning project — nothing fancy, just an endpoint for apps to POST feedback and a dashboard to read it. It's not built to handle enterprise traffic, but I treated it like production because that's where you actually learn this stuff.

A few months in, one integrator's frontend had a retry loop with no backoff — every failed request immediately retried, and a brief blip in their own network turned into a sustained burst against my /feedback endpoint. It wasn't 100,000 requests, but it was enough (a few thousand in under a minute) to be a real stress test.

What actually saved it wasn't anything clever — it was the boring stuff: the token bucket limiter returned 429s immediately instead of letting requests queue up, the body size cap meant even the retries were cheap to reject, and the circuit breaker around my database call meant the brief connection pressure never turned into a full outage. The service degraded gracefully (some legitimate requests got 429'd too) instead of falling over entirely. That's the tradeoff you're signing up for: rate limiting means occasionally rejecting a request that would've been fine, in exchange for never going fully down.

🤔 What Would Your API Do?

Honestly ask yourself: if a client-side bug sent your busiest endpoint 100,000 requests in five minutes right now, what would happen? Would it 429 gracefully, or would your database connection pool just... give up?

If you're not sure, that uncertainty is the signal to add a rate limiter today — even a basic one. It's a couple hours of work that turns a viral "oops" story into a boring non-event. What's your go-to rate limiting setup, and have you ever had a spike (accidental or not) actually test it for real? I'd love to hear the war stories in the comments.

I Stopped Trusting AI Agents With My API

Renato Silva — Fri, 14 Aug 2026 19:51:29 +0000

🤖 The Problem

A few weeks ago I wired an LLM agent up to minimalist-feedback-api, my little side project for collecting product feedback. The pitch to myself was simple: let a support-bot agent read feedback threads and occasionally write a triage note or close a stale ticket, without me manually reviewing every call.

It took about two days for the agent to do something I didn't ask for.

Nothing catastrophic — it bulk-updated the status of a dozen feedback items because it decided, on its own, that they were "resolved" based on a fuzzy read of the conversation. Technically it used an endpoint I'd exposed to it. Technically the request was authenticated. But nobody had actually agreed that an agent should be allowed to do bulk writes, and there was no record of why it thought that was a good idea.

That's the part that got me. With a human client, a bad API call is a bug. With an agent, a bad API call is a decision, made by a system that can also decide to make it again, faster, in a loop, at 3am.

So I stopped trusting agents with the same trust model I give human-driven clients, and built a gatekeeper middleware specifically for tool-calling traffic.

🔐 What "Trust" Even Means for an Agent

Before writing code, I had to get concrete about what I was actually worried about. It came down to three things:

Scope — an API key belonging to "the support agent" should not be able to call every write endpoint just because it's authenticated.
Rate — agents don't get bored or embarrassed. A misbehaving loop can hit your API way harder than a person ever would.
Audit — when something weird happens, I need to reconstruct not just what was called, but which agent, with what identity, doing what it claimed to be doing.

Regular auth middleware answers "who are you." This needed to answer "are you allowed to do this specific thing, right now, at this rate, and is someone going to know about it."

🏗️ The Shape of the Middleware

minimalist-feedback-api has a handful of write endpoints: create feedback, update status, delete feedback, bulk operations. I treated agent access as a distinct concern from normal API auth — it sits after authentication and before the route handler.

js
// middleware/agentGatekeeper.js
const agentScopes = {
'agent:support-triage': ['feedback:update-status', 'feedback:read'],
'agent:analytics-readonly': ['feedback:read'],
};

function requireAgentScope(action) {
return (req, res, next) => {
const agentId = req.headers['x-agent-id'];
const agentToken = req.headers['x-agent-token'];

if (!agentId) {
  // Not an agent request, let normal auth handle it
  return next();
}

if (!verifyAgentToken(agentId, agentToken)) {
  return res.status(401).json({ error: 'invalid agent credentials' });
}

const allowed = agentScopes[agentId] || [];
if (!allowed.includes(action)) {
  return res.status(403).json({
    error: `agent '${agentId}' is not scoped for action '${action}'`,
  });
}

req.agent = { id: agentId, action };
next();

};
}

module.exports = { requireAgentScope };

The key decision here: scopes are actions, not endpoints. feedback:update-status and feedback:delete are separate permissions even though they might hit similar routes, because "update a status field" and "permanently delete a record" are very different risk levels. My support-triage agent gets the former, never the latter. No agent in this system currently has delete access, on purpose — if it needs to happen, a human does it.

🚦 Rate-Limiting Per Agent, Not Per IP

Standard rate limiters key off IP address, which is close to useless for agents — they usually run from the same handful of server IPs as your other backend traffic. I keyed limiting off the agent identity instead, with tighter windows than I'd ever apply to a human-facing key:

js
const rateLimit = require('express-rate-limit');

Five writes a minute felt aggressive when I set it, but it's forced something useful: if the agent legitimately needs to do more than that, it should be batching its reasoning into fewer, larger, more deliberate calls — not firing off a write per sentence of its own chain of thought.

📝 Auditing: The Part I Actually Use Every Day

Scopes and rate limits prevent damage. The audit log is what lets me trust the system incrementally instead of all-or-nothing. Every agent-originated write gets logged with enough context to answer "why did this happen" without me guessing:

js
function auditAgentWrite(req, res, next) {
const original = res.json.bind(res);
res.json = (body) => {
if (req.agent) {
logAgentEvent({
agentId: req.agent.id,
action: req.agent.action,
method: req.method,
path: req.originalUrl,
requestBody: req.body,
statusCode: res.statusCode,
timestamp: new Date().toISOString(),
});
}
return original(body);
};
next();
}

Wiring it all together on a real route looks like this:

js
router.patch(
'/feedback/:id/status',
requireAgentScope('feedback:update-status'),
agentWriteLimiter,
auditAgentWrite,
updateFeedbackStatus,
);

The log entries go to a plain table (agent_audit_log) rather than a generic app log stream, because I wanted to query it directly: "show me every write agent:support-triage made in the last 24 hours" is a query I actually run now, especially after a prompt or model change.

⚖️ Trade-offs I'm Consciously Accepting

This isn't zero-cost. Static scope tables mean I have to redeploy to change what an agent can do — I'm fine with that friction on purpose, because "redeploy to expand agent permissions" is a feature, not a bug, at this stage. A more dynamic, database-backed scope system would remove the friction and also remove the forcing function that makes me think twice.

I also don't do anything fancy with the audit data yet — no anomaly detection, no auto-revocation. It's a log I read. That's deliberately unglamorous; I'd rather have a boring, reliable trail than a clever system I don't fully understand when it fires.

🙋 Over to You

If you're letting an agent call real write endpoints today, what's actually stopping it from doing something scoped, rate-limited access wouldn't have caught anyway? I'm curious whether people are seeing failure modes that permission systems can't touch — like an agent staying within scope but still making bad judgment calls.

Happy to share the full minimalist-feedback-api gatekeeper module if there's interest — it's small enough to drop into most Express projects in an afternoon.

Is Node.js Losing Its Crown? The Rise of Bun, Deno, and Native Runtimes

Renato Silva — Mon, 10 Aug 2026 09:26:08 +0000

For more than a decade, if you wanted to build a JavaScript or TypeScript backend, there was only one real answer: Node.js.

It revolutionized web development, gave birth to the massive npm ecosystem, and powered millions of applications worldwide. But nothing in tech stays static forever.

In recent times, we’ve seen a massive shift. Developers are no longer taking Node.js for granted. Tools like Bun and Deno are no longer experimental projects—they are mature, production-ready runtimes that are directly challenging the king.

Why is this happening, and should you consider switching your next project away from Node.js?

1. The Speed Dilemma (Zig & Rust vs. C++)

Node.js is built on top of Google's V8 engine and C++. It’s fast, but it carries over 15 years of legacy architecture.

Deno was created by Ryan Dahl (the original creator of Node.js!) using Rust to fix the security and architectural design flaws he regretted in Node.
Bun was built from scratch using Zig and the JavaScriptCore engine (from Safari), specifically optimized for raw speed, lower memory footprint, and instantaneous cold starts.

When you run benchmarks on HTTP server throughput, package installation speeds, or file I/O operations, Bun often leaves Node.js in the dust. Running bun install feels like a magic trick compared to npm install.

2. All-in-One Tooling vs. "Tooling Fatigue"

To build a modern TypeScript backend in Node.js, you usually need a constellation of extra tools:

tsc or esbuild for TypeScript compilation.
tsx or ts-node for running scripts during development.
dotenv for environment variables.
Jest or Vitest for running tests.

Bun and Deno completely eliminate this friction.

Both runtimes feature native TypeScript support out of the box—no transpilation step required. They include built-in test runners, environment variable support, and even native bundlers. You clone a project, run one command, and everything just works.

3. The Counter-Attack: Node.js Isn't Standing Still

If you think the Node.js core team is sitting idly by, think again. The competition from Bun and Deno has been the best thing to happen to Node.js in years!

Node.js has been aggressively shipping modern features to stay competitive:

Native .env file parsing support.
Built-in test runner (node --test).
Experimental support for running TypeScript files directly.
Significant performance improvements in HTTP and file system operations.

Node’s biggest superpower remains its unmatched ecosystem and stability. Enterprise companies with millions of lines of code aren't going to migrate away from Node.js overnight just for a few milliseconds of performance gain.

The Verdict: Which One Should You Use?

Use Node.js if you are building enterprise applications where long-term stability, massive community support, and ecosystem compatibility are non-negotiable.
Use Bun if you are building high-performance microservices, CLI tools, or want an insanely fast development cycle with zero-config TypeScript.
Use Deno if security, strict web-standard APIs, and modern runtime architecture are your top priorities.

The "monopoly" of Node.js is over, and that’s a win for all developers. Competition breeds innovation.

What about you?

Have you tried Bun or Deno in production, or are you sticking with Node.js for your daily work? What’s keeping you from making the switch?

Drop your thoughts and benchmarks in the comments below! ⚡👇

How to Survive a Live Coding Interview Without Having a Panic Attack

Renato Silva — Sun, 28 Jun 2026 15:16:40 +0000

It’s the moment every developer dreads.

You passed the initial screening, you know your tech stack inside out, and now you’re sitting on a Zoom call. The interviewer drops a link to a shared editor and says: "Alright, here is the problem. Please share your screen and code the solution while explaining your thought process."

Suddenly, your hands start sweating. Your mind goes completely blank. You forget how a basic for loop works, and you start questioning if you even know how to program at all.

If you have ever experienced this, let me tell you a secret: You are not a bad developer. Live coding is just a fundamentally unnatural way to write software.

Here is a survival guide on how to manage the anxiety, prepare effectively, and turn the interview into a conversation rather than an interrogation.

1. Shift Your Mindset: It’s Not About the Solution

The biggest mistake candidates make is thinking that if they don’t finish the code or if it has a small bug, they failed.

In 90% of professional tech interviews, the interviewer cares much more about how you think than whether you get a 100% perfect syntax on the first try. They want to see:

How do you react when you get stuck? (Do you panic, or do you ask questions?)
Can you break a big problem into smaller pieces?
Are you pleasant to work with?

Remember: They are looking for a future colleague, not a compiler.

2. The "Think Out Loud" Framework (Your Superpower)

Silence is your worst enemy during a live coding session. If you are silent, the interviewer has no idea if you are thinking of a brilliant solution or completely lost.

Force yourself to speak. Explain your chaotic thoughts:

"Okay, I’m thinking we need to filter this array first, but since the data structure is nested, I might need to normalize it. Let me try a simple approach first, and we can optimize it later."

If you say this out loud, two amazing things happen:

It slows your heart rate down because you are pacing yourself.
If you are going down a completely wrong path, a good interviewer will usually drop a hint to guide you back ("That makes sense, but what if the array is empty?").

3. The Practical Checklist to Stay Calm

Ask Clarifying Questions First: Never start typing immediately. Spend the first 3 minutes asking about edge cases. "Can the input be null?", "Should this handle negative numbers?" This gives your brain time to calm down and process the problem.
Write Pseudo-code: Before writing syntax, write comments.
```
// 1. Get the category ID from the input
// 2. Check if the category exists in the database
// 3. Return error or proceed
```
This gives you a roadmap. If you freeze mid-way, you just need to look at your next comment.
Admit What You Don't Know: If you forget a specific JavaScript method name, don't fake it. Say: "I can't recall the exact native method name for this right now, so I'm going to create a placeholder function/variable called formatData and come back to it." Interviewers respect this level of honesty.

4. How to Actually Prepare (Without Burning Out)

Don't just grind 500 LeetCode problems. That will only increase your anxiety. Instead:

Practice talking while coding: Open an old project or a simple challenge, record yourself on Zoom, and force yourself to explain your code out loud to an empty room. It feels silly, but it builds the muscle memory.
Mock Interviews: Ask a developer friend to give you a random problem and watch you solve it for 30 minutes.

Live coding is a performance. And just like any performance, the more you practice the act of performing, the less terrifying it becomes.

Over to you...

What is your relationship with live coding interviews? Do you think they are a valid way to test a developer's skills, or should the industry ban them forever?

Share your worst (or best) interview stories in the comments! 👇

Your node_modules is Heavier Than a Black Hole (And How to Fix It)

Renato Silva — Tue, 16 Jun 2026 18:16:30 +0000

We’ve all seen the meme: a black hole, a highway collapsing, or the universe warping under the unimaginable weight of a single folder named node_modules.

It used to be a joke. Today, it’s a production hazard.

If you create a fresh project using some modern meta-frameworks or tools, before you even write your first console.log(), you already have tens of thousands of files sitting in your directory. We have reached a point where we need thousands of external packages just to render text on a screen or route a basic HTTP request.

How did the JavaScript ecosystem become so heavily dependent on others, and why is this breaking modern software engineering?

The "Left-Pad" Trauma and the Security Nightmare

A few years ago, the internet famously broke because a developer unpublished a tiny 11-line package called left-pad. Today, the problem is much worse, but it’s silent. It hides under the name of Supply Chain Attacks.

When you install a major framework, you aren't just trusting that framework. You are trusting the hundreds of anonymous open-source developers who wrote the micro-dependencies that the framework relies on.

Every time you run npm install, you are playing roulette with:

Malicious packages disguised as typos.
Deprecated code running in your production environment.
The infamous Found 87 vulnerabilities (12 critical) message that nobody actually knows how to completely clear.

The Art of "No-Dependency" Coding

A silent revolution is happening. Senior developers are actively looking at their package.json and asking: "Can I write this myself in 10 lines of code instead of installing a 5MB package?"

Modern runtimes like Node.js (with its native test runners and .env support), Bun, and Deno are trying to cure this sickness by built-in tools that eliminate the need for basic third-party utilities.

Look at our backend stacks:

Do you really need a massive utility library just to capitalize a string or filter an array? No, native JavaScript array methods are incredibly fast now.
Do you need a dependency to format a date? Often, the native Intl.DateTimeFormat API does exactly what you want.

Keeping your code close to the metal (or native to the runtime) makes your application faster, secure, and infinitely easier to upgrade.

Finding the Sweet Spot

Don't get me wrong. I am not saying you should build your own ORM instead of using Prisma, or rewrite Fastify from scratch. Frameworks and complex tools solve massive, hard problems, and they deserve to be in your project.

The problem is the micro-dependency addiction. Installing an entire package just to check if a number is even (yes, is-even is a real package with millions of downloads) isn't smart engineering—it's laziness.

The next time you are tempted to run npm install <package>, take 2 minutes to think: Can I write a simple, typed function to handle this? Your deployment speed, your security team, and your laptop's hard drive will thank you.

Time to confess...

What is the most ridiculous, tiny package you have ever found buried deep inside your node_modules? Are we too lazy to write plain JavaScript/TypeScript nowadays?

Let’s discuss (and share our dependency horror stories) below! 📦👇

How I Stopped Losing Track of Clients, Invoices, and Money as a Freelancer (And the System I Built to Fix It)

Renato Silva — Wed, 10 Jun 2026 16:29:42 +0000

If you've been freelancing for more than a few months, you know the feeling: a client emails asking about an invoice you're not sure you sent. A project deadline sneaks up because it was buried in a note somewhere. You check your bank account and can't tell if that deposit was from the March project or the April one.

It's not that you're disorganized. It's that freelancing forces you to be a designer AND an accountant AND a project manager AND a sales team — all at once, with no system holding it together.

I spent way too long managing my freelance work across scattered tools: spreadsheets for invoices, a to-do app for tasks, email threads for client info, a notes app for project details. Everything lived somewhere different, and nothing talked to anything else.

So I built a system in Notion that connects everything into one workspace. Here's the framework behind it — whether you use my template or build your own.

The 5 things every freelancer needs to track

After trying dozens of setups, I landed on five core areas. Not more, not less. Every piece of freelance admin falls into one of these:

1. Clients

Not just names and emails — you need to see a client's full picture at a glance. Are they a lead, active, or past? What's their rate? What projects have you done for them? What invoices are outstanding?

Most freelancers track this in their head until they have 5+ clients. Then things start slipping.

The fix: A single client database where every client links to their projects and invoices. You click on "Acme Co" and see everything — every project, every invoice, every payment — without searching.

2. Projects

Every piece of work needs a status (not started, in progress, completed, on hold), a deadline, a fee, and a connection to the client who's paying for it.

The key insight: projects aren't tasks. "Website Redesign" is a project. "Design the homepage" is a task inside that project. Mixing these up is why most freelancer to-do lists become unusable.

The fix: A project pipeline with both a table view (for detail) and a kanban board (for a visual overview of what's where). Each project links to its client.

3. Tasks

The daily work. Each task belongs to a project, has a priority, a due date, and a status. You need two views: a flat list for "what do I need to do today?" and a board for dragging things between To Do, In Progress, and Done.

The fix: A task database linked to projects, with a kanban board view. Filter by "not done" and you have your daily action list.

4. Invoices

This is where most freelancers lose money — literally. You finish a project, forget to invoice for two weeks, then can't remember the exact amount or what it was for.

Every invoice should link to both the client AND the project, have a clear status (draft, sent, paid, overdue), and show the amount and dates.

The fix: An invoice tracker that connects to both clients and projects. You can see all unpaid invoices in one view, and every invoice traces back to the work it covers.

5. Finances

Income and expenses in one place. The critical feature most freelancers miss: linking income entries to their invoices. When a payment lands, you mark which invoice it covers. Now you can trace the full path: Client → Project → Invoice → Payment.

Expenses get tracked separately with categories (software, marketing, education, office). Come tax time, you have everything in one place instead of scrolling through bank statements.

The fix: A finance database with income linked to invoices, and expenses categorized. You can see your net position at any time without opening a spreadsheet.

Why connected databases matter

The magic isn't in any single database — it's in the links between them. When you click on a client, you see their projects. Click a project, you see its tasks and invoices. Click an invoice, you see the payment.

This means:

You never lose track of what you owe or what you're owed
Every task traces back to a project and a paying client
Your finances connect to real work, not just anonymous numbers
Status changes in one place make sense everywhere else

If you've tried building something like this in spreadsheets, you know it falls apart fast. Spreadsheets don't link. Notion does.

The system I built

I put this exact framework into a Notion template called Freelance OS. It has all five databases pre-built and connected, filled with sample data so you can see how it works before swapping in your own info.

It includes:

Client manager with status tracking
Project pipeline (table + kanban)
Task manager with priority levels and board view
Invoice tracker linked to clients and projects
Finance tracker with income linked to invoices
Setup guide to get running in 5 minutes

It works on Notion's free plan and takes about 5 minutes to set up.

If you want to skip building this yourself: Get Freelance OS here

Or build your own

If you prefer to build it yourself, here's the order that works best:

Clients first — this is the foundation everything links to
Projects second — add a relation column pointing to Clients
Tasks third — add a relation column pointing to Projects
Invoices fourth — add relations to both Clients AND Projects
Finances last — add a relation to Invoices for income entries

Build in this order because each database links to the one before it. If you try to build finances first, you'll have nothing to connect it to.

The most important Notion feature to learn: relations and rollups. Relations link databases. Rollups pull data from linked entries (like summing all invoice amounts for a client). These two features turn five separate tables into one connected system.

The takeaway

Freelancing doesn't have to mean chaos. The moment you connect your clients to your projects to your invoices to your money, everything gets simpler. You spend less time on admin and more time on the work that actually pays.

Whether you build this yourself or grab the template, the framework is the same: five databases, all connected, one home for everything.

If you found this useful, I'm building more tools for freelancers. Follow me here or check out Freelance OS on Gumroad.

The Cloud is a Scam (For 90% of Your Projects)

Renato Silva — Mon, 08 Jun 2026 20:10:15 +0000

For the past seven years, we’ve been brainwashed into believing that if your app isn’t deployed across multiple AWS availability zones, using serverless functions, and managed via an intricate mesh of cloud-native tools, you aren’t doing "real" modern development.

We were promised infinite scalability, zero maintenance, and pay-as-you-go pricing.

But nobody told us about the hidden costs:

The $500 surprise bill because an infinite loop triggered a serverless function overnight.
The nightmare of debugging "cold starts" that make your API feel sluggish.
The reality that 95% of applications will never need to scale dynamically to millions of users in seconds.

The tech industry is finally waking up from the cloud hangover, and the "De-clouding" movement is officially here.

The Rise of the $5 VPS and the "Local-First" Database

Companies like Basecamp famously saved $1.5 million a year by leaving the cloud and buying their own hardware. But you don't need to buy a physical server rack to benefit from this mindset shift.

Lately, there’s a massive resurgence in keeping things incredibly lean:

The Revenge of SQLite: For years, SQLite was treated as a "toy" database. Today, with tools like Prisma and modern storage, devs are realizing that a local, single-file SQLite database running on a tiny virtual private server (VPS) can handle hundreds of concurrent requests per second with zero network latency. No AWS RDS required.
Predictable Pricing: Deploying a standard Node.js/Fastify monolith on a flat-rate provider (like Hetzner, DigitalOcean, or a simple Render instance) means you know exactly how much you will pay at the end of the month. No complex math, no bandwidth tax.

Why We Fell for the Hype

We mistook architectural complexity for engineering maturity.

We started designing infrastructure for the scale of Netflix while having the traffic of a local bakery. Serverless and micro-cloud architectures are fantastic tools for highly unpredictable, massive workloads. But for a standard SaaS, a portfolio, or a business API? It's just an expensive layer of friction.

Bringing Sanity Back to the Backend

Going back to basics isn't "regression"; it's pragmatism.

When you build an API with a straightforward framework, protect it with a local memory rate-limiter, and write to a local or predictable database, you remove 90% of the moving parts that could break. You spend less time configuring YAML files and more time actually writing features.

Let's talk numbers...

Are you still fully bought into the serverless/cloud-native dream, or have you started moving your side projects (and company apps) back to simpler, predictable hosting? What’s the craziest cloud bill you’ve ever seen?

Let’s debate in the comments below! 💸👇

Stop Building Space Shuttles When All You Need Is a Bicycle

Renato Silva — Fri, 22 May 2026 19:18:14 +0000

We’ve all been there. You join a new project, excited to look at the codebase. It's a simple application—maybe a Todo app, a simple blog, or a feedback collector.

You open the repository, expecting a clean, straightforward structure. Instead, you find:

12 different microservices.
A Kubernetes configuration that looks like a NASA launch manual.
5 layers of abstractions (Interfaces, Repositories, DTOs, Presenters, Adapters) just to fetch a single row from a database.
Docker containers eating 90% of your laptop's RAM just to run npm run dev.

All of this... for an application that gets 50 users a day.

Welcome to the era of Overengineering.

How Did We Get Here?

As developers, we suffer from what I call "Resume-Driven Development" (RDD). We don't choose tools based on what the project needs today; we choose tools based on what looks cool on our LinkedIn profile or what Netflix uses to handle billions of requests.

We became so obsessed with scalability that we forgot about maintainability and velocity.

If it takes a junior developer three days just to set up the local environment and understand how a single HTTP request routes through twenty layers of architecture, your system isn't "advanced." It's broken.

The Power of the "Boring" Monolith

There is a silent counter-movement happening right now. Senior developers who have tasted the pain of managing distributed transactions and network latency in tiny microservices are screaming: Go back to the monolith!

Building a "boring", well-structured monolithic application using simple tools (like a clean Fastify/Node.js setup, standard relational databases, and straightforward code) gives you something a distributed system can't:

Unmatched Speed: You can ship features in hours, not weeks.
Mental Clarity: You can open one folder and understand the entire data flow.
Cheap Hosting: A single tiny instance on Render, Fly.io, or DigitalOcean can easily handle thousands of concurrent users if your code is efficient.

Pragmatism > Hype

Don't get me wrong. If you are building the next Uber, Netflix, or Amazon, yes—bring on the microservices, Kafka, and complex caching layers. You earned that complexity.

But if you are starting an MVP, testing a product, or building a standard internal tool, keep it stupidly simple (KISS). Use a reliable SQLite or Postgres database, write clean functions, validate your data with Zod, protect your endpoints with a simple Rate Limiter, and get things done.

Architecture shouldn't be a monument to your ego. It should be a tool to deliver value to the user.

Let's Be Honest...

What is the worst case of overengineering you have ever witnessed (or accidentally built) in your career? Are we, as a community, making coding harder than it needs to be?

Drop your horror stories in the comments below! 🛰️👇

Is 'Vibe Coding' Making Us Better Developers, or Just Lazier Managers?

Renato Silva — Sat, 16 May 2026 07:34:13 +0000

If you’ve been on tech Twitter, LinkedIn, or scrolling through Dev.to lately, you’ve probably heard the latest buzzword taking over the industry: Vibe Coding.

Coined to describe the workflow where a developer sits back, thinks about a feature, prompts an AI tool (like Cursor, GitHub Copilot, or Claude), and lets the machine do 90% of the heavy lifting, it’s being praised as the ultimate productivity hack. You don't write the code; you just guide the vibe.

It sounds amazing. But as someone who loves building and diving deep into backend architecture, it makes me wonder: Are we actually becoming super-developers, or are we just becoming lazy code-reviewers who don’t understand our own systems?

The Dream: From Idea to Production in Minutes

Let’s be honest: the "vibe" is real.

Being able to prompt an AI agent to set up a boilerplate boilerplate, write basic CRUD operations, or configure a tricky library saves hours of stack-overflowing. For solo founders, hackers, and junior devs looking to ship MVPs quickly, Vibe Coding feels like having a senior engineer sitting right next to you.

You focus on the product, the business logic, and the user experience. The AI handles the syntax.

The Nightmare: "Zombie Architectures"

But here is where the vibe gets ruined. What happens when the AI writes 1,000 lines of complex, asynchronous Node.js code, it works on your machine, but three weeks later it breaks in production under heavy load?

If you didn't write the code line by line, how long will it take you to debug it?

When we rely too much on AI to generate architecture, we run into three massive risks:

The Black Box Effect: You know what the application does, but you don't know how it does it.
Technical Debt on Steroids: AI writes clean-looking code, but it doesn't always know about your specific edge cases, security validation (like strict Zod schemas), or rate-limiting needs.
The Death of Junior Problem-Solving: If a junior developer spends their formative years just reviewing AI code, do they ever actually learn how to solve hard logical problems from scratch?

Balancing the Vibe with Engineering Discipline

I don't think Vibe Coding is bad. In fact, it's inevitable. The tools are too good to ignore. But we need to change how we define "coding."

The future developer isn't just someone who types syntax; they are a System Architect and a Quality Inspector.

To survive the era of Vibe Coding without deploying broken systems, we must follow three golden rules:

Never accept code you don't understand: If an AI generates a complex Regex or database query, make it explain it to you before you commit.
Enforce strict validation and security: AI loves to skip error handling. Make sure your inputs are validated (e.g., using Zod) and your endpoints are safe (e.g., using Rate Limiters).
Write integration tests: Let the AI write the code, but you should control the tests to ensure the machine actually delivered what you asked for.

What is your take?

Are you currently "vibe coding" your way through your daily job, or are you resisting the urge to keep your engineering skills sharp? Do you think this will ruin the next generation of software engineers, or elevate them?

Let’s argue in the comments below! 👇

Giving Your API a Voice: Sending Emails with Node.js and Nodemailer

Renato Silva — Mon, 04 May 2026 16:29:03 +0000

A great backend application doesn't just store data in a database; it communicates with the outside world. Whether it's a welcome email, a password reset, or a notification for a new feedback, knowing how to integrate an email service is a crucial skill for any developer.

In this article, I’ll show you how I integrated email notifications into my Feedback API using Nodemailer and the Provider Pattern.

The Goal

When a user submits feedback, the system should:

Validate the data.
Save it to the database.
Notify the administrator via email.

Architecture Matters: The Provider Pattern

Instead of hardcoding Nodemailer directly into my business logic, I used the Provider Pattern. This keeps the code decoupled. If I decide to switch from Nodemailer to AWS SES or SendGrid in the future, I only need to change one file.

1. Defining the Contract (Abstract Class)

First, we define what a MailProvider should do:

// src/providers/mail-provider/mail-provider.js
class MailProvider {
  async sendMail({ to, subject, body }) {
    throw new Error("Method 'sendMail' must be implemented.");
  }
}

module.exports = MailProvider;

2. Implementing with Nodemailer

Now, we create the actual implementation. We use environment variables to keep credentials safe.

// src/providers/mail-provider/nodemailer-provider.js
const nodemailer = require("nodemailer");
const { env } = require("../../env");

class NodemailerProvider {
  #transporter;

  constructor() {
    this.#transporter = nodemailer.createTransport({
      host: env.MAIL_HOST,
      port: env.MAIL_PORT,
      auth: {
        user: env.MAIL_USER,
        pass: env.MAIL_PASS,
      },
    });
  }

  async sendMail({ to, subject, body }) {
    await this.#transporter.sendMail({
      from: "Feedback Tool <no-reply@feedback.com>",
      to,
      subject,
      html: body,
    });
  }
}

module.exports = NodemailerProvider;

Integrating into the Use Case

Our Use Case (the business logic) doesn't care how the email is sent; it only knows that it has a mailProvider capable of sending one.

// src/use-cases/submit-feedback.js
async execute(request) {
  const parsedData = submitFeedbackSchema.parse(request);
  const { name, email, message } = parsedData;

  // Persisting data
  const feedback = await this.feedbackRepository.create({ name, email, message });

  // Sending notification
  const mailProvider = new NodemailerProvider();

  try {
    await mailProvider.sendMail({
      to: "Admin <admin@example.com>",
      subject: "New Feedback Received!",
      body: `<h1>New Feedback</h1><p>From: ${name}</p><p>${message}</p>`
    });
    console.log("✅ Email sent!");
  } catch (error) {
    console.error("❌ Email failed, but feedback was saved:", error);
  }

  return feedback;
}

Key Takeaways

1. Don't Let Email Failures Break Your App

I wrapped the sendMail call in a try/catch block. If the email service is down, the user's feedback is still saved in the database. The user shouldn't see an error 500 just because a notification failed.

2. Environment Validation

Always use a tool like Zod to validate your SMTP credentials (MAIL_HOST, MAIL_USER, etc.). If your credentials are missing, your app should fail early during startup, not when a user tries to send feedback.

3. Testing with Mailtrap

During development, I used Mailtrap. It acts as a "fake" SMTP server that catches your emails in a virtual inbox, so you don't accidentally spam real addresses while testing.

Conclusion

Adding an email service makes your application feel professional and alive. By using providers and dependency injection, you ensure your code remains maintainable and ready for scale.

How do you handle background tasks like emails in your projects? Let's talk in the comments!