Why You Should Replace useEffect API Calls With Tanstack React Query

hasnain alam — Sun, 13 Sep 2026 07:28:11 +0000

Every React dev has written this at least once.

useEffect(() => {
  fetchData();
}, []);

It works sure. But once your app gets a bit bigger this pattern starts causing problems, specially performance and backend load.

I'm a Mern stack developer and for a long time i just used useEffect for every single api call in my apps, until i actually tried Tanstack React Query properly. Now i barely write a raw useEffect for fetching data anymore.

Here is why i made the switch.

Your API Gets Called Twice (and its not a bug)

If you're using React 18 with StrictMode, you probably noticed your effects run twice in development. This is intentional, React does this to help catch side effect bugs. But it also means your api is getting hit 2 times on mount which confuses a lot of devs, and even in production if a component remounts often, useEffect fires again and again without any smart caching.

That means more load on your backend for no real reason.

React query fixes this because it caches by query key. If the data is already there and still "fresh" it wont refetch, it just returns the cached data instantly.

Boilerplate for Loading and Error States

With plain useEffect you end up writing this same block over and over.

const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

Do this for every single fetch in a medium size app and you got a lot of repeated code, plus more chances of bugs, like forgetting to reset loading in the catch block or not handling cleanup on unmount.

React Query gives you all this for free from the hook itself, isLoading, isError, data, error, done.

No More Dependency Array Guessing

Dependency arrays are one of the most confusing part of hooks for beginners and even experienced devs mess it up sometime. Missing a dependency causes stale data bugs. Adding too many causes unnecessary re renders and re fetching.

React Query removes this whole problem. You give it a query key and a fetch function, that's it. It manages refetching based on mount, focus, or your staleTime settings, not a manually managed array.

The Real Power: Cache, StaleTime and Invalidation

These are the 3 features that actually changed how i build react apps.

Cache: data fetched once is stored under its key, come back to same page and you instantly see data while it refreshes quietly in background if its stale.
staleTime: tells react query how long the data stays "fresh". Fresh data means no unnecessary refetch, which directly reduces backend calls.
invalidateQueries: after a mutation like updating or deleting something, you just invalidate the related query key and react query refetches it automatically. No manual syncing of state after mutations.

Once you use these together, most of the manual data fetching logic you used to write with useEffect just disappears.

A Project Where This Actually Mattered

I worked on a Next js SaaS platform recently where the dashboard was firing multiple api calls on every tab switch, all because of useEffect running on every mount. The backend was getting hammered with repeated requests and users noticed the slow loading.

After replacing useEffect with react query, adding staleTime, and using invalidateQueries for mutations, the whole dashboard felt way faster and the backend load dropped a lot. That project is live here if you want to see it, it was a Next.js SaaS Platform built for managing mineral owner contact data.

Is useEffect Useless Now

No, not at all. useEffect still has its place for things like subscriptions, event listeners, timers, syncing with non react code etc. Its just not the right tool for data fetching anymore, specially when a purpose built library like react query exists and handles it so much better.

Wrapping Up

As a Mern stack developer i learned this the hard way, after debugging way too many "why is my api getting called 3 times" issues that all came back to useEffect misuse. Switching to react query fixed most of it instantly, and gave me caching and invalidation on top, basically for free.

If you're building serious apps and want to reduce backend load while writing cleaner code, i'd say give react query a shot on your next project. As someone who works as a Full stack Mern & Next.js developer, this is one of those changes i recommend to almost every team i work with now.

I have covered some common issues with Tanstack here, Common React Query Issues, Query Key and Invalidate Queries Problems Explained, where i explained why invalidate queries sometime dont work and how to fix pagination, update and delete cases properly.

Let me know if you already use react query or still on useEffect, curious to hear what others think.

Surviving the iOS Push Notification Setup Process

hasnain alam — Thu, 23 Jul 2026 03:03:36 +0000

Why iOS is a different beast

To be real with you, setting up notifications on Android is like a walk in the park compared to iOS. Apple takes security seriously, which is great for users but a bit of a nightmare for us developers. You can't just drop a config file and call it a day. You have to deal with the Apple Developer Portal, certificates, and provisioning profiles. I've lost count of how many times a notification failed to deliver because of a mismatched Bundle ID or a missing capability in Xcode.

The magic of the P8 file

Back in the day, we used P12 certificates that expired every year. It was a mess. If you forgot to renew it, your app's notifications just stopped working one morning. Thankfully, we now have Authentication Keys (the .p8 file). It's way better because it doesn't expire and one key can work for all your apps. You upload this to your Firebase settings under the Cloud Messaging tab. But make sure you have your Team ID and Key ID ready. If you get those wrong, Firebase won't be able to talk to the Apple Push Notification service (APNs).

Xcode configurations you can't miss

Open your project in Xcode and go to the Signing & Capabilities tab. You need to add two specific things. First is Push Notifications. Second is Background Modes. Inside Background Modes, make sure you check Remote notifications. Without this, your app won't wake up to handle the incoming data when it's in the background. It's a small checkbox, but it's the difference between a working app and a broken one.

// Even if you have the token, you must register for remote notifications on iOS

import { useEffect } from 'react';

import { Platform } from 'react-native';

import messaging from '@react-native-firebase/messaging';

const usePushNotification = () => {


  useEffect(() => {


    if (Platform.OS === 'ios') {


      // This is crucial for iOS device registration


      messaging().registerDeviceForRemoteMessages();


    }


  }, []);


};

I've spent hours debugging iOS notifications only to realize I forgot to enable the capability in Xcode. It happens to the best of us. Take your time with the Developer Portal and double-check every string. Once you get that first 'Hello World' notification on an iPhone, you can breathe a sigh of relief. You've cleared the hardest part of the project.

Hasnain Alam, Full-Stack Developer

DEV Community: hasnain alam