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

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