DEV Community: Hemanth Babu

🎪Kafka Without the Zoo: Should You Go KRaft Mode?

Hemanth Babu — Mon, 14 Jul 2025 14:01:24 +0000

✅ TL;DR

Kafka’s new KRaft mode removes Zookeeper, simplifies architecture, speeds failover, improves metadata consistency, and preps you for massive scale—worth the migration if you're ready for the next generation of Kafka.

Intro – What’s Cooking with Kafka?
Imagine you’re building a food-ordering app—orders flood in, must be queued, routed, and reliably stored. Kafka stands behind the scenes like a high-speed restaurant order line. But until recently, you needed another service—Zookeeper—to manage who’s cooking what. Now Kafka has learned to handle things solo with KRaft. So… what’s the deal?

🧐 Quick Kafka Recap

Producer = kitchen staff placing orders (messages)
Topic = menu (e.g., "pizza-orders")
Partition = individual order queueline
Consumer = delivery staff pulling orders
Broker = kitchen station storing your orders
Offset = tracker of what’s been cooked (read by consumers)

Kafka handles streaming data like a champ—millions of messages per second—often in real-time 🔥

🏛️ The Old Way: Kafka + Zookeeper

Think of Zookeeper as Kafka’s maître d’—manages metadata, broker leader elections, and keeps the whole place synchronized.

What It Does:

Keeps track of topic layouts, partitions, replicas, and who’s boss
Elects broker leaders and handles failovers
Ensures everyone agrees (consistency & metadata coordination)

Zoo Problems:

Double ops: you now manage Kafka + ZK—extra overhead
Scaling pains: Zookeeper can choke under heavy metadata load
Laggy updates: slow metadata changes can cause stale reads
Timeout hiccups: delays can yield frustrating request timeouts

Classic case: you fix Kafka, but ZK chokes—and nothing works. 😬

🌟 The New Hotness: Kafka + KRaft

Enter KRaft ("Kafka Raft Metadata Mode"), Kafka’s new internal conductor—no Zookeeper required.

How It Works:

Metadata lives in a Kafka-internal topic
Controller nodes form a quorum for high availability
Leaders are elected via Raft—Kafka’s own internal election
Brokers and controllers are unified—no external components

Benefits of Going KRaft:

🔄 Simplicity: One stack, one config, no zoo to feed
⚡ Speedy failover: metadata leader swaps in milliseconds
📈 Scale-friendly: handles millions of partitions easily
✏️ Consistency: shared log ensures all nodes agree
⚙️ Operational efficiency: faster topic changes, less overhead

🧪 KRaft mode has been production-ready since Kafka 3.3+, and it's expected to become the default mode in future releases. If you're starting fresh, it's the future-proof choice.

🤷 What You Gain—and What You Might Trade

Feature	Zookeeper Setup	KRaft Setup
Architecture	Kafka + external ZK	Kafka alone
Setup complexity	2 clusters, 2 configs	Just Kafka
Failover speed	Moderate (dependent on ZK)	Milliseconds
Metadata updates	Slower, prone to delays	Fast & consistent
Scalability	Hobbled by ZK limits	Ready for millions of partitions
Migration effort	Noisy	Must reconfigure & migrate

☕ Real-World Café Example

In our food app:

With Zookeeper, launching a new “coffee-orders” topic meant flipping switches in two places (Kafka + ZK), with occasional delays.
With KRaft, it’s just Kafka—order up: topic live instantly, with no extra coordination.

🚦 Should You Make the Jump?

Go KRaft if you want:

A simpler, more scalable Kafka setup
Quicker metadata updates and leader elections
Fewer moving parts to manage
Future-proofing (KRaft is Kafka’s strategic direction)

Stick with Zookeeper if you:

Already have stable ZK-managed clusters
Don’t want migration overhead just yet
Need tested compatibility with older Kafka tools

🛠️ Migration Tips (High-Level)

Plan a migration window — test in staging
Export metadata from existing cluster
Boot a KRaft-only cluster with the same metadata
Test thoroughly (failovers, topic ops, partition splits)
Cut-over when confident — tell clients to switch

(No need for fancy diagrams—just plan, test, and go.)

🧭 Final Takeaway

Kafka with Zookeeper has been a reliable combo for years—but it’s time to retire the zoo. KRaft brings simplicity, speed, and future readiness. If you’re standing up a new cluster—or gearing up for scale—go KRaft. It’s not just Kafka under the hood—it’s Kafka leveled up.

🧠 How I Won a Hackathon With AI as My Entire Dev Team

Hemanth Babu — Sat, 05 Jul 2025 05:31:54 +0000

🧠 How I Won a Hackathon With AI as My Entire Dev Team

TL;DR:

🏁 Two apps, built in parallel, done in 45 mins

💬 ChatGPT acted as my prompt engineer

🤖 GitHub Copilot (Claude Sonnet 4) handled everything from UI to backend to test scripts

🛠️ I just orchestrated: feeding prompts, reviewing code, nudging when needed

🏆 Finished first — still waiting on the prize 👀

The Setup:

Internal hackathon. Two app-building challenges.

Everyone geared up to use GitHub Copilot.

I decided to do what I do best:

Let the AI agents take the wheel, while I just asked good questions..

📋 The Hackathon Brief

The event was part of an internal initiative on AI-assisted development — specifically around GitHub Copilot. After a few sessions on "Community of Practice," the hackathon was announced as a way to put those ideas to the test.

Two challenges. Everyone gets the same brief. Fastest (and cleanest) implementation wins.

🔧 Challenge 1: Shopping Cart

REST API for automobile parts (search, detail, pagination)
Shopping cart: add/remove items, calculate totals
Frontend: list view, product detail view, filters
(Bonus): Price slicer, modern UI

📋 Challenge 2: Interactive To-Do List App

Add, edit, delete tasks
Categorize by type (work, personal, etc.)
Due dates, reminders, priorities
Search and filter by any field

🧙 Enter the Prompt Engineer

I didn’t dive into code — I fired up ChatGPT.

I keep a dedicated chat I call my Prompt Engineer — it helps me generate perfect prompts for:

Building full apps
Debugging errors
Generating role/personality setups (e.g. for ChatGPT agents)
Image generation (like with Sora)
Styling or scripting tweaks — you name it

So naturally, I gave it both challenge descriptions and asked:

💬 “Give me a prompt for Copilot to build this functionality (Challenge 1). I like Python, but suggest the best stack.”

Then the same for Challenge 2.

In return, I got two perfectly structured prompts — ready to feed into GitHub Copilot’s agent chat.

My job? Just passing messages between two AIs.

📊 Here’s how the flow looked in practice:

From requirements to results — one prompt at a time.

⚡ Copilot (Claude Sonnet 4) Gets to Work

I pasted the prompts into GitHub Copilot Chat (Agent Mode) — which runs on Claude Sonnet 4 — and sat back.

And just like that, my AI dev team clocked in. And then the magic began.

✅ The To-Do List App: Done in 10 Minutes

Copilot spun up:

Full frontend and backend
Batch scripts to launch it
Markdown documentation (usage, features, setup)
Even test scripts

I didn’t write a single line of code.

It even opened a browser window inside VS Code to preview the app. Don’t ask me how.

🛒 The Shopping Cart: Completed in 45 Minutes

While the To-Do app wrapped itself up, the Shopping Cart took a bit longer — but not by my hand.

Copilot generated everything:

API endpoints
Paginated product listing
Cart add/remove
Total price calculation
Markdown docs, test files, batch scripts — the full package

There was a small hiccup: clicking a product didn't show its detail view. I pointed it out, and it fixed itself.

Another bug threw an error. I didn’t even read it — I just asked ChatGPT Prompt Engineer to generate a fix prompt for Copilot. Boom. Fixed.

Honestly, it might have wrapped up even faster if it didn’t insist on writing the README, tests, and startup scripts too.
But I wasn’t complaining — it was like having a junior dev who cares too much about clean handoffs.

⏱️ Total Human Effort: 45 Minutes, 0 Code, 100% Prompts

From problem statement to working apps — Copilot did it all.

The only thing I did manually was manage the flow:

Asked ChatGPT for smart prompts
Fed those to Copilot
Gave feedback and nudges
Watched the apps build themselves

It felt like prompt-driven programming — not software development as we know it.

🏆 I Finished First (Still Waiting on the Prize)

By the end of the session, both challenges were:

Fully working
Documented
Tested
Launch-ready

I submitted, wrapped up, and sat back while others were still midway.

“What is the prize?”

They said goodies are coming.

Still waiting. 🫠

💡 What This Experience Proves

AI isn't just co-pilot — it's a team, if you prompt it well
You can orchestrate entire apps with structured instructions
Prompt engineering is a real skill — and a dev superpower
You don’t need to write code to ship quality software

This wasn’t cheating — it was effective orchestration.

🔗 Want to Peek Inside?

Here are the links to both repos — explore the code, docs, and flow if you're curious:

🔗 To-Do List App Repo
🔗 Shopping Cart App Repo

💬 Also, the exact prompts used for Copilot are included inside the repo VibeCoded-Projects.

🔮 Final Thoughts

I used to think hackathons were about caffeine, chaos, and typing fast.

Now?

It’s about:

Clear thinking
Smart delegation
And knowing which AI does what best

This wasn’t "cheating."

It was leveraging the best tools available — and letting humans focus on orchestration.

The future isn’t just developers typing faster — it’s developers thinking better.

🚀 What’s Next?

This is just one example. I’ve been using the same AI-assisted workflows for client projects too — like building & deploying websites in a single evening. (Wrote about that too.)

There’s more coming — and more experiments to try.

Until then… keep prompting. The future is listening.

⚡ How I Built and Deployed a Client’s Website in 90 Minutes — with AI as My Pair Programmer

Hemanth Babu — Sun, 29 Jun 2025 10:07:19 +0000

⚡ How I Built and Deployed a Client’s Website in 90 Minutes — with AI as My Pair Programmer

TL;DR:

🧑‍💼 Friend’s uncle needed a quick landing page for ABC Logistics

🧠 Used ChatGPT for planning + Claude Sonnet (in Copilot) for rapid dev

🛠️ Built the page, added branding & feedback-driven tweaks

🌐 Deployed it for free using GitHub Pages + GoDaddy DNS

⚡ Done in ~90 minutes — AI-assisted dev is a cheat code!

The Setup:

A friend asked me to build a website for his uncle’s new business.
All I had was a PowerPoint, a domain name, and an open evening.
So I teamed up with some smart AI agents — and we got it done in one sitting.

📨 A Tiny Ask That Snowballed

It started like most side gigs do — a casual message from a friend:

“Hey, my uncle’s launching a company. He needs a simple landing page. Can you help?”

There wasn’t much to go on. Just a .pptx with some basic info, a logo file, and a domain name they’d already bought. No developer on their team. No fancy design specs. Just a blank slate and a simple ask:

“It should look professional… and we don’t want to spend on hosting.”

Perfect.

🧠 Planning with ChatGPT: The Invisible PM

Before touching any code, I fired up ChatGPT and shared everything I had — the context, constraints, and files.

It became my project manager in seconds.

We mapped out a high-level plan:

Extract structured content from the PowerPoint
Design a lightweight, single-page layout
Incorporate branding from the logo
Host it somewhere free
Connect it to the client’s domain

What would’ve taken 30 minutes of thinking or scribbling got distilled into a clear action plan in 30 seconds.

🧑‍💻 My AI Pair Programmer Goes to Work

For implementation, I leaned on GitHub Copilot’s Chat (Agent Mode) — which, under the hood, was using Claude Sonnet 4. That model is surprisingly good at front-end work.

With a single prompt:

I want to build a simple, responsive landing page for a logistics company called ABC LOGISTICS. The page should be clean, professional, and mobile-friendly. Use only HTML, CSS, and optionally TailwindCSS or a lightweight framework—no backend logic is needed.

The structure should include:

A header with the company name and tagline

An "About Us" section

A Services section (split into Logistics and Employee Transport Services)

A Sustainability or Green Initiatives section

A Contact section (with address, phone, and email)

An optional Call-to-Action at the bottom

A footer with minimal legal/disclaimer text

Here's the {{Extracted content}} that should be used to fill in the sections.

💡 The result should be a single HTML file (or include an external CSS file if needed) that I can easily host. Optimize for clarity and visual balance.

Boom — HTML and CSS, styled and ready to go.

I didn’t write a single line of layout code from scratch. Just reviewed, tweaked a few labels, and it looked clean on the first try.

Adding the logo? Copilot handled that too.

Aligning elements, changing backgrounds, cleaning up sections? All handled via short follow-up prompts.

The only thing I had to do manually was clean the background of the .jpg logo using an online tool. Everything else — structure, styling, polish — came from prompting.

🔄 The Feedback Loop

As with any real-world project, a few edits came in later.

My friend shared a couple of requests:

Remove some extra company details
Make the layout more minimal
Adjust mobile view for cleaner contact info

I just passed these as prompts to Copilot.

It iterated like a good junior dev — fast, consistent, and tireless.

🌐 From Prompt to Production (Without Spending a Rupee)

Once the page looked good, I set up a GitHub repository and used the platform’s free static site hosting. For connecting the domain, I had to do a bit of DNS wizardry — just following chatgpt's lead.

Within 90 minutes of starting, the website was up and running on the client’s domain.

No infrastructure. No deployment scripts.

Just AI-stitched web magic — no scripts, no stress.

📌 Why This Felt Different

This wasn’t just a “build a page” story.

It was a real taste of how development is evolving:

ChatGPT acted as strategist, spec-writer, and reviewer
Copilot (Claude Sonnet under the hood) handled 90% of the implementation
I became the orchestrator, not the factory

For once, I wasn’t chasing edge cases or fiddling with flexbox. I was just telling the tools what I wanted — and they built it.

🧭 The Bigger Picture

We often talk about “AI replacing developers.” But the real power is in augmenting us.

This wasn’t about speed — though finishing it in 90 minutes felt good.

It was about how seamless and fun it felt:

No tutorial rabbit holes
No blank-canvas paralysis
Just clear ideas, fast execution, and space for creativity

If anything, it left me more excited for the future of development.

💬 Curious About the Stack?

If you're wondering what helped me pull this off:

ChatGPT (for planning, extraction, strategy)
GitHub Copilot w/ Claude Sonnet 4 (for generation + feedback loops)
GitHub Pages (for zero-cost hosting)
A friend’s trust (for creative freedom)

🧩 Final Thought

We’re entering a time where a solo dev with AI tools can ship professional results — fast.

This wasn’t a hackathon or startup sprint.

Just a quiet evening, a small ask, and the right tools.

And sometimes, that’s all it takes.

🔮 What’s Next?

This isn’t the end of my AI-assisted dev adventures. I’ve even used similar workflows during a company hackathon (more on that soon 👀).

The MongoDB Role Pitfalls That Bit Me: Lessons in Multi-Customer Access Control

Hemanth Babu — Sat, 21 Jun 2025 13:56:16 +0000

The MongoDB Role Pitfalls That Bit Me: Lessons in Multi-Customer Access Control

TL;DR:

❌ Global roles don't auto-scope to each customer databases

🎯 Create roles per customer database

🔐 Define privileges exactly where they apply

🤖 Automate role/user creation for scale

🔄 Always restart after config changes

🔍 Intro: "I thought I understood MongoDB access control... until I didn't."

I'd just published a guide on setting up MongoDB users and custom roles. See the tutorial-style primer on Dev.to version or Medium version. It covered the commands, the theory, and a neat walkthrough.

Confidently, I thought: “Great—now I can lock down any MongoDB instance.” But when I tried to adapt that for a multi-customer, multi-module SaaS environment, things fell apart in unexpected ways.

In this post, I'll share exactly what I tried, why it didn't work, and how I fixed it. If you're building a MongoDB setup where each customer has its own database and each module/service should only see its own collections, these lessons will save you headaches. And if you haven't read the tutorial-style primer yet, check it out here:

Dev.to: https://dev.to/hemanthbabu164_76/mongodb-access-control-creating-secure-users-with-custom-roles-48f5

Medium: https://medium.com/@hemanthbabu1121/MongoDB-access-control-creating-secure-users-with-custom-roles-2916bf953658

🏗️ What I Was Trying to Build

Architecture in simple terms:
- A SaaS-like application where each customer has its own database.
- Within each customer database, multiple modules/services (e.g., orders, products, analytics) each have dedicated collections.
- Each module (i.e., the code/service) uses a MongoDB user to access only its own collections for that specific customer.
End goal: When Service A runs for Customer X, it connects with credentials that allow only the “CustomerX*ServiceA” collections. It must _never* access ServiceB collections or CustomerY data.
Initial idea: Create roles at the admin level—one role per module/service that spans all customer databases. Then, for each customer, assign that role scoped to the customer database. I assumed that specifying { role: "<moduleRole>", db: "<customerDb>" } in db.createUser() would filter the module role's privileges to that customer database.

In short: I thought I could define one “ServiceA” role globally, then assign it with db= to restrict it to that DB. Spoiler: that assumption was wrong.

⚠️ The Misunderstanding: “db” in `createUser` Is Where the Role Lives, Not Its Scope Filter

Initial Plan (Wrong assumption)

// Pseudocode for each module role created once under admin database:
use admin;
db.createRole({
  role: "serviceA",
  privileges: [
    // Suppose we try to list resource patterns under many DBs:
    { resource: { db: "customer1_db", collection: "serviceA_*" }, actions: ["find", "insert", "update", "remove"] },
    { resource: { db: "customer2_db", collection: "serviceA_*" }, actions: ["find", "insert", "update", "remove"] },
    // ...and so on for each customer
  ],
  roles: []
});

Then for user creation:

use customerX_db;
db.createUser({
  user: "customerX_serviceA_user",
  pwd: passwordPrompt(),
  roles: [
    { role: "serviceA", db: "customerX_db" }
  ]
});

I assumed:

“By specifying db: "customerX_db", the serviceA role's privileges get filtered to customerX_db only.”

Reality: Role's `db` parameter is where the role is defined, not a filter of where it applies.

The { role: "...", db: "customerX_db" } in createUser means “look for a role named ‘serviceA' in the customerX_db database.” It does not say “apply the global serviceA role only in this DB.”
If “serviceA” role was created under admin (or any other DB), referencing it under customerX_db fails (role not found), or if found under another DB, privileges don't magically filter to the user's connect-DB context.
MongoDB's RBAC: A role's actions/resources are defined exactly where you create the role. Assigning that role to a user requires you refer to that same DB where the role exists.

Lesson: You cannot “create once globally and assign with filtering by specifying db in createUser.” The db is the namespace of the role definition.

🔄 How I Fixed It: Role Creation Per Customer Database

Approach:

For each customer database, create distinct roles for each module/service.
When creating the user for a module in that customer DB, reference the role in the same DB.

Example Flow (pseudo-automation script style):

// For each customer (e.g., customerX_db):
use customerX_db;

// 1. Create or update role for ServiceA in this customer DB:
const roleName = "serviceA"; // consider prefixing with module name or include customer in name if desired
db.createRole({
  role: roleName,
  privileges: [
    {
      resource: { db: "customerX_db", collection: "serviceA_orders" },
      actions: ["find", "insert", "update", "remove"]
    },
    // Note: MongoDB privileges require exact collection names; wildcards aren't supported here, so list each collection explicitly.

  ],
  roles: []
});

// 2. Create user for ServiceA in this customer DB:
db.createUser({
  user: "customerX_serviceA_user",
  pwd: passwordPrompt(),
  roles: [
    { role: roleName, db: "customerX_db" }
  ]
});

You repeat this for ServiceB, ServiceC, etc., in each customer DB.
If you have many customers, script this process (e.g., a Node.js or Bash script that loops customer list).

Why This Works:

Role is defined in the same database where its privileges apply, so no confusion.
When the service connects with mongodb://customerX_serviceA_user:pwd@host:27017/customerX_db?authSource=customerX_db, it gets only the privileges defined in that DB's role.

Tip: If you have common privilege patterns per module, template the JSON structure and programmatically fill in the db and collection names per customer.

🔧 Bonus Pitfall: Enabling Authentication in mongod.cfg

What happened: After editing mongod.cfg to add:

  # In mongod.cfg, ensure 'security:' is at root indentation level; YAML is indentation-sensitive.

  security:
    authorization: enabled

I tried connecting with the new users, but MongoDB still allowed unauthenticated access.

Root cause: Didn't restart the MongoDB service/process after config change.
Fix: Always restart or reload the mongod service after modifying the config file.
- On Windows, use Services UI or net stop MongoDB, net start MongoDB (or the equivalent PowerShell commands).
- On Linux, sudo systemctl restart mongod.
Lesson: Authentication “not working” is often because the config change isn't live yet.

📈 What I Learned (and You Should Know)

Understand that the db field specifies where roles live, not their access scope.
- The db field in createRole and in user's roles assignment refers to where the role is defined, not a dynamic filter. Always create roles in the DB where they should apply.
Multi-customer (multi-DB) adds complexity
- One-size-fits-all global roles often don't work. Better to script role/user creation per customer DB.
Automate repetitive setup
- If you have tens or hundreds of customers, manually creating roles/users is error-prone. Build scripts or use Infrastructure-as-Code.
Test early and often
- Spin up a staging customer database, create roles/users, verify permissions before rolling out widely.
Restart after config changes
- Simple but easily overlooked; always confirm authorization: enabled is in effect.

✅ Conclusion & Next Steps

Key takeaway: Don't assume MongoDB will scope a global role by specifying a different db at user-creation time. Define roles in the exact database where their privileges apply. (For the basic tutorial on custom roles, see My previous MongoDB ACL tutorial on Dev.to.)
Call to action: Have you tackled MongoDB RBAC in a multi-DB environment? What strategies or scripts did you use? Share your approaches or questions in the comments below!

MongoDB Access Control: Creating Secure Users with Custom Roles

Hemanth Babu — Mon, 16 Jun 2025 17:42:26 +0000

🔐 MongoDB Access Control: Creating Secure Users with Custom Roles

TL;DR:

✅ Create an admin user with full privileges

🧱 Define custom roles for specific collections

👥 Assign roles to users per database

🔒 Enable access control in MongoDB config

🔗 Use correct connection strings with authSource

🚀 Why MongoDB Access Control Matters

Security isn't optional—especially when you're dealing with databases that store critical application data. MongoDB, one of the most popular NoSQL databases, offers powerful access control mechanisms that let you define who can do what—right down to the collection level.

In this guide, you'll learn how to set up user-based authentication and custom roles to secure your MongoDB deployment like a pro. Whether you're managing dev environments or preparing for production, this setup will help you sleep better at night.

🛠️ Step-by-Step: Setting Up Access Control in MongoDB

🔑 1. Create the Admin User

Let’s begin with setting up an admin user who has the power to manage users and roles across all databases.

use admin

db.createUser({
  user: "myUserAdmin",
  pwd: passwordPrompt(),
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" }
  ]
})

💡 The userAdminAnyDatabase role allows this user to create, modify, and assign roles across all databases.

🧱 2. Define a Custom Role (Fine-Grained Access Control)

Want to allow users access only to specific collections like products and orders? Create a user-defined role tailored to those needs.

use mydb;

db.createRole({
  role: "editor",
  privileges: [
    {
      resource: { db: "mydb", collection: "products" },
      actions: ["find", "insert", "update", "remove"]
    },
    {
      resource: { db: "mydb", collection: "orders" },
      actions: ["find", "insert", "update", "remove"]
    }
  ],
  roles: [] // Inherited roles (leave empty if none)
})

🧠 Think of this like giving someone keys to just two rooms in a building—not the whole building.

👤 3. Assign the Role to a User

✅ Option A: Create the User (if they don’t exist yet)

use mydb

db.createUser({
  user: "myUser",
  pwd: passwordPrompt(),
  roles: [
    { role: "editor", db: "mydb" },
    { role: "read", db: "reporting" }
  ]
})

🔄 Option B: Update an Existing User

use mydb;

db.updateUser("myUser", {
  roles: [
    { role: "editor", db: "mydb" }
  ]
})

🔐 Roles are assigned per database, so always specify both the role and the target DB.

🧪 4. Verify Users and Roles

Before moving forward, it’s good practice to check that everything is set up correctly.

use admin;

db.getUsers();
db.getRoles();

Use this to confirm that the users and their assigned roles appear as expected.

⚙️ 5. Enable Access Control in MongoDB Config

This step locks the door and turns on the bouncer. Modify your MongoDB configuration file:

Path: C:\\Program Files\\MongoDB\\Server\\8.0\\bin\\mongod.cfg

# Security section
security:
  authorization: enabled

📁 After saving the file, restart your MongoDB service for changes to take effect.

🔗 6. Connect with Authenticated Access

Here’s how your MongoDB URI looks when connecting with credentials:

mongodb://myUser:myPassword@localhost:27017/mydb?authSource=mydb

✨ Notice the authSource=mydb? That’s telling MongoDB where to verify credentials.

🎯 Conclusion: Lock It Down Like a Pro

By now, you’ve:

Created an admin user
Defined custom roles
Assigned those roles to users
Enabled authentication
Verified and connected securely

This setup gives you tight control over who can access what in your database. Whether you're building a multi-user app or just locking down a staging server, these best practices put security front and center.

💬 What’s Next?

What other MongoDB topics would you like to see covered? Maybe role inheritance, replica set authentication, or integration with external identity providers? Let’s continue the conversation—drop your thoughts in the comments below!

DEV Community: Hemanth Babu

🎪Kafka Without the Zoo: Should You Go KRaft Mode?

✅ TL;DR

🧐 Quick Kafka Recap

🏛️ The Old Way: Kafka + Zookeeper

What It Does:

Zoo Problems:

🌟 The New Hotness: Kafka + KRaft

How It Works:

Benefits of Going KRaft:

🤷 What You Gain—and What You Might Trade

☕ Real-World Café Example

🚦 Should You Make the Jump?

🛠️ Migration Tips (High-Level)

🧭 Final Takeaway

🧠 How I Won a Hackathon With AI as My Entire Dev Team

🧠 How I Won a Hackathon With AI as My Entire Dev Team

📋 The Hackathon Brief

🔧 Challenge 1: Shopping Cart

📋 Challenge 2: Interactive To-Do List App

🧙 Enter the Prompt Engineer

⚡ Copilot (Claude Sonnet 4) Gets to Work

✅ The To-Do List App: Done in 10 Minutes

🛒 The Shopping Cart: Completed in 45 Minutes

⏱️ Total Human Effort: 45 Minutes, 0 Code, 100% Prompts

🏆 I Finished First (Still Waiting on the Prize)

💡 What This Experience Proves

🔗 Want to Peek Inside?

🔮 Final Thoughts

🚀 What’s Next?

⚡ How I Built and Deployed a Client’s Website in 90 Minutes — with AI as My Pair Programmer

⚡ How I Built and Deployed a Client’s Website in 90 Minutes — with AI as My Pair Programmer

📨 A Tiny Ask That Snowballed

🧠 Planning with ChatGPT: The Invisible PM

🧑‍💻 My AI Pair Programmer Goes to Work

🔄 The Feedback Loop

🌐 From Prompt to Production (Without Spending a Rupee)

📌 Why This Felt Different

🧭 The Bigger Picture

💬 Curious About the Stack?

🧩 Final Thought

🔮 What’s Next?

The MongoDB Role Pitfalls That Bit Me: Lessons in Multi-Customer Access Control

The MongoDB Role Pitfalls That Bit Me: Lessons in Multi-Customer Access Control

🔍 Intro: "I thought I understood MongoDB access control... until I didn't."

🏗️ What I Was Trying to Build

⚠️ The Misunderstanding: “db” in createUser Is Where the Role Lives, Not Its Scope Filter

Initial Plan (Wrong assumption)

Reality: Role's db parameter is where the role is defined, not a filter of where it applies.

🔄 How I Fixed It: Role Creation Per Customer Database

Approach:

Example Flow (pseudo-automation script style):

Why This Works:

🔧 Bonus Pitfall: Enabling Authentication in mongod.cfg

📈 What I Learned (and You Should Know)

✅ Conclusion & Next Steps

MongoDB Access Control: Creating Secure Users with Custom Roles

🔐 MongoDB Access Control: Creating Secure Users with Custom Roles

🚀 Why MongoDB Access Control Matters

🛠️ Step-by-Step: Setting Up Access Control in MongoDB

🔑 1. Create the Admin User

🧱 2. Define a Custom Role (Fine-Grained Access Control)

👤 3. Assign the Role to a User

✅ Option A: Create the User (if they don’t exist yet)

🔄 Option B: Update an Existing User

🧪 4. Verify Users and Roles

⚙️ 5. Enable Access Control in MongoDB Config

🔗 6. Connect with Authenticated Access

🎯 Conclusion: Lock It Down Like a Pro

💬 What’s Next?

⚠️ The Misunderstanding: “db” in `createUser` Is Where the Role Lives, Not Its Scope Filter

Reality: Role's `db` parameter is where the role is defined, not a filter of where it applies.