Forem: Muditha Jayaweera

What is Authentication : The Gatekeeper

Muditha Jayaweera — Thu, 07 May 2026 03:48:22 +0000

The Gatekeeper

Every building that matters has one.

A bouncer at the door. A security guard at the lobby. A lock on the gate. Something — or someone — whose entire job is to look you in the eye and ask a single question before letting you through.

Are you really who you say you are?

In the digital world, that question has a name. It’s called authentication. And every time you tap “Log In” on any app, anywhere in the world, a gatekeeper quietly wakes up and goes to work.

This is what happens behind the door.

You Step Up to the Gate

It starts simply enough.

You open your favorite app. You type your email. You type your password. You tap Log In with the casual confidence of someone who’s done this a thousand times.

But the moment that button registers your tap, your credentials — your email, your password, your claim to this account — are packaged up by the frontend and sent off through the API toward the backend.

The gate has been approached. The gatekeeper has been summoned.

Now the real work begins.

The Secret the Database Keeps

Here’s something most people never think about — your password isn’t actually stored anywhere.

Not really. Not in the way you’d imagine.

If you picture a database as a filing cabinet, you might assume your password is written on a card somewhere, sitting in a folder with your name on it. But any system worth trusting doesn’t work that way. Storing plain passwords is like writing your house key on the front door — the moment someone breaks in, everything is exposed.

So instead, something clever happens when you first create your password. The system runs it through a process called hashing — a one-way mathematical transformation that turns your password into a long, scrambled string of characters. Something completely unrecognizable.

That is what gets stored. Not your password. Its shadow.

And the original? It’s never saved. Not even the system knows what it was.

The Comparison That Decides Everything

So when you show up at the gate and hand over your password, the gatekeeper can’t just look it up. Instead, it does something elegant.

It takes the password you just typed, runs it through that exact same hashing process, and produces a shadow — your shadow, right now, in this moment.

Then it holds two things side by side.

The shadow you just created. And the shadow stored in the database from the day you signed up.

If they match — if those two scrambled strings are identical — the gatekeeper nods.

It’s you.

If they don’t match, the gate stays closed. No explanation, no second chances. Just a quiet, firm denial.

Access denied.

The Identity Card

But verification is only half the story. Because once the gatekeeper confirms who you are, a new problem appears.

You’re inside now — but how does the system keep knowing it’s you?

You’re going to tap through different pages, load your feed, send messages, make purchases. The system can’t ask you to prove your identity every single time. That would be exhausting. So instead, the moment your identity is confirmed, the system hands you something.

A token.

Think of it like a wristband at a concert. You showed your ticket at the door — you proved you belong here. Now the wristband is your pass for the rest of the night. Every time a security guard sees it, they wave you through without asking for your ticket again.

In the digital world, this token — often called a JWT, a JSON Web Token — is a small, secure piece of data that says “this person was verified at this time, and they’re allowed to be here.” Your app holds onto it quietly, and every time you make a request, it sends the token along as proof.

No need to log in again. The wristband speaks for you.

The Door Opens

With the token created and the identity confirmed, the backend sends its response back through the API.

The frontend catches it, tucks the token away safely, and then — the door swings open.

Your feed loads. Your profile appears. Your data, your history, your world inside the app — all of it unfolds in front of you, just as you left it.

From the outside, it felt instant. Effortless. A tap and a second.

But behind the scenes, an entire sequence of events had fired — credentials sent, passwords hashed, shadows compared, tokens created, responses returned. A gatekeeper had done its job with quiet, invisible precision.

Why This Matters More Than You Think

Authentication isn’t just a technical detail. It’s the difference between a safe system and a dangerous one.

Without it, there are no gates. No wristbands. No comparisons. Anyone could walk up to any account and simply walk in — your messages, your bank details, your private data, all of it exposed.

Authentication is what makes trust possible in a world where you can’t look anyone in the eye.

It’s also, for many developers, the first real moment where building software starts to feel serious. Because when you understand how authentication works — when you see the hashing, the tokens, the careful choreography — you realize that security isn’t something you add to an app later.

It’s something you build into its bones from the very beginning.

The Gatekeeper Never Sleeps

Right now, as you read this, millions of login requests are flying through systems around the world. Passwords being hashed. Shadows being compared. Tokens being minted and sent back to waiting frontends.

Instagram. Your bank. Your email. Every app with an account has a gatekeeper standing at the door, asking the same question it always asks.

Are you really who you say you are?

And now — you know exactly how it decides.

What is a REST API: Four Words That Power the Internet

Muditha Jayaweera — Wed, 06 May 2026 03:55:46 +0000

The Menu You Never Questioned

You’ve probably walked into a restaurant hundreds of times without ever thinking about how it actually works.

You sit down. A waiter appears. You point at something on the menu. Food arrives.

Simple. Comfortable. Familiar.

But what if I told you that this exact same system — this quiet, organized dance between you, the waiter, and the kitchen — is how almost every app on your phone communicates behind the scenes?

Welcome to the world of REST APIs.

The Problem With No Rules

Imagine a world with no menus.

Every customer walks straight into the kitchen, shouts their order in whatever language they feel like, and expects the chef to understand. One person draws a picture of a burger. Another hums a description of pasta. Someone else just points aggressively at the stove.

Chaos.

This is what software communication looked like before standards were put in place. Every system had its own custom way of talking. If you wanted two systems to work together, you had to learn a brand new language every single time.

It was exhausting. It didn’t scale. Something had to change.

So the industry did what every good restaurant figured out centuries ago — they created a menu.

That menu is called REST.

The Waiter Who Knows the Rules

REST — which stands for Representational State Transfer — is simply an agreed-upon set of rules for how systems should talk to each other over the internet.

And like any good restaurant, it works because everyone plays their role.

You are the client — the frontend, the app on your phone, the website in your browser. You know what you want, but you don’t go barging into the kitchen to get it yourself.

The kitchen is the backend — where the real work happens, where the data lives, where requests get processed. You don’t need to see it or understand it. You just need your order filled.

And in between? The waiter. The API. The one who carries your request in one direction and your answer in the other, fluently, without confusion, every single time.

But here’s what makes a REST API special — the waiter doesn’t just take any order in any format. There’s a structure. A language. A menu.

Learning the Menu

In a restaurant, the menu tells you what’s available and how to ask for it. In a REST API, that menu is built from four simple actions — four words that cover almost everything you’d ever need to do with data.

GET — “Bring me something.” You want to see your profile. You want a list of products. You want today’s news feed. GET goes and fetches it for you.

POST — “Add something new.” You’re creating an account. You’re submitting a form. You’re posting a photo. POST takes what you’ve prepared and delivers it to the kitchen to be made.

PUT or PATCH — “Change something that’s already there.” You want to update your username. You need to edit a booking. Something needs to be different from what it was. PUT and PATCH walk back to the kitchen and ask the chef to adjust the dish.

DELETE — “Take it away.” You’re removing a post. Cancelling an account. Clearing out old data. DELETE sends back the plate and makes sure it doesn’t come back.

Four actions. Almost infinite possibilities.

The Address of Every Order

But knowing what to ask for is only half the story. You also need to know where to ask.

In a REST API, every resource — every piece of data — has its own address, called an endpoint. Think of it like a table number, or a specific item on the menu.

Want a list of all users? That’s GET /users. Want to add a new one? POST /users. Want just one specific person? GET /users/1.

Clean. Predictable. Once you learn the pattern, you can walk into any REST API in the world and feel right at home — because the menu always looks the same.

A Morning on Your Phone

Let’s make this real.

You wake up and open your favorite app. You tap on your profile picture in the corner. Without you realizing it, your phone quietly whispers a GET /profile request to the server. The API receives it, passes it to the backend, the backend retrieves your data, and within a second your name, your photo, your details — all of it appears on screen.

You didn’t write any code. You didn’t configure anything. You just tapped.

But underneath that tap, REST did its job — organized, fast, and completely invisible.

Why the Whole World Agreed on This

REST didn’t become the dominant standard by accident. It earned its place.

It’s simple — the concepts are easy to grasp, and the structure is easy to follow. It’s standardized — a developer in Sri Lanka and a developer in San Francisco can look at the same REST API and immediately understand what it does. It’s scalable — the same structure that powers a small startup can handle millions of users at a time. And it’s flexible — the frontend and backend don’t need to know each other’s secrets. They just need to agree on the menu.

Separation. Clarity. Order.

The Door This Opens

Once you understand REST, something quietly shifts in how you see the digital world.

Every app that loads your feed, every website that takes your order, every platform that remembers your preferences — they’re all just waiters carrying menus, running back and forth between you and a kitchen you’ll never see.

And once you’re comfortable with that idea, the next doors start to appear. GraphQL — a different kind of menu, one where you get to choose exactly what goes on your plate. WebSockets — where the waiter doesn’t wait for you to ask, but brings you updates the moment they’re ready. Distributed systems — where instead of one kitchen, there are hundreds, spread across the world.

But all of it starts here.

With a menu. A waiter. And the quiet confidence of knowing exactly how to place your order.

How Data Flows in a Simple Application: The Journey of a Single Click

Muditha Jayaweera — Tue, 05 May 2026 15:00:00 +0000

🗺️⁀જ✈️ The Journey of a Single Click

Every great story has a journey. A hero who sets out, faces challenges, crosses through different worlds, and finally returns home with something valuable.

Your click is that hero.

And this is its story.

🌍 The World Your Eyes See

It starts with you.

You’re on an app — maybe you’re trying to log into your favorite platform after a long day. You find the login button, type your email, type your password, and with a quiet confidence, you tap Log In.

To you, it feels like nothing. A tap. Half a second. Done.

But the moment your finger lifts off that screen, something extraordinary begins. A journey launches — invisible, lightning-fast, and more organized than most people’s morning routines.

That button? That’s the frontend. It’s the face of the app — the part designed for your eyes, your fingers, your experience. Websites, mobile apps, dashboards — they all live here, in this layer built entirely for you.

And the moment you tapped that button, the frontend did its job. It packaged up your request—your email, your password, your intention — and sent it off into the unknown.

The journey had begun.

🌉 The Bridge in the Middle

But here’s something most people don’t realize — your request didn’t go straight to where the data lives. It couldn’t just barge in.

It had to go through a bridge first.

That bridge is the API.

Think of it like a border checkpoint between two countries. You can’t just drive across — you have to stop, show your documents, get cleared, and then continue. The API receives your request, makes sure it’s properly formatted, and then passes it forward to where the real work happens.

It’s not flashy. It doesn’t make decisions. But without it, nothing gets through. It is the silent gatekeeper that keeps the whole system organized.

Your request cleared the checkpoint. Now it was heading somewhere deeper.

🏠 The Room Where Decisions Are Made

On the other side of the bridge lives the backend — and this is where the story gets interesting.

If the frontend is the face, the backend is the brain.

Your login request arrived here, and suddenly the room came alive. The backend picked up your request, rolled up its sleeves, and got to work. It read your email. It looked at your password. It asked the questions that needed asking — Is this email registered? Does this password match what we have on file? Is this person who they say they are?

This is where the rules live. The logic. The decisions that determine what you get to see and what you don’t. The backend doesn’t care about design or colors or how pretty the button looked. It only cares about one thing — doing the right thing with the right data.

But to answer those questions, it needed to look something up. So it went further.

🗄️ The Vault

Deep in the system, past the logic and the rules, sits the database — the vault where everything is stored.

Every account ever created. Every transaction ever made. Every booking, every message, every preference you’ve ever set. It’s all here, organized and waiting.

The backend knocked on the vault door and asked its question — “Does this user exist? Does this password match?”

The database searched. Found the record. Checked the details.

And sent the answer back.

The Journey Home

Now the story reverses — and just as quickly as it left, everything comes rushing back.

The database gave its answer to the backend. The backend processed it, wrapped it into a clean response, and handed it back to the API. The API carried it across the bridge, back to the frontend. And the frontend — the world your eyes live in — lit up.

Welcome back.

Your homepage loaded. Your profile appeared. The app smiled at you as if nothing had happened.

But something had happened. In the span of a few seconds, your single tap had traveled through five distinct worlds — the frontend, the API, the backend, the database, and back again — each one playing its role perfectly, handing off to the next without missing a beat.

🗺️ The Map of the Journey

When you step back and look at it, the path is clean and clear:

You → Frontend → API → Backend → Database → Backend → API → Frontend → You

A full circle. A complete story. Every time you use an app, this journey happens. Often multiple times per page. Millions of times per second, across the world.

Why This Changes Everything

Once you see this journey clearly, something shifts.

You stop seeing apps as magic and start seeing them as systems. You understand why things sometimes go wrong — because any point in that journey can stumble. A slow database. A confused backend. A broken API. A frontend that misread the response.

You know where to look. You know what questions to ask.

And when you sit down to learn bigger, heavier topics — system design, distributed systems, scalability — you won’t be starting from zero. You’ll recognize the same journey, just taken by millions of clicks at once.

Every expert in this field once watched a single click and asked, “Wait… where does that actually go?”

Now you know.

Understanding APIs and Backend: The Kitchen You Never See

Muditha Jayaweera — Tue, 05 May 2026 04:57:40 +0000

The Hidden World Behind Your Screen

Imagine you’re sitting in a restaurant. You pick up the menu, choose your meal, and call the waiter. The waiter walks to the kitchen, passes your order to the chef, and a few minutes later — your food arrives at your table.

You never saw the kitchen. You never spoke to the chef. But somehow, exactly what you asked for appeared in front of you.

That’s exactly how the internet works. And today, we’re going to walk into that kitchen.

The Moment You Open Instagram

It’s 9 PM. You’re lying on your couch, you unlock your phone and tap Instagram. Within seconds, your feed loads — photos from your friends, reels you didn’t ask for but can’t stop watching, and an ad for shoes you looked up last Tuesday.

But pause for a second. Where did all of that come from?

Your phone doesn’t store those posts. It can’t. There are billions of them. So something had to go fetch them — fast, silently, invisibly. That messenger — the one carrying requests back and forth between your app and the server — has a name.

It’s called an API.

An API is simply a agreed-upon way for two systems to talk to each other. Your app says, “Hey, give me the latest posts for this user.” The server understands that language, grabs the right data, and sends it back. Your feed appears. You scroll. You never even noticed the conversation that just happened.

Now Let’s Go Deeper — Into the Kitchen

When the waiter takes your order to the kitchen, someone back there does the real work — chopping, cooking, plating. You enjoy the result without ever seeing the effort.

In the digital world, that kitchen is called the backend.

Think about the last time you logged into Facebook. You typed your email, typed your password, and hit Login. Simple enough. But in that single moment, an entire chain of events fired off behind the scenes.

Your request flew to a server somewhere — maybe thousands of miles away. The backend received it, woke up, and got to work. It searched through a database of billions of accounts, found yours, compared your password to what was stored, and within milliseconds made a decision: Yes, this is them. Let them in. And just like that, you were inside.

You saw none of it. You just saw your homepage load.

That invisible decision-making — the logic, the checking, the processing — that’s what the backend does all day, every day, for every user, without rest.

Three Characters, One Story

Every app you love is actually a story told by three characters working together:

The frontend is the actor on stage — the beautiful interface you tap, swipe, and interact with. It’s what makes you feel something.

The backend is the director behind the curtain — making decisions, processing data, enforcing the rules. You never see it, but nothing works without it.

The API is the script they both follow — the shared language that lets the actor and the director communicate without ever being in the same room.

Remove any one of the three, and the story falls apart.

Why This Should Excite You

Here’s the thing — this isn’t just how Instagram works. It’s how your banking app works. It’s how Google Maps knows your location. It’s how Uber finds you a driver in under three minutes. It’s how Netflix remembers you left off at episode four.

These systems feel like magic. But they’re not magic. They’re just these three ideas — frontend, backend, API — repeated, scaled, and layered on top of each other.

Once you truly understand this foundation, something clicks. Topics that used to sound intimidating — distributed systems, event-driven architecture, microservices — suddenly start to make sense. Because underneath all of it, you’ll recognize the same restaurant, the same waiter, the same kitchen.

You’ll just be learning how to build a bigger one.