DEV Community: Shloka

Eli5: AI Agents are toddlers that need adult supervision!

Shloka — Sat, 25 Jul 2026 15:53:35 +0000

In this fast-paced world, parents are obsessed with making their babies smart, before they can even start walking!

So out come the flashcards of colors, shapes, and animals. At this stage, teaching a baby is low-stake. Most of the time, the baby gets the answers right. But once in a while, he points to a “Red” card and confidently says, "Black”. You smile, correct them, and move on.

There's no real world damage. The mistake stays inside the flashcard.

Until a few years ago, this was the exact "baby" stage AI was in. Think about early chatbots... you asked a question, the model answered, and occasionally it confidently gave you the wrong answer. You corrected it, and that was it. The mistake was contained. No "actual" damage.

The Toddler Phase

Everything changes the moment a kid starts walking. Suddenly, a house designed around predictable adult behavior has a toddler running loose in it.

I mean a common adult would not stick their finger in a socket, right?

So, like any prepared parent, you do your research and toddler proof every corner, outlet covers, cabinet locks, stair gates. You take every precaution imaginable.

And it works... right up until it doesn't. :/

Why? Because toddlers are so freaking smart. Out of curiosity, they don't just walk into problems you prepped for, they invent entirely new ones!

Case in point: as a kid, I took my mom’s expensive lipstick and drew on the bathroom floor with it! Ask my or your mom, and she'll tell you every single week brought a brand-new edge case she never saw coming.

Now.. the real shift isn't just that toddlers aren't predictable, it's that their mistakes are no longer contained. One tiny decision or mistake can quickly lead to a big accident!

That is precisely what happened when AI went from being a baby to a toddler i.e evolved from chat window into autonomous agent.

Toddler-proofing agents

As long as AI lived inside a chat box, the worst outcome was a wrong answer. You could ignore it, regenerate it, or start over.

But the moment we let models browse the web, call APIs, execute code, or touch production systems, their mistakes stopped being conversations and started affecting reality.

Traditional software infrastructure, was build for predictable software i.e it’s deterministic: give it the exact same input, and it follows the exact same path to the exact same output every single time.

And just like toddlers, AI agents don't work like that! They operate probabilistically. Every step is the model's best guess about what to do next, not a guaranteed sequence of operations.

Naturally, before letting agents touch the system, engineers did the digital equivalent of toddler-proofing:

Prompt rules & system instructions
Input guardrails
Permission checks & tool restrictions
Manual approval gates

These are all useful and necessary.

But just like toddlers, agents eventually throw an edge case nobody benchmarked for. And because agents don't just say things, they do things, the consequences aren't contained anymore.

Consider a common scenario:- an agent invokes a tool with bad formatting. The request fails, so it retries with a slightly altered payload. Then again. And again. In seconds, it’s trapped in a recursive retry loop—racking up thousands of API calls, burning GPU compute, and blowing through your cloud budget.

It's the digital equivalent of a toddler knocking over a glass lamp. except instead of sweeping up glass, you're cleaning up runaway infrastructure.

And to make things worse, agentic failures are freaking hard to debug.

When traditional software breaks, the logs tell a clear step-by-step story. However with agents, logs show what happened, but struggle to explain why the model thought that action made sense in the first place.

The Fix is adult supervision

A child should NOT grab sharp tools and act on them alone. In an ideal world, the kid points to what he wants, an adult checks if it's safe, then hands it over or says "no".

The kid isn't running things, but you also don't have to hover over every millisecond of his day.

The same principle applies to AI. It comes down to ONE rule: never let a probabilistic model directly control production infrastructure.

Instead, separate intelligence from execution using a deterministic control plane.

Propose: The AI agent suggests an action, workflow step, or tool call.
Validate: A predictable, rule-based policy engine checks whether that action is valid, safe, and/or permitted.
Execute: An underlying execution gateway carries out the operation only after passing policy checks.

Alongside this runtime barrier, you need multi-dimensional observability, capturing the model's full decision-making chain and memory state so you understand the reasoning path behind EVERY action.

In this, humans don't disappear, nor do they sit around acting as a bottleneck for every micro-action. Automated code enforces safety at runtime, allowing human operators to act purely as high-level exception handlers who step in only when an action hits an unhandled edge case or ambiguous scenario.

Bonus section: The Kindergarten Classroom

Scaling up from one agent to many introduces an entirely new challenge. Imagine it’s no longer just one toddler, but FIVE kids sharing ONE single art project.

Anyone who's run or observed kids in a classroom knows what happens next. Kids color over each other's drawings. Supplies go missing. Somebody grabs the marker someone else was actively using.

This is what a multi-agent system looks like, several AI agents coordinating on a complex workflow.

In AI infrastructure, these aren't reasoning failures, they are classic distributed systems problems:

Conflicting updates: Agents overwriting each other's shared state.
Stale reads: Agents acting on outdated context.
Context drift: A shared memory space degrading into chaos over time.

From the outside, it looks like "the AI is making weird mistakes," when in reality, it's a state management and memory consistency issue.

Managing a multi-agent system requires structured orchestration what engineers call an "agent control plane"

Cubbies: Isolated context memory so individual agent state stays clean.
Rotation charts: Workload routing, turn-taking, and concurrency management.
Layers of backup: A defense-in-depth architecture combining prompt controls, tool permissions, deterministic policy checks, and human exception handlers.

No single guardrail does the whole job. It’s the entire infrastructure stack working together that keeps multi-agent systems reliable.

The Big Takeaway

Here's the fundamental truth worth sitting with: making the underlying model smarter doesn't solve this problem. A smarter toddler still needs supervision, arguably needs it more.

Prompting tricks and raw model intelligence are rapidly becoming table stakes. The real competitive advantage will go to whoever builds the equivalent of great parenting: a deterministic system where the AI proposes, code validates, and only safe, approved actions ever touch production.

That's not a limitation on AI. It's how you let it grow up.

Acknowledgement:

IBM videos
That one meta tech lead for his video
All and any llms.

Are deterministic tasks eating your tokens?

Shloka — Mon, 20 Jul 2026 19:04:57 +0000

If you've built a system with integrated AI (or are building one now) you've probably felt the pain of a climbing token bill.

When costs spike, the instinct is often to look for a cheaper model. But what if the problem isn't the model but the "task" you gave it?

People usually bring models into a system because they need some "thinking" done. But what if the task you handed it isn't actually a “thinking” task? what if it's just basic math? adding up a column of numbers? sorting a list alphabetically? checking if a string matches a regex pattern? scraping data off a page?

For example, does a task like 2 + 2 need any “real” thinking? Nope! The answer is always going to be 4!

Whether you're in 1978 or 2025, India or Japan the answer is always going to be 4.

When a task returns the same output for the same input, EVERY time, it's deterministic.

There's ZERO creativity, judgment, or opinion needed. A calculator, a basic script, or an existing library can handle a deterministic task perfectly, instantly, and for fraction of a penny.

Now you may ask, “Shloka WHY are you whining and being so dramatic? Why the heck is it a problem to hand a deterministic task to an AI model when it can do both deterministic and non-deterministic tasks?”

Wellll……

There are a bunch of problems, but for this blog, let's stick to two of em:

Tokens (i.e some sweet Moolah). by now we've learned that more tokens means more money. When you ask a model to do something deterministic, like "add these 50 numbers", it has to generate every step of that work. That's slow AND expensive compared to just running actual code, which does the same task in a fraction of a second for basically nothing.
Reliability. Fun fact, models CAN get deterministic tasks wrong. Now this is a dumb example, cause we have come a long way, but to keep things simple... a calculator never miscounts. Whereas A language model, doing arithmetic by "reasoning" in text, sometimes does.

It's like asking a toddler "what's 2+2?", they'll usually say 4, but every so often they'll confidently get it wrong, and you won't catch it until it's already caused a problem downstream.

Now, in a real codebase, at scale, the line between "this needs a model" and "this doesn't" gets blurry FAST since AI ends up woven into a dozen different steps of a pipeline. So how do you actually draw that line?

Well, the general fix isn't asking the model to do "less" thinking. It's asking it to do "different" thinking.

A good system doesn't ask the model to do everything itself, instead, it gives the model the ability to call actual tools: a code interpreter, a calculator, a database query, a search function, for anything deterministic. The model's real job becomes:

Understand what's being asked
Decide which tool solves the deterministic part
Hand that part off
Use its own judgment only for the fuzzy, non-deterministic parts (writing, reasoning, interpreting, deciding)

This is often called "tool use" or "function calling."

So how do you actually decide what gets delegated and what doesn't?

Think of it as a priority list, checked top to bottom, cheapest and most reliable first, most expensive and flexible last. Only move down if the step above can't do the job.

Can plain math or logic solve it? Write a script. Always check this first.
Can an existing tool or lookup solve it? Call a database, API, or search index directly instead of guessing.
Can simple fixed rules solve it? Even a long list of "if this, then that" rules can usually be handled with plain code.
Does it need real understanding, language, or judgment? Now bring in AI.

A quick gut-check, if you forget the order is to ask yourself: would 10 different careful people all land on the exact same answer? If yes, you're probably still in script territory. If no, that's AI's job.

This keeps your system fast and cheap by default, and saves the AI's "thinking" for the one thing it's actually needed for.

PS: In the next blog I want to build on this and talk about how even handing AI control of deterministic tasks is not the end game.

Why Traditional Token Savers Fall Short on Big Coding Jobs (And How We Fix It)

Shloka — Thu, 02 Jul 2026 15:54:07 +0000

Earlier this week, we announced that we’re launching DestinyAI’s Token Saver Engine for free on July 24th.

The internet did its magic, and almost immediately, the community started hitting us with existing token-saving tools, specifically rtk and Headroom, asking one core question:

“How are you different?”

Fair enough! So here’s a breakdown:

rtk is great for your everyday work. It's fast. Think of it as a smart filter that sits in your command line, catches the output from your usual dev tools, and shrinks it down before sending it to an LLM. Good pick if you just want something simple and quick to cut down noisy command output.

Headroom is built for bigger jobs: like RAG systems or AI agents that need to process huge amounts of text (logs, raw files, big data chunks). It's an optimization layer (and also works as an MCP server) that compresses that text a lot, and can give you back the original if you need it. Basically, a heavy-duty compressor for your context window.

So when should you use DestinyAI's Token Saver Engine instead?

Well, you would want to use our token saving engine for big coding jobs refactoring many files, changing your app's structure, auditing a whole codebase. This is where simple text-trimming tools like rtk and Headroom struggle. They treat your code like regular text: they guess what to cut or shorten. That guessing can quietly break your code or make the AI make things up.

DestinyAI works differently.

It's not a text compressor it actually understands your code.

Here's how:

It gives real facts, not guesses. It reads your code properly (understands the actual structure, works with many languages) and gives your ai assistant the exact lines it needs. Word for word, with proof they came from your real files. If it's not sure about something, it says so clearly instead of pretending to know.
It double-checks the AI's work. rtk and Headroom only make the input smaller. DestinyAI also checks the output. Before accepting any code change, it tests it on a safe copy of your project. If something breaks, it rejects the change and tells you exactly which test failed. So a wrong answer doesn't slip through.
It remembers your codebase. rtk and Headroom start fresh each time. DestinyAI builds up memory of your code and patterns over time, so it gets faster and smarter the more you use it. And that memory isn't tied to one AI, switch from Claude to OpenAI anytime, and it still remembers. One memory, works with any AI, no lock-in.
It keeps your code private. It runs on your own computer. Your code and secrets never leave your machine. It also keeps different projects separate and hides sensitive info automatically.

And it saves you money everywhere, not just on big jobs. For big tasks, this approach cuts costs by 50–90% (based on our own testing). For small everyday tasks, the engine just does the work itself and the AI checks it, so those get much cheaper too, with the same safety guarantee.

All these claims are pointless without proof.

We didn't just guess these differences, we benchmarked them.

We ran all three engines through a rigorous production-grade engineering capability evaluation on a scale of 0–100. We didn't look at lab micro-benchmarks; we tested how these tools handle serious, high-stakes engineering pipelines:

For Input/Output and Context Control: rtk and Headroom score strongly on basic payload trimming (scoring 55–85). But when it comes to true codebase stability, like Accuracy Preservation and Output Verification (actually catching a bad AI change before it ships)—their text-based architectures score in the 15–25 range.
Where DestinyAI sits: Because we approach this as a local semantic compiler rather than a compressor, DestinyAI scores 94/100 overall across core engineering metrics, delivering a near-perfect 98 on exact verbatim grounding with tamper-evident proof.

Every single capability we claim is backed by these evidence-labeled test sets.

The bottom line?

We aren't trying to be the best text zipper on the market. We're building a local codebase compiler that lets you ship trusted code with absolute integrity, while dropping your AI bill by 50–90%.

DestinyAI’s Token Saver Engine drops for free on July 24th. Stay tuned.

Happy women in STEM day!! <3

Shloka — Wed, 11 Feb 2026 21:12:49 +0000

Wrote a blog that explains ReAct (Reasoning + Action) through the analogy of the game "Pass the story" https://dev.to/shlokaguptaa/understanding-react-reasoning-action-through-a-simple-childhood-game-1b20

Shloka — Wed, 04 Feb 2026 14:34:33 +0000

Shloka

Feb 4

Eli5: Understanding ReAct (Reasoning + Action) through a simple game

#explainlikeimfive #agents #ai #game

4 min read

Eli5: Understanding ReAct (Reasoning + Action) through a simple game

Shloka — Wed, 04 Feb 2026 05:16:01 +0000

When I first moved from New York City to Philadelphia, I was starved for social interaction. So naturally, I did what any adult would do.

I downloaded Hinge.

Just kidding. I downloaded Meetup. And for my first social outing, I went to a writers’ meetup. Now the funny thing about a group of adult strangers meeting is that to kill the awkwardness we end up playing childhood games as ice breakers.

And the game we played at this meetup is called “Pass the Story.”

To refresh your memory, about the game, here’s how it works, there’s a sheet of paper. One person writes a line and passes it on. The next person reads what’s written and adds the next line. This continues until, collectively, the group creates a story. Simple, right?

Now here’s the interesting part: If you’ve played this game before, you already understand ReAct.

But... what is ReAct?

ReAct is a model Observing + Reasoning + Acting, (or you can also say, seeing, thinking, and doing) to solve a problem step by step until it reaches an end goal.

To understand the words “observing, reasoning, and acting” better, let’s map our game “Pass the Story” game to these words.

The first line written on the page?

That’s the query.

When a person receives the paper, they:

Observe. The person sees what the story so far says.
Reason. The person thinks about how to continue.
Action. The person writes the next line and pass it along.
The person passes the paper to the net person till the reach their goal of having a completed story.

Now here’s the most important part.

The person you pass the paper to has no idea what the story is until they read it.

And just like the players in the game, models are stateless. They have no inherent memory. They don’t remember your previous API call. They don’t remember your previous conversation.

They start fresh every single time.

Like Ghajini. (Yes, the Bollywood movie.)

Passing that sheet of paper forward, the full story so far, is exactly like sending the conversation history back to the LLM in your next API call.

The story so far in the paper is the context.

Now, ReAct is awesome. Most agentic AI systems lean on it. Heavily.

But it has it’s goddam flaws.

1. The "Infinite Loop" Trap.

Imagine you’re playing this game with a toddler who only knows one sentence:

_“Cats and dogs are animals. Animals are cats and dogs.”
_

And they keep writing it. Over and over again. Not cause they mean to. They just have limited vocabulary.

In AI, this happens too. It’s called infinite looping.

Sometimes the observation doesn’t provide new useful information. The agent reasons the same thing. Takes the same action. Gets the same result. Repeat.

Solution? You set a limit.

For example: “Only allow 5 iterations.”

2. Context Window & "Token Fatigue"

Imagine, people are really enjoying the game and the story becomes 100 pages long.

The next person can’t possibly read all of it before adding their line.

They’ll skim. They’ll miss context. They’ll get tired. LLMs have the same limitation, and it's called context windows.

Every Observe → Reason → Act loop adds more tokens to the prompt. This:

Increases cost
Slows response time
Risks hitting context limits

The solution? Context pruning

Instead of passing the entire history every time:

Keep the last few steps
Maintain a high-level summary of earlier steps

3.ReAct vs. ReWOO (Plan First, Execute Later)

“Pass the Story” is fun. But you know what’s more efficient? Everyone agreeing on an outline before writing.

In ReAct, you think after every step.

In ReWOO,you think deeply once, generate a structured plan, and then execute it.

It’s the difference between:

Improvising a story line by line vs.
Agreeing on the plot first, then writing chapters.

Both are useful. One is reactive. The other is strategic.

Opinion:
THINGS ARE MOVING FAST! I feel like I am on a never ending roller coaster ride!

And, I believe that ReWOO is what the IBM video meant by "2026 is the age for multiple agents". Maybe towards the end of this year, this blog won't even be relevant. :')

But in the mean time, I hope it was a decent insight into how the ReAct loop works and that you won't be shy to reach out about your thoughts!

xoxo!

Rolling credits:

The awesome people of Philly write up group who have welcomed me!
Reddit
LLMs

January started out strong. I put out 4 blogs, which I would like to think caused a ripple effect, and inspired 4 other people in my network to use Devto and start blogging. YAY!

Shloka — Sun, 25 Jan 2026 16:26:49 +0000

ELi5 : AI Workflows vs AI Agents, Explained with LEGOs

Shloka — Fri, 23 Jan 2026 02:58:04 +0000

Ever dumped a pile of LEGOs on the floor?

Yes?

Well then, you are already a step closer to understanding the difference between AI workflows and AI agents.

AI workflows: LEGO manual builds

An AI workflow is like opening a LEGO house kit and following the instruction manual from step 1 to step 12.

You know:

exactly which piece snaps where
the order of the steps
and what the final house will look like

Nothing is left to chance.

AI workflows work the same way. They follow a fixed control path, a predefined sequence of steps.

But why do we even need workflows in the first place?

Why Models Alone Aren’t Enough

Models are really good at tasks like drafting emails, writing text messages, generating blog content, creating images, onverting text to voice, and other stuff

For example, if I ask an LLM:

“Hey, can you draft me a text to ask Sam out on a date?”
An LLM (based application) like ChatGPT or Gemini will do a great job...

...but sometimes, they kinda suck!

Say, I ask chat:
"When is my date with Sam?"
It won’t have a clue.

But what makes LLMs/Models kinda suck sometimes?

While, it's true that they have been trained on massive public datasets, they don’t have access to your personal or proprietary data. Stuff like your calendar, emails, company’s internal documents, etc.

So what’s the solution?
Give the model access to your data.(Not all of it. Be careful. Duh!)

Now, when the LLM gets questions around time like:
“When is my date with Sam?”
OR
"When is my lunch?"
OR
"When is my meeting?"

it will:

Query your calendar
Extract the relevant event
Summarize it
Respond to you

That’s an AI workflow!

Note that over here the model is NOT deciding what to do, it’s following a pre-wired path:
Input → Retrieve → Process → Respond

Just like a LEGO manual, the logic and path is fixed!

What makes workflows awesome

AI workflows are awesome because of:

Predictable behavior
Easy to reason about
Cheap and efficient (Like really cost friendly)
Same input → same output

You have a ballpark figure of how many “pieces” (API calls, LLM calls, compute) it will take.

The downside

If you didn’t plan for a step, the system breaks.

Just like realizing mid-build that the manual requires a rare LEGO piece you lost under the couch. Everything stops until a human fixes it. :/

Say, in the AI workflow above, you ask:
“What should I wear for my date, given the weather?”

The workflow will fail! Not because the question is hard, but because:

it doesn’t have access to a weather API
it doesn’t know how to fetch outfits
it wasn’t designed for this path

Sure, you can fix this by adding a weather API, adding an image generation model, wiring everything together

But no matter how many modules you add, it’s still just a workflow.

It is still a fixed, predefined path.

No matter how many extra tools you glue on, the workflow still can’t decide to change the plan. When you need the system to rethink the plan itself, you don’t need more steps, you need something with a goal and autonomy. That’s where agents come in.

AI Agents: Free Builds With a Goal

An AI agent is like dumping a pile of LEGOs in front of a kid and saying:

“Build me something I can live in."

You don’t give the kid instructions. You give them a goal.

The kid then:

inspects the available pieces
decides to build a house
realizes they’re missing roof tiles
pivots to a cabin… or a cave

They reason their way to the goal using whatever resources they have.

Similarly, with agents, you don’t give the Model a pre defined path, you give:

a goal
a set of tools (APIs, vector databases, workflows, search)
permission to decide what to do next

When you give models tools, a goal, and permission to decide what to do next, that’s when they start acting like agents.

In a workflow, you decide this once at design time. In an agent, the LLM decides this at runtime.

But the awesomeness of agents comes at a cost

Every decision , “Should I search the web?” , “Should I call this API?”, “Do I need another refinement loop?” is another LLM reasoning step.

Think of it like hiring a brilliant architect:

incredible ideas
lots of sketches
very expensive

Agents rarely crash outright. instead, they might give you something technically valid but very wrong.

Like a LEGO jail, when all you wanted was a small cabin.

So When Should You Use Which?

If you need certainty and repeatability, workflows are your friend.
You know exactly what pieces exist, exactly how they fit together, and exactly how the system behaves. Basically, when you need a factory.

If you need adaptability in messy environments, agents make sense.
They can reason around missing pieces, try alternative approaches, and still deliver something when the path isn’t clear.

But the most practical pattern is hybrid.

Let workflows handle the predictable assembly line
Drop agents into the steps that truly need flexible reasoning

This approach is called, Agentic Workflows, and it’s how most real-world AI systems are being built today.

Manual where possible. Free build where necessary. Just like LEGOs.

Rolling Credits:

YouTube videos
LLMs
Reddit

Vector Embeddings (with OpenAI and Supabase) - Part 3 (storing & searching)

Shloka — Fri, 16 Jan 2026 04:43:20 +0000

Hey there! In the last two blogs, we talked about what vector embeddings are and how to set up OpenAI and Supabase locally so you have a solid playground to experiment in. So incase you want to check out the theory or have your set up up and running, go to the blogs below.

Part 1 – The theory (what embeddings are and why they matter)
Part 2 – Setup ( set up OpenAI client + Supabase + pgvector)
Part 3 – Vector database & search (👈 YOU ARE HERE)
Part 4 – A chatbot (proof of concept)

This post is where we actually put everything to work: we’ll turn plain text into vectors, store them in a pgvector‑powered table, and run semantic searches over that data using a custom SQL function. From there, we’ll refactor the logic into small, reusable functions and add the Chat Completions API so the final experience feels like a friendly, grounded assistant instead of a raw database query.

Also, it may look a little overwhelming for now, but trust me, if I can do it, you. I believe in you!

So! We’ll walk through this blog in three sections:

Part A: Storing data in Supabase
Part B: Querying
Part C: Adding chat completions

Let's get this party started!

A. Storing Data in Supabase

Creating a basic embedding

Now, being able to create an embedding is one of the most important building blocks in any vector database workflow. So let’s start by learning how to use OpenAI’s embeddings API from our Node project.

If you go to OpenAI’s vector embeddings page, you’ll see that the API expects three main things:

The text you want to embed
The embedding model to use
The encoding format, which determines how you receive the vectors (as a float array or compressed base64)

In our previous blog, in our project, we already set up an OpenAI client in config.js, so we just import it and call the embeddings API from index.js

And we are going to tweak the code given to us, a bit, to extract the embeddings vector i.e embedding.data[0].embedding.

//index.js
import { openai } from "./config.js";

// Create an embedding for a given text string
const embedding = await openai.embeddings.create({
  model: "text-embedding-3-small",
  input: "Your text string goes here",
  encoding_format: "float",
});

console.log(embedding.data[0].embedding);

#Output
[
  0.005132983,
  -0.03028705,
  -0.0016865017,
  0.017242905,
  ...
  -0.020154044,
  -0.048173763
]

Note that:

The input can be a single string or an array of strings.
Regardless of text length, the embedding vector size for text-embedding-3-small is 1536, from Open AI vector embedding model response.

You can experiment by changing the input value and observing how the vector changes.

Embeddings for multiple items

If you pass an array of strings, each element gets its own embedding vector, and the response is a list of embedding objects.

The response contains an array where each entry corresponds to one input string’s embedding

//index.js
import { openai } from "./config.js";

// Create an embedding for a given text string
const embedding = await openai.embeddings.create({
  model: "text-embedding-3-small",
  input: ["cat", "dog", "be good to earth"],
  encoding_format: "float",
});

console.log(embedding);

#Output
PS > node index.js
[
  0.0090422972,  0.02994411,  -0.00023611961,  0.063080595,
  0.043438736,   0.0212318581, 0.0535876,      0.016274985,
  0.025267525,   0.012582723,  0.023231698,    0.034558498,
  0.02852485,    0.011034184,  -0.026081856,
  ...
  1436 more items
]

PS > node index.js
{
  object: 'list',
  data: [
    { object: 'embedding', index: 0, embedding: [Array] },
    { object: 'embedding', index: 1, embedding: [Array] },
    { object: 'embedding', index: 2, embedding: [Array] }
  ],
  model: 'text-embedding-3-small',
  usage: { prompt_tokens: 6, total_tokens: 63 }
}

To make this more fun, let’s work with a small music list

//index.js
import { openai } from "./config.js";

const music = [
  "Taylor Swift : The Fate of Ophelia",
  "Taylor Swift : Cruel Summer",
  "Taylor Swift : Love Story",
  "Harry Styles : Daylight",
  "Harry Styles : As It Was",
  "Harry Styles : Watermelon Sugar",
  "Elvis Presley : Can't Help Falling in Love",
  "Elvis Presley : Blue Christmas",
  "Bruno Mars : I Just Might",
  "Bruno Mars : Die With A Smile",
  "Frank Sinatra : My Way",
  "Frank Sinatra : Fly Me To The Moon",
];

// Create an embedding for a given text string
const embedding = await openai.embeddings.create({
  model: "text-embedding-3-small",
  input: music,
  encoding_format: "float",
});

console.log(embedding);

To keep things tidy, move the array into a separate file content.js and import it.

//content.js
const music = [
  "Taylor Swift : The Fate of Ophelia",
  "Taylor Swift : Cruel Summer",
  "Taylor Swift : Love Story",
  "Harry Styles : Daylight",
  "Harry Styles : As It Was",
  "Harry Styles : Watermelon Sugar",
  "Elvis Presley : Can't Help Falling in Love",
  "Elvis Presley : Blue Christmas",
  "Bruno Mars : I Just Might",
  "Bruno Mars : Die With A Smile",
  "Frank Sinatra : My Way",
  "Frank Sinatra : Fly Me To The Moon",
];

export default music;

//index.js

import { openai } from "./config.js";
import music from "./content.js"; // Import the music array

// Create an embedding for a given text string
const embedding = await openai.embeddings.create({
  model: "text-embedding-3-small",
  input: music,
  encoding_format: "float",
});

console.log(embedding);

You can also print each item together with its own embedding, with forEach.

//index.js
import { openai } from "./config.js";
import music from "./content.js"; // Import the music array

// Create an embedding for a given text string
function main(input) {
  input.forEach(async (item) => {
    const embedding = await openai.embeddings.create({
      model: "text-embedding-3-small",
      input: item,
      encoding_format: "float",
    });

    console.log(`Embedding for "${item}":`, embedding.data[0].embedding);
  });
}

main(music);

Setting up Supabase with pgvector

In the previous blog, you set up Supabase with pgvector to store and query vector embeddings. Now you need a table to store vectors and their corresponding text, and it can be created directly from Supabase’s docs with a few tweaks.

Go to: https://supabase.com/docs/guides/ai/vector-columns

You will see:

Copy the example table, then tweak it to match this project.

create table documents (
  id bigserial primary key,
  content text,          -- the text chunk
  embedding vector(1536) -- 1536 for OpenAI 'text-embedding-3-small'
);

Here, content combines the “title + body” into a single text field, and the vector size is 1536 because that’s the embedding dimension for text-embedding-3-small.

Open your Supabase project

Click on SQL Editor, in the side bar
Run the code we copied and modified.

After running this, you should see “Success. No rows returned”, and under Table Editor, in the side bar, you’ll see the new documents table..

Inserting embeddings into Supabase

The process is:

Pass your data through OpenAI’s embedding model.
Insert the text and embedding, received from OpenAI, into Supabase

You already did step 1 when you generated embeddings for your music list, so now you can focus on inserting those into the documents table.

First, here is the original forEach version, from our code in index.js.

import { openai } from "./config.js";
import music from "./content.js"; // Import the music array

function main(input) {
  input.forEach(async (item) => {
    const embedding = await openai.embeddings.create({
      model: "text-embedding-3-small",
      input: item,
      encoding_format: "float",
    });

    console.log(`Embedding for "${item}":`, embedding.data[0].embedding);
  });
}

main(music);

Insert all your rows at once

Use map instead of forEach.
Build an array of { content, embedding } objects.
Wrap everything in Promise.all.
Insert the whole data array into Supabase in a single call.

import { openai, supabase } from "./config.js";
import music from "./content.js"; // Import the music array

async function main(input) {
  // Build an array of { content, embedding } using map
  const data = await Promise.all(
    input.map(async (item) => {
      const embeddingResponse = await openai.embeddings.create({
        model: "text-embedding-3-small",
        input: item,
        encoding_format: "float",
      });

      const embedding = embeddingResponse.data[0].embedding;

      // Key names must match your SQL table: content, embedding
      return {
        content: item,
        embedding,
      };
    })
  );

  // Insert all rows at once
  const { error } = await supabase.from("documents").insert(data);

  if (error) {
    console.error("Error inserting embeddings (batch):", error);
  } else {
    console.log("Embeddings inserted successfully (batch)!");
  }
}

main(music);

When you go back to your table, in your Supabase you will see that all your songs, will be in your table.

YAY! We are done with part A. The hard part is behind us now.

To summarize Part A

B. Querying

Now that your data is in the database, the next step is search. At a high level, you need:

A user question (query).
A way to convert that query into an embedding using OpenAI.
A similarity function that compares the query embedding to stored embeddings.

A user question / query

Start fresh in index.js with an example question based on your data. Let’s say, “What song of Taylor’s is about Summer?”

import { openai , supabase } from "./config.js"; // Import OpenAI and Supabase clients
import music from "./content.js"; // Import the music array

let query = "What Taylor swift song is aboout summer?";

Convert the query into a vector embedding using OpenAI

Next, just like we converted our data in create single embedding, we are going to convert our query into an embedded vector

import { openai , supabase } from "./config.js"; // Import OpenAI and Supabase clients
import music from "./content.js"; // Import the music array

let query = "What Taylor swift song is aboout summer?";

const response = await client.embeddings.create({
    model: "text-embedding-3-small",
    input: query,
});

const embedding = response.data[0].embedding;

You now have an embedding representing the user’s question.

Defining the match function in SQL

To search over your embeddings, you can use a helper SQL function based on cosine similarity provided by Supabase’s pgvector extension

And before this sounds scary, you don’t have to write this function. It already exists. To search over your embeddings, you can use a helper SQL function based on cosine similarity provided by Supabase’s pgvector extension

You can head over to the docs at https://supabase.com/docs/guides/ai/vector-columns, where there is a ready-made SQL helper for semantic search that you can copy and tweak.

We are going to tweak the code provided to us on supabase just a little because the function must reference your table and columns exactly. In our code, the table name is documents and the columns are id, content, and embedding.

create or replace function match_documents (
  query_embedding vector(1536),
  match_threshold float,
  match_count int
)
returns table (
  id bigint,
  content text,
  similarity float
)
language sql stable
as $$
  select
    documents.id,
    documents.content,
    1 - (documents.embedding <=> query_embedding) as similarity
  from documents
  where 1 - (documents.embedding <=> query_embedding) > match_threshold
  order by similarity desc
  limit match_count;
$$;

Add this in Supabase:

Open your project and go to the SQL Editor.
Create a new query, paste this function, and click Run.
You should see “Success. No rows returned”

Calling the function from your code

Once the function exists, Supabase exposes it as an RPC, which you can call from anywhere in your code.

//index.jsx
import { openai, supabase } from "./config.js";

// User query
const query = "What Taylor Swift song talks about summer?";

main(query);

async function main(input) {
    // 1. Convert the query to an embedding
    const embeddingResponse = await openai.embeddings.create({
        model: "text-embedding-3-small",
        input,
    });

    const embedding = embeddingResponse.data[0].embedding;

    // 2. Ask Supabase for the most similar documents
    const { data, error } = await supabase.rpc("match_documents", {
        query_embedding: embedding,
        match_threshold: 0.5, // tune this based on your data
        match_count: 1,       // top 1 match
    });

    console.log("Matches:", data);
}

query_embedding is the vector for the user’s query.
match_threshold is a value from 0 to 1 that controls how similar a match must be to be returned.
match_count is how many top matches you want back.

Once it runs, you will see:

PS> node index.js
Matches: [
  {
    id: 5,
    content: 'Taylor Swift : Cruel Summer',
    similarity: 0.685700174742966
  }
]

Which makes sense. Because that is the Taylor swift song in our database about summer.

C. Adding chat completions

The semantic search already works, but the output is just a JSON row from the database. To make the experience feel conversational, you can pass the matched content plus the original question to OpenAI’s Chat Completions API and ask it to generate a short answer.

Refactoring the code

At this point, the logic to create embeddings, call Supabase, and handle the user query is all in one place, which makes it harder to read and reuse. A small refactor into separate functions keeps responsibilities clear: one function creates the embedding, one talks to Supabase, and one coordinates the whole flow

import { openai, supabase } from "./config.js";

// User query
const query = "What Taylor swift song is about Summer?";
main(query);

// Bring all function calls together
async function main(input) {
  const embedding = await createEmbedding(input);
  const match = await findNearestMatch(embedding);
  await getChatCompletion(match, input);
}

// Create an embedding vector representing the input text
async function createEmbedding(input) {
  const embeddingResponse = await openai.embeddings.create({
    model: "text-embedding-3-small",
    input,
    encoding_format: "float",
  });

  return embeddingResponse.data[0].embedding;
}

// Query Supabase and return a semantically matching text chunk
async function findNearestMatch(embedding) {
  const { data } = await supabase.rpc("match_documents", {
    query_embedding: embedding,
    match_threshold: 0.5,
    match_count: 1,
  });

  if (!data || data.length === 0) return null;
  return data[0].content;
}

Using OpenAI to make the response conversational

Now add a small chat layer on top of the search result

const chatMessages = [
  {
    role: "system",
    content:
      "You are enthusiastic and love recommending music to people. " +
      "You will be given some context about a song and a question. " +
      "Your main job is to formulate a short answer to the question using the provided context. " +
      "If you are unsure and cannot find the answer in the context, say, \"Sorry, I don't know the answer.\" " +
      "Please do not make up the answer.",
  },
];

async function getChatCompletion(text, query) {
  if (!text) {
    console.log("Sorry, I don't know the answer.");
    return;
  }

  chatMessages.push({
    role: "user",
    content: `Context: ${text}\nQuestion: ${query}`,
  });

  const response = await openai.chat.completions.create({
    model: "gpt-4o-mini", // or any chat model you prefer
    messages: chatMessages,
    temperature: 0.5,
    frequency_penalty: 0.5,
  });

  console.log(response.choices[0].message.content);
}

With this in place, the flow looks like:

Take a natural‑language query.
Convert it into an embedding with OpenAI.
Use Supabase’s match_documents function to find the most similar row.
Feed that row and the original query into Chat Completions.
Return a short, friendly answer to the user.

The complete code for querying:

import { openai, supabase } from "./config.js";

// User query
const query = "What Taylor swift song is about Summer?";
main(query);

// Bring all function calls together
async function main(input) {
  const embedding = await createEmbedding(input);
  const match = await findNearestMatch(embedding);
  await getChatCompletion(match, input);
}

// Create an embedding vector representing the input text
async function createEmbedding(input) {
  const embeddingResponse = await openai.embeddings.create({
    model: "text-embedding-3-small",
    input,
    encoding_format: "float",
  });

  return embeddingResponse.data[0].embedding;
}

// Query Supabase and return a semantically matching text chunk
async function findNearestMatch(embedding) {
  const { data } = await supabase.rpc("match_documents", {
    query_embedding: embedding,
    match_threshold: 0.5,
    match_count: 1,
  });

  if (!data || data.length === 0) return null;
  return data[0].content;
}

const chatMessages = [
  {
    role: "system",
    content:
      "You are enthusiastic and love recommending music to people. " +
      "You will be given some context about a song and a question. " +
      "Your main job is to formulate a short answer to the question using the provided context. " +
      "If you are unsure and cannot find the answer in the context, say, \"Sorry, I don't know the answer.\" " +
      "Please do not make up the answer.",
  },
];

async function getChatCompletion(text, query) {
  if (!text) {
    console.log("Sorry, I don't know the answer.");
    return;
  }

  chatMessages.push({
    role: "user",
    content: `Context: ${text}\nQuestion: ${query}`,
  });

  const response = await openai.chat.completions.create({
    model: "gpt-4o-mini", // or any chat model you prefer
    messages: chatMessages,
    temperature: 0.5,
    frequency_penalty: 0.5,
  });

  console.log(response.choices[0].message.content);
}

Once you run this you will see:

PS> node index.js
The Taylor Swift song about summer is "Cruel Summer."

What you built

In this blog, you went from basic embeddings to a full semantic search pipeline over your own data, powered by OpenAI and Supabase. You created a documents table with pgvector, generated and stored embeddings in bulk, wrote a custom SQL function for similarity search, refactored your code into small helper functions, and layered Chat Completions on top so the final result feels like a tiny, polite assistant instead of a raw SQL query.

I AM SO PROUD OF YOU! You made it to the end.

I know it was probably a little overwhelming, but I think knowing that you have these tools in you tool box and knowing how to work them, is a W!

Credits:

Scrimba
LLMs to help me fix this
Random posts on reddit

Vector Database (OpenAI and Supabase )-Part 2 (Setup)

Shloka — Sun, 11 Jan 2026 22:42:56 +0000

Remember how I said there were only going to be 2 parts to “Vector Databases (with Supabase and OpenAI)”? 😬

Well… slight change of plans, there are 4 parts now.
And before you start screaming at me through the screen,

I split the series up because I go into these steps in excruciating detail. Cause what if there is somewhere out there is someone doing this for the very first time? And the goal is to make every step feel approachable, not overwhelming.

To keep things digestible, I’m “chunking” the series into four smaller posts instead of one giant wall of text.

And they are:

Part 1 – The theory
Part 2 – Setup (👈 YOU ARE HERE)
Part 3 – Vector database & search
Part 4 – A chatbot (proof of concept)

So, before doing anything fancy with vector databases, you need three things: a Supabase project, an OpenAI API key, and a Node project that can talk to both.

We are going to set up the above in under easy 9 steps.

Create a Supabase project
Enable the vector extension
Get your Supabase URL and anon key
Set up your OpenAI API account
Create a Node project
Store your secrets in .env
Create reusable OpenAI and Supabase clients
Test everything with a tiny script
Where you are now

1. Create a Supabase project

Go to Supabase and sign in with GitHub or email

On the dashboard, click New project

You will be prompted to create an organization.
Fill in:
- Name: anything you like (your name, side‑project, or company).
- Type of organization: Personal.
- Pricing plan: Free.
- Click Create

Next you will have to set up your project.

Under Organization, pick the one you just created
Set a Project name (for example, vector-embeddings).
Choose a strong Database password (this is for Postgres, not your login).
Pick a Region close to you/users for better latency.
Click Create new project

Once it’s ready, click on your new project card in the dashboard to enter the Studio

2. Enable the vector extension

Next, we need to enable Vector extension. To store embeddings efficiently, Supabase uses the vector (pgvector) extension in Postgres
In your project sidebar, go to Database > Extensions.
Search for vector.
Click to Enable the vector extension.

3. Get your Supabase URL and anon key

In the sidebar, click Project Settings > API Keys

Under Legacy anon, service_role API keys, find anon public.
Click Copy.
This is the key you will use in your Node app.

_NOTE: Never share the **service_role key publicly_**

In Project Settings, open the Data API (or API section depending on UI).
Copy the value labeled Project URL (the one that looks like https://xyzcompany.supabase.co)

Store both these values somewhere safe, you will paste them into your .env file in a minute

4. Set up your OpenAI API account

Uhmm, this is the part where I need your 5 dollars. Well, not me, but Open AI. And yes, I know it sounds expensive, but hear me out:

It’s pay-as-you-go. There are no automatic charges unless you explicitly enable auto-pay.
$5 goes a long way. I’ve been using OpenAI’s API for weeks now, started with $5, and I’m still on $5.

And before you ask, “I already pay $20 for ChatGPT, can I just use that?”

Unfortunately, that's not how it works. Paying for ChatGPT is like buying a fully built car, it’s a finished product. Paying for OpenAI’s API is like paying for the engine, the part you can actually build things with.

So, let’s get to it.

Log in to your OpenAI account.
Click on API platform

In the sidebar (or using the search bar), go to Billing.

Add a payment method and purchase credits.

(At the time of writing, the minimum preload for new API users is 5 USD)

- Keep **auto‑recharge disabled**

In the dashboard, search for API keys and open the API keys page.

Click Create new secret key.

Give it a name and select the Default project.

Click Create secret key and copy it immediately, you will not be able to see it again.

*NOTE: Treat this key like a password. Never post it online or commit it to GitHub. If it leaks, delete it and create a new *

5. Create a Node project

Open your terminal and create a fresh folder for this project:
- mkdir my-ai-project && cd my-ai-project
Initialize a Node project with a package.json:
- npm init -y

Install the official OpenAI SDK and the Supabase JavaScript client: npm install openai @supabase/supabase-js
If you want to use a .env file for secrets (recommended), also install dotenv: npm install dotenv

Open package.json and ensure it looks like this (only showing the important parts):


{

"name": "my-ai-project",

"version": "1.0.0",

"main": "index.js",

"type": "module",

"scripts": {

"start": "node index.js"

}

}

6.Store your secrets in .env

Create a file named .env in the root of my-ai-project
Replace the placeholders with the values you copied from OpenAI and Supabase.
- OPENAI_API_KEY=your-openai-secret-key
- SUPABASE_URL=your-supabase-project-url
- SUPABASE_API_KEY=your-supabase-anon-key
Do NOT wrap them in quotes.
Do NOT commit this file to GitHub; .env should stay private.

7. Create reusable OpenAI and Supabase clients

Create a new file called config.js and add this:

import OpenAI from "openai";
import { createClient } from "@supabase/supabase-js";
import "dotenv/config";

export const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

export const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_API_KEY
);

8. Test everything with a tiny script

Create a file index.js with a minimal test, for example:

`import { openai } from "./config.js";

async function main() {
  const response = await openai.responses.create({
    model: "gpt-4.1-mini",
    input: "Say hello from my Node project.",
  });

  console.log(response.output[0].content[0].text);
}

main();`

This script sends a tiny test request to the OpenAI API so you can verify that your key and project setup works
Make sure you are in the project folder in your terminal and run:
- node index.js
If everything is set up correctly, you should see a short greeting printed in the terminal from the model.

9. Where you are now

At the end of Part 2, you have:

A Supabase project with the vector extension enabled
A safe place to copy your Supabase URL and anon key
An OpenAI API key with a small prepaid balance and no auto‑recharge required.
A Node project where node index.js can successfully call the OpenAI API.

In the next part, i.e. Part 3 of the series,, you can build on this by creating a documents table with a vector column in Supabase, generating embeddings with OpenAI, and storing them for semantic search

Until then,

Vector Databases (with OpenAI and Supabase) - Part 1

Shloka — Fri, 09 Jan 2026 22:11:02 +0000

It’s the early 2010s, Apple Music (iTunes) is strongly dominating the market. And services like Pandora, Rhapsody, and Last.fm are all fighting for user attention.

The music streaming space is already crowded, and competing with a tech giant like Apple seems almost impossible.

But then, a tiny European startup emerges.

In just five years, it goes from zero to tens of millions of users, eventually becoming the number one music streaming platform in the world.

Today, on the same platform, created by the European startup, when you click on shuffle, it recommends the exact beats you’re looking for, and you love it. Somehow, it just gets your taste.

And towards the end of every year, you receive a wrapped that tells you you’ve spent 60,000 minutes listening to music.

Yep. The “tiny European startup” is… Spotify!!!

But how did Spotify do that? How did it beat a tech giant?
How did it recommend music you didn’t even know you wanted?

Well, one of the secret sauces behind Spotify’s success is vector databases.

Now, before going into details about vector databases, though, I want to talk about relational databases. So that we know where we were and where we are at now.

Relational Database

I want you to think for a second about, how you would store the song APT by Bruno mars and Rose in a relational database?

Of course ,you would store the audio file itself, under the name apt.mp3., along with metadata such as the artist (Bruno Mars, Rose), the release date, the genre, and maybe a few tags like Pop, R&B, or Dance.

And how would you search for the song APT in the database? You would perform a lexical search. It might look something like this:

WHERE artist = 'Bruno Mars'

WHERE title ILIKE '%APT%'

This works fine, as long as you know exactly what you’re looking for.

BUT what if you want to search for “late-night city drive vibes” or “smooth, confident, feel-good energy”?

Your query will fail!

WHY?!

Because your database only understands hard-coded labels like Pop or R&B. It has no way of knowing that APT feels like a "feel-good energy" song.

Relational databases don’t understand similarity beyond what you explicitly define in columns, tags, or foreign keys.

This limitation is called the semantic gap.

So, how is this solved? Well, with the help of a vector embedings.

Vector Embeddings

Let’s start with an example.

Consider some popular the songs you may have come across on the radio or tik tok. Like, fate of ophelia, manchild, end of beginning, etc.

Now imagine plotting these songs on a graph based on two characteristics:

Danceability (x-axis)
Energy (y-axis)

After plotting them, each song gets a pair of numerical values, its position on the graph.

Song Title	Artist	Danceability (X)	Energy (Y)
The Fate of Ophelia	Taylor Swift	0.42	0.38
Golden	HUNTR/X feat. EJAE	0.81	0.76
Ordinary	Alex Warren	0.35	0.44
Manchild	Sabrina Carpenter	0.78	0.68
Luther	Kendrick Lamar & SZA	0.65	0.52
End of Beginning	Djo	0.68	0.45

So now, every song is represented as a pair of numbers i.e [danceability, energy]

For example:

Manchild → [0.78, 0.68]
Ordinary → [0.35, 0.44]

That pair of numbers is a vector and the process of converting a song, with something abstract like danceability and energy into numbers is called an embedding.

Putting it together

Embeddings are numerical representations of data
Vectors are those numbers organized into arrays (like [x, y], or even hundreds of dimensions)

So a vector embedding is simply:

Storing real-world data in the form of numbers, arranged as vectors, so that similar things end up close to each other in space.

In this space, songs with similar energy and danceability appear near each other, making it possible to recommend music based on "vibe", not just tags or keywords.

An important thing to note is though, in reality, Spotify doesn’t use just two dimensions like energy and danceability.

A real embedding might have hundreds or even thousands of dimensions, capturing tempo, rhythm patterns, vocal style, instrumentation, and more.

But the idea remains the same.

Creating Embedding

Whenever math is involved, I get a little scared

Plotting in 2D, is fine 3D is manageable but, thousands of dimensions?!! That’s where my brain is like "Oh hell no"

Thankfully, we don’t actually need to visualize or manually compute vectors. There are embedding models that do all the heavy lifting for us.

Some common embedding models are:

CLIP for Images (and image–text similarity)
GloVe for Text
Wav2Vec for Audio

Frameworks like Hugging Face provide many pre-trained embedding models for text, images, audio, and more.

But no matter the data type, the process remains the same:

Take your data (text, image, audio, etc.)
Pass it through an embedding model
Get back a vector embedding (an array of numbers)

Example: Text Embeddings with OpenAI

This code snippet, in JavaScript, from OpenAI converts text into a vector embedding.
(Don't get scared of it, we will get into the code in the next blog.)

You can use other languages as well.

Now, as you can see, the text “Your text string goes here” is converted into a vector with 1536 dimensions.

Remember, no matter how long or short your text is, the output vector always has the same fixed size of 1536.

Vector Databases

Once you’ve created vector embeddings, the next step is storing them in a vector database.

When data is stored as embeddings, similar vectors naturally form clusters in vector space. These clusters are then indexed. The process is known as vector indexing. Indexing allows the database to retrieve similar vectors quickly and efficiently, even as the dataset grows.

At a high level, a vector database does three things:

Store embeddings
Indexes them efficiently
Retrieves similar vectors with low latency

Vector embeddings are what makes semantic search, recommendations, and RAG systems possible.

All of this sounds good. But so far, everything we’ve discussed lives mostly in theory.

In the next blog, we’ll get hands-on and walk through:

Creating embeddings using OpenAI
Storing those embeddings in SupaBase
Querying the database to find similar results

And turn theory into code.

See you in the next blog. In the mean time

Credits:

Scrimba
IBM's video
LLMs for correcting the errors.

What the heck Is a Single-Page Application Anyway?

Shloka — Thu, 18 Dec 2025 22:02:35 +0000

When I first started learning React, every friend and every YouTube tutorial seemed to say the same damn thing:

"React is used to build Single-Page Applications (SPAs)!"

I'd always pretend I actually knew what a Single-Page Application was, because who wants to sound dumb, right? Honestly, it reminded me of when I'd say, "An object is an instance of a class" without really understanding what it meant. :')

I would like to tell you, dear reader, after some Reddit scrolling and LLM-ing (or as the common person says, "ChatGPT-ing"), I finally figured it out! And if you've ever been confused about Single-Page Applications or are just curious, I hope this little blurb helps clarify things.

But before we can really get to understanding what Single-Page Applications are, we need to take a detour and understand Multi-Page Applications (MPAs).

Multi-Page Applications (MPAs)

Let's pretend that "blahblahblah.com" (yes, I could not come up with a better name) is a traditional application.
Here's what will happen when you go to blahblahblah.com on your device/browser (the client):

1. When the page initially loads

When you first visit blahblahblah.com, your browser (the client) will send a request to blahblahblah.com's server for the homepage.

Once the server receives the request, it gets to work, gathers everything it needs, such as HTML, CSS, JavaScript, and maybe some data from databases or APIs. Once it's got everything ready, it bundles it up and sends a fully rendered homepage in the form of an HTML file back to your browser.

2. Navigating to Another Page

Now let's say you head to the About page of blahblahblah.com. Your browser will send another request to blahblahblah.com's server. The server repeats the same process, builds the About page from scratch (HTML, CSS, JS, data), and sends the resulting About page as an HTML file back to your browser.

When your browser receives the About page, it throws out the previous homepage and fully replaces it with the About page. Everything reloads from scratch.

3. Returning to Home Page

Now, when you navigate back to the homepage, the whole process repeats: another request, another page rebuild, another full reload in your browser.

Moreover, most pages like Home, About, and Contact share common elements like headers and footers, but the browser still reloads everything each time.

This constant back-and-forth, where the browser requests an entirely new HTML file from the server for every single "page" change , is the essence of Multi-Page Application (MPA) architecture.

The clearest sign you're dealing with an MPA is the brief flicker or white screen you see during navigation as the browser unloads the old page and loads the new one.

Now as you can tell there are some obvious flaws with MPA, such as:

Re-rendering the same shared content, repeatedly
Extra server requests
Increased load time and heavier server strain

So how are single page applications different? Well…

Single-Page Applications (SPAs)

Here's the Twist:

A Single-Page Application doesn't actually mean you're stuck with a never ending page. 😅

Instead, the whole starts pretty much with the same process as a multi-page application: you open your browser and head over to blahblahblah.com, and your browser asks the server for the site.

Now, here's the important part: remember how in multi-page applications, every time you went to a new page, your browser would send a new request to the server and the server would build the page on its end and send the whole thing back?

Well, in a Single-Page Application, on that very first request, the server hands over a single HTML file, along with the entire application bundle (the core JavaScript, CSS, and framework code like React).

This entire application framework loads into your browser, and from then on, when you "navigate" to a new section (like About or Contact), the JavaScript on the client-side simply intercepts the request and dynamically updates the view without a full page reload

Now, the browser isn't totally disconnected from the server, it still fetches just the right bits of data as needed. All of this adds up to fewer server requests, less repeated content, and smoother navigation for users.

And…. that's Single Page Applications architecture for you!

Now, despite all the cool stuff SPAs have to provide, I still have some lingering questions, for example, what if only part of the app was sent, or if super-frequently visited pages could be delivered separately to make things even faster? There's clearly plenty more to learn.
If you've wondered about SPAs and MPAs too, or just want to share your thoughts, feel free to reach out on X or LinkedIn. It's always good to swap ideas with others on this stuff.

xoxo! :)