DEV Community: Thanos Korakas

React template: Tanstack Query

Thanos Korakas — Tue, 18 Nov 2025 17:05:06 +0000

Introduction

In my React template, I mentioned that Tanstack Query is one of my core libraries for handling HTTP requests and caching. In this post, I'll dive deeper into how I use it and why it's become an essential part of my development workflow.

Before Tanstack Query

Fetching data is a crucial part of any frontend application. I can't remember building a web app that didn't need to fetch and display data from the server.

I've tried GraphQL with Apollo and SWR, but nothing felt quite right until I discovered Tanstack Query. Before that, like most developers, I used React state (or Redux and other libraries) to handle server state.

Below is a simple example of fetching data using the fetch API and useEffect.

When the page renders for the first time, we fire a request, and when we get the data, we update the users state. React will then re-render to display the updated state.

const [users, setUsers] = useState([]);

useEffect(() => {
  fetch("https://jsonplaceholder.typicode.com/users")
    .then((res) => res.json())
    .then((data) => {
      setUsers(data);
    })
    .catch((err) => {
      console.error("Error fetching users:", err);
    });
}, []);

This seems simple but lacks important features like loading and error handling.

Adding these features makes the code more complex:

const [users, setUsers] = useState([]);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

useEffect(() => {
  fetch("https://jsonplaceholder.typicode.com/users")
      .then((res) => res.json())
      .then((data) => {
        setUsers(data);
      })
      .catch((err) => {
        console.error("Error fetching users:", err);
        setError(err);
      })
      .finally(() => {
        setLoading(false);
      })
}, []);

We could improve this by using useReducer to manage state, but it doesn't solve the fundamental challenges.

I've also tried building custom hooks to reuse this logic, but new problems arise. What if we need user data in multiple components? We might end up making the same request multiple times. Moving the query higher in the component tree and using React Context helps, but creates other issues: what if the query depends on component state? The entire app re-renders every time we fetch data since the Provider is typically at the top level.

And with Tanstack Query we can simply do:

const { data: user, isLoading, error } = useQuery({
  queryKey: 'users',
  queryFn: getUsersFn
  staleTime: 5000,
});

useQuery functions returns multiple properties like isLoading or error.

What I find more interesting though is the queryKey and stale time. Tanstack Query gives us out of the box caching.

Caching

Tanstack Query solves many of these problems: loading states, error handling, pagination, infinite queries, dependent queries, polling, and more. But what really clicked for me was caching.

With Tanstack Query, you specify how long data remains valid. After that period, it automatically refetches. Even better, if two components request the same data, the library makes only one request and provides the result to both components.

This works through cache keys.

const { data: user, isLoading } = useQuery({
  queryKey: ['users'], // cache keys
  queryFn: getCurrentUser,
  gcTime: Infinity,
  staleTime: Infinity,
});

In my React template, I use this approach for authentication. Instead of maintaining an isAuthenticated boolean in context or Zustand, I rely on caching. Each component that needs user data calls the useAuth hook, which makes an HTTP request to the /me endpoint. Since I cache indefinitely using staleTime: Infinity and gcTime: Infinity, it won't make another request until we invalidate the USER_QUERY_KEY cache.

When logging out, after calling the /logout endpoint, we clear the cache:

const clearUser = () => {
  queryClient.setQueryData(USER_QUERY_KEY, null);
  queryClient.removeQueries({ queryKey: USER_QUERY_KEY });
};

The PrivateRoute component uses the useAuth hook, so it automatically re-renders and navigates the user to login.

Similarly, I listen for 401 responses using a Ky hook and clear the user cache, which redirects the user to login:

const beforeErrorHook: BeforeErrorHook = async error => {
  if (error.response?.status !== 401) {
    return error;
  }
  const requestUrl = error.request?.url || '';
  const isAuthMeEndpoint = requestUrl.includes('/auth/me');

  if (isAuthMeEndpoint) {
    return error;
  }

  queryClient.setQueryData(USER_QUERY_KEY, null);
  queryClient.removeQueries({ queryKey: USER_QUERY_KEY });
  return error;
};

You can apply this pattern to any data that's used across the app but changes infrequently, like a list of countries for a dropdown. Cache it indefinitely, and it's available everywhere. When a user adds a new country, simply invalidate the cache after a successful response, and Tanstack Query will fetch the updated list including the newly created entry.

Using Tanstack Query helps separate server state from UI state, letting React focus on what it does best: managing the interface.

Tanstack Query is an incredibly powerful library with many more features. To learn more, I highly recommend this series by one of the core contributors.

React template: Introduction

Thanos Korakas — Mon, 17 Nov 2025 22:07:22 +0000

You can find the original post on my blog

The Problem

Lately I've found myself wanting to work on some side project ideas. Every time I had to implement the same stuff again and again: basic library configuration, routing, layout, forms, authentication. Most of the time I would start a project using Vite and copy-paste parts from other apps I'd worked on.

That alone could take a couple of hours or days without making any progress on my idea.

My Tech Stack

The things I usually need are simple. I like working with Tanstack Query for handling HTTP requests and caching. I implement authentication using sessions where an HTTP-only cookie is set by the backend, and on the frontend I make a request against a /me or /user endpoint to check if the user has a session. I set up some interceptors to log the user out on 401 requests. Finally, I like to wire basic input fields so I can build forms without having to care about error handling or wiring the field every time.

Here is a more detailed list of the libraries that I use:

React Router
Tanstack Query
React Hook Form
Zod
Ky (previously Axios)
Chakra UI

The Solution

It was time for my side project to be a React template to help me build my next ideas faster. I published the code on GitHub.

Project Architecture

In my project, I prefer separating files by logic/context rather than file type. So you won't find components and hooks folders in the project.

It follows a DDD-like approach where each feature goes into the features folder. Features are composed of a template file and a view model where I wire stuff like forms or HTTP requests.

src/
├── features/
│   ├── login/
│   │   ├── index.tsx
│   │   └── use-handler.ts
│   └── register/
│       ├── index.tsx
│       └── use-hander.ts
├── data-access/
│   ├── api.ts
│   └── users.schema.ts
└── commong/
    └── auth/

I keep features agnostic of storage or external dependencies by putting them in the data-access folder. So data-access describes and validates API requests using Ky and Zod.

Then in the view model, I use Tanstack Query to call the API and get a response.

In the past, I used to create custom hooks inside data-access so I didn't expose Tanstack Query into my features. Although this helped a lot with testing and keeping features agnostic of implementation details, it required a lot of boilerplate and honestly, I depend a lot on Tanstack Query for many things, so I decided to simplify the setup.

Mock Server

I also created a mock server to help me prototype fast without touching the backend yet. The mock server supports authentication using an HTTP-only cookie, MFA by printing an OTP to the console, and OAuth2 providers for login—currently it implements GitHub.

The mock server can read JSON files from the filesystem and use them as a database. It also supports all CRUD operations. That way I can build CRUD APIs fast to verify my ideas. Usually it helps me a lot to build a POC of the UI and improve it by using it, instead of spending more time designing and thinking about how it should work.

Future Plans

I plan to continue working on the template by adding support for more OAuth providers like Google and enhancing security by implementing XSRF and other best practices.

Further improvements include:

Support for HOTP/TOTP
More features regarding user management like profile management and password changes
Roles & permissions, perhaps payments
Helpers for handling tables by integrating Tanstack Table and custom helpers all wired with Chakra components

If you have any issues with the template, please create an issue or share any other ideas.

Thanks for reading.

Circuit breaker pattern in Laravel applications

Thanos Korakas — Mon, 20 Jul 2020 07:05:35 +0000

Let's start by framing the problem. A lot of applications make external requests to get or sent data. As we already know by the Fallacies of distributed computing
the network is not reliable and is one of those things that we can’t control in our applications. A failing network request happening repeatedly may drive your application to be unresponsive.

For example, you are building an application and you are using an external search service. Like we mentioned before the network is not our friend in this and one day the service starts having big delays or stops responding completely.

As you can easily understand, these are bad news for our application. Allowing an application to make requests in a situation like this will result in it underperforming or stop working entirely.

Circuit breaker pattern to the rescue

The circuit breaker is a design pattern used in modern software development. It is used to detect failures and encapsulates the logic of preventing a failure from constantly recurring, during maintenance, temporary external system failure or unexpected system difficulties. - Wikipedia

Circuit breaker is a pattern that prevents request execution against unresponsive services.

If you looking for more information on the topic I can highly recommend this article by Martin Fowler.

Laravel 7 ships with all the ingredients needed to build a circuit breaker:

An HTTP client
The RateLimiter (A good explanation https://medium.com/@DarkGhostHunter/laravel-there-is-a-rate-limiter-and-you-didnt-know-eb443b1bedc)

I’ll try to keep the code as simple as possible and focus more on the pattern itself to better explain the concept.

Before the circuit breaker pattern our application looked something like this:

$response = Http::get('https://fake-search-service.com/api/v1/search?q=Laravel');

return view('articles.index', ['articles' => $response->body()];

The HTTP client will wait for a couple of seconds before throwing an exception so it’s a good practice to always define timeout on our requests.

Laravel's client comes with a handy method to define the timeout of our request.

$response = Http::timeout(2)->get('https://fake-search-service.com/api/v1/search?q=Laravel');

return view('articles.index', ['articles' => $response->body()];

Ok, but we are still not preventing our service to make a request to the unresponsive API.

$limiter = app(RateLimiter::class);
$actionKey = 'search_service';
$threshold = 10;

try {
    if ($limiter->tooManyAttempts($actionKey, $threshold)) {
        // Exceeded the maximum number of failed attempts.
        return $this->failOrFallback();
    }
    $response = Http::timeout(2)->get('https://fake-search-service.com/api/v1/search?q=Laravel');

    return view('articles.index', ['articles' => $response->body()]);
} catch (\Exception $exception) {
    $limiter->hit($actionKey, Carbon::now()->addMinutes(15));

    return $this->failOrFallback();
}

Using Laravel's RateLimiter we can count the failed attempts performed to the search API $limiter->hit($actionKey, Carbon::now()->addMinutes(15)).

By counting those attempts we can prevent our application from making any more requests to this API for a certain amount of time.

Before every request, we check if there are too many failed attempts $limiter->tooManyAttempts($actionKey, $threshold) and if the failed attempts have passed our threshold we will prevent our service to request the search API for 15 minutes.

With the failOrFallback method we can provide a fallback implementation like search in the database instead of the external service or return an appropriate error message to the user.

Having a lot of requests waiting to be answered by the unresponsive service will slow down our application. Using the circuit breaker pattern we can prevent our whole application from going down. The search page is down but without affecting the performance of the other pages.

If we are building an application using the microservices architecture, we can use this pattern for our services as well.

Moreover, it would be good to use shared storage (like Redis) so all the services will have a common way to learn if another service is down without requesting N times. Using this pattern will help the unresponsive service to recover faster instead of adding more load on top.

Like I said this is a simplistic implementation of the circuit breaker pattern. You can implement it in a more sophisticated way and handle many things more appropriately.

If you have implemented this pattern in Laravel in a different way I would love to read it so feel free to leave your feedback.