DEV Community: Hidaya Vanessa

Consuming APIs from a Backend POV: Normalizing Data Across Multiple Endpoints

Hidaya Vanessa — Mon, 19 Jan 2026 14:06:22 +0000

How my bookstore project taught me that APIs don’t always tell the same story

I’ve been building an online bookstore called Hearthside Reads.
Nothing fancy just books, authors, and the metadata that makes a bookstore feel complete: ISBNs, descriptions, covers, the usual stuff.

Like most people, I didn’t want to manually enter all this data, so I did what made sense.

I turned to external APIs.

Where it all started

The first API I used was the Open Library API.

It worked… but not consistently.

Some books came back without ISBNs. Others had no descriptions. In some cases, the author data felt a bit off or incomplete.

At first, I thought:

“Maybe this is just how it is.”

But I wanted richer data, so I added a second source: Google Books API.

My thinking was simple:

If one API is missing something, the other one probably has it.

And that part was true.

What I didn’t anticipate was the new set of problems that came with it.

Where things started getting messy

Once I started consuming data from both APIs, I noticed a few things almost immediately:

The same book showed up more than once
Author names were formatted differently
ISBNs existed in one response but not the other
Descriptions didn’t always match

Same book.Different versions of the truth.

Here’s a simplified example.

Open Library response

{
  "title": "The Hobbit",
  "authors": [{ "name": "J.R.R. Tolkien" }],
  "isbn_10": ["0345339681"]
}

Google Books response

{
  "volumeInfo": {
    "title": "The Hobbit",
    "authors": ["J. R. R. Tolkien"],
    "industryIdentifiers": [
      { "type": "ISBN_13", "identifier": "9780345339683" }
    ]
  }
}

Both are correct. Both describe the same book But if you store this data as it comes, you’re asking for trouble.

The real problem (that took me a while to see)

The problem wasn’t Open Library and itcertainly wasn’t Google Books. The problem was me assuming external APIs would agree with each other.

They don’t.

Each API has its own structure, priorities, and idea of what “complete” data looks like. That’s when I ran into the concept that quietly fixed everything:Normalization.

So… what is normalization?

In the simplest terms:

Normalization is deciding what your data should look like, then forcing everything else to conform to it.

For non‑techies:

It’s cleaning and standardizing information before saving it
It’s making sure one book doesn’t end up with five slightly different identities

For techies:

It’s mapping external API responses into a single internal schema

Either way, the idea is the same:

One system. One structure. One source of truth.

Why normalization actually matters

Before normalization, I had:

Duplicate books in my database
Inconsistent author names
Unreliable ISBN lookups

After normalization:

One book = one record
Predictable fields
Much cleaner logic downstream

It’s one of those things that doesn’t feel exciting, but quietly saves you hours of debugging later.

Achieving Normailzation

Step one: Decide what a “book” means to you

Before touching any API logic, I had to answer a simple question:
"What does a book look like inside my system?"

Here’s the structure I settled on:

Book = {
    "title": str,
    "authors": list[str],
    "isbn_10": str | None,
    "isbn_13": str | None,
    "description": str | None
}

This became my reference point.

Anything coming from outside had to be reshaped to fit this.

Step two: Normalize each API separately

Instead of mixing logic, I treated each API independently.

Open Library normalization

def normalize_openlibrary(data):
    return {
        "title": data.get("title"),
        "authors": [a.get("name") for a in data.get("authors", [])],
        "isbn_10": data.get("isbn_10", [None])[0],
        "isbn_13": data.get("isbn_13", [None])[0],
        "description": data.get("description")
    }

Google Books normalization

def normalize_googlebooks(data):
    info = data.get("volumeInfo", {})

    isbn_10 = None
    isbn_13 = None

    for identifier in info.get("industryIdentifiers", []):
        if identifier["type"] == "ISBN_10":
            isbn_10 = identifier["identifier"]
        elif identifier["type"] == "ISBN_13":
            isbn_13 = identifier["identifier"]

    return {
        "title": info.get("title"),
        "authors": info.get("authors", []),
        "isbn_10": isbn_10,
        "isbn_13": isbn_13,
        "description": info.get("description")
    }

At this point, both APIs were finally speaking the same language.

Step three: merging without duplicating

Normalization gets your data into the same shape.Merging decides which data wins.

My rules were simple:

Prefer ISBN‑13 when available
Use Google Books as a fallback for missing descriptions

def merge_books(primary, fallback):
    return {
        "title": primary["title"] or fallback["title"],
        "authors": primary["authors"] or fallback["authors"],
        "isbn_10": primary["isbn_10"] or fallback["isbn_10"],
        "isbn_13": primary["isbn_13"] or fallback["isbn_13"],
        "description": primary["description"] or fallback["description"],
    }

Nothing fancy. Just clear rules.
The mental model that helped me was I started thinking of APIs as raw ingredients, normalization as the recipe and the database as the final dish.

If you skip the recipe, you still get food just not something you’d confidently serve.

What I took away from this

APIs don’t owe you consistency
More data sources = more responsibility
Normalization isn’t optional once you scale

Most importantly, I learned that backend work isn’t just about fetching data. It’s about deciding what truth looks like in your system and enforcing it.

If you’re consuming multiple APIs and things feel slightly off, normalization is probably the missing piece.

Happy building 🚀

AI Agents: More Than Chatbots, Less Than Sci-Fi

Hidaya Vanessa — Sun, 21 Dec 2025 15:35:04 +0000

When you hear AI agents, what comes to mind?

For many people, it’s sophisticated bots running around on their own, something straight out of a sci-fi movie. And while there is a tiny bit of truth in that, the reality is far less dramatic and far more useful.

At their core, AI agents are simply software systems that can think, decide, and act on their own with little to no human intervention.

Think of them as smart assistants, not robots.

Imagine telling your assistant:

"I need a weekly report."

Instead of just giving suggestions, the agent:

figures out what should go into the report,
gathers the relevant information,
compiles it,
and even emails it to your team lead.

That’s an AI agent in action.

Where Do We Draw the Line Between AI Agents and Chatbots?

This is where most confusion happens.

Chatbots

Chatbots are reactive.

They respond to prompts and guide you through tasks.

A chatbot can:

help you draft a report,
suggest improvements,
help write an email.

But you still do the execution copying, pasting, sending, deciding the next step.

AI Agents

AI agents go a step further.

They don’t just assist,they execute.

An AI agent can:

plan the steps needed to complete a task,
take actions on your behalf,
use tools,
and decide what to do next based on results.

Chatbots talk. AI agents act.

What Powers AI Agents? (Their “Superpowers”)

AI agents work because of a few key capabilities working together:

1. Memory

AI agents can remember past interactions, data, or outcomes.

This allows them to learn from previous tasks and improve over time.

2. Reasoning

They can break down complex tasks into smaller, logical steps.

Instead of being told every single action, they figure out how to get things done.

3. Tools & Actions

AI agents can use external tools, such as:

databases,
APIs,
browsers,
files,
calendars,
email systems.

This is what allows them to actually do things, not just suggest them.

4. Autonomy

Once given a goal, an AI agent can work independently:

no fatigue,
no boredom,
no constant prompting.

This autonomy is what separates agents from traditional automation.

So… What’s the Big Deal About AI Agents?

Here’s where it really clicks.

Illustration: Chatbot vs AI Agent in Real Life

Scenario: Scheduling a team meeting

With a chatbot:

You ask for help scheduling.
It suggests possible times.
You check calendars.
You send emails.
You follow up manually.

With an AI agent:

You say: "Schedule a team meeting for next week."
The agent:
- checks everyone’s availability,
- picks an optimal time,
- sends calendar invites,
- sends reminders,
- reschedules if conflicts appear.

You don’t manage the steps the agent does.

Why This Matters

AI agents can:

handle repetitive tasks (scheduling, reminders, follow-ups),
run automations (customer support, internal workflows),
monitor systems and trigger actions when something changes.

This frees humans to focus on:

creativity,
decision-making,
strategy,
and problem-solving.

Types of AI Agents

AI agents come in different forms depending on what they’re built to do:

Task Agents

Focus on a single job (e.g., sending reports, answering tickets).
Workflow Agents

Handle longer chains of steps and decisions.
Multi-Agent Systems

Multiple agents working together, each with a role, like a team.
Embedded Agents

Built directly into apps or systems to quietly assist in the background.

How AI Agents Actually Work (High-Level Flow)

You can think of an AI agent’s workflow like this:

Request
   │
Think
   │
Decide
   │
  Act
   │
Observe
   │
Improve

A request is made.
The agent reasons about the task.
It selects the right tools.
It performs actions.
It observes the results.
It adjusts if needed.

No sci-fi. Just structured decision-making.

Final Thought

AI agents aren’t here to replace humans or take over the world.

They’re here to handle the busy work: the repetitive, time-consuming tasks that slow teams down.

Think of them as reliable digital coworkers:

quiet, tireless, and surprisingly practical.

I Am Two Years in Tech and I'm Not Afraid to Admit That:

Hidaya Vanessa — Sat, 20 Dec 2025 22:37:40 +0000

1. I don’t have it all figured out

When I first started out, I thought that by now I’d have found my niche in tech. I imagined I’d be confidently calling myself a frontend expert or clearly walking one defined path.

Well that hasn’t happened yet and I’m learning to be okay with that.

What I’ve realized instead is that I’m someone who uses technology based on need. If a project requires data analysis, I’ll lean into data. If it needs automation, I’ll build it. If integrating LLMs makes sense, I’ll explore that too. Not because data or AI is my niche, but because the problem demanded certain tools and principles.

Maybe my path isn’t about narrowing down quickly. Maybe it’s about learning how to adapt, explore, and build what’s needed and letting clarity emerge with time.

2. I still Google syntax and concepts

A lot.

Mention something unfamiliar to me and I’m probably already opening a new tab to understand it better. I used to think that by now, things should just stick, that knowing how to code meant memorizing syntax and concepts.

What I’m slowly unlearning is this: good developers aren’t walking encyclopedias. They’re problem solvers.

Googling isn’t a weakness; it’s part of the workflow. It’s how things get built. Accepting this has helped me stop measuring my competence by how much I can recall, and start measuring it by how well I can figure things out.

3. There are moments impostor syndrome gets the best of me

Especially when I’m in rooms with people who sound more confident, move fast, and seem to know exactly what they’re doing.

Sometimes it shows up quietly in the form of a small voice asking if I really belong here. Other times it’s loud, convincing me I’m behind or just pretending. But I’ve started to notice something: impostor syndrome tends to show up when I care deeply, when I’m stretching myself, and when I’m stepping into spaces that challenge me.

And maybe that’s not a sign of inadequacy,maybe it’s a sign of growth.

How Am I Coping?

1. By surrounding myself with developers who’ve been where I am

Not people who pretend the journey was easy, but people who remember what it felt like to be confused, unsure, and still showing up.

Being in community has reminded me that many of the struggles I experience aren’t personal failures, rather they’re shared experiences. Seeing others a few steps ahead who once stood where I am gives me perspective, reassurance, and hope.

2. By putting myself in rooms that stretch me

Not to compare myself or shrink, but to listen, connect, and learn.

Truth be told, it’s uncomfortable sometimes. I don’t always feel like I have something impressive to say. But I’m learning that growth rarely happens in isolation or comfort. It happens when you stay in the room long enough to listen, ask questions, and allow yourself to be seen.

3. By doing things that scare me: like writing this post

This has been on my to-do list since January. Not because I didn’t have time, but because I was afraid of being perceived. Afraid of saying the wrong thing. Afraid of not sounding “ready.”

Publishing this feels like winning a battle against self

A small introduction

Hi there,

I’m Nessah, well it's Vanessa(but feel free to call me Nessah)
I'm just a techie navigating the uncharted waters of this industry.

Welcome to my tech journal.

It's not a highlight reel, but a record. A place to think out loud, document what I’m learning, and make sense of the work as it unfolds.

Here you’ll find technical notes, half-formed ideas, lessons that only make sense after you trip over them, and reflections from navigating an industry that moves fast and rarely waits for certainty.

Please be nice😊

How social media changes my life:My PLP Story

Hidaya Vanessa — Sat, 12 Jul 2025 04:49:22 +0000

I didn’t plan this.

One day, I was just scrolling through social media, doing what we all do, tapping, liking, minding my own business, when I stumbled on a post from Power Learn Project Africa (PLP). And boom, something in me lit up.

I don’t even remember the exact caption. All I know is that it spoke about tech, youth, community, and opportunity. Then I saw their hashtag: #MillionDevsForAfrica. That stuck.

I kept reading, and that’s when I discovered that PLP isn’t just about code. It’s about people. Real people. Young Africans. People like me. It’s a Pan-African organization giving youth access to technical skills, helping them build careers in software engineering, and even offering scholarships to make that happen. Tell me that’s not amazing?

But it wasn’t just the scholarship thing that got me. What really pulled me in was their vibe, their Coffee and Code sessions. Students meeting up to code, connect, and share ideas over a cup of coffee? I was sold. Like, why wasn’t this already happening at my university? Or in my city? Why wasn’t Eldoret part of this story?

And that’s when it hit me: Maybe I could bring it here.

So, I Applied
No hesitation, no overthinking. I saw they were looking for Campus Ambassadors and I knew this was it. A chance to bring something powerful to my university. A chance to create a space for students to grow together, to learn and code in the most real, chill, community-driven way.

Fast forward to now…
I Got the Role 😭
I’m officially a PLP Campus Ambassador!!

This isn’t just a title for me. It’s a responsibility. It’s a dream. I’m about to power up UoE and help create a community where devs don’t feel alone, where ideas are shared freely, where coffee and code are a lifestyle (yes, I’m serious 😅).

I want people to walk into our sessions and feel like they belong. Whether they’re just curious about tech or already knee-deep in code, this community is for all of us.

This Is Bigger Than Me
Honestly, this whole thing has reminded me that one small decision,even something as simple as reading a social media post, can change your life's course.

So if you're reading this and you’ve ever doubted if you can be a part of tech, if you’ve ever felt like opportunities aren’t made for you I’m here to tell you: they are.PLP believes in that. And now, so do I.

We’re building something in Eldoret. And it’s going to be beautiful.

Let’s go. #MillionDevsForAfrica #PLPAfrica #CoffeeAndCode #UoEPoweredUp