DEV Community: Yogesh Kumar

5 Mistakes I Made While Building React and Next.js Applications

Yogesh Kumar — Mon, 16 Mar 2026 08:17:33 +0000

Hi everyone,

Over the past few years I’ve worked on several projects using React, React Native and more recently Next.js. While building real production applications, I made quite a few mistakes that taught me valuable lessons.

I wanted to share a few of them here. Maybe they can save someone else some debugging time.

1. Not thinking about project structure early

When starting a project, it's tempting to move fast and not worry too much about folder structure. I did this in a few projects.

Everything worked fine at the beginning, but as the codebase grew it became harder to maintain.

Files were scattered, components became large, and new developers struggled to understand the code.

Later we reorganized the project into clearer folders like:

components
hooks
services
utils

After that, navigating the project became much easier.

2. Fetching data the wrong way in Next.js

When I first started working with Next.js, I treated it like a normal React app and fetched most data on the client side.

But later I realized some pages loaded slower than necessary.

For pages that needed fast loading or SEO, fetching data on the server side worked much better.

Understanding when to use server-side data fetching versus client-side fetching made a big difference.

3. Ignoring caching for API calls

Another mistake I made earlier was not thinking about caching API requests.

In some applications the UI made the same API request multiple times, which slowed things down and increased server load.

After introducing TanStack Query (React Query) for API management, things improved a lot.

It handled caching, loading states, and retries in a much cleaner way.

4. Not paying attention to loading and error states

In early versions of some apps I built, the UI didn’t handle loading states very well.

Sometimes users would see blank screens while data was loading, which made the app feel broken.

Now I try to always think about:

loading indicators
skeleton UI
proper error messages

These small things make the app feel much more polished.

5. Spending too much time debugging the wrong thing

One thing I learned the hard way is that many bugs are actually simple configuration issues.

For example:

incorrect environment variables
wrong API URLs
missing headers

Now whenever something breaks, the first thing I check is the Network tab and request data before digging deeper into the code.

It saves a lot of time.

Final thoughts

Building production applications teaches you a lot more than tutorials.

Mistakes are part of the process, and every project improves your understanding of how to structure applications and solve problems.

I’m still learning and improving every day.

If you’ve worked on React or Next.js projects, I’d be interested to hear what mistakes taught you the most.

Thanks for reading.

Handling API Data in Next.js: Things I Learned While Working on Real Projects

Yogesh Kumar — Sun, 15 Mar 2026 07:11:46 +0000

Hi everyone,

Over the past few years I’ve mostly worked with React and React Native, but more recently I started working more with Next.js for web applications.

One area where I learned a lot was handling API data in production applications. In tutorials everything looks simple, but in real projects things become a bit more complicated.

I wanted to share a few things that helped me while working on Next.js applications that rely heavily on APIs.

1. Choosing the right data fetching approach

One thing that confused me at the beginning was when to fetch data on the server and when to fetch it on the client.

Next.js gives several options:

Server components
Client-side fetching
API routes
Static generation

At first I used client-side fetching for almost everything because it was similar to how I worked with React.

But later I realized that some pages worked much better when data was fetched on the server side, especially pages that needed fast loading and good SEO.

Now I usually think about these questions first:

Does the page need SEO?
Does the data change frequently?
Does the page require user interaction?

This helps decide the best approach.

2. Managing API calls properly

In a few projects we noticed that the UI was making too many API requests, especially when users navigated between pages.

This caused unnecessary loading states and sometimes slower performance.

To improve this, we started using TanStack Query (React Query) for managing API data.

This helped us with:

caching API responses
reducing duplicate requests
better handling of loading and error states

After introducing it, the application felt much smoother.

3. Handling loading states carefully

One mistake I made earlier was not thinking enough about loading states.

Sometimes the UI would look empty while waiting for API data, which made the application feel broken.

Now I usually:

show skeleton loaders
display clear loading indicators
handle errors gracefully

These small UI details improve the overall experience a lot.

4. Debugging API issues

One thing that always happens in real projects is unexpected API errors.

Sometimes the issue is in the frontend, sometimes in the backend, and sometimes it's just a configuration problem.

When debugging API issues I usually follow a simple process:

Check the Network tab in the browser
Verify request headers and payload
Test the API in Postman or curl
Check backend logs if possible

Many times the issue turns out to be something simple like a missing header or incorrect request body.

5. Environment variables and deployment

Another issue I ran into was APIs working locally but failing in production.

In many cases the problem was related to environment variables.

Now I always double-check:

.env.local
deployment environment variables
API base URLs

This avoids a lot of confusion during deployment.

Final thoughts

Working with Next.js in production taught me that handling API data properly is just as important as writing good UI code.

Frameworks make many things easier, but real-world applications always introduce small challenges that you only learn by experience.

I’m still learning better patterns for structuring applications and managing data efficiently.

If you’ve worked on Next.js projects, I’d be curious to hear what challenges you faced while handling APIs.

Thanks for reading.

Things I Learned While Integrating APIs in Next.js Projects

Yogesh Kumar — Sun, 15 Mar 2026 07:09:33 +0000

Hi everyone,

Over the last few months I worked on a few projects using Next.js with REST APIs. One thing I realized is that integrating APIs in real applications is very different from small demo projects.

There are many small issues that come up which you usually don't notice when learning Next.js for the first time.

I wanted to share a few things I learned while dealing with these situations.

1. CORS problems happen more often than expected

One issue I ran into multiple times was CORS errors when calling APIs.

Sometimes the API worked perfectly in Postman but failed in the browser.

At first it was confusing, but later I realized that the browser blocks requests if the backend doesn't allow the origin.

In some cases we solved this by updating backend headers, and in other cases we used Next.js API routes as a proxy.

That helped avoid the CORS issue completely.

2. Debugging API requests is easier with simple tools

While debugging API issues, I started using a few simple techniques:

checking the network tab carefully
logging request and response data
testing APIs separately in Postman

Many times the problem was actually small, like a missing header or incorrect request body.

These small checks saved a lot of time.

3. Handling loading and error states properly

When building real user interfaces, API calls don't always succeed.

Sometimes the request takes longer than expected or fails completely.

Using TanStack Query (React Query) helped a lot with this. It made handling loading states, caching, and retries much easier compared to writing custom logic every time.

4. Environment variables matter in production

Another thing I learned while deploying Next.js apps was the importance of environment variables.

Sometimes an API worked locally but failed in production because the environment variables were not configured correctly.

Now I always double-check .env files and deployment settings before debugging deeper issues.

Final thoughts

Working with Next.js in production applications taught me that most problems are not about the framework itself but about API integration, debugging, and handling real-world edge cases.

Each project teaches something new, and I'm still learning better ways to structure and debug applications.

If you have worked on Next.js projects and faced similar API issues, I would be interested to hear how you solved them.

Thanks for reading.

A Few Things I Learned While Working with Next.js in Real Projects

Yogesh Kumar — Sun, 15 Mar 2026 07:05:35 +0000

Hi everyone,
After working mostly with React projects, I recently spent more time working with Next.js in production applications. I liked many things about it, but I also learned a few lessons while building real features.

I thought I would share a few of them.

1. Folder structure becomes important very quickly
When a Next.js project is small, everything feels simple. But as the project grows, it can become messy if there is no clear structure.
In one project we had pages, components, hooks, and API logic mixed in many places.
Later we organized things better:

components
hooks
services
utilities

It made the code much easier to navigate for the team.

2. Server vs Client components can be confusing at first
One thing that confused me in the beginning was when to use server components and when to use client components.
Sometimes I accidentally used a hook in a server component and the build failed.
After some time I started following a simple rule:

Server components for data and layout
Client components for interactivity

That helped avoid many issues.

3. Data fetching strategy matters Next.js gives many ways to fetch data:

server-side
static
client-side

At first I used client-side fetching for many pages. Later I realized some pages worked better with server-side fetching for SEO and faster first load.
Choosing the right method really affects performance.

4. Performance improvements come almost for free

One thing I like about Next.js is that many optimizations are built-in.

For example:

automatic code splitting
image optimization
better routing These small things make a big difference in production apps.

Final thoughts

Working with Next.js feels very productive once you understand the basics and structure your project well.

I’m still learning new patterns, but overall it has been a great experience building real applications with it.

If you have worked with Next.js in production, I’d be interested to hear what challenges you faced.

Thanks for reading.

A Few Things I Learned While Working on Real React Projects

Yogesh Kumar — Fri, 13 Mar 2026 05:22:55 +0000

Hi everyone,
I have been working as a frontend developer for a few years now, mainly with React, React Native, Next.js and TypeScript. During this time I worked on different kinds of apps like mobile apps, dashboards and even an OTT platform.
I just wanted to share a few things I learned while working on real projects.

1.A messy codebase makes everything harder
In one of the projects I joined, the codebase had grown very quickly and there was no clear structure. Components were large and many things were mixed together.
Adding even a small feature sometimes took much longer than expected.
Later we started breaking components into smaller pieces and making them reusable. We also added better folder structure and TypeScript types. Things became much easier after that.

2.API handling affects performance a lot
In some mobile apps we noticed screens were loading slowly. After checking the code we realized the problem was not the UI but how APIs were being handled.
We started using TanStack Query (React Query) for better data fetching and caching. That helped reduce unnecessary API calls and the app felt much faster.

3.Communication with backend teams is really important
Sometimes frontend developers start building features without fully understanding the API responses. I have seen this cause a lot of rework.
Now I always try to discuss API structure with backend developers early. It saves a lot of time later.

Final thoughts
One thing I learned is that building production apps is very different from small demo projects.
Clean code structure, good communication and simple UI decisions make a big difference.

I’m still learning and improving every day. If you have faced similar challenges while working with React or React Native, I would love to hear your experience.
Thanks for reading.