DEV Community: Mehdi Hassan Jony

Navigating Xianyu: A Developer’s Guide to Buying Used Hardware in China without Getting Scammed

Mehdi Hassan Jony — Mon, 26 Oct 2026 06:03:01 +0000

If you live in China or shop through consolidation proxies, Xianyu (咸鱼 - "Idle Fish")—Taobao’s C2C second-hand marketplace—is a goldmine for tech bargains. From dirt-cheap RTX 3060 12GB cards to budget desktop platforms, the deals can look irresistible.

However, Xianyu is also a wild frontier of e-waste recycling, modified vBIOS cards, and predatory commercial resellers disguised as personal sellers.

Whether you are building a budget local AI workstation for ComfyUI / LLMs or assembling a 1440p gaming rig, here is how to navigate China’s second-hand PC ecosystem, spot common fraud scripts, and extract real value.

Part 1: Anatomy of a Xianyu Scam

Commercial second-hand dealers (“工作室” or “二手贩子”) flood Xianyu with copy-pasted listings designed to deceive non-technical buyers. Understanding their tactics is essential to avoiding them.

Scam Trap #1: The "12-Core Flagship" E-Waste Machine

The Copy: "Intel 12-Core 24-Thread, turbo locked to 3.5GHz, crushes 10th-gen i5s."
The Reality: This is almost always a decade-old server CPU (such as an Intel Xeon E5-2678 v3 / E5-2673 v3) paired with a cheap, recycled Chinese motherboard (Huananzhi/Jingyue X99) and slow DDR3 server RAM.
Why it fails: While 24 threads sound impressive for multi-tasking, the single-core IPC (instructions per cycle) is abysmal. Modern AI frameworks (like PyTorch and ComfyUI) and modern game engines rely heavily on single-core throughput for tokenization and model loading.

+-----------------------------------------------------------------------+
| SCAM LISTING CHECKLIST (AVOID AT ALL COSTS)                           |
+-----------------------------------------------------------------------+
| [x] "英特尔12核24线程" (Intel 12-core 24-thread)                     |
| [x] "性能碾压i7" (Performance crushes i7)                             |
| [x] "华硕雪豹 8G" or "对标3060Ti" (Claiming ancient cards match 3060Ti) |
| [x] "工作室挂机 / 准备直播带货亏本转让" (Bought for livestreaming loss)  |
| [x] "跑分190万" (Manipulated LuDaShi benchmark scores)                 |
+-----------------------------------------------------------------------+

Scam Trap #2: The "Asus Snow Leopard / RX 580 8GB" GPU Illusion

The Copy: "ASUS Snow Leopard 8GB! Outperforms RX 580, matches RTX 3060 Ti!"
The Reality: In China's second-hand market, "Snow Leopard 8G" (雪豹 8G) usually refers to heavily mined RX 470/480/570 cards re-flashed with modified vBIOS files.
Why it fails for AI: Older AMD Polaris architecture (GCN 4) has no native ROCm support on modern software and lacks CUDA completely. Trying to run AI video generation tools (like AnimateDiff, LTX-Video, or Wan) on an RX 580 results in direct fallback crashes or hours-long render times.

Scam Trap #3: "Bait-and-Switch" Barebones Pricing

The Copy: "i5 14400F + B760 motherboard, ocean view case — Only 1,199 RMB!"
The Reality: Physical computer shops (实体店) list incomplete systems or Engineering Sample (ES/QS) CPUs at impossibly low prices to generate leads. Once you message them, they reveal the price excludes RAM, SSD, and GPU, or requires buying overpriced bundled parts.

Part 2: Buying for AI vs. Gaming on Xianyu

Hardware requirements differ significantly depending on your primary target workload:

                  +-----------------------------------+
                  |      YOUR MAIN WORKLOAD           |
                  +-----------------+-----------------+
                                    |
            +-----------------------+-----------------------+
            |                                               |
            v                                               v
  [ LOCAL AI WORKLOADS ]                          [ GAMING WORKLOADS ]
  (ComfyUI, LLMs, Diffusion)                     (1080p / 1440p Raster)
  * Priority: CUDA & VRAM Capacity                * Priority: Raster & Bandwidth
  * Minimum: 6GB VRAM (8GB+ ideal)                * Flexible: NVIDIA or AMD
  * Architecture: RTX 20/30/40 Series             * Architecture: GTX 1660S, RX 6600
  * Hardware Requirement: NVIDIA CUDA             * Platform: Intel / AMD Consumer

1. Requirements for AI (LLMs, ComfyUI, Image & Video Generation)

NVIDIA is mandatory: AMD cards can technically run PyTorch via ROCm on Linux, but the developer ecosystem, custom nodes, FlashAttention kernels, and xFormers rely natively on NVIDIA CUDA.
VRAM Is King: Model parameters must fit directly into GPU memory.
Absolute Minimum: 6GB VRAM (GTX 1660 Super / RTX 2060 6GB) for basic 512x512 SD1.5 generation.
Sweet Spot Budget: 12GB VRAM (RTX 3060 12GB) or 16GB VRAM (RTX 4060 Ti 16GB / RTX 3090 24GB).
System RAM: Aim for 32GB DDR4/DDR5. When VRAM spills over during large model initialization, low system RAM causes immediate out-of-memory crashes.

2. Requirements for Pure Gaming

AMD is Viable: Cards like the RX 6600 8GB (~800–900 RMB on Xianyu) or RX 6700 XT 12GB offer higher raw rasterization frame rates per RMB than equivalent NVIDIA cards.
CPU Focus: Prioritize higher single-core boost clock CPUs (e.g., Intel Core i3-12100F / i5-10400F or AMD Ryzen 5 5600) over high core-count server chips.

Part 3: Golden Rules & Inspection Strategy

When purchasing hardware on Xianyu, follow this strict checklist to guarantee a smooth transaction:

              +-----------------------------------------------+
              |            XIANYU BUYING PIPELINE             |
              +-----------------------------------------------+
                                      |
            +-------------------------+-------------------------+
            | Step 1: Seller Audit    | Zhima Credit (优秀/极好) |
            |                         | No bulk merchant scripts|
            +-------------------------+-------------------------+
                                      |
            +-------------------------+-------------------------+
            | Step 2: Request Proof   | FurMark + GPU-Z Video   |
            |                         | Match Serial Numbers    |
            +-------------------------+-------------------------+
                                      |
            +-------------------------+-------------------------+
            | Step 3: Unboxing Test   | Continuous video recording|
            |                         | Benchmarks before sign  |
            +-------------------------+-------------------------+

1. Check Zhima Credit & Seller Profile (芝麻信用)

Filter for High Credit: Only transact with sellers marked as "Zhima Credit Excellent" (芝麻信用优秀) or "Outstanding" (芝麻信用极好).
Avoid Bulk Sellers: Click on the seller’s avatar. If they have 20 identical listings for "office liquidation PCs" (工作室退役), pass immediately. Look for individual personal sellers (个人自用).

2. Request Live Stress-Test Videos Before Shipping

Never accept static photos of hardware. Message the seller and ask for a unified video showing:

GPU-Z Validation: Verifying official lookup parameters, memory type, and stock vBIOS version.
FurMark / 3DMark Run: At least 10–15 minutes of continuous load displaying stable core temperatures (<80°C) and hot-spot/VRAM temperatures (<95°C).
Serial Number Verification: Showing the SN on the GPU PCB matching the outer box (if available).

3. Record the Unboxing & Benchmarking

When your courier package arrives (usually via SF Express / 顺丰速运 or JD Express / 京东快递):

Record a continuous, unedited video opening the package, checking for physical PCB damage or missing components.
Install the hardware, run GPU-Z and FurMark on your own rig, and verify stability before clicking "Confirm Receipt" (确认收货) on Xianyu. Once confirmed, escrow funds are released to the seller, making disputes significantly harder.

Summary Reference Table: Realistic Second-Hand Pricing

Use this baseline table to evaluate whether a Xianyu listing is priced fairly or inflated by shop margins:

Target GPU / System Spec	Typical Xianyu Price Range (RMB)	Recommended Workload	AI Viability
GTX 1660 Super 6GB	450 – 580 RMB	Budget 1080p Gaming / Entry AI	Basic SD1.5 / Small Models
RTX 2060 6GB	650 – 750 RMB	1080p Gaming / Budget CUDA	Tensor Accelerated SD / ComfyUI
RTX 3060 12GB	1,300 – 1,550 RMB	Mid-Range AI Workstation	Excellent (12GB VRAM Sweetspot)
Complete System: i3-12100F + GTX 1660S	1,400 – 1,700 RMB	Complete Budget Entry PC	Stable Starter AI Workstation
Complete System: i5-12400F + RTX 3060 12G	2,500 – 2,900 RMB	Complete Mid-Tier PC	High-Performance Local AI Setup

Key Takeaway

Cheap second-hand hardware is one of the best ways to get started with local machine learning and gaming. However, never trade architectural compatibility for raw core counts. Stick to verified consumer platforms (Intel 10th Gen+, AMD Ryzen, and NVIDIA RTX cards), enforce technical verification via video proof, and buy strictly through escrow-protected platforms.

Stop Wasting Days on Dev Setup: How We Automated Our Microservices Environment for Every Developer

Mehdi Hassan Jony — Tue, 22 Sep 2026 08:38:16 +0000

How we reduced new developer onboarding from 3 days to 15 minutes and eliminated configuration drift across 12 microservices.

The Problem That Made Us Snap
Picture this: A new senior developer joins your team. They’re excited, ready to ship code on day one. Then reality hits.
Day 1: They spend 6 hours installing Node, Docker, configuring ESLint to match the team’s style, figuring out which environment variables go where, and asking Slack questions like, “Which version of NestJS are we on again?”
Day 2: They finally get user-service running, but auth-service throws a CORS error because their local config is slightly different from everyone else’s. They spend the afternoon comparing .env files with a teammate.
Day 3: They submit their first PR. The CI pipeline fails because their local Prettier config formats code differently from the shared config that was updated last month — but nobody told them.
Sound familiar?
We had 12 microservices, a team that was growing fast, and a configuration mess that was eating our productivity alive. Every service had slightly different ESLint rules, Docker setups, folder structures, and VS Code settings. Senior developers were spending hours every week answering setup questions instead of building features.
So we built a system that fixed all of it. Here’s exactly how.

The Solution: One Repo to Rule Them All

We created a central configuration repository called dev-environment-config that acts as the single source of truth for every development environment across our entire microservices ecosystem.
The idea is simple:

One repository controls the setup, structure, linting, Docker config, VS Code settings, and shared code for every service. When a senior developer updates it, every developer’s machine automatically syncs the next morning.

The Architecture at a Glance

dev-environment-config (Central Repo)
├── templates/          → Project scaffolding (NestJS, React)
├── shared/             → ESLint, Prettier, Git configs
├── vscode/             → Extensions & settings
├── docker/             → Base Docker configs
├── scripts/            → Automation (setup, sync, update)
├── common-lib/         → Shared NPM package
└── manifest.json       → Version tracking

         │  syncs to
         ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ user-svc │ │ auth-svc │ │ pay-svc  │  ... 12 services
│ .eslint  │ │ .eslint  │ │ .eslint  │
│ .vscode  │ │ .vscode  │ │ .vscode  │
│ Docker   │ │ Docker   │ │ Docker   │
└──────────┘ └──────────┘ └──────────┘

Implementation: Step by Step

Step 1: The Central Config Repository

We created a new repository with this structure:

dev-environment-config/
├── templates/
│   ├── nestjs-service/    # Complete NestJS starter
│   └── reactjs-service/   # Complete React starter
├── shared/
│   ├── .eslintrc.js
│   ├── .prettierrc
│   ├── .editorconfig
│   ├── .gitignore
│   └── commitlint.config.js
├── vscode/
│   ├── extensions.json
│   ├── settings.json
│   └── launch.json
├── scripts/
│   ├── setup-new-developer.sh
│   ├── sync-config.sh
│   ├── auto-update.sh
│   └── create-new-service.sh
├── common-lib/            # Shared NPM package
└── manifest.json          # Version tracker

The manifest.json is the heartbeat of the system:

{
  "version": "1.2.0",
  "lastUpdated": "2024-01-15T10:00:00Z",
  "updatedBy": "senior-dev",
  "configs": {
    "eslint": "3.2.0",
    "prettier": "2.1.0",
    "docker": "1.5.0"
  },
  "services": [
    "user-service",
    "auth-service",
    "payment-service"
  ]
}

Every time a config changes, we bump the version. This is how the auto-update system knows something changed.

Step 2: The One-Command Onboarding Script

This was the game-changer. We wrote a bash script that a new developer runs once, and their entire environment is ready.

The new developer’s experience:

Install VS Code ✅
Run one command:

curl -sSL https://raw.githubusercontent.com/company/dev-environment-config/main/scripts/setup-new-developer.sh | bash

Wait ~10 minutes. Done.

What the script does under the hood:

#!/bin/bash
set -e

WORKSPACE_DIR="$HOME/company-workspace"
CONFIG_REPO="https://github.com/company/dev-environment-config.git"

echo "🚀 Setting up your development environment..."

# 1. Check & install prerequisites
check_and_install "git" "Git"
check_and_install "node" "Node.js" "nvm install 20"
check_and_install "docker" "Docker"

# 2. Create workspace & clone everything
mkdir -p "$WORKSPACE_DIR" && cd "$WORKSPACE_DIR"
git clone "$CONFIG_REPO"

# 3. Clone all service repos from manifest
SERVICES=$(cat dev-environment-config/manifest.json | \
  python3 -c "import sys,json; \
  [print(s) for s in json.load(sys.stdin)['services']]")

for service in $SERVICES; do
  git clone "https://github.com/company/${service}.git"
done

# 4. Install VS Code extensions
EXTENSIONS=$(cat dev-environment-config/vscode/extensions.json | \
  python3 -c "import sys,json; \
  [print(e) for e in json.load(sys.stdin)['recommendations']]")

for ext in $EXTENSIONS; do
  code --install-extension "$ext" --force
done

# 5. Sync shared configs to all services
bash dev-environment-config/scripts/sync-config.sh

# 6. Install dependencies everywhere
for service in $SERVICES; do
  cd "$service" && npm install && cp .env.example .env && cd ..
done

# 7. Set up daily auto-update cron (8 AM weekdays)
CRON="0 8 * * 1-5 cd $WORKSPACE_DIR && \
  bash dev-environment-config/scripts/auto-update.sh"
(crontab -l 2>/dev/null; echo "$CRON") | crontab -

echo "✅ Setup complete! Open VS Code: code $WORKSPACE_DIR"

That’s it. The developer opens VS Code, and everything is configured — extensions, linting, formatting, Docker, environment variables, the works.

Step 3: The Config Sync Script

This script copies the shared configs from the central repo into every service:

#!/bin/bash
# sync-config.sh

CONFIG_ROOT="$(dirname "$SCRIPT_DIR")"
WORKSPACE_DIR="$(dirname "$CONFIG_ROOT")"

for service in $SERVICES; do
  SERVICE_DIR="$WORKSPACE_DIR/$service"

  # Copy shared configs
  cp -f "$CONFIG_ROOT/shared/.eslintrc.js" "$SERVICE_DIR/"
  cp -f "$CONFIG_ROOT/shared/.prettierrc" "$SERVICE_DIR/"
  cp -f "$CONFIG_ROOT/shared/.editorconfig" "$SERVICE_DIR/"
  cp -f "$CONFIG_ROOT/shared/.gitignore" "$SERVICE_DIR/"

  # Copy VS Code settings
  mkdir -p "$SERVICE_DIR/.vscode"
  cp -f "$CONFIG_ROOT/vscode/settings.json" "$SERVICE_DIR/.vscode/"
  cp -f "$CONFIG_ROOT/vscode/extensions.json" "$SERVICE_DIR/.vscode/"

  echo "✅ $service synced"
done

Step 4: The Daily Auto-Update (The Magic)

This is the part that keeps everything in sync without anyone thinking about it.
Every morning at 8 AM (weekdays), a cron job runs auto-update.sh on every developer’s machine:

#!/bin/bash
# auto-update.sh — Runs daily at 8 AM

cd "$CONFIG_ROOT"

# 1. Check for config updates
OLD_VERSION=$(cat manifest.json | jq -r '.version')
git pull origin main
NEW_VERSION=$(cat manifest.json | jq -r '.version')

if [ "$OLD_VERSION" != "$NEW_VERSION" ]; then
  echo "🆕 Config updated: $OLD_VERSION → $NEW_VERSION"
  bash "$SCRIPT_DIR/sync-config.sh"
fi

# 2. Pull latest code for all services
for service in $SERVICES; do
  cd "$WORKSPACE_DIR/$service"

  # Stash local changes safely
  git stash push -m "auto-update-$(date +%Y%m%d)" 2>/dev/null

  # Pull latest
  git pull origin $(git branch --show-current) --rebase

  # Update dependencies if package.json changed
  if git diff HEAD~1 --name-only | grep -q "package.json"; then
    npm install
  fi

  # Update shared library
  npm update @company/common-lib
done

# 3. Notify the developer
notify-send "Dev Environment" "✅ Updated to config v$NEW_VERSION"

The flow:

Senior Dev pushes config change
         │
         ▼
   GitHub Actions
         │
    ┌────┴────┐
    │ Slack   │ Notify team
    │ Publish │ common-lib to NPM
    └────┬────┘
         │
    Next 8 AM
         │
         ▼
  Every developer's cron runs
         │
    ┌────┴────────────────┐
    │ Pull config repo    │
    │ Sync shared configs │
    │ Pull service repos  │
    │ Update dependencies │
    │ Desktop notification│
    └─────────────────────┘

Step 5: The Shared Common Library

Instead of copying and pasting guards, interceptors, and DTOs across 12 services, we created @company/common-lib — a private NPM package:

// In any service, just import and use:
import {
  AuthGuard,
  RolesGuard,
  ResponseInterceptor,
  LoggingInterceptor,
  HttpExceptionFilter,
  PaginationDto,
  McpService,        // Qwen MCP integration
} from '@company/common-lib';

@Controller('users')
@UseGuards(AuthGuard, RolesGuard)
@UseInterceptors(ResponseInterceptor)
@UseFilters(HttpExceptionFilter)
export class UserController {
  constructor(private mcpService: McpService) {}

  @Get()
  findAll(@Query() pagination: PaginationDto) {
    return this.userService.findAll(pagination);
  }

  @Post('analyze')
  async analyze(@Body() dto: AnalyzeDto) {
    return this.mcpService.callTool('text-analysis', {
      text: dto.text,
    });
  }
}

When we update the common library (add a new guard, fix a bug in the exception filter), the auto-update system bumps the version in every service automatically.

Step 6: Service Scaffolding

Creating a new microservice used to take a day of copy-pasting and tweaking. Now it takes 30 seconds:

bash scripts/create-new-service.sh

# Prompts:
# Service name: order-service
# Description: Handles order processing
# Port: 3002
# Type: nestjs

# ✅ Done! Complete service with:
# - src/common/ (filters, guards, interceptors, DTOs)
# - Docker setup (Dockerfile + docker-compose)
# - VS Code settings
# - ESLint + Prettier
# - Health check endpoint
# - Swagger docs
# - MCP integration
# - Auto-update scripts

The Benefits (With Real Numbers)
1. Onboarding: 3 Days → 15 Minutes

Before: Manual setup following a 40-step Confluence page.
After: One curlcommand.
Before: 3 days to first productive commit.
After: 15 minutes to running all services.
Before: "Hey, can you help me with my env vars?" (daily Slack noise).
After: Zero setup questions.

2. Configuration Drift: Eliminated
Before, every service slowly diverged. user-service had ESLint v8, auth-service had v7. Prettier configs had subtle differences. Docker setups were copy-pasted and never updated. Now, every service has identical configs, and they stay identical because the sync script overwrites them daily.

3. Senior Developer Time: Saved ~5 Hours/Week
Senior devs were spending roughly an hour a day helping juniors with setup issues, reviewing PRs that failed CI due to formatting, and manually updating configs across services. That time is now spent building features.

4. Consistent Code Quality
Every developer has:

The same ESLint rules (auto-fixed on save)
The same Prettier config (format on save)
The same commit message format (enforced by Husky)
The same VS Code extensions (auto-installed)

PR reviews went from "please fix your formatting" to "let’s discuss the architecture."

5. Zero-Effort Config Updates

When a senior developer wants to:

1. Add a new ESLint rule → Push to config repo → Everyone gets it tomorrow
2. Update Docker base image → Push → Auto-synced
3. Add a VS Code extension → Push → Auto-installed
4. Fix a bug in the exception filter → Publish common-lib → Auto-updated No Slack announcements needed. No "please run npm install" messages. It just happens.

6. Standardized Project Structure
Every service looks the same. A developer can jump from user-service to payment-service and immediately know where everything is. The src/common/ folder has the same patterns. The Docker setup is identical. The health check endpoint is at the same path.

What We Learned

Start Small

We didn’t build this all at once. We started with just syncing ESLint and Prettier configs. Once the team saw the value, we added Docker, VS Code settings, the common library, and the auto-update system incrementally.

Don’t Force Everything

We allow service-specific overrides. If payment-service needs a special ESLint rule, they can add a .eslintrc.local.js that extends the shared one. The shared config is the baseline, not a straitjacket.

Notifications Matter
The desktop notification ("✅ Updated to config v1.2.0") was a small touch, but it made developers aware of the system. Before that, updates happened silently and people were confused when things changed.

Version Everything
The manifest.json version tracking was critical. Without it, the auto-update script had no way to know if anything changed, and it would waste time syncing configs that were already up to date.

The Complete Stack

Backend: NestJS (TypeScript)
Frontend: ReactJS (TypeScript)
AI: Qwen MCP
Containers: Docker, Docker Compose
Runtime: Node.js 20 LTS
Database: PostgreSQL 16
Cache: Redis 7
CI/CD: GitHub Actions
Editor: VS Code
Config Sync: Bash scripts + Cron

TL;DR
If your team has more than 3 microservices and more than 5 developers, you need a centralized dev environment config. Here’s the recipe:

Create a config repo with templates, shared configs, and scripts.
Write a setup script that onboards new devs in one command.
Write a sync script that copies shared configs to all services.
Set up a cron job that auto-updates every morning.
Create a shared NPM library for reusable code.
Build a service generator for scaffolding new microservices.

The result: developers spend their time writing code, not configuring environments.

Have you solved this problem differently at your company? I’d love to hear about it in the comments.
If you found this useful, give it a clap 👏 and follow for more microservices architecture deep-dives.

I Couldn't Afford AWS Cognito Experience — So I Built It Myself

Mehdi Hassan Jony — Tue, 28 Apr 2026 06:33:45 +0000

How open-source alternatives can land you the cloud job you're not "qualified" for

The job posting said "AWS Cognito experience required." I had never touched Cognito. I had never paid an AWS bill above the free tier. I almost closed the tab and moved on.

Two weeks later, I got called into the interview anyway. And I was ready.

Here's the uncomfortable truth about tech hiring: companies post aspirational requirement lists. They know the talent pool is wider than their wishlist. They shortlist you anyway. The question isn't whether you'll face that room — it's whether you'll be prepared when you do.

The concepts are what matter. The brand name is just packaging.

I'm going to show you the exact open-source alternatives I used to build enterprise-level knowledge without an enterprise budget. By the end of this, you'll have a map, a 30-day plan, and the exact words to use in your next interview.

What Interviewers Are Actually Asking

When someone asks "Have you used AWS Cognito?", they're really asking:

Do you understand OAuth2, SAML, SSO, MFA, and RBAC?
Can you reason about authentication flows in a distributed system?
Have you actually built something that handles identity?

I've been on both sides of this table. When a candidate says "I haven't used Cognito, but I self-hosted Keycloak, configured OAuth2/OIDC flows, set up LDAP federation, and implemented MFA" — that answer impresses me more than "Yes, I clicked through the Cognito wizard once."

Open source teaches you what managed services hide. You're not just consuming abstractions — you're wrestling with the actual systems.

The Stack: Enterprise Cloud → Open Source Alternative

🔐 Identity & Auth

You need to know	You can build with
AWS Cognito	Keycloak, Authentik, ZITADEL
Auth0, Okta	SuperTokens, Ory

I started with Keycloak. One Docker command. Within an hour I had OAuth2 SSO running against a test app with MFA enabled. The concepts map 1:1 to Cognito.

Fun fact: Cognito isn't natively multi-tenant — you need a dedicated user pool per tenant. Keycloak handles this through realms. Understanding that architectural difference alone puts you ahead of candidates who just clicked "Create User Pool."

🗄️ NoSQL Databases

Enterprise	Open Source
DynamoDB	Apache Cassandra, ScyllaDB Alternator
Firestore	Supabase, PocketBase

Here's the thing about DynamoDB: it's built on the same research paper as Cassandra. The partition key model, the consistency levels, the distributed architecture — it's the same DNA.

ScyllaDB's Alternator goes a step further. It offers an actual DynamoDB-compatible API. I ran my AWS SDK code against it locally. Zero changes. That's legitimate DynamoDB development experience without touching an AWS account.

📨 Message Queues

Enterprise	Open Source
AWS SQS / SNS	RabbitMQ, NATS
AWS Kinesis	Apache Kafka, Redpanda

I configured RabbitMQ with dead-letter queues, topic exchanges, and consumer acknowledgments. When the interviewer asked about SQS, I could talk about every pattern they cared about — because they're the same patterns.

🔥 Backend-as-a-Service

Enterprise	Open Source
Firebase, AWS Amplify	Supabase, Appwrite, PocketBase

Supabase is the open-source Firebase. Postgres database, authentication, real-time subscriptions, file storage, edge functions — all runnable with a single docker compose up. I built a full-stack app on my laptop. When they asked if I understood the BaaS model, I could walk them through every layer.

🪣 Object Storage

Enterprise	Open Source
AWS S3, Azure Blob	MinIO

MinIO is S3-API compatible. Not metaphorically — literally. My SDK calls, presigned URL generation, bucket policies — identical surface. MinIO to S3 is a config change, not a rewrite.

⚡ The Nuclear Option: LocalStack

LocalStack simulates 45+ AWS services on your machine. DynamoDB, S3, SQS, Lambda, API Gateway, Cognito — same SDK calls, same Terraform configs, same everything. Point your endpoint to localhost instead of amazonaws.com.

This was how I built "AWS experience" without an AWS bill.

The Interview Framework That Works

When they ask about a tool you haven't used commercially:

1. Acknowledge.
"I haven't used Cognito in production."

2. Bridge.
"But I've built authentication systems with Keycloak — OAuth2/OIDC, multi-tenant realms, LDAP federation."

3. Go deeper.
"I configured MFA with TOTP and WebAuthn, and set up fine-grained authorization policies. These map directly to Cognito's user pool features."

I've watched interviewers visibly recalibrate their assessment after this kind of answer. You're no longer "the candidate without Cognito." You're "the candidate who understands identity systems at a depth most Cognito users don't."

My 30-Day Zero-Cost Roadmap

Here's exactly what I did. You can start today.

Week 1 — Identity

docker run keycloak
Configure a realm, users, OAuth2 client
Add MFA
Build a simple login flow in your preferred language

Week 2 — Messaging

docker run rabbitmq
Producer/consumer app with dead-letter queue
Then try Kafka, understand the difference
Be able to explain when you'd choose each

Week 3 — Data

MongoDB and Cassandra, both on Docker
CRUD API against each
Design partition keys for different access patterns
Try DynamoDB-compatible queries against ScyllaDB

Week 4 — Full Stack

docker compose with Supabase
Build a small app using auth, database, storage
Then simulate S3, SQS, DynamoDB with LocalStack
Push everything to GitHub with good READMEs

The Bottom Line

The developer who says "I built this with Keycloak, RabbitMQ, Cassandra, and MinIO — here's my repo" is demonstrating something better than managed service familiarity.

They're demonstrating that they seek understanding over convenience. That they build rather than configure wizards. That they'll know why something works, not just that a button exists.

The cloud services you're being asked about were built on open-source concepts. Cognito implements the standards Keycloak speaks. DynamoDB evolved from the same paper as Cassandra. S3's API is so dominant MinIO cloned it.

The knowledge transfers. It always does.

Start building. Document everything. Walk into that interview with something real.

What open-source alternative has been most useful in your career? I'm genuinely curious — drop it in the comments and I'll check it out.

I built a CLI that installs a production-ready Auth system into any NestJS project in < 5 mins

Mehdi Hassan Jony — Mon, 27 Apr 2026 03:41:26 +0000

The "Day One" NestJS Fatigue

Every time I start a new NestJS project, I get a brief moment of excitement... followed by the realization that I have to build Auth again.

We’ve all been there. You spend 3 days setting up:

JWT strategies and refresh token rotation.
Password hashing with Bcrypt or Argon2.
Passport strategies for Google/GitHub.
Database schemas for Users and Roles.
Docker Compose for Redis and Postgres.
Swagger docs so the frontend team stops asking for endpoints.

It’s the same 80% of code every time. So, I decided to automate it.

Introducing `@mehdijony/nestjs-user-service`

I built a CLI tool that doesn't just scaffold a new project—it installs a complete, high-performance user management engine into your existing project.

⚡️ The 5-Minute Setup

In your terminal, just run:

npx @mehdijony/nestjs-user-service init

The CLI kicks off an interactive session. It’s smart enough to detect your stack:

Package Manager: npm, yarn, pnpm, or bun.
ORM: Prisma, TypeORM, Mongoose, or Drizzle.
Environment: It reads your .env and docker-compose.yml to ensure zero conflicts.

🛠 What's under the hood?

I didn't want this to be "just another boilerplate." It’s built for senior-level requirements:

1. The Modular Architecture

It generates a src/user-service/ directory with a clean separation of concerns. It even injects the UserServiceModule into your AppModule automatically.

2. Multi-Driver Support

Whether you are a Prisma fan or a TypeORM veteran, the CLI generates the correct entities and repositories for your chosen database (Postgres, MySQL, MongoDB, etc.).

3. Safety First (The Rollback Engine)

This is my favorite feature. Modifying source code is scary.
Before the CLI touches a single line, it creates a Restore Point.

If you don't like the result, or something goes wrong:

npx @mehdijony/nestjs-user-service rollback

It uninstalls the packages, deletes the generated files, and restores your app.module.ts and .env to their exact original state. Zero footprint.

📦 Feature Checklist

Category	Features
Auth	JWT, Refresh Tokens, Magic Links, OTP, Social OAuth
Security	2FA (TOTP), RBAC, Rate Limiting, Account Lockout
Infra	Redis Caching, BullMQ/Kafka, S3 File Uploads
DevOps	Auto-Swagger, Health Checks, Docker Compose Merge

🚀 Why I built this

As a Backend Engineer, I want to spend my time on unique business logic, not re-writing the same AuthService for the 10th time. This tool is for the solo dev who needs to ship fast and the agency team that wants a standardized auth foundation across all projects.

Give it a spin

I'd love to get the community's feedback on this. If it saves you a few days of work, drop a star on GitHub!

NPM: [https://www.npmjs.com/package/@mehdijony/nestjs-user-service]
GitHub: [https://www.github.com/mehdijony/nestjs-user-service]

What feature should I add next? LDAP support? SAML? Let me know in the comments! 👇

How Claude Code Built My Dashboard with Almost No Effort

Mehdi Hassan Jony — Mon, 20 Apr 2026 03:31:58 +0000

I’ve built dashboards before. Usually, it means hours of structuring components, managing state, wiring APIs, and refining UI behavior.

This time was different.

I used Claude Code and reduced the entire process to a few precise prompts.

What I did

I described the system at a high level:

Backend: NestJS
Data source: APIs / database
Frontend: dashboard with analytics, charts, and tables

Then I iterated with small corrections instead of writing everything manually.

What changed

Instead of:

Writing boilerplate
Structuring folders manually
Debugging repetitive code

I focused on:

System design
Data flow
Edge cases

The AI handled:

Component scaffolding
API integration patterns
Basic UI logic
Where it actually helps

This approach is not magic. It works well when:

You already understand architecture
You can detect wrong outputs instantly
You guide the system with constraints

Without that, it breaks quickly.

What still matters
Code review is still mandatory
Security and validation are not guaranteed
Performance tuning still requires manual work
Final thought

The shift is real:
Development is moving from writing code → directing code generation.

Tools like Claude Code don’t replace engineers.
They compress execution time.

The bottleneck is no longer typing speed.
It’s clarity of thought.

Most developers rely on cloud AI tools. I switched to running AI locally using Ollama.

Mehdi Hassan Jony — Thu, 16 Apr 2026 05:07:17 +0000

No API cost. No latency. No data exposure.

I use it daily for:

code generation
debugging
SQL queries
documentation

Full breakdown:
https://medium.com/@shoyshab/using-ollama-locally-how-it-changed-my-daily-development-workflow-9a07045dcd6c

Building a Scalable Backend Architecture with NestJS, Kafka, and PostgreSQL

Mehdi Hassan Jony — Wed, 15 Apr 2026 09:37:03 +0000

Most backend systems collapse under scale not because of traffic, but because of poor architectural decisions made early. Tight coupling, synchronous dependencies, and weak data strategies create bottlenecks that are expensive to fix later.

Problem

Typical backend issues at scale:

API latency increases under load
Services become tightly coupled
Failures cascade across the system
Database becomes a bottleneck

Architecture Overview

An event-driven microservices architecture:

API Gateway (NestJS)
Microservices (NestJS)
Kafka (message broker)
PostgreSQL (database)

Flow:

Client hits API Gateway
Event is produced
Kafka distributes it
Consumers process independently
Data persists

Why This Stack

NestJS

Modular architecture
Dependency injection
Scalable structure

Kafka

High-throughput messaging
Decouples services
Enables async workflows

PostgreSQL

Strong consistency
Reliable transactions
Powerful querying

Event-Driven Communication

Producer:

this.kafkaClient.emit('order_created', data);

Consumer:

@MessagePattern('order_created')
handle(data: any) {
  // process event
}

Key Strategies

Failure Handling

Retry with backoff
Dead Letter Queues

Idempotency

Track processed events
Prevent duplication

Scaling

Horizontal scaling for consumers
Read replicas for DB

Real-World Use Case

In systems like logistics or trading platforms:

Orders trigger multiple services
Payments, inventory, notifications run independently
Failures don’t block the system

Takeaways

Design async-first
Avoid tight coupling
Plan for failure
Scale consumers, not just APIs

Full Article

https://medium.com/@shoyshab/building-a-scalable-backend-architecture-with-nestjs-kafka-and-postgresql-ae938465b39b