DEV Community: Al Zaki Ibra Ramadani

Real-World Next.js Performance: Moving Beyond standard useEffect and Fetching Hooks

Al Zaki Ibra Ramadani — Fri, 22 May 2026 08:44:25 +0000

Let’s be honest for a second. When we are first learning React or Next.js, we all do the exact same thing to get data onto a screen: we spin up a useEffect, drop a standard fetch() inside it, point it at an API endpoint, and throw the response into a local useState.

It feels like magic. It works on your local machine (localhost:3000), and your app looks perfect.

But then you push that app into the wild. Real users start clicking around on slow mobile networks, networks drop, users spam the refresh button, and suddenly your clean dashboard turns into a chaotic mess of layout shifts, infinite loading spinners, and redundant API calls that put unnecessary strain on your backend.

When I started transitioning from building simple hobby sites to shipping heavy, production-ready applications, I realized that how you manage data on the frontend is what separates a junior project from an enterprise-grade platform.

If you want to build web apps that feel instantaneous—even on a weak 3G connection—you have to move past basic fetching. Here is how I approached rewriting my frontend architecture to handle data like a pro.

The Silent Killer: Client-Side Fetching Waterfalls

One of the biggest performance bottlenecks on modern web apps is what developers call a fetching waterfall.

Imagine a dashboard with a sidebar, a user profile header, and a main content table. If every single one of those components relies on its own useEffect to fetch data, Component B might wait for Component A to finish loading before it even starts its own API call.

The result? A stuttering, frustrating user experience where elements pop in one by one.

To fix this in modern Next.js, I had to completely re-think my rendering strategies. Instead of forcing the user's browser to do all the heavy lifting after the page loads, I shifted the heavy data fetching to the server side using Server Components or leveraging Parallel Data Fetching.

By triggering multiple asynchronous requests simultaneously with Promise.all(), you cut down the total loading time to match only the slowest request, rather than stacking them up.

Smart Caching: Stop Pinging the Server for Everything

Another massive wake-up call came when looking at network logs. Why should a user re-download their entire profile information or a static list of options every single time they click back and forth between tabs?

This is where integrating tools like TanStack Query (React Query) or utilizing Next.js’s built-in fetch caching mechanism becomes non-negotiable.

By introducing proper cache validation strategies (like Stale-While-Revalidate), the frontend can instantly display data from the local cache the moment a user clicks a route, while silently fetching the latest updates in the background. If the data hasn't changed, the UI doesn't twitch. It feels instantaneous.

+-------------------------------------------------------------+
| User clicks a tab -> Shows cached data INSTANTLY |
| |
| Simultaneously -> Background sync checks for new updates |
+-------------------------------------------------------------+

This drastically improves the User Experience (UX) and saves a massive amount of bandwidth on your server infrastructure.

Defeating the "Janky" UI with Optimistic Updates

If you are building an interactive app—like a system where a user can toggle a status, save a bookmark, or check an item off a list—waiting for a server response before showing the visual change feels laggy.

If a user clicks "Like," and there’s a 500ms delay before the icon turns red, the app feels broken.

To solve this, I started implementing Optimistic Updates.

The concept is simple: when a user triggers an action, you assume the server call will succeed and update the frontend state immediately. If the server comes back with a success, great—everything matches. If the server fails (e.g., a network timeout), you gracefully roll back the UI state to what it was before and show a helpful error toast.

To the end user, your application feels like it's running locally at 120 frames per second, masking whatever latency is happening behind the scenes on the cloud.

The Takeaway: UX is an Engineering Challenge

As frontend and full-stack engineers, our job isn't just to look at UI design files and translate them into HTML and CSS. Our true value lies in managing the state of the application across an unpredictable internet.

When you optimize your data-fetching patterns, implement strict caching, and eliminate layout shifts, you aren't just making the code cleaner. You are directly impacting user retention, keeping conversion rates high, and keeping your server costs under control.

Don't just settle for code that "works." Build interfaces that feel alive, predictable, and incredibly fast.

What’s your go-to strategy for keeping your frontend snappy? Are you Team Server Components all the way, or do you heavily rely on client-side state managers? Let’s talk architecture in the comments below! ⚡

Want to see how this fast frontend hooks into a hyper-optimized backend? Keep an eye out for my next post where I talk about ditching Node.js entirely for Bun and ElysiaJS!

Code Meets Commerce: What Building Websites for Real Businesses Taught Me About Software Engineering

Al Zaki Ibra Ramadani — Fri, 22 May 2026 08:26:52 +0000

When you're learning to code, your focus is entirely on the technical stuff. You worry about clean code, component reusability, state management, and picking the coolest looking UI libraries. You live in a perfect bubble where the user always inputs the right data and the requirements never change.

Then, you get your first real-world freelance client.

And suddenly, that perfect bubble bursts.

A while ago, I took on a project to build a travel agency and rental website for Srikandi Trans Purwokerto and Sandita Rent Car. Up until that point, I had been working on structured school applications like an LMS. But stepping into the SME (Small and Medium-sized Enterprises) sector taught me that in the real world, coding is only half the battle.

Here is what building production websites for real businesses taught me about what it actually means to be a software engineer.

1. Clients Don't Care About Your Tech Stack (And That's Okay)

When I started the project, I was incredibly excited to use React.js, Next.js, and Tailwind CSS. I wanted to show off fast rendering speeds, server-side capabilities, and optimized build sizes.

But during my first meeting with the owner, I realized something crucial: They didn't care. They didn't know what React was, and they didn't care about Tailwind. What they cared about was simple:

"Will this help customers book our travel services easily?"
"Will it load fast on a cheap smartphone with a weak internet connection?"
"Will it rank on Google so people in Purwokerto can find us?"

This was a massive shift in mindset for me. As developers, we get obsessed with our tools. But for a business, technology is just a tool to solve a commercial problem. Your job isn't just to write code, it's to build a solution that drives business results.

2. The Power of UX Optimization over Over-Engineering

When building a commercial site, every second of loading time and every confusing button costs the business money. If a user gets confused trying to find the contact button or the fleet list, they will simply leave and go to a competitor.

Instead of over-engineering complex animations or features the client didn't ask for, I focused heavily on UI/UX optimization and site speed.

I spent hours ensuring the mobile responsiveness was flawless, because in the transport sector, almost 80% of your traffic comes from people browsing on their phones while on the move. I optimized images, removed heavy scripts, and streamlined the booking flow so a user could go from landing on the homepage to hitting the WhatsApp booking button in less than three clicks.

Seeing the conversion rates and user reach improve after the launch was infinitely more satisfying than just writing a clever piece of JavaScript.

3. Communication is a Hard Skill, Not a Soft Skill

People often call communication a "soft skill," as if it's optional. It's not. When working with freelance clients, clear communication is just as vital as writing bug-free code.

Local business owners know their industry inside out, but they might not know tech jargon. Part of my job as a developer was to play the role of a translator. Instead of saying, "We need to optimize asset delivery and configure DNS zone records for better propagation," I learned to say, "We are going to make the images load faster and make sure your domain name correctly points to our new server so customers can access it without issues."

Simplifying complex technical logic into clear, actionable business value saves time, prevents scope creep, and builds massive trust with your clients.

Final Thoughts

Freelancing while navigating my high school years at SMKN 1 Purbalingga and finishing up my internship has been a wild, exhausting ride. But nothing beats the experience of shipping real code that impacts a real business's bottom line.

If you're a junior developer looking to level up, stop just building fictional projects for your portfolio. Go out there and find a local business, a café, a laundry service, or a transport agency. Offer to fix their web presence. The technical challenges, the client meetings, and the pressure of pushing a commercial site live will teach you lessons no bootcamp or tutorial video ever could.

Have you ever built a project for a non-technical client? How did you handle the communication gap? Let's talk in the comments below!

If you want to check out the rest of my development work or collaborate on a project, feel free to visit my Portfolio or see what I'm breaking next on GitHub.

Cheers,
Ibra 🚀

From Code to Clusters: A High Schooler's Journey into the Wild World of Kubernetes

Al Zaki Ibra Ramadani — Sun, 17 May 2026 16:45:41 +0000

if you asked me what happens after running npm run build, I would have probably said: "Well, you just throw it on Netlify or Vercel and call it a day." And for most side projects, that's completely fine.

But during my recent web developer internship at PT Perwira Media Solusi, I was handed a reality check. I wasn't just there to build pretty user interfaces anymore. I was tasked to build an Automated Deployment Platform with auto-scaling capabilities for my capstone project.

The weapon of choice? Kubernetes (K8s) and Docker.
As a high school student who mostly spent his time writing React components and Laravel APIs, diving into container orchestration felt like being thrown into the deep ocean without a life jacket. Here is how I survived the learning curve and why I think every developer should understand a bit of DevOps.

The "But it works on my machine" Problem

Before jumping into Kubernetes, I had to master Docker. Up until then, I often faced the classic developer curse: code working perfectly on my laptop but breaking completely when deployed somewhere else.

Learning how to containerize applications using Dockerfiles was an eye-opener. Wrapping my apps, environment variables, and dependencies into isolated containers meant they would run anywhere exactly the same way. No more magic bugs.

But what happens when you have dozens of containers running at the same time? What if one crashes in the middle of the night? What if thousands of users suddenly hit the platform at once?
That's where the big boss comes in: Kubernetes🎉.

Wrestling with YAML Files and Clusters

I'm not going to sugarcoat it: learning Kubernetes feels like hitting a brick wall at first. The terminology alone is overwhelming-Pods, Deployments, Services, Ingress, ConfigMaps.

For weeks, my VS Code was just endless lines of YAML files. One wrong indentation or a misspelled tag, and the whole cluster would refuse to deploy. I lost count of how many times I stared at the terminal waiting for a pod to status Running, only to see CrashLoopBackOff staring back at me.

But the breakthrough came when I finally configured Horizontal Pod Autoscaling (HPA).

Seeing the system automatically spin up new pods when simulated traffic spiked, and then gracefully scale them down when the traffic subsided, felt like pure magic. I wasn't just building a website, I was building infrastructure that could breathe and adapt on its own.

Why Frontend and Full-Stack Devs Should Care About DevOps

You might be wondering, "Ibra, you're a Frontend/Full-stack guy, why are you wrestling with cloud infrastructure?"

Here is what this internship taught me: Understanding how your application is deployed makes you a 10x better developer.

Better Architecture: When you know how containers interact, you write cleaner REST APIs and manage your environment variables better.
Empathy for the Team: Knowing how painful deployment can be makes you a better collaborator. You don't just dump code on the operations team; you deliver a system that is actually deployable.
No Fear of Scaling: It removes the fear of production. You stop worrying about "what if the server crashes?" because you built a self-healing system that restarts itself.

Final Thoughts

If there is one thing I want you to take away from this post, it's this: Don't be afraid of the complex stuff. When I first saw the architecture diagram for a Kubernetes cluster, I thought, "There's no way an SVHS student can pull this off." But by breaking it down step-by-step, reading docs daily, and doing weekly presentations to my senior mentors, it became second nature.

The tech industry changes incredibly fast. Don't just stick to what's comfortable. Go break a production environment, read the error logs, and fix it. That's where the real learning happens.

Have you ever messed around with Docker or Kubernetes? What was your biggest "aha!" moment or your worst deployment nightmare? Let's chat in the comments!

If you want to see what else I'm building, feel free to drop by my Portfolio or check out my open-source chaos on GitHub.

Catch you in the next one!

Ibra 🚀

Beyond the Tutorials: How I Built Production-Ready Apps Before Graduating High School

Al Zaki Ibra Ramadani — Sun, 17 May 2026 16:22:54 +0000

Hey everyone i’m Al Zaki Ibra Ramadani, you can call me Ibra! 👋

If you look up "how to learn web development" today, you’ll get hit with a mountain of courses telling you to build a Todo app, a weather tracker, or a basic clone of Netflix. Don't get me wrong, those are great for learning syntax. But honestly? They get boring pretty fast.

I wanted to build things that real people actually use.

As a software engineering student at SMKN 1 Purbalingga, I decided to skip the safety net of basic tutorials and jump straight into the deep end. I want to share a bit about that journey, the chaos of deploying real apps, and why breaking things in production is the best way to grow.

Turning My School Into a Testing Ground

My first massive wake-up call came when I tackled a Learning Management System (LMS) for my school. Up until that point, I knew how to make things look pretty on the frontend. But an LMS is a completely different beast.

I chose React.js and Tailwind CSS for the frontend because I loved the speed and flexibility. But a real LMS needs to handle grades, daily teacher journals, quizzes, and strict security. That meant building a solid Laravel REST API and implementing Role-Based Access Control (RBAC) so students couldn’t casually wander into the teacher panels and tweak their scores (nice try, guys).

When we finally pushed it live and saw teachers and students actually using it for daily school operations, it was an unmatched feeling. That’s when it clicked for me: Code isn't just about logic; it's about making someone's day-to-day life easier.

Diving Into the Deep End: Kubernetes & DevOps

Just when I thought I was getting comfortable with Full-stack development, my internship at PT Perwira Media Solusi handed me a new challenge: DevOps and Container Orchestration. Suddenly, I wasn’t just writing code; I was looking at infrastructure. For my capstone project, I worked on building an automated deployment management platform using Kubernetes and Docker.

If you’ve ever messed around with Kubernetes, you know the learning curve looks like a brick wall. Managing clusters, configuring auto-scaling, and dealing with YAML files for hours can make you want to pull your hair out. But pushing past that discomfort taught me how modern software scales at an enterprise level.
What I’ve Learned So Far

Being a junior developer—especially while still finishing school—comes with a lot of imposter syndrome. You constantly feel like there’s too much to learn. But here are my two biggest takeaways so far:

Ship real things. Build a site for a local business, your school, or a friend. The bugs you encounter when real users hit your site will teach you 10x more than any tutorial ever could.
Don’t box yourself in. I love frontend (React & Next.js are my absolute favorites), but understanding the backend and how your app actually deploys makes you a much better collaborator and developer.

Why Am I Writing on Dev Community?

I’m starting this space to document my ongoing dev journey—the architectures I’m experimenting with, the deployment bugs I fix, and the random things I learn while building web apps. Expect raw dev logs, tutorials, and honest thoughts on modern web tech.

If you want to see what else I'm building, feel free to drop by my Portfolio or check out my open-source chaos on GitHub.

Until the next bug,

Ibra 🚀