DEV Community: Churchill Emmanuel

Two Weeks Stuck on Authentication: My Headless API Journey

Churchill Emmanuel — Tue, 18 Nov 2025 17:13:31 +0000

Turning my Laravel blog into a Headless CMS API sounded like a simple plan.
Until authentication humbled me.

I’ve been debugging this for over two weeks now, and each day feels like I’m peeling another layer of confusion off the code.

At first, I thought the issue was with tokens. Then middleware. Then Laravel itself.
But as usual, the real problem was somewhere between my assumptions and my logic.

1. The Setup That Started It All

I began with Laravel Sanctum for API authentication.
It looked straightforward at first:

// routes/api.php
Route::post('/login', [AuthController::class, 'login']);
Route::middleware('auth:sanctum')->get('/user', [AuthController::class, 'me']);

The login route worked perfectly — until it didn’t.
Some requests passed, others failed without reason.
At one point, valid tokens were being rejected.

Here’s the login method that caused most of the headaches:

public function login(Request $request)
{
    $request->validate([
        'email' => 'required|email',
        'password' => 'required'
    ]);

    if (!Auth::attempt($request->only('email', 'password'))) {
        return response()->json(['message' => 'Invalid credentials'], 401);
    }

    $user = Auth::user();
    $token = $user->createToken('api_token')->plainTextToken;

    return response()->json([
        'user' => $user,
        'token' => $token
    ]);
}

Looks fine, right?
Except, when I tested it repeatedly, Sanctum started throwing token mismatch errors or expiring tokens too early.

2. The Debugging Spiral

At first, I tried clearing caches.

php artisan config:clear
php artisan cache:clear
php artisan route:clear

That didn’t help.
Then I reinstalled Sanctum.
Still broken.

I even doubted my API routes.
But the actual problem turned out to be with how Sanctum handles SPA vs API tokens.
Sanctum was originally built for SPA authentication using session cookies, not pure token-based APIs.

Once I understood that, things started to click.

3. What Finally Worked

I switched to token-based authentication for full API separation.
In config/sanctum.php, I set:

'stateful' => [],

Then I ensured my frontend (still testing via Postman) sent the right headers:

Authorization: Bearer <token>
Accept: application/json

That single header fixed 60% of my issues.
The rest were logic errors — bad validation, expired tokens, missing guards.

4. Lessons Learned

Authentication bugs are not always framework issues. Sometimes it’s how you configured it.
Always test endpoints individually in Postman.
Read the docs again. Then again. Slowly.
Don’t overcomplicate things. Start simple, then layer up.

I haven’t even reached the Next.js frontend yet, but this phase taught me something more valuable than a working API:
Debugging is where developers grow.

It’s not about fixing errors.
It’s about learning to think like your system.

And if you can survive two weeks debugging Laravel auth, trust me — you’ll survive anything.

When Cloudflare Sneezes, the Internet Catches a Cold

Churchill Emmanuel — Tue, 18 Nov 2025 16:30:54 +0000

A breakdown of today’s outage, what it exposed, and why infrastructure still runs the world

Cloudflare went down today and the internet panicked.
Apps froze.
Websites refused to load.
Developers refreshed dashboards like their salaries depended on it.
And for a moment, the digital world felt strangely quiet.

It’s almost funny until you remember how true the meme is:
The entire internet sits on a few layers of infrastructure, and Cloudflare is one of the blocks holding everything together.

But this outage did something important.
It revealed how fragile our systems are, how dependent we’ve become on a handful of global providers, and how easy it is for the entire web to shake when one of them stumbles.

Let’s break this down in a practical way.

1. The Internet Is Not as Decentralized as We Think

Everyone likes to imagine the internet as a giant distributed mesh of computers spread all over the world.
The reality is far simpler and less glamorous.

A few companies carry a disproportionate amount of global traffic.
Cloudflare alone powers:
• DNS resolution
• CDN content delivery
• Security layers
• DDoS protection
• Edge compute
• Routing optimization (Argo)
• API protection
• Reverse proxy

When Cloudflare has issues, everything stacked above it shakes.

It’s not because “Cloudflare is too big.”
It is because they solved problems at a scale others avoided.

2. Today’s Outage Wasn’t About Blame

Cloudflare is one of the most reliable infrastructures on the planet.
Even the best systems fail.
Even the most replicated networks experience downtime.
Even the strongest engineering teams hit unexpected faults.

The real story isn’t “Cloudflare broke.”
The real story is what the outage exposed about everyone else.

When users get locked out, developers are reminded of something we forget during smooth days:
Your architecture is fragile if a single failure shuts everything down.

3. Lessons for Developers, Startups, and Businesses

A. Redundancy isn’t optional

If your DNS has no fallback, your service disappears during outages.
If your CDN is single-provider, your global users suffer.
If your API gateway has no backup route, your app becomes unusable.

Businesses think redundancy is expensive.
Downtime is far more expensive.

B. Understand every layer your app depends on

Too many developers know their framework but not their stack.
You must know:
• Where your DNS lives
• How your SSL is served
• Where your traffic is routed
• What caching layer sits in front
• Which provider affects which part of your app

When outages happen, ignorance multiplies panic.

C. Outages are learning opportunities

Every major outage globally has given birth to better architecture patterns:

• The AWS S3 outage led to multi-region replication becoming default.
• The Fastly outage pushed companies to adopt failover CDNs.
• Today’s Cloudflare outage will push more teams toward deeper resilience.

Outages teach what documentation alone cannot.

4. A Reality Check for the Internet

We depend on invisible infrastructure more than we realize.
No matter how strong your application is, it inherits the strengths and weaknesses of the layers below it.

Cloudflare’s outage didn’t “break the internet.”
It exposed how interconnected everything is.

And ironically, episodes like this are what make the internet stronger.
Engineers will fix code, patch systems, improve routing logic, reconfigure redundancy, and reinforce their stacks.

This is how the web matures.

Final Thoughts

Laugh at the memes, enjoy the jokes, and refresh Twitter for updates.
But remember the deeper message.

Infrastructure still runs the world.
A single platform going dark affects millions.
And the smartest teams are the ones that prepare for a day like this long before it happens.

Today was a reminder.
Tomorrow should be an adjustment.

What Keeps Me Coding When It Gets Tough

Churchill Emmanuel — Mon, 29 Sep 2025 12:48:03 +0000

Coding isn’t always glamorous.
In fact, some days, it feels like wrestling with invisible enemies. The bugs multiply, the deadlines breathe down your neck, and your confidence takes a hit with every error message on the screen.

So why do I keep going? Why not just give up when it gets hard?

For me, it comes down to a few things:

1. The thrill of the “aha!” moment

There’s nothing quite like it.
You’ve been staring at the same bug for hours — maybe even days — and then suddenly, it clicks. That one semicolon, that missing import, that overlooked logic… and boom, the code runs. That tiny victory is addictive. It’s proof that persistence pays off.

2. The joy of creation

Every project, no matter how small, is a chance to bring something new into the world. A simple script that automates a task. A blog site for a client. A portfolio that reflects who I am. Watching ideas turn into reality through lines of code is a satisfaction that keeps pulling me back.

3. Growth through struggle

Here’s a lesson coding taught me: frustration isn’t the end, it’s the process.
Every time I struggle, I’m not just learning syntax or frameworks — I’m learning patience, grit, and how to problem-solve under pressure. The real skill isn’t just writing code, it’s staying calm when things fall apart and figuring it out step by step.

4. Persistence over passion

We always hear “follow your passion.” But the truth is, some days passion isn’t enough. Some days, coding feels heavy. On those days, it’s persistence that saves me. Choosing to show up, even when I don’t feel like it. Choosing to learn, even when I feel stuck. That consistency builds resilience — and resilience is what creates long-term growth.

Coding isn’t always easy. But it’s worth it.
Because every time I push through the tough days, I come out sharper, stronger, and more confident in my ability to figure things out.

👉 Now I’ll ask you: *What keeps you going when the code fights back?

The Day I Got Interviewed by AI

Churchill Emmanuel — Mon, 22 Sep 2025 12:28:00 +0000

Some months ago, I had one of the most surreal experiences of my developer journey: I got interviewed by an AI.

Yes — a literal artificial intelligence. And not the chatbots we’re all used to. This was a full-blown AI interviewer, with a voice, feedback loop, and everything.

How It Started

Before the session began, I was sent a set of instructions:

Turn on my camera
Share my screen
Keep my mic on

Fair enough. The idea was to ensure there was no foul play.

Then it began.

A warm, female voice greeted me:

“Hello Churchill, how are you doing today?”

She even mentioned my name. I responded verbally — and just like that, the interview kicked off.

The Experience
As the minutes passed, I was genuinely impressed. She asked me questions, listened to my answers, and even gave feedback based on keywords and scenarios I mentioned. It didn’t feel robotic at all. It honestly felt like I was speaking to a real human being.

The flow was smooth. Natural. Almost too good to be true.

And then… Nigeria happened.

When the Internet Became the Villain

Out of nowhere, my ISP decided it was time to embarrass me. Suddenly, “Auntie AI” (as I nicknamed her) started glitching.

Sometimes she would cut me off, responding before I had even finished my sentence.

Other times, she would pause, then reply a whole 30 seconds after I was done speaking.

The conversation started breaking apart. And then she froze completely.

I just sat there, watching the timer tick down… 8 minutes left… 5 minutes left… until the meeting ended automatically.

Interview incomplete.

The Bigger Picture

That’s when it hit me: we are truly living in the age of AI evolution — but without proper infrastructure, countries like mine will always be playing catch-up.

Japan is already decades ahead of even the U.S. in infrastructure. Meanwhile, we’re here fighting ISPs that can barely keep a video call stable. If this gap remains, we won’t just be behind — we’ll be irrelevant in the global tech race.

Final Thoughts
The AI interview itself was brilliant — a taste of what the future of hiring could look like. But the experience also revealed something sobering: no matter how much talent you have, your environment and infrastructure can either amplify it or cripple it.

Until we invest in fixing our infrastructure, we’ll keep being spectators in a game where we should be players.

God help us. God bless Nigeria. 🇳🇬

👉 Have you ever had tech let you down at a crucial moment (especially in Nigeria)? I’d love to hear your story.

Why Every Dev Should Set Boundaries With Clients Early

Churchill Emmanuel — Fri, 19 Sep 2025 08:22:45 +0000

When I first started freelancing, I thought being “helpful” meant saying yes to everything.

“Yes, I can add that.”
“Yes, I’ll squeeze that in.”
“Yes, no problem.”

But every “yes” without boundaries turned out to be a silent no — no to my own time, no to my health, no to my focus.
And that’s how I learned the hard way: scope creep is real.

The Truth About Boundaries
A lot of devs, especially when we’re just starting out, fear that setting boundaries will scare clients away. We think if we speak up, they’ll run to the next freelancer who’s “more flexible.”

But here’s the reality I’ve discovered:

Boundaries don’t make you rigid — they make you reliable.
Clear agreements don’t push serious clients away — they attract them.
Saying “this will cost extra” isn’t being difficult — it’s being professional.

The clients who run when you set boundaries are the same ones who were going to drain you anyway.

My Guardrails Now
These days, I don’t start any project without three simple things:
✔️ A written agreement (even if it’s just a simple contract)
✔️ A clear scope — what’s included, what’s not
✔️ A plan for how extras will be handled (because there will always be extras)

This doesn’t just protect me; it actually makes the project smoother for the client. Everyone knows what to expect, and trust grows from that clarity.

A Note to Nigerian Developers
In our ecosystem (where clients sometimes expect magic for peanuts 🥲), it’s even more important to set these boundaries. Because if we don’t value our time, skills, and sanity, no one else will.
Boundaries aren’t walls. They’re guardrails. They keep both you and the client safe on the road to a successful project.

Final Word
To my fellow devs: set your boundaries early. Trust me, you’ll thank yourself later.
👉 What’s one boundary you wish you set earlier in your career? Drop it in the comments — maybe another dev will learn from your story.

How I Handled Scope Creep on a Client Project

Churchill Emmanuel — Mon, 15 Sep 2025 14:59:06 +0000

When I first started freelancing as a developer, I thought building a simple blog site in PHP would be a straightforward project.
Spoiler: it wasn’t.
What began as “just a blog” quickly turned into something else.
The client kept asking:
“Can we add this extra feature?”

“Just a small tweak here.”

“Maybe a dashboard too?”

Individually, none of these requests looked harmful. But together, they transformed a blog into something resembling a mini social network. And that’s when I had my first real encounter with scope creep.

What Went Wrong

The truth? The client wasn’t being malicious.
They didn’t realize how “small changes” add up in terms of development time, testing, and maintenance.
The mistake was mine.
I never:

Defined the scope clearly before starting.
Put the agreement in writing.
Set up a system for handling new requests.

Because of that, I found myself working longer hours, juggling new features I hadn’t priced for, and watching the project grow way beyond what I’d signed up for.

What I Learned

That project became one of my biggest teachers. It showed me that scope creep isn’t just about clients asking for more — it’s about the developer not setting boundaries.
Here are three lessons I carry with me to every project now:
Document everything. Before starting, outline exactly what the project includes (and what it doesn’t).

Add a clause for change requests. Extra features → extra cost. It’s not rude; it’s professional.

Communicate early and clearly. Don’t wait until you’re drowning to speak up. The moment a new request pops up, clarify how it affects the timeline and budget.

Why This Matters

Scope creep is one of those silent killers in software development. It can:

Destroy your timeline.
Burn you out.
Create tension between you and the client.

But it doesn’t have to. With clear communication and boundaries, projects run smoother, relationships stay intact, and both devs and clients leave happier.

Final Thoughts
That early PHP blog project was a wake-up call for me. Today, I don’t start any project without proper guardrails in place.

To fellow developers: learn this lesson early — your sanity will thank you.

To clients: when developers set boundaries, it’s not resistance. It’s a way to protect the project (and you) from spiraling out of control.
Because trust me: scope creep can drown you if you let it.

💬 Have you ever dealt with scope creep? How did you handle it?

The Art of Debugging

Churchill Emmanuel — Fri, 12 Sep 2025 12:22:36 +0000

Debugging is one of those things every developer dreads at first. You write your code, you’re confident it’ll run — and then boom: red errors, broken features, nothing works the way you expected.

For a long time, debugging felt like punishment to me. Hours spent staring at a blank screen, scrolling through endless error messages, wondering if I was even cut out for this path.

But somewhere along the line, I realized something: debugging is not just about fixing broken code.
It’s about training your mind to stay calm when everything seems to be falling apart.

Errors Have Stories

Every error I’ve encountered has had a story.
Sometimes it was as small as a missing semicolon.
Other times it was a deeper lesson: rushing through code, overlooking documentation, or simply stepping into a concept I didn’t yet understand.

Take this classic PHP example:

<?php
// What I thought would run
echo "Hello World  

// What I actually got: Parse error: syntax error, unexpected end of file
?>

One missing quotation mark broke the entire script.
Frustrating? Absolutely.
But also a reminder: slow down, read carefully, and respect the details.

Debugging as Growth

The more I debugged, the more I noticed something strange: I wasn’t just fixing code — I was fixing myself.

For example, in Laravel, I once chased down an error that said:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'userss' doesn't exist

I had written userss instead of users. Hours wasted… until I laughed at myself.
Now? I always double-check migrations and spelling before running queries.

These bugs taught me:

Patience when things don’t make sense right away.
Resilience when I hit the same wall repeatedly.
Humility in admitting I don’t have all the answers (yet).
And most importantly, that bugs aren’t failures — they’re signposts, pointing me to what I need to understand next.

From Punishment to Process

Today, debugging feels less like a punishment and more like a process of becoming.
It’s an art form: the art of turning chaos into clarity.

Every time I step into the debugging process, I’m not just solving a problem — I’m refining how I think, how I approach challenges, and how I adapt under pressure.

And honestly, that’s why I’ve grown to love it.

Because if you can survive debugging, you can survive almost anything.

✦ What about you? Do you see debugging as a chore, or has it taught you something deeper about yourself?

💡 I’m sharing my journey as a developer from Nigeria — the struggles, the wins, and the lessons learned along the way. If this resonates, stick around for more.