Day 6/30 — Middleware in Express, the invisible flow behind every request

At first, I used Express like this 👇

app.get("/users", (req, res) => {
  res.send("Users data");
});

Simple. Works. But as the app grows, u quickly need more..
- Authentication
- Logging
- Validation
- Error handling
That’s where middleware come.. b/c the real backbone of ur API

# What is middleware?
Middleware is simply a function that runs b/n the request and the response. Think of it like a checkpoint system:-

Request → Middleware → Route → Response

Ex:-

app.use((req, res, next) => {
  console.log(`${req.method} ${req.url}`);
  next();
});

👉 Every request passes through this first
👉 Then moves to the next step using next()
# Why it’s powerful??
Instead of repeating code in every route ❌

app.get("/users", ...);
app.get("/posts", ...);
app.get("/profile", ...);

u centralize shared logic ✅

For ex:- auth middleware 👇

const auth = (req, res, next) => {
  if (!req.headers.token) {
    return res.status(401).send("Unauthorized");
  }
  next();
};

Use it like this:-

app.get("/profile", auth, (req, res) => {
  res.send("Private profile");
});

Real-world use cases, Middleware is perfect for:-
- JWT authentication
- Request logging
- Input validation
- Rate limiting
- Error handling
This is where your backend starts feeling professional...

# Day 6 takeaway:-

Middleware keeps your API clean, reusable, and scalable. It’s not just a feature of Express, it’s the request flow architecture :}

Tomorrow —> Error handling in Node.js APIs... how production apps stay stable.,.



@devcap12
#30dayschallenge #nodejs #BackendDev

Morning fam :}

We launched the LinkedIn Changemaker Awards Ethiopia 2026 to recognize Ethiopians creating real impact through knowledge sharing, career growth, and community influence on LinkedIn.

This initiative highlights individuals and organizations shaping Ethiopia’s professional space with consistent value.

The platform is now live:-
https://changemakeraward.com

It features 22 categories across areas like career development, health, mental health, climate, and more, all focused on impact.

Behind this platform is a full process we built from the ground up:
• Public nominations
• Careful review and shortlisting
• Final voting by the community

We worked across technical, creative, and operational levels to make this happen and deliver something meaningful for Ethiopia.

Now it’s your turn.
Vote. Support. Amplify impact.

Let’s make recognition meaningful.

⏳ 3… 2… 1… The next chapter is almost here.

Before we move forward, we honor where we began. As HUDC, we met incredible developers, shared breakthroughs, and built a space where curiosity thrived. Every discussion and milestone is part of our history—never forgotten. Thank you to everyone who helped shape it.

As we grew, we realized our name might unintentionally limit us. Our vision is bigger: to reach anyone with that spark for tech. Started in the East, we’re proudly carrying that origin with us as we step beyond university walls into a wider, inclusive space.
That's why we're evolving into:

ESDA — East Spark Devs Association

The logo above marks this new era. (Design story coming soon!)

📢 This channel's name will update to ESDA soon. You'll see the change reflected here first.
💬 What do you think of the logo? Drop your thoughts below 👇

Same heart. More energy. Let's ignite the next phase. 🔥
#HUDC #ESDA #EastSparkDevs #HUDCLegacy #TechCommunity #FromCampusToBeyond #NextChapter

Day 7/30 — Error handling is what separates demos from production APIs

A route that works in local development is easy. A route that fails gracefully in production??

# The common beginner approach

app.get("/users/:id", async (req, res) => {
  const user = await User.findById(req.params.id);
  res.json(user);
});

Looks clean. But what happens if:-
- the database is down?
- the ID is invalid?
- the query throws an exception?
ur API crashes or returns confusing errors right....

# Production mindset
Every request can fail. ur job is to make failure predictable and readable..

—> Use try/catch for async routes :-

app.get("/users/:id", async (req, res) => {
  try {
    const user = await User.findById(req.params.id);

    if (!user) {
      return res.status(404).json({
        message: "User not found"
      });
    }

    res.json(user);
  } catch (error) {
    res.status(500).json({
      message: "Internal server error"
    });
  }
});

* Now the API stays stable... Better centralized error middleware

# below are how real apps scale:-

app.use((err, req, res, next) => {
  console.error(err);

  res.status(500).json({
    success: false,
    message: err.message || "Something went wrong"
  });
});

Now every route can forward errors:-

next(error);

⚡️ Why this matters

Good error handling gives u:-
- stable APIs
- clean responses
- easier debugging
- better frontend integration
Because frontend teams need consistent error shapes,.,

# Day 7 takeaway

- A good backend developer doesn’t prevent every error. they design systems that fail safely. that’s production thinking :}

Tomorrow —> JWT Authentication in Node.js and we gonna see real-world secure APIs :}



@devcap12
#30dayschallenge #nodejs #BackendDev

Here we are... first week is done bezenezena 🫡

Ethio Ministry
Something BIG is about to land... and trust me, u don’t wanna miss this!!!

We’re cooking up something powerful for Grade 7 & 8 students— Ethio Ministry is coming soon.. Imagine having real past exams from Addis Ababa, Oromia, Dire Dawa, and Harar right in your pocket, combined with clean explanations that actually make things click (no more guessing vibes). From textbook to smart practice and progress tracking, everything is built to help students move from "I think I know this" to "I got this 💯".
And yeah... the best part? It works offline too :} so whether u’re online or not, ur learning never stops. This is student full exam partner, designed to help students study smarter, not harder.
Built with passion by Hegere Technology, n proud to say I was part of the mobile app development team that brought this to life :}

This is more than just an app, t’s a whole upgrade to how students prepare and succeed.

⏳ It’s almost here.. Stay locked in... Ethio Ministry is coming to Play Store VERY SOON! 🚀

WEEK 1 RECAP — 7 Days of Node.js and Let's see 7 Shifts in Mindset :}


Within this first week/7-days i didn’t just revisit Node.js concepts.. i just started seeing how systems actually behave under the hood,,,,

#Day 1 — From Using Node.js to Understanding It
I realized something uncomfortable. I had been using Node.js for a while, but not truly understanding how it works internally. The shift was this:
- Writing routes is easy
- Understanding runtime behavior is engineering
That was the real starting point.

#Day 2 — Event Loop a;so we can call it the Heartbeat of Node.js,.,
This was the first major mindset shift. Node.js feels fast not b/c it’s multi-threaded But because it doesn’t waste time waiting. The event loop taught me that performance is often about delegation, not raw power.
Heavy I/O tasks are pushed away, while the main thread keeps serving work
That’s elegance :)

#Day 3 — Blocking vs Non-Blocking
This concept hit hard. Node.js gives u speed by design
but ur code can destroy that speed. A single blocking call can freeze the entire request flow
That means performance is not just framework-level
It’s developer responsibility. This is where I started thinking in terms of runtime pressure :}

#Day 4 — Async/Await vs Promises
This was less about syntax and more about execution behavior
The biggest lesson?
Clean-looking code can still be slow. Sequential awaits may look elegant but parallel execution often performs far better..
This is where readability meets performance thinking :}

#Day 5 — Streams
Streams changed the way I think about memory. Before now I thought data = load → process → return. Now I think in continuous flow.
Data doesn’t always need to exist fully in memory Sometimes the smartest system is the one that processes in motion. That’s how scalable systems think

#Day 6 — Middleware
This was where API structure started making sense. Middleware taught me that backend systems are not just routes.
There are **pipelines ->
Authentication
validation
logging
rate limits
Everything becomes a controlled request flow. This is architecture inside the application layer.

#Day 7 — Error Handling
Production systems are judged by how they fail.
Graceful failures
predictable responses
centralized error control
This is what separates projects from systems!!

*** My biggest realization from Week 1
Backend development is not only about code It’s about:-
- flow
- behavior
- failure
- scale
- architecture
And that’s the mindset I want to keep building :}

In the will of God Week 2 gets even deeper 🫡

@devcap12
#30dayschallenge #nodejs #BackendDev

Day 8/30 — JWT Authentication. how real-world login APIs work??

Authentication is one of the first things every backend developer builds.nBut many people stop atmUser logs in successfully. The real question is how does the server remember the user afterward??
That’s where JWT comes in 🔐

@ What is JWT??
JWT = JSON Web Token
After login, the server creates a signed token that contains user information, such as:-

{
  "userId": "12345",
  "role": "admin"
}

This token is sent back to the client and stored there.
Every future request includes it 👇

Authorization: Bearer <token>

# Real login flow

1️⃣ User logs in

app.post("/login", async (req, res) => {
  const user = await User.findOne({ email: req.body.email });

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

  res.json({ token });
});

2️⃣ Protected route middleware

const auth = (req, res, next) => {
  const token = req.headers.authorization?.split(" ")[1];

  if (!token) {
    return res.status(401).json({
      message: "Unauthorized"
    });
  }

  const decoded = jwt.verify(token, process.env.JWT_SECRET);
  req.user = decoded;

  next();
};

3️⃣ Use it in routes

app.get("/profile", auth, (req, res) => {
  res.json({
    message: "Private profile",
    user: req.user
  });
});

=> Why JWT is powerful...... JWT enables:
- stateless authentication
- scalable APIs
- mobile + web integration
- role-based access

⚠️ Production tip
Never store sensitive data directly inside the token
Keep only identifiers + roles

# Day 8 takeaway

Authentication is about secure request identity across every API call🔐

Tomorrow — Refresh Tokens + Access Tokens ... how big apps keep users logged in :}


@devcap12
#30dayschallenge #nodejs #BackendDev

Do u prefer JWT or session-based auth??

ANOTHERR DAY....

G Morning fam :}

🎤 Join us for a special DEV DIALOGUE session!🎤

We are happy to host Tesfaye Adugna, a Software Engineer @ Google, for an inspiring conversation on professional growth and technical excellence.

Tesfaye lives by the mantra: "Success is my fuel. I believe in hard work, consistency, and giving every challenge my full focus." Don't miss the chance to learn from his journey and expertise!

✍️ Topic: Career Paths in Big Tech, Engineering Mindset & Navigating Global Software Development

📅 Sunday, April 26, 2026
🕔 2:00 LT 🌐 Google Meet Link: http://meet.google.com/pbd-iirx-sdg

#GDGAASTU #DevDialogue #GoogleEngineers #TechCommunity #SoftwareEngineering

Day 9/30 — Tokens + Refresh Tokens 🔐

Why real-world apps use Access???
Yesterday we talked about JWT authentication. But here’s something I used to overlook...
A single token system is not enough for production apps. b/c if ur token lives too long —> security risk... If it expires too quickly —> bad user experience. So modern apps solve this with two-token authentication:-

# Access Token
it's short-lived and used for every protected API request. expires fast (e.g. 15 minutes)

Ex:-

{
  "userId": "123",
  "role": "admin"
}

# Refresh Token
- long-lived
- used only to generate a new access token
- expires in days or weeks
This keeps users logged in without asking them to sign in again every few minutes...

🔁 Real-world flow

Login
↓
Access Token (15 min)
Refresh Token (7 days)
↓
API Requests
↓
Access Token expires
↓
Use Refresh Token
↓
Generate new Access Token

* Practical ex....
# Login route

const accessToken = jwt.sign(
  { userId: user._id },
  process.env.ACCESS_SECRET,
  { expiresIn: "15m" }
);

const refreshToken = jwt.sign(
  { userId: user._id },
  process.env.REFRESH_SECRET,
  { expiresIn: "7d" }
);

# Refresh route

app.post("/refresh", (req, res) => {
  const token = req.body.refreshToken;

  const decoded = jwt.verify(
    token,
    process.env.REFRESH_SECRET
  );

  const newAccessToken = jwt.sign(
    { userId: decoded.userId },
    process.env.ACCESS_SECRET,
    { expiresIn: "15m" }
  );

  res.json({ accessToken: newAccessToken });
});

⚡️ Why this matters in production???
This gives you:
- better security 🔐
- smoother UX 🚀
- reduced re-login friction
- session continuity across devices
This is exactly how many modern apps handle auth flow.
# Day 9 takeaway

- Secure systems balance security and user experience.
- Access tokens protect, Refresh tokens preserve continuity

Tomorrow —> Role-Based Access Control (RBAC) in Node.js APIs :}



@devcap12
#30dayschallenge #nodejs #BackendDev

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