codeditor@ross

Biotechnologist | Software Engineer

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟰𝟬/𝟭𝟬𝟬

Imagine a customer changing product prices or staff deleting admin records. That’s what happens when everyone has the same access.

RBAC separates permissions by role: user, staff, and admin. The backend must enforce them.

#100DaysOfLearning

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟵/𝟭𝟬𝟬

While studying my backend, I also started building the frontend.

We moved from an admin dashboard to a login page, then planned a separate public product page where visitors can browse without logging in.

It's still a work in progress

#100DaysOfLearning

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟴/𝟭𝟬𝟬

Why track refresh sessions?

Because a token that expires in 7 days may need to be revoked before then.

Session tracking helps a backend handle logout, revoke compromised sessions, and manage logins across devices.

#100DaysOfLearning

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟳/𝟭𝟬𝟬

What's the difference?

Access token: Accesses protected resources.

Refresh token: Gets a new access token when the current one expires.

In my MMS, access tokens last 1 hour, refresh tokens last 7 days.

#100DaysOfLearning

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟲/𝟭𝟬𝟬

Why should tokens expire?

If a token is stolen, an expiry time helps limit how long it can be used.

In my MMS backend:
Access token: 1 hour
Refresh token: 7 days

it is not just granting access, also control how long that access lasts.

#100DaysOfLearning

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟱/𝟭𝟬𝟬

35 days of learning, building, debugging, and growing.

Today is for resting, reflecting, and recharging.

Consistency isn't about never resting. It's about showing up again.

#100DaysOfLearning #Rest #Consistency

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟰/𝟭𝟬𝟬

What happens when you click "Forgot Password”?

Generate a secure token → Hash it → Store the hash → Send the reset link → Verify the token → Change the password.

#100DaysOfLearning #Security #PasswordHash

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟯/𝟭𝟬𝟬

Hashing ≠ Encryption.

Encryption lets you recover the original data with the right key. Hashing is designed to be one-way.

That’s why my MMS uses bcrypt to hash passwords instead of storing them in plain text.

#100DaysOfLearning #BackendDevelopment

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟮/𝟭𝟬𝟬

What if my MMS database were exposed and every password was stored in plain text?

That's why I use bcrypt. it hashes passwords and makes guessing them more expensive. My current setup uses a cost factor of 12.

#100DaysOfLearning #CyberSecurity #CRUD

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟭/𝟭𝟬𝟬

I moved toward a minimal JWT payload: { id, iat, exp }.

Why? User roles and details changes. Fetching the current user from the database helps my backend use up-to-date information instead of relying on stale token data

#100DaysOfLearning #BackendDevelopment

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟯𝟬/𝟭𝟬𝟬

An admin, staff member, and user can all log in successfully. But should they have the same permissions?

Authentication identifies the user. Authorization decides what they can do.

#100DaysOfLearning #BackendDevelopment #API #SoftwareEngineering

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟮𝟵/𝟭𝟬𝟬

How my MMS backend recognize an authenticated user

Login → Verify details → Generate JWT → Client sends token → Server verifies → Request

Authentication identifies user, authorization determines what they can do

#100DaysOfLearning #BackendDevelopment

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟮𝟴/𝟭𝟬𝟬

A rest day after a week of exploring PostgreSQL, database performance, transactions, and backend reliability.

Sometimes, progress means pausing, reflecting and allowing what you've learned to settle.

We continue tomorrow

#100DaysOfLearning #DeveloperJourney

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟮𝟳/𝟭𝟬𝟬

Instead of guessing why my query is slow, I can ask PostgreSQL.

EXPLAIN reveals the query execution plan, helping me investigate table scans, index usage, the work PostgreSQL expects to perform.

Understand before optimizing.

#100DaysOfLearning #PostgreSQL

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟮𝟲/𝟭𝟬𝟬

Imagine searching 100,000 products for one spare part.

A database index is like a book's index: it helps PostgreSQL find matching records faster without scanning every row.

But indexes also have costs.

N/B: This is a demo app

#100DaysOfLearning #PostgreSQL

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟮𝟱/𝟭𝟬𝟬

While working on my order flow, I started thinking about who should calculate the final order total. The frontend can calculate it, the backend shouldn't blindly trust it.

It should verify the data give the final total.

#100DaysOfLearning #BackendDevelopment

[codeditor@ross @Chinedu_PD]

@vickyiru09 Thank you

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟮𝟰/𝟭𝟬𝟬

Stock = 1.

Request A sees 1.
Request B sees 1.
Both try to buy.

The code may work perfectly for one request, but concurrent requests can produce an incorrect result.

That’s a race condition.

#100DaysOfLearning #BackendDevelopment #SoftwareEngineering

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟮𝟯/𝟭𝟬𝟬

What happens when two customers try to buy the last item at the same time?

Both could see stock = 1. That’s where PostgreSQL’s SELECT FOR UPDATE comes in — locking the row so concurrent requests don't oversell.

#100DaysOfLearning #PostgreSQL #Backend

[codeditor@ross @Chinedu_PD]

𝗗𝗮𝘆 𝟮𝟮/𝟭𝟬𝟬

Today I started Week 4 with PostgreSQL transactions using my MMS order flow.

I learned how BEGIN → operations → COMMIT keeps related changes together, while ROLLBACK prevents partial changes when something fails.

#100DaysOfLearning #PostgreSQL #Database