Day 10/30 —> RBAC in Node.js.

how real apps control permissions??
Authentication answers:-
👉 Who are you?
Authorization answers:
👉 What are you allowed to do?
That 2nd part is where RBAC comes in 👇
# What is RBAC?
RBAC = Role-Based Access Control, Instead of checking every user individually, u assign roles such as:-
- admin
- editor
- user
Each role gets specific permissions. This keeps your API secure, clean, and scalable,.,

# Real-world example
Imagine an e-commerce backend:
👤 user —> can view products
📝 editor —> can update products
👑 admin —> can delete users & manage everything
Now your backend decides access based on role.

# JWT + RBAC flow
When the user logs in, include the role in the token:-

const token = jwt.sign(
  {
    userId: user._id,
    role: user.role
  },
  process.env.JWT_SECRET,
  { expiresIn: "1h" }
);

# Authorization middleware

const authorize = (...allowedRoles) => {
  return (req, res, next) => {
    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({
        message: "Forbidden"
      });
    }

    next();
  };
};

# Use it in routes

app.delete(
  "/users/:id",
  auth,
  authorize("admin"),
  deleteUser
);

Now only admins can access that route 🔥
Why this matters......
Without RBAC, Every authenticated user can potentially access everything

With RBAC, Access becomes controlled, predictable, and secure

This is essential in:
- SaaS platforms
- dashboards
- admin panels
- enterprise systems

# Day 10 takeaway

- Security is not only about login
- It’s about permission design
- RBAC is how backend systems enforce trust..

Tomorrow —> Rate Limiting + API Protection,.,


@devcap12
#30dayschallenge #nodejs #BackendDev

Day 11/30 — Rate Limiting.. how production APIs protect themselves,.,

Building an API is one thing n Protecting it from abuse is another things... One of the first production grade protections every backend should have is rate limiting :}

# What is rate limiting??
- Rate limiting controls how many requests a client can make within a time window.
For ex:-

100 requests / 15 minutes

If the client exceeds that limit, it blocked temporarily.
This protects ur API from:-
- spam requests
- brute-force login attacks
- accidental frontend loops
- basic DDoS-style abuse

# Real-world Express setup
Using Express.js middleware:-

const rateLimit = require("express-rate-limit");

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  message: "Too many requests, try again later"
});

app.use(limiter);

That’s it fire.. Now ur API automatically limits excessive traffic, Better: route-specific protection
For login routes, use stricter rules like:-

app.use(
  "/login",
  rateLimit({
    windowMs: 10 * 60 * 1000,
    max: 5
  })
);

This helps stop password brute-force attacks.

Why this matters??
- Without rate limiting
- A single bad client can overwhelm your server
- With rate limiting
- Ur backend becomes more stable and secure
This is especially important for:
* auth routes
* payment APIs
* public endpoints
* AI inference routes

# Production mindset
- Security isn’t only about authentication
- It’s also about resource protection
- Rate limiting protects both your system and your infrastructure cost..

# Day 11 takeaway

- A secure backend doesn’t trust unlimited traffic, It enforces boundaries

Tomorrow —> API Caching with Redis speed + scale :}



@devcap12
#30dayschallenge #nodejs #BackendDevn

it's monday agian..... GM amigosss :}

Day 12/30 — Redis Caching. how APIs become fast at scale :}

One thing I learned while building backend systems is sometimes the problem isn’t bad code, it’s repeated work.

Imagine if 10000 users request the same product list. Without caching ur API does this every time:-
- query database
- process data
- send response
Again and again, That’s expensive and very slow.

# What Redis solves
Redis is an in-memory cache. That means data is stored in RAM, so reading it is extremely fast. Instead of hitting the database every time, the API checks Redis first.

# Real request flow

Request
|
Check Redis Cache
|
Cache Hit? → Return fast ⚡️
|
Cache Miss
|
Query DB
|
Store in Redis
|
Return response

# Practical Express example

const cachedData = await redis.get("products");

if (cachedData) {
  return res.json(JSON.parse(cachedData));
}

const products = await Product.find();

await redis.set(
  "products",
  JSON.stringify(products),
  "EX",
  60
);

res.json(products);

Here:-
- cache key = products
- expires in 60 seconds ⏱️

# Why this matters
Caching helps with:
- faster response times
- reduced DB load
- better scalability
- lower infrastructure cost

This is huge for:
- dashboards
- product feeds
- analytics APIs
- AI response caching

Note that:-
- Not every request needs fresh DB reads
- Sometimes speed beats recalculation
- That’s where caching becomes system design

# Day 12 takeaway

- Fast APIs are not only about code quality, They’re about smart data access patterns :}

Tomorrow —> Background Jobs + Queues with BullMQ


@devcap12
#30dayschallenge #nodejs #BackendDevn

Morning Amigosss :}

today is presentation day... let's cook it eski 😁

& finally heres the app itself , SUPER compact at 6 mbs. ( there are images bigger than this on unsplash lol )

Youll need to uninstall the old app , disable play protect and install this one

@rb_wk & @oditet

yo guys 👀

quick sneak peek of what we’re building right now… still cooking but it’s coming together 🔥

once we launch:
> daily DSA challenges (stay sharp fr)
> beginner-friendly learning tracks (Python for sure, maybe JavaScript too if there’s demand)

so if you’re tryna level up consistently, this is for you join us in community as well @ETH_X01

also huge shoutout to @BelemaBuilds for absolutely carrying the frontend + redesign 💻✨

more updates soon… stay locked in 🚀

Day 13/30 — Background Jobs + Queues.

One mistake I made early in backend development was Doing everything inside the request-response cycle. For example: sending emails, generating PDFs, processing images, AI tasks, notifications..... This makes APIs slow.
The better approach is Move heavy tasks to the backgrounds. That’s where queues come in.
Instead of making the user wait, ur API immediately responds and pushes the heavy task into a queue.

# Real-world flow

Client Request
↓
API receives task
↓
Push to Queue
↓
Immediate Response ✅
↓
Worker processes task in background

This is how production systems stay fast .
Examp, with BullMQ plus Redis
** Add job to queue

const { Queue } = require("bullmq");

const emailQueue = new Queue("emails", {
  connection: redis
});

await emailQueue.add("sendWelcomeEmail", {
  userId: user._id
});

# Worker processes it

const { Worker } = require("bullmq");

new Worker("emails", async job => {
  await sendEmail(job.data.userId);
});

Why this matters? Queues are perfect for:
- email sending
- scheduled tasks
- report generation
- image processing
- AI inference jobs

# Day 13 takeaway

Fast systems don’t do everything instantly. They do the right work at the right time. That’s backend architecture thinking :}

Tomorrow —> WebSockets plus Real-Time Communication in Node.js :}



@devcap12
#30dayschallenge #nodejs #BackendDevn

That's all for today....... Have A Nice dream fam🫡

Breaking : Claude started working in Ethiopia 🇪🇹.

As of yesterday, May 1, 2026, Anthropic has officially expanded access to Claude AI in Ethiopia.

Yo yoo fam :}

I gotta keep it real with y’all.... I went a bit ghost for like 3 days. Not gonna lie life hit different b/n distance exams, classes stacking up, and some urgent projects, things got kinda crzyy. I couldn’t keep up with my daily posts like I promised. But no excuses.
I’m officially BACK on my 30 Days Node.js grind
Same energy. Same mission. Learning. Building. Sharing everything with u all And yeah... FInal exam are also gonna starting this Friday too (SWE life no joke), but I’m not stopping. Ima balance it all somehow study, code, build, repeat :}

Appreciate everyone still rocking with me and feel sorry for not keep my promise....

Boommmmmmm back to the trackkk :}
Day 14/30 — WebSockets + Real-Time Communication how live apps actually work.,.

Traditional APIs work like this 👇

Client —> Request —> Server —> Response

Simple. But what if you need instant updates??
Like:-
- chat messages
- live notifications
- stock prices
- real-time dashboards
Sending repeated HTTP requests every second is inefficient... That’s where WebSockets come in :}

# What are WebSockets?
WebSockets create a persistent two-way connection b/n client and server.. Instead of opening a new request every time, the connection stays open. That means both sides can send data instantly.

# Real-world flow

Client connects
↕️
Persistent connection
↕️
Real-time data exchange

Unlike REST:

Request —> Response —> Closed

Practical Node.js ex:-
Using Socket.IO:-

const io = require("socket.io")(server);

io.on("connection", socket => {
  console.log("User connected");

  socket.on("message", msg => {
    io.emit("message", msg);
  });
});

Now when one user sends a message, everyone connected receives it instantly. Why this matters?
This powers:-
- chat systems
- live collaboration tools
- multiplayer apps
- instant alerts
- live order tracking
This is how modern apps feel “alive” .. Production mindset Use REST for standard CRUD APIs. Use WebSockets when the server needs to push updates instantly. Choosing the right communication model is architecture thinking :}

Day 14 takeaway

Not all communication should be request-response, Some systems need continuous conversation. That’s where WebSockets shine :}

Tomorrow —> Microservices vs Monolith in Node.js

@devcap12
#30dayschallenge #nodejs #BackendDevn

we grow not by age but by the battles we fight in silence :}

Day 15/30 — Microservices vs Monolith

how architecture choices shape ur backend?
One of the biggest shifts in backend engineering is moving from how do I write this route to how should this system be structured. That’s where Monolith vs Microservices comes in,.,

# What is a Monolith?
monolith means ur entire backend lives in one application.
For ex:-

Auth
Products
Orders
Payments
Notifications
|
Single Node.js App

Everything is inside one codebase and one deployment unit.

# Why monoliths are great??
For most early-stage apps, monoliths are actually the best choice. They are:
- simpler to build
- easier to deploy
- faster to debug
- easier for small teams
A lot of people overcomplicate this too early

# What r Microservices?
Microservices split ur system into independent services..
Ex:-

Auth Service
Order Service
Payment Service
Notification Service

Each service can be:=
- deployed separately
- scaled independently
- owned by different teams
This is powerful at scale.

in real world, Imagine ur payment traffic spikes 10x
With a monolith ❌
u scale the whole app
With microservices ✅
u scale only the payment service
That saves resources and improves flexibility :}

# But here’s the truth, Microservices are NOT always better. They introduce:-
- service communication complexity
- distributed debugging
- deployment orchestration
- data consistency challenges
Sometimes simplicity wins.

# Day 15 takeaway

Architecture is about trade-offs. Start simple with monoliths n Move to microservices when scale and team structure demand it.
That’s system design thinking !!

Tomorrow —> API Gateway + Service Communication


@devcap12
#30dayschallenge #nodejs #BackendDevn

GM amigoss :}
Take a deep breath, smile n step into today with confidence.. u’ve got this :}

Someone told me about this agentic CLI : Qoder CLI —and it is great !

They also got an IDE.
The model is owned by Alibaba Group.

check it out...

@wadehlife

Day 16/30 — API Gateway + Service Communication

how microservices stay connected??
Yesterday we talked about microservices. But once ur system is split into multiple services, a big question appears, How do clients talk to all these services?
Do they call each one directly?
hat quickly becomes messy ❌
This is where the API Gateway becomes the front door of your system :}

# What is an API Gateway?
An API Gateway is a single entry point for all client requests.
Instead of this 👇

Client —> Auth Service
Client —> Order Service
Client —> Payment Service

You do this 👇

Client
|
API Gateway
|
Auth | Orders | Payments

Much cleaner and easier to manage.
btw why it matters??
The gateway handles cross-cutting concerns like:
- authentication
- rate limiting
- logging
- request routing
- response aggregation
This keeps services focused on business logic

Real-world example
-A mobile app requests user dashboard data Instead of calling 3 services separately:
- profile
- notifications
- recent orders
The API Gateway can call all of them and return one response.

Gateway
↓
Profile Service
Orders Service
Notifications Service
↓
Combined Response

This improves frontend simplicity a lot. Service-to-service communication Services also need to talk to each other.
For ex:

Order Service —> Payment Service

This can happen using:-
- HTTP APIs
- message queues
- event-driven architecture
The communication model depends on scale and reliability needs

# Production mindset
Microservices are not only about splitting apps, They’re about designing communication boundaries.
- Poor communication design = distributed chaos ❌
- Good communication design = scalable architecture

# Day 16 takeaway

Microservices need structure. The API Gateway becomes the control layer of the entire system

Tomorrow —> Database Scaling + Read Replicas


@devcap12
#30dayschallenge #nodejs #BackendDevn