DEV Community: Nahid

Mail Spam – Im stuck need help

Nahid — Thu, 01 Oct 2026 16:33:54 +0000

Is a custom domain safer than Gmail for cold outreach?
I’ve built an automation where I use my own Gmail account as the sender. However, after sending a few emails, my messages started going to the recipients’ spam folders, even when the email content was legitimate and well-written.

Could you please advise me on whether using a custom domain would be better for cold outreach, and what I should do to improve email deliverability?

Is Custom Domain Is more safer then Gmail ? for cold outreach . i'm besicly made an automation . sender is my own gmail but after sending some gmail now it's take me into spam in anyone inbox . evan if i right hlw (hlw == spam) Need advice please help me

Nahid — Thu, 01 Oct 2026 16:22:02 +0000

API Performance Profiler: Live route latency directly inside VS Code ⚡

Nahid — Sun, 27 Sep 2026 10:25:53 +0000

Hey everyone! 👋 I'm Nahid, the creator of API Performance Profiler.
As backend developers, we often fly blind when building APIs locally. You write a route, but you don't really know how fast it runs until you leave your editor, set up Postman, or configure a heavy APM tool.
I wanted performance testing to feel native and frictionless, so I built an open-source, zero-dependency local profiling extension for Node.js (Express & NestJS).
Here is what it brings directly to your editor:
🟢 Inline Latency Metrics: See real-time execution speeds (e.g., 🟢 84ms) rendered right beside your route definitions in the code.
🚀 1-Click Load Testing: A '▶ Load test' CodeLens sits directly above your route. Click it to replay the last recorded request 1000 times under heavy load.
📊 Routes Dashboard: A dedicated VS Code sidebar showing all observed routes in your app, sorted from slowest to fastest.
🔐 100% Local & Secure: Everything is stored in local memory. No cloud accounts, no external dashboards.
It takes less than a minute to set up. I’d love for you to try it out!
🔗 VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=nahid625.api-profiler-vscode
🐙 GitHub Repo: https://github.com/Nahid625/api-performance-profiler

AI-model releases are moving Fast

Nahid — Tue, 22 Sep 2026 12:11:47 +0000

🚨 7 AI models launched in just ONE week.

• Grok 4.7
• Xiaomi MiMo-V2.6-Pro
• Xiaomi MiMo-V2.6-Flash
• Step 5 Preview
• Jev
• Qwen3.8-Omni-Flash
• Union Alpha (stealth)

AI model releases are moving FAST.

Good News For Backend And Devops Buddy

Nahid — Sun, 20 Sep 2026 15:50:22 +0000

I shipped a Goated tool Today: API Performance Profiler.

It answers one question backend devs ask every day: how fast is this route, actually?

Most of us guess. Or we add console.time, or we open Postman and eyeball the number. Then we ship, and production tells us the truth.

So I built something that measures instead:

npm install @api-profiler/express

app.use(profiler());
That's the whole setup. Send a few requests, then open a second terminal:

npx api-profiler
and you get a live table: every route, average latency, max, error rate, req/s, 🟢🟡🔴.

The part I'm actually excited about: the middleware sees the real request — the working auth token, the path param that exists in your DB, the body the route accepts. It records it (in memory, masked, never written anywhere) and can replay it under load:

npx api-profiler run GET /users/:id
Hit the route once, it replays it a few thousand times, and reports the route's own server-side numbers for the run. No k6 script, no fake fixtures, no copying tokens around.

Rules I refused to bend while building it:

A number that wasn't measured is never shown. Not enough samples → --.
Latency and throughput are never mixed up.
Load tests are off in production, localhost only, GET only unless you opt a route in. Replaying a POST writes real data.
Nothing leaves your machine. No account, no telemetry, no server.
Works with Express 4/5 and NestJS on the Express adapter. A VS Code extension that shows 🟢 84ms right next to the route line is packaged and coming to the marketplace this week.

Open source, AGPL: https://github.com/Nahid625/api-performance-profiler
npm: https://www.npmjs.com/package/@api-profiler/express

If you try it on a real project and something is wrong, open an issue. I'd rather hear it now.

These days, a vibe coder can build almost anything a senior engineer can—with the help of Claude and OpenAI tools. Agree or not?

Nahid — Tue, 15 Sep 2026 06:41:14 +0000

I'm building a VS Code extension that shows API latency right next to your code — no dashboard, no cloud

Nahid — Sun, 13 Sep 2026 15:36:50 +0000

## The problem

A route feels slow. What do you do? Usually console.log(Date.now()) around
the code, or open a separate dashboard, or hit the route a few times in
Postman and try to eyeball the difference. It works but it's slow and
disconnected from the actual code.

## What I'm building

API Performance Profiler. An open-source tool that shows real API latency
inline in VS Code, right next to the route.

@get('/users') 🟢 84ms
@get('/products') 🟡 430ms
@get('/orders') 🔴 1.82s

No dashboard. No cloud account. No API key. It runs on your machine and
watches real traffic as it comes in.

## Why local first

I don't want a tool that needs a signup and a config file just to tell me
one route is slow. So it works offline:

Your backend runs locally like normal
A small middleware measures real request timings
VS Code reads that data and shows it next to your code

Nothing leaves your machine.

What it supports first

Node.js and TypeScript. Express and NestJS to start.

Only real metrics. Average latency, P50/P95/P99, throughput, error rate.
If there isn't enough traffic yet it just says so instead of showing a
fake number.

## What's next

Database query timing. External HTTP call breakdowns. A CLI for people who
don't use VS Code. Later, something for teams to see this data together.

## Follow along

Building this in public and posting updates here as it comes together.
Repo isn't public yet but will be soon, and I'd love contributors once it
is (issues, ideas, PRs).

If this is something you'd use, follow along. And let me know in the
comments if there's a framework you'd want supported first.