DEV Community: Abdul Ahad Abeer

Edge Runtime and Edge Functions in Next.js — Explained the Easy Way

Abdul Ahad Abeer — Tue, 03 Feb 2026 18:24:28 +0000

Web Development is being evolved in every now and then. Every change brings some enhancement in performance and user experiences. The concept of Edge Computing is one of the most significant recent shifts. This post will demystify the Edge Runtime along with edge computing, explain its purpose, highlight its limitations, and discuss the recent developments in Next.js regarding Node.js support in Middleware.

What is Edge Computing?

Edge computing is a way of doing server computation that brings processing power, storage, and analysis closer to where the data is actually created or used, instead of sending everything to a far-away central server or big cloud data center.

Think of the internet/network like a big map:

The center = huge cloud data centers (AWS, Google Cloud, Azure) located in specific regions.
The edge = the "outer borders" closest to you — your phone, a local Wi-Fi router, a nearby cell tower, a small server in a store/factory, or points of presence (PoPs) of CDNs.

Edge computing moves some (or a lot) of the work to these outer/nearby locations → the "edge" of the network.

The "edge" refers to the outer parts of the network — places physically nearer to end-users (CDN points, cell towers, local devices, mini-servers in stores/factories, etc.).

Edge servers are the actual machines/hardware located at those edge locations that run the code/workloads. Edge reduces mainly the network travel time for both directions, plus often execution startup time.

Why bother? Because:

Things happen instantly (no waiting for round-trips) → perfect for self-driving cars that need to brake NOW, video games that feel smooth, or a doctor watching live surgery footage without lag.
You don't send tons of raw data back and forth → saves internet bandwidth and money.
It works even if the internet is spotty → the local part keeps running.
Sometimes it's more private → sensitive info doesn't travel far.

So yeah — cloud is the giant central kitchen, edge is lots of small smart kitchens everywhere near people and devices. That's why apps feel snappier, cars get safer, and factories run smoother in 2026 and beyond. Pretty cool, right?"

What is Edge Runtime?

The Edge Runtime is not the physical edge servers or the global network itself (that's the edge computing infrastructure provided by Vercel, Cloudflare, Fastly, etc.). Instead, it's a very specific, lightweight software runtime — basically a slim JavaScript execution engine — designed on purpose to run inside those edge locations.

Built on the same V8 engine (the super-fast JS engine inside Chrome and Node.js).
But stripped down to only Web Standard APIs (fetch, Request/Response, Streams, Web Crypto, etc.).
Runs in tiny isolated sandboxes called V8 Isolates — no full containers or VMs needed.
No access to full Node.js stuff like fs (filesystem), child_process, native modules that need OS access, or many older Node APIs.

Result: Extremely fast startup (cold starts often < 10 ms, sometimes ~1 ms), tiny memory footprint, secure by default, and perfect for running on hundreds of edge points worldwide without heavy overhead.

Edge Runtime = the lightweight "brain" that actually executes your JavaScript code at the edge locations.

What are Edge functions?

An edge function = any piece of server-side code that you tell Next.js/Vercel to run using the Edge Runtime (that lightweight, fast, global thing we talked about).

The most common and main way to create one in Next.js (especially in the modern App Router) is by writing a Route Handler and adding export const runtime = 'edge';. In practice, edge functions are usually Route Handlers running at the edge. But edge functions can also appear in other places (like Middleware in older setups).

Why "mainly" here? Because Route Handlers are the primary way to build custom server endpoints (like APIs) in Next.js App Router, and opting into 'edge' turns them into edge functions for low-latency global use.

// app/api/hello/route.ts
export const runtime = 'edge';  // ← makes this an edge function

export async function GET(request) {
  return Response.json({ message: "Hello from edge!" });
}

Server Components or Server Actions can sometimes opt into edge (with config), but it's uncommon and limited. Mostly, when people say "edge function" in Next.js/Vercel docs, they mean Route Handlers with runtime: 'edge'.

Why Route Handlers Are the "Main" Home for Edge Functions

Route Handlers are built exactly like tiny serverless APIs (GET/POST/etc.).
They use Web standards (Request, Response) — perfect match for the Edge Runtime's limits.
Vercel auto-deploys them globally at the edge when you choose 'edge'.
Great for fast, dynamic stuff: auth checks, geo-personalization, quick proxies, small APIs.

Conclusion

Edge computing moves computation closer to users on a global network of nearby servers, slashing latency and making apps feel instant worldwide.

In Next.js, the Edge Runtime is a lightweight JS engine that lets you run code at these edge locations. Add export const runtime = 'edge' to a Route Handler → it becomes an edge function, executing fast and locally for every visitor.

Trade-off: Speed & reach come with limits (Web APIs only, no heavy Node packages or file system). Use edge for latency-sensitive paths, stick with Node.js runtime for complex logic.

Cache Components and Partial Pre-Rendering (PPR) in Next.js 16

Abdul Ahad Abeer — Thu, 29 Jan 2026 00:51:56 +0000

Before diving into all the nitty-gritty stuffs of cache components and partial pre-rendering, I just want to let you know that these two concepts go hand-in-hand and that’s why you can’t skip PPR when you are learning cache components and the vice-versa.

The reason cache components and partial pre-rendering are such a big deal is that these concepts greatly improve the user experience and quality of a web app. The more elaborative answer would be this - the concept of Cache Components lets you mix static, cached, and dynamic content in a single route, giving you the speed of static sites with the flexibility of dynamic rendering.

Server-rendered applications typically force a choice between static pages (fast but stale) and dynamic pages (fresh but slow). Moving this work to the client trades server load for larger bundles and slower initial rendering. Cache Components eliminates these tradeoffs by prerendering routes into a static HTML shell that's immediately sent to the browser, with dynamic content updating the UI as it becomes ready. Don’t worry if you haven’t been able to grasp all the concepts yet. Let’s dive into more details.

Cache Components

Caching is a technique that stores frequently accessed data temporarily. Instead of fetching the same information repeatedly from the server, your website retrieves it from a faster storage location.This reduces loading times and improves performance.

Cache Components let you save parts of your website. This makes pages load faster for your visitors. It introduce a new suite of features that allow more explicit and flexible caching capabilities. At the core is the “use cache” directive, which enables developers to cache pages, components, and functions. This directive works with the compiler to automatically generate cache keys for each usage, streamlining the caching process and improving efficiency.

In earlier versions of the App Router, caching happened automatically without you having to do anything. With Cache Components, you now have to choose when and where to use caching — it doesn’t happen by default. By default, any dynamic code in your pages, layouts, or API routes runs every time someone visits your site. This gives developers more control.

How to enable cacheComponents

As it’s explained above that it gives more control to developer and it's an opt-in feature. By setting cacheComponents flags to true in your Next config file, you enable the feature.

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  cacheComponents: true,
}

export default nextConfig

When cacheComponents is enabled, the following cache functions and configurations are available:

The use cache directive
The cacheLife function in conjunction with use cache
The cacheTag function

`use cache` Directive

This can be applied at the function, page, or component level — either at the top of the file or directly inline above a specific component or function.

// File level
'use cache'

export default async function Page() {
  // ...
}

// Component level
export async function DemoComponent() {
  'use cache'
  return <></>
}

// Function level
export async function getDemoData() {
  'use cache'
  const data = await fetch('/api/data')
  return data
}

By default, when you use 'use cache', it follows a "standard profile" — a set of built-in rules for how long to keep that saved data and when to update it. These rules are called "revalidation settings." Revalidation just means "checking and refreshing the data to make sure it's not too old."

The Default Revalidation Settings (Standard Profile):

Stale: 5 minutes (on the client side)

When you fetch data from the server, the browser caches the data right away and shows it to the user (the browser). From that very moment to the next 5 minutes, every time user tries to get the data it comes from the cache, not the server. Right after the 5 minute period ends, Next.js marks the cached data as "stale" (a bit outdated, like yesterday's news). But it doesn’t erase the data right away.

At any time after the 5 minute period the user makes a fetch request, the browser shows the old data (which is cached, not erased) to the user and triggers the fetch request to happen in the background quietly. If the new data is different, the page updates smoothly without the user noticing a delay — the old data on the screen gets swapped with the new one without refreshing/reloading the web page. This is great for quick loads while still staying mostly up-to-date.
Revalidate: 15 minutes (on the server side)

It's similar to the client-side stale 5 minutes, but with a few key differences in timing, sharing, and what happens with many users. This is like the big shared fridge (the server's Data Cache or Full Route Cache). One copy for everyone. The 15-min timer applies to this shared cache.

First time someone makes a request to the server, it does the real work (fetch DB, calculate, etc.), saves the fresh result in its shared cache, and sends it to the user. From that moment to the next 15 minutes, the server serves the cached data to all the users. After the 15 minute period ends, the server marks the shared cache as "stale" (old, needs checking) but no background fetch starts on its own right away.

The first request (the ‘Ring bell’ request) after the 15 minute period triggers the recalculation (the task), but it doesn’t wait for the re-calculation to end, rather it sends the old data (so that the speed seems quite fast). Meanwhile, the re-calculation goes on. Now if 10 or whatever the number of users request before the action finishes, all of them get the old data. Once the background calculation finishes, Server overwrites the shared cache with the new fresh data. From that moment on, every subsequent request (even from the same second batch) gets the new data instantly — no loading, no stale.
Expire: No time-based expiration (It's server-side only)

What happens when you don’t specify expire? The server-side cache entry lives indefinitely (forever) as long as the app runs. It only gets updated (replaced) when someone requests after the revalidate time (15 min default) → stale-while-revalidate kicks in, background refresh happens, new data overwrites old. If literally no one ever visits that cached item again? It stays in the server's cache forever (or until server restart, deployment, or manual invalidation like revalidateTag). No auto-delete.

What happens with expire specified? If no requests arrive for longer than the expire time (from the last real access/refresh), the server deletes the cache entry completely ("vanishes" it). Next request after that? No old data available → server does a full fresh calculation (synchronous—might show loading/fallback if slow). Once done, new data is cached, and timers reset (revalidate and expire start counting from now).

Expire is basically a "if forgotten for too long, erase it" rule to prevent very stale or unused data from cluttering server memory.
When used at file level, all function exports must be async functions.

If you put 'use cache' right at the top of a whole file (not just inside one function), it applies to every function you export from that file (like sharing tools with other parts of your app). But there's a catch: All those functions must be "async" (they use async and await to handle slow tasks like fetching from a database). Why? Because caching only makes sense for things that take time—quick, simple stuff doesn't need saving. If a function isn't async, Next.js will complain with an error.

`cacheLife` Function

The cacheLife function lets you decide how long you want to keep saved results for a function or component. You use it together with the “use cache” directive, and you put it inside the function or component you want to control. Without 'use cache', cacheLife has no effect—it's ignored.

Think of cacheLife as the remote control for the three timers we talked about earlier: stale, revalidate, and expire. By default, 'use cache' uses a built-in "standard" profile with stale=5 min (client), revalidate=15 min (server), and no expire. cacheLife lets you override those defaults with your own numbers or simple names.

Then, in your code:

// Inside an async function or component
'use cache'  // This turns caching on
import { cacheLife } from 'next/cache';

async function getBlogPosts() {
  cacheLife('days');  // Simple way: use a preset name
  // or
  cacheLife({ stale: 3600, revalidate: 7200, expire: 86400 });  // Custom seconds

  const posts = await fetch('/api/posts');  // or DB query, etc.
  return posts.json();
}

Custom Object (full control)

cacheLife({
  stale: 3600,      // seconds until client sees it as "old" (1 hour)
  revalidate: 7200, // seconds until server starts background refresh (2 hours)
  expire: 86400     // seconds until cache is deleted if no visits (1 day)
});

All values in seconds.
You can mix: short stale for fast client updates, longer revalidate for server savings.

Next.js has built-in cache profiles to help you manage how your website stores and updates data. The built-in profiles like "seconds", "minutes", "hours", "days", "weeks", and sometimes "max" (mentioned in some docs/PRs) are pre-defined shortcut sets of the same three timers mentioned earlier:

stale → client-side "how long before this feels old"
revalidate → server-side "when to start background refresh"
expire → server-side "when to delete if untouched for too long"

They just save you from writing seconds manually. Next.js picks reasonable values based on the name of the preset, so you can say "days" instead of calculating 60*60*24.

Choose a profile based on how often your data changes:

seconds — For data that changes constantly (like live scores)
minutes — For data that updates often (like news feeds)
hours — For data that updates a few times a day (like product stock)
days — For data that updates daily (like blog posts)
weeks — For data that updates weekly (like newsletters)
max — For data that rarely changes (like legal info)

8f.png align="center")

Quick Examples

'use cache'
import { cacheLife } from 'next/cache'

async function getWeather() {
  cacheLife('minutes')   // → stale 5 min (client), revalidate 1 min (server), expire 1 hour (server)
  return fetchWeatherAPI()
}

Must-Known Facts

If you use cacheLife, put it inside the function whose results you want to cache, even if you added the use cache directive at the top of your file.

You should only run cacheLife once each time your function runs. If your function has different paths (like if/else), you can call cacheLife in those branches but make sure only one gets used each time.

For example the following is correct as it calls once in every function call:

'use cache'

async function getUserData(userId: string, isPremium: boolean) {
  if (isPremium) {
    cacheLife('hours');           // Only this branch runs → one call
    // fetch premium features, longer cache ok
    return fetchPremiumStuff(userId);
  } else {
    cacheLife('minutes');         // Only this branch runs → one call
    // free users get shorter cache
    return fetchBasicStuff(userId);
  }
}

→ Perfect. No matter which if branch executes, exactly one cacheLife runs.

→ Next.js gets a clear single rule for that execution.

Not Allowed / Problematic (multiple calls in same run):

'use cache'

async function getUserData(userId: string) {
  cacheLife('days');               // First call

  const data = await db.user.find(userId);

  if (data.isSpecial) {
    cacheLife('minutes');          // Second call — now two calls happened!
    // ...
  }

  return data;
}

→ Bad. If isSpecial is true → two cacheLife calls in one function run.

→ Next.js might ignore the second, use the first, crash, or do something random → unpredictable cache behavior (e.g. wrong lifetime applied).

`cacheTag` Function

The cacheTag function lets you label saved data so you can easily clear or refresh certain parts of your cache whenever you want. By adding tags, you can update or remove specific cached items without touching the rest.

It's the on-demand invalidation tool — the opposite of time-based timers like cacheLife. While cacheLife says "wait X minutes then refresh automatically", cacheTag says "only refresh when I tell you to, and only for this specific thing".

You use it inside code that's already marked with 'use cache' (or in fetch with next.tags), just like cacheLife. It's especially useful for data that changes because of user actions (e.g., adding a product to cart, editing a blog post, uploading a photo) — you can instantly tell Next.js "this is outdated now".

// app/products/page.tsx or lib/getProducts.ts
'use cache'

import { cacheTag } from 'next/cache'

async function getProducts() {
  cacheTag('products')          // ← Attach the label "products" to this cache entry
  // You can add multiple: cacheTag('products', 'featured', 'category-electronics')

  const products = await db.products.findMany()
  return products
}

Now the cache entry for getProducts() is tagged "products".

To invalidate (refresh) it later — usually in a Server Action after a mutation:

// app/actions.ts
'use server'

import { revalidateTag } from 'next/cache'

export async function addProduct(formData: FormData) {
  // Save new product to DB...
  await db.products.create({ ... })

  revalidateTag('products')     // ← "Hey Next.js, anything tagged 'products' is now invalid!"
}

What happens after revalidateTag('products')?

The cache entry tagged "products" gets marked as invalid/stale.
Next time someone visits a page that uses getProducts():
- It serves the old (stale) data instantly (fast UX).
- In the background, it re-runs the function → fetches fresh products → updates the cache.
- Future requests get the new data.

Key Points & Behaviors

Multiple tags possible:
```
cacheTag('products', `product-${newProductId}`, 'admin-dashboard')
```
→ You can invalidate any one of them later (e.g., revalidateTag('product-123') only affects that single product).
Tags are per-cache-entry:
- If two different functions both tag "products", invalidating it affects both.

Works with fetch too (alternative to cacheTag):

'use cache'
const res = await fetch('/api/products', {
  next: { tags: ['products'] }   // Same as cacheTag('products')
})

Partial Pre-Rendering

For years, web developers have been forced to make a difficult, you either choose Static Site Generation (SSG) for blazing-fast initial loads at the cost of stale data, or Server-Side Rendering (SSR) for real-time data at the cost of slower Time to First Byte (TTFB). There was rarely a middle ground. Next.js 16 effectively ends this debate with the stabilization of Partial Prerendering (PPR).

The Binary Choice Problem

Before Next.js 16, the rendering decision was often an "all-or-nothing" waterfall. If a single component on your page required dynamic data at request time—for example, a personalized "Welcome, [User]" message in the header or a real-time stock ticker—the entire route had to switch to dynamic rendering.

This meant that even your static footer, logo, navigation links, and marketing copy—elements that never change between users—had to be regenerated on the server for every single request. This unnecessary CPU overhead increased latency for the user and server costs for you.

The Concept of Partial Prerendering

Imagine your page has parts that don’t change (like a header or layout) and parts that do based on an API request to the server (like user data). Next.Js will first send a static shell with the parts it can cache, so the page shows up quickly.

any dynamic sections you wrap in React <Suspense> will load after those placeholders are initially blank or show a fallback UI, then stream in with real data when ready. in other words, “the server sends a static shell containing cached content, ensuring a fast initial load” and “dynamic sections wrapped in Suspense stream in parallel as they become ready”. Those dynamic sections are often called ‘dynamic holes’. This means users see the basic page immediately, and then the dynamic data fills in smoothly.

Suspense Boundary ( React )

Suspense is the key mechanism behind PPR. React <Suspense> helps Next.js know where the dynamic gaps are. You must wrap any code that fetches data at request time (APIs, database calls, cookies(), etc.) in a <Suspense> boundary. If you don’t, Next.js will block the whole page until that data loads, which feels slow. When wrapped, the fallback UI shows instantly, and the real data replaces it later. The docs say wrapping a component in <Suspense> doesn’t make it dynamic by itself your data-fetching does but Suspense “acts as a boundary that enables streaming.

Enabling the Feature

Before using Partial Prerendering, you need to enable the new Cache Components architecture in your configuration. In Next.js 16, this single flag unlocks both PPR and the new caching directives.

// next.config.ts
mport type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true, // Enables Partial Prerendering & Cache Components
};

export default nextConfig;

How This Looks in Practice

An async Server Component consumes that data and is placed inside a Suspense boundary, while the rest of the layout remains fully static.

import { Suspense } from 'react';
import SlowData from '@/components/SlowData';
import Skeleton from '@/components/Skeleton';

export default function PPRPage() {
  return (
    <div>
      <h1>Partial Prerendering Demo</h1>
      <p>This header loads instantly as part of the static shell</p>

      {/* Suspense boundary separates static from dynamic */}
      <Suspense fallback={<Skeleton />}>
        <SlowData />
      </Suspense>
    </div>
  );
}

When the page loads, the prerendered shell is available immediately. The header and descriptive text appear without waiting for any backend work, since they do not rely on request-time data. The dynamic section enters a pending state, and a lightweight skeleton placeholder occupies the space where the final content will appear.

Last Words

As we wrap up this blog post, I hope you now understand how cache components, their directives and partial pre-rendering work, where to use them in real-life projects, and how to choose the right tool for your needs.

Everything you need to know on JWT Authentication

Abdul Ahad Abeer — Thu, 11 Dec 2025 15:15:34 +0000

Before directly jumping into the topic of this post, lets understand how authentication is usually classified. So, authentication can be classified in two kinds - stateful and stateless.

Stateful Authentication

This picture explains how a normal process of getting logged in and authorized data fetching happens.

You login with username and password. If all the credentials match, it creates a session and stores the session id in the database or memory. Then, the session is sent to the browser and the browser saves it as a cookie. Now you are logged in. Now if you fetch any data the server verifies the session before delivering the asked data.

When the server must store information about each logged-in user, this approach is called stateful authentication.

With stateful authentication, the server keeps a session for every user. So if thousands of users are logged in, the server must maintain thousands of active sessions at the same time. If the server stops storing a user’s session, that user would effectively be logged out.

At smaller scales this is fine, but at large scale it becomes challenging. The server needs extra memory or a shared session store (like Redis) to keep track of all user sessions across multiple servers. Managing all these sessions adds complexity and can create performance bottlenecks when many users are logged in simultaneously.

Problems with Storing Server-Side Sessions

Stateful authentication comes with a set of architectural challenges that grow more apparent as an application scales. Some of the key issues include:

1. Sessions vanish when the server restarts: In traditional session-based systems, session data often lives in memory (RAM). This means a simple server restart, whether due to deployment, a crash, or scaling event, it immediately clears all the active sessions. Users who were previously logged in suddenly get logged out. To avoid this inconvenience, teams must introduce persistent stores like Redis or databases, which adds operational overhead and cost.

2. Sticky-session requirements complicate scaling: When a server stores a user’s session data locally, the load balancer (a system that distributes incoming traffic across multiple servers) must always send that user to the same server - this is called a sticky session. It works, but creates problems: if that server crashes, the user’s session is lost, and if traffic isn’t evenly spread, some servers get overloaded. In modern systems, this limits scalability and flexibility.

3. Managing a large session store becomes a burden: As user count grows, so does the volume of session data. Servers must continuously store, update, expire, and clean up thousands or millions of active sessions. This demands robust storage systems, efficient eviction policies, and careful monitoring.

Stateful Authentication requires in-memory cache which is expensive and risky sometimes because of data wiping out issue. Stateless auth is the solution for this problem.

Stateless Authentication

In this case, you login with email/username and password. If your credentials match, server creates a token called ‘jwt’. This token is digitally signed with a secret cryptography key. Then this token can be saved as a cookie or in local storage. Now at this stage, the logged-in state has been created.

Then whenever a request comes to the server, it verifies the token by the crypto key first and then provides the requested data. Mainly it checks expiry date and if the signature isn’t changed.

Unlike stateful auth, stateless doesn’t require to store the token in the server. So, it becomes game-changer in many cases as there is no need to maintain another server or a big chunk of data. Even in horizontal scaling, we just need to put the token in all the horizontal servers.

Dissect JWT

JSON Web Token is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JON object.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

any jwt token contains 3 parts - header, payload and signature.

The header contains 2 things - type which is jwt and the algorithm it uses for create the signature.

{
  "alg": "HS256",
  "typ": "JWT"
}

Here it says the type of this token is ‘jwt’, the algorithm ‘HS256’ is used to sign and verify the the signature with the key given in the server. There are other algorithms as well.

The second part ‘white’ part contains payload.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022,
  "exp": 1516259022
}

The payload consists of claims—key-value pairs that convey information about the token or the subject (e.g., a user).

sub, iat and exp are registered claims. But name and admin are private claims that user put in.

How signature is created?

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

In HMAC SHA256 algorithm, the signature will be created by HMACSHA256 function:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

When the signature gets created, it depends on the header and payload. so if someone deliberately changes the payload, eventually it will change the signature.

But there is a catch. if someone steals the whole token and uses in some other machine/browser, then you can get into trouble.

One solution could be setting a minimum expiry duration. But this wont’ be viable in most cases. because most of the time you can’t bother the user login again and again in a very short time. So, in this case → you set the access token’s expiry duration short with a refresh token. This way, the moment access token gets expired and server sends 401 status code, it requests server to create a new access token with the help of refresh token. then the user gets logged-in again. All of these things happen behind the scenes without the user getting to realize.

What if the refresh token gets stolen? In the situation of refresh token getting compromised, developer can programmatically logout the user. This way the refresh token gets removed. This way no one cannot use refresh token to get a new access token. We can get one step ahead and increase the security level by something called ‘Token Rotation’. Token rotation is like when a new access token gets created by the help of refresh token, it generates a new refresh token.

There is something to remember - there is no bullet-proof method for authentication. You can just increase the level of security.

How to create JWT Authentication

Access Token: API sends and receives access token as JSON data. To avoid security risks like XSS or CSRF attack, it is recommended to store the access-token in the memory instead of local storage or cookie.

Essentially if you store the access token somewhere in the browser with javascript, the hacker can retrieve it with javascript. It is recommended to keep it in the memory, so that they automatically be lost when the app is closed. Memory can also be referred as current application state.

Refresh Token: Our API will issue Refresh token as httpOnly cookie. This type of cookie is not accessible with javascript. Refresh tokens do need to have expiration, which will require the user login again. Refresh token should not have the ability to issue a new refresh token, because this grants indefinite access if a refresh token falls into wrong hands.

Code - Project-wise

You can create your own authentication project. Here I am just demonstrating how jwt tokens get integrated and help in this process.

We need to add 2 env variables in .env file. They are access token secret and refresh token secret.

ACCESS_TOKEN_SECRET=9574b4057abe6e85c3dcd986afbf83f1ffe074c22e2cac22446b5cf6f438857596fc4b983f78a713ed191cfac22557d19ce15458e70a235a4fb07c6b8f1c98d7
REFRESH_TOKEN_SECRET=b57f1cf16c2efd417d226d4dc62b2c9eed5b226dc599cd356c0b72e001d53548e98ffd5e81f4818171fce4700d392f78a478f23b4e25a040e29fd616fce70672

Make sure you add .env in the .gitignore file.

Now generate accessToken and refreshToken in the login controller with the help of their respective secrets:

const jwt = require("jsonwebtoken")
require("dotenv").config()

const accessToken = jwt.sign(
      { username: foundUser.username },
      process.env.ACCESS_TOKEN_SECRET,
      { expiresIn: "30s" }
    )
    const refreshToken = jwt.sign(
      { username: foundUser.username },
      process.env.REFRESH_TOKEN_SECRET,
      { expiresIn: "1d" }
    )

After that, save the refresh Token in the respective user’s document and send the access token to the browser as json object. Also send refreshToken to the browser as cookie with httpOnly setting true - this way refreshToken won’t be accessible with javascript:

......
...
const currentUser = { ...otherUsers, currentUser }
    usersDB.setUsers([...otherUsers, currentUser])
    await fsPromises.writeFile(
      path.join(__dirname, "..", "model", "users.json"),
      JSON.stringify(usersDB.users)
    )
    res.cookie("jwt", refreshToken, {
      httpOnly: true,
      maxAge: 24 * 60 * 60 * 1000, // 1 day
    })
    res.json({ accessToken })

Authorization

To authorize every secure api endpoint, we need to verify the jwt token in a middleware:

// middleware/verifyJWT.js
const jwt = require("jsonwebtoken")
require("dotenv").config()

const verifyJWT = (req, res, next) => {
  const authHeader = req.headers["authorization"]
  if (!authHeader) return res.sendStatus(401)
  console.log(authHeader) // Bearer token
  const token = authHeader.split(" ")[1]

  jwt.verify(token, process.env.ACCESS_TOKEN_SECRET, (err, decoded) => {
    if (err) return res.sendStatus(403)
    req.user = decoded.username
    next()
  })
}

module.exports = verifyJWT

Basically it collects the token from headers. Then, it verifies the token with the provided secret. Then, we can get decoded data - payload. Now just place the middleware before controllers.

How authorization works from the frontend perspective?

Once the user requests for logging in, it sends back an access token within the response. This access token is supposed to be stored securely. But when it comes to authorization, you pass bearer within headers like the following:

const res = await fetch("https://api.example.com/profile", {
  method: "GET",
  headers: {
    "Content-Type": "application/json",
    "Authorization": `Bearer ${accessToken}`,
  },
});

How to make refreshToken work along?

For that we need to create a new route for refreshing. Let’s first get through the refresh-token-controller - so create a new refresh token controller:

const usersDB = {
  users: require("../model/users.json"),
  setUsers: function (data) {
    this.users = data
  },
}
const jwt = require("jsonwebtoken")
require("dotenv").config()

const handleRefreshToken = (req, res) => {
  const cookies = req.cookies
  if (!cookies?.jwt) return res.sendStatus(401)
  console.log(cookies.jwt)
  const refreshToken = cookies.jwt

  const foundUser = usersDB.users.find(
    (person) => person.refreshToken === refreshToken
  )
  if (!foundUser) return res.sendStatus(403) //Forbidden
  // evaluate jwt
  jwt.verify(refreshToken, process.env.REFRESH_TOKEN_SECRET, (err, decoded) => {
    if (err || foundUser.username !== decoded.username)
      return res.sendStatus(403)
    const accessToken = jwt.sign(
      { username: decoded.username },
      process.env.ACCESS_TOKEN_SECRET,
      { expiresIn: "30s" }
    )
    res.json({ accessToken })
  })
}

module.exports = { handleRefreshToken }

Can you remember that we set refreshToken as a cookie with httpOnly property? That cookie was set named jwt. So, we need to get the jwt cookie - if it doesn’t exist, that means the user didn’t even log in. So, that makes it return 401 error.

That jwt cookie is the refreshToken for this program. Then, find the user which contains this refreshToken - here named foundUser. The same way to handle foundUser error.

At this point this refreshToken needs to be verified with the set REFRESH_TOKEN_SECRET on the server’s env variables. If it’s found verified, then create a new access token with the ACCESS_TOKEN_SECRET. The same way it will be sent to the frontend code as json data.

Then this controller will be assigned to /refresh endpoint in the main file along with other endpoints.

Note: ✅ httpOnly and secure are NOT alternatives

They are two separate flags, and both can (and SHOULD) be used together in production.

httpOnly: true: Prevents JavaScript access.

Prevents JavaScript from reading the cookie. This protects against XSS attacks.

Works on both HTTP and HTTPS

Does not depend on environment (dev or prod)

secure: true: Restricts cookie sending to HTTPS only.

Only sends the cookie over HTTPS.

This protects against network sniffing / MITM attacks.

Now the logout controller should look like this:

const usersDB = {
  users: require("../model/users.json"),
  setUsers: function (data) {
    this.users = data
  },
}
const fsPromises = require("fs").promises
const path = require("path")

const handleLogout = async (req, res) => {
  // On client, also delete the accessToken

  const cookies = req.cookies
  if (!cookies?.jwt) return res.sendStatus(204)
  const refreshToken = cookies.jwt

  // Is refreshToken in db?
  const foundUser = usersDB.users.find(
    (person) => person.refreshToken === refreshToken
  )
  if (!foundUser) {
    res.clearCookie("jwt", { httpOnly: true })
    return res.sendStatus(404)
  }

  // Delete refreshToken in db
  const otherUsers = usersDB.users.filter(
    (person) => person.refreshToken !== foundUser.refreshToken
  )
  const currentUser = { ...foundUser, refreshToken: "" }
  usersDB.setUsers([...otherUsers, currentUser])
  await fsPromises.writeFile(
    path.join(__dirname, "..", "model", "user.json"),
    JSON.stringify(usersDB.users)
  )

  res.clearCookie("jwt", { httpOnly: true }) // secure: true - only serves on https
  res.sendStatus(204)
}

module.exports = { handleLogout }

How would the frontend (React) send refresh request behind the scene?

Credentials need to be enabled to get cookies in the response.

export const axiosPrivate = axios.create({
  baseURL: BASE_URL,
  headers: { "Content-Type": "application/json" },
  withCredentials: true,
})

Now we need to add interceptors with this one — axiosPrivate.

So, the better is to create a custom hook where it will have interceptors added with it (the explanation is below):

import { axiosPrivate } from "../api/axios"
import { useEffect } from "react"
import useRefreshToken from "./useRefreshToken"
import useAuth from "./useAuth"

const useAxiosPrivate = () => {
  const refresh = useRefreshToken()
  const { auth } = useAuth()

  useEffect(() => {
    const requestIntercept = axiosPrivate.interceptors.request.use(
      (config) => {
        if (!config.headers["Authorization"]) {
          config.headers["Authorization"] = `Bearer ${auth?.accessToken}`
        }
        return config
      },
      (error) => Promise.reject(error)
    )

    const responseIntercept = axiosPrivate.interceptors.response.use(
      (response) => response,
      async (error) => {
        const prevRequest = error?.config
        if (error?.response?.status === 403 && !prevRequest.sent) {
          prevRequest.sent = true
          const newAccessToken = await refresh()
          prevRequest.headers["Authorization"] = `Bearer ${newAccessToken}`
          return axiosPrivate(prevRequest)
        }
        return Promise.reject(error)
      }
    )

    return () => {
      axiosPrivate.interceptors.request.eject(requestIntercept)
      axiosPrivate.interceptors.response.eject(responseIntercept)
    }
  }, [auth, refresh])

  return axiosPrivate
}

export default useAxiosPrivate

axiosPrivate is in a separate module. So, importing it here in the custom hook.
refresh is just a function that refreshes the accessToken by /refresh endpoint of the backend. useRefreshToken hook’s code will be below.
In useEffect the first thing to do is adding request interceptor. In this interceptor Bearer is being integrated in the headers for authorization. This one has been assigned to requestIntercept.
In the second part of useEffect response response interceptor is being integrated. When any request fails, the response interceptor’s error handling callback runs.
The refresh function gets called when a 403 error happens. This refresh function returns the accessToken, what we include in the request header and send another request with that accessToken. This request is done by the axiosPrivate.
This process could lead to a loop. To get rid of looping, we add sent property and set its value to true, so that it gets checked while checking the error status.
In the end when you get out of the component, the interceptors get removed as it’s specified by eject for both of them.

// useRefreshToken
import axios from "../api/axios"
import useAuth from "./useAuth"

export default function useRefreshToken() {
  const { setAuth } = useAuth()

  const refresh = async () => {
    const response = await axios.get("/refresh", {
      withCredentials: true,
    })
    setAuth((prev) => {
      console.log(JSON.stringify(prev))
      console.log(response.data.accessToken)
      return { ...prev, accessToken: response.data.accessToken }
    })
    return response.data.accessToken
  }
  return refresh
}

All You Need to Know About the useCallback Hook

Abdul Ahad Abeer — Fri, 14 Mar 2025 11:05:58 +0000

At present, when I am writing this article, React 19 is already out there, where useCallback is not necessary because of the new React Compiler. Since the new React compiler optimizes performance, there is no real need for using useCallback hook. However, it is not obsolete and many applications have been built on React 18. So, it’s crucial to understand how useCallback works.

In this article, I will primarily explore what the recreation of functions in components is, how useCallback hook prevents them from being recreated and how this leads to performance optimization.

What is Function Recreation in React Components?

In JavaScript, functions are objects, meaning they are reference types. In React, when a component re-renders, every function declared inside it gets re-created (a new reference is assigned) unless it's memorized.

import { useState } from "react"

const Counter = () => {
  const [count, setCount] = useState(0)

  // This function is re-created on every render
  const increment = () => {
    setCount(count + 1)
  }

  console.log("Counter re-rendered!") // Logs on every render

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
    </div>
  )
}

export default Counter

What Happens Here?

The component renders for the first time.
The increment function is created.
When the button is clicked, setCount updates the state.
The component re-renders, and a new version of increment is created in memory.
The process repeats on every render.

This means every render creates a brand new function, even though the logic inside it remains the same.

Why is Function Recreation a Problem?

Function recreation itself is not a problem in simple cases. But in more complex scenarios, it can cause unnecessary re-renders or break optimizations in React.

Problem 1: Function Recreation Causes Unnecessary Child Re-renders

Whenever a function is passed as a prop to a child component, if that function gets re-created on every render, the child component will re-render unnecessarily even when its props haven’t changed.

import React, { useState } from "react"

// Child component that only re-renders when its props change
const Button = React.memo(({ onClick }: { onClick: () => void }) => {
  console.log("Button re-rendered!")
  return <button onClick={onClick}>Click Me</button>
})

const Parent = () => {
  const [count, setCount] = useState(0)
  const [otherState, setOtherState] = useState(false)

  // Function gets re-created on every render
  const increment = () => {
    setCount(prev => prev + 1)
  }

  console.log("Parent re-rendered!")

  return (
    <div>
      <p>Count: {count}</p>
      <Button onClick={increment} />
      <button onClick={() => setOtherState(prev => !prev)}>Toggle</button>
    </div>
  )
}

export default Parent

What's Wrong Here?

Whenever setOtherState updates state, the parent re-renders.
The increment function gets re-created because it's defined inside the parent component.
Even though Button is wrapped with React.memo, it still re-renders because it receives a new function reference (onClick).
This defeats the purpose of React.memo, which is supposed to prevent re-renders when props don’t change.

Problem 2: Function Recreation Causes Unnecessary `useEffect` Runs

If a function is inside the dependency array of useEffect, and it gets re-created on every render, it will trigger the effect every time.

import React, { useState, useEffect } from "react"

const FetchData = () => {
  const [data, setData] = useState<string | null>(null)

  const fetchData = async () => {
    const response = await fetch("https://jsonplaceholder.typicode.com/todos/1")
    const result = await response.json()
    setData(result.title)
  }

  useEffect(() => {
    fetchData() // Function reference changes every render, causing unnecessary API calls!
  }, [fetchData])

  return <div>Data: {data}</div>
}

export default FetchData

What's Wrong Here?

fetchData is inside the component, so it gets re-created on every render.
Since it's in the useEffect dependency array, React thinks the function has changed and runs the effect again.
This leads to unnecessary API calls on every render.

How `useCallback` Solves Function Recreation

useCallback is a React hook that memoizes a function, preventing it from being re-created on every render unless its dependencies change.

If dependencies remain the same, React returns the same function reference, preventing unnecessary re-renders.

import React, { useState, useEffect, useCallback } from "react"

const FetchData = () => {
  const [data, setData] = useState<string | null>(null)

  // Function is now memoized and will only change if setData changes
  const fetchData = useCallback(async () => {
    const response = await fetch("https://jsonplaceholder.typicode.com/todos/1")
    const result = await response.json()
    setData(result.title)
  }, [])

  useEffect(() => {
    fetchData() // Now this only runs when needed
  }, [fetchData])

  return <div>Data: {data}</div>
}

export default FetchData

The API would have been called unnecessarily on every render because fetchData gets re-created in every render without the useCallback wrapper. Now, the API call runs only once because fetchData reference doesn’t change on re-renders.

When It Needs to Re-create Functions

A function in a React component needs to be recreated when it depends on values that change over time. This ensures that the function always has access to the latest state or props.

const Counter = () => {
  const [count, setCount] = useState(0)

  const logCount = useCallback(() => {
    console.log("Current count:", count) // Needs to be recreated to use the latest count
  }, [count])

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(prev => prev + 1)}>Increment</button>
      <button onClick={logCount}>Log Count</button>
    </div>
  )
}

If logCount didn't update, it would log an old count value. Adding [count] as a dependency ensures it re-creates when count updates.

TanStack Table - Quick Learning

Abdul Ahad Abeer — Mon, 10 Mar 2025 10:09:46 +0000

Basic React Table

Create an instance of a react-table.

const BasicTable = () => {
    ......
    ...

    const table = useReactTable({ data, columns })

    return (
        <div></div>
    )
}

data is the data the table contains. Columns need to be defined based on what data the table is going to contain. The following is how you define the columns.

const columns = [
    {
      header: "ID",
      accessorKey: "id",
      footer: "ID",
    },
    {
      header: "First Name",
      accessorKey: "first_name",
      footer: "First Name",
    },
    {
      header: "Last Name",
      accessorKey: "last_name",
      footer: "Last Name",
    },
    ......
    ...
]

what each property does:

header: This defines the column's title that appears at the top of the table. It's what users see as the column name.
accessorKey: This is the key used to extract data from each row's object. It tells the table which property from your dataset should be displayed in this column. So, accessorKey should match the exact property name in your data objects.
footer: Similar to header, but it defines the text that appears at the bottom of the column as a footer.

Render table in jsx:

<table>
  <thead>
    {table.getHeaderGroups().map((headerGroup) => (
      <tr key={headerGroup.id}>
        {headerGroup.headers.map((header) => (
          <th key={header.id}>
            {flexRender(header.column.columnDef.header, header.getContext())}
          </th>
        ))}
      </tr>
    ))}
  </thead>
  <tbody>
    ...
  </tbody>
  <tfoot></tfoot>
</table>

Why Are There headerGroups? Normally, when you define simple columns, there’s only one header row. However, if you group columns under a parent column, React Table creates multiple header rows.

What Does header.getContext() Do Here? header.getContext() creates an object that contains useful information about the column and table state. This context object is then passed into flexRender(), allowing it to properly render the header.

Why is header.getContext() Needed?

In react-table, header.column.columnDef.header can be:
1. A string (e.g., "Name" -> just displayed as-is).
2. A function (e.g., ({ column }) => <span>{column.id} Column</span> -> needs context to work).
If header is a function, it requires an argument (getContext() provides this argument).
flexRender() takes this function and calls it with the necessary context.

Render Rows and Cells

<table>
   <thead>
       ...
   </thead>
   <tbody>
   {table.getRowModel().rows.map((row) => (
      <tr key={row.id}>
        {row.getVisibleCells().map((cell) => (
          <td key={cell.id}>
            {flexRender(cell.column.columnDef.cell, cell.getContext())}
          </td>
        ))}
      </tr>
    ))}
   </tbody>
   <tfoot>
   </tfoot>
</table>

This is how you can render the data. But data will be rendered only when getCoreRowModel is set in table instance:

// import { getCoreRowModel } from "@tanstack/react-table"

const table = useReactTable({
  data,
  columns,
  getCoreRowModel: getCoreRowModel(),
});

Set Footer

<tfoot>
  {table.getFooterGroups().map((footerGroup) => (
    <tr key={footerGroup.id}>
      {footerGroup.headers.map((header) => (
        <th key={header.id}>
          {flexRender(header.column.columnDef.footer, header.getContext())}
        </th>
      ))}
    </tr>
  ))}
</tfoot>

Custom Cell Rendering

const columns = [
    ......
    ...
    {
      header: "Date of Birth",
      accessorKey: "dob",
      footer: "Date of Birth",
      cell: (info) =>
        DateTime.fromISO(info.getValue()).toLocaleString(DateTime.DATE_MED),
    },
  ]

Basically, this is how you can customize cells.

The function parameter is the object where you can have all the information regarding the particular cell.

Accessor Function - accessorFn

accessorKey is a static value property. But instead of static value, we can have dynamic value with accessorFn

const columns = [
  {
    header: "ID",
    accessorKey: "id",
    footer: "ID",
  },
  {
    header: "Name",
    accessorFn: (row) => `${row.first_name} ${row.last_name}`, // accessor function
    footer: "Name",
  },
  // {
  //   header: "First Name",
  //   accessorKey: "first_name",
  //   footer: "First Name",
  // },
  // {
  //   header: "Last Name",
  //   accessorKey: "last_name",
  //   footer: "Last Name",
  // },
]

Header Groups with Child Columns

const columns = [
  {
    header: "ID",
    accessorKey: "id",
    footer: "ID",
  },
  {
    header: "Name",
    columns: [
      {
        header: "First",
        accessorKey: "first_name",
        footer: "First Name",
      },
      {
        header: "Last",
        accessorKey: "last_name",
        footer: "Last Name",
      },
    ],
  },
  ......
  ...
];

Here, this creates 2 layer of header groups. This creates gibberish like the first group is going to have ID and Name. The second group is also going to have ID and then First and Last. This way it doesn’t serve our purpose. So, render them this way:

<thead>
  {table.getHeaderGroups().map((headerGroup) => (
    <tr key={headerGroup.id}>
      {headerGroup.headers.map((header) => (
        <th key={header.id}>
          {header.isPlaceholder
            ? null
            : flexRender(header.column.columnDef.header, header.getContext())}
        </th>
      ))}
    </tr>
  ))}
</thead>;

/*
Parent HeaderGroup > -- Name
Child_ HeaderGroup > ID First Last
*/

Name header has child columns. These child columns merge with headers that don’t have child columns.

So, there will be placeholders in the first header group. The placeholders will have null values as it’s in the code.

Pagination

In order to have pagination, the first condition you have to set getPaginationRowModel in the useReactTable hook’s object.

const table = useReactTable({
  data,
  columns,
  getCoreRowModel: getCoreRowModel(),
  getPaginationRowModel: getPaginationRowModel(),
});

Now, add pagination buttons right after the table elements:

<table>
......
...
</table>
<div>
  <button onClick={() => table.setPageIndex(0)}>First page</button>
  <button onClick={() => table.previousPage()}>Previous page</button>
  <button onClick={() => table.nextPage()}>Next page</button>
  <button onClick={() => table.setPageIndex(table.getPageCount() - 1)}>
    Last page
  </button>
</div>

These button events are pretty self-explanatory.

This way it creates a conflict. The conflict is when there are no data, it will still try to get the next data and obviously it will show no data or empty. So, disabling the buttons in such cases is the solution.

<div>
  <button onClick={() => table.setPageIndex(0)}>First page</button>
  <button
    disabled={!table.getCanPreviousPage()}
    onClick={() => table.previousPage()}
  >
    Previous page
  </button>
  <button disabled={!table.getCanNextPage()} onClick={() => table.nextPage()}>
    Next page
  </button>
  <button onClick={() => table.setPageIndex(table.getPageCount() - 1)}>
    Last page
  </button>
</div>

These methods are also very much self-explanatory.

Sorting

First of all set getSortedRowModel.

Now, set the sorting state (state property after getSortedRowModel).

Then, set ascending and descending sign right after every header value.

Then, add onClick={header.column.getToggleSortingHandler()} in header to change sorting.

const [sorting, setSorting] = useState([]);

const table = useReactTable({
  data,
  columns,
  getCoreRowModel: getCoreRowModel(),
  getPaginationRowModel: getPaginationRowModel(),
  getSortedRowModel: getSortedRowModel(),
  state: {
    sorting: sorting,
  },
  onSortingChange: setSorting,
});

return (
  <div>
    <table>
      <thead>
        {table.getHeaderGroups().map((headerGroup) => (
          <tr key={headerGroup.id}>
            {headerGroup.headers.map((header) => (
              <th
                key={header.id}
                onClick={header.column.getToggleSortingHandler()}
              >
                {header.isPlaceholder ? null : (
                  <div>
                    {flexRender(
                      header.column.columnDef.header,
                      header.getContext()
                    )}
                    {
                      { asc: "↑", desc: "↓" }[
                        header.column.getIsSorted() ?? null
                      ]
                    }
                  </div>
                )}
              </th>
            ))}
          </tr>
        ))}
      </thead>
    </table>
  </div>
);

TanStack Table uses ‘asc’ and ‘desc’ by default for sorting. So, the sorting mechanism here is pretty straight-forward.

Filtering

set getFilteredRowModel(),

const table = useReactTable({
  ......
  ...,
  getFilteredRowModel: getFilteredRowModel(),
});

Here, we need to set filtering state as well.

const [filtering, setFiltering] = useState('')

const table = useReactTable({
  ......
  ...,
  state: {
      ...,
      globalFilter: filtering
  },
  onGlobalFiltering: setFiltering
});

This globalFilter setting makes a searching mechanism for data table.

Now, add a search input right before the table:

<>
  <input
    type="text"
    value={filtering}
    onChange={(e) => setFiltering(e.target.value)}
  />
  <table></table>
</>

Master Drizzle ORM

Abdul Ahad Abeer — Fri, 07 Mar 2025 16:52:06 +0000

A Few Important Words

I am consciously avoiding unimportant, gibberish talk. I was watching Code Genix’s YT tutorial on drizzle-orm and I found it very much useful and comprehensive. So, I noted while watching the tutorial. After watching the tutorial, I organized it and decided to write the whole thing here in this platform in a more cheatsheet manner. This will help me revise anytime I need to look at the topics, and it might help you as well.

I will cover the topic using other technologies, such as Next.js, Docker, drizzle-zod, etc., because I found them helpful, and they made the development scalable. But you will not need to worry, as I will mention at points when you can skip these technologies in case you don’t know them. I am not going to explain the entire project; rather, I will just leave some minimal explanations on topics that gives you an idea of how the other technologies can be incorporated with Drizzle ORM.

Introduction

Drizzle ORM is a lightweight, TypeScript-first ORM designed for modern JavaScript applications. It focuses on SQL-like query building, migrations, and type safety, making it a good fit for both relational and some NoSQL databases. Unlike Prisma, which abstracts SQL heavily and generates queries dynamically, Drizzle gives you a more SQL-like experience while still providing TypeScript support and automation for migrations.

Prerequisites

The technologies below must be known.

TypeScript
NodeJS
SQL
PostgreSQL

Setup

Install pg, drizzle-orm and drizzle-kit packages in your project:

npm install pg drizle-orm

npm install --save-dev @types/pg drizzle-kit

pg is the PostgreSQL client for Node.js. It allows your application to connect to, query, and interact with a PostgreSQL database. Here, in this case of Drizzle ORM, pg is the database driver that Drizzle uses under the hood to communicate with PostgreSQL.

drizzle-kit is a CLI tool for Drizzle ORM that helps with database migrations and schema generation. It automates the process of managing your database structure in sync with your TypeScript models.

First of all make sure your database is up and running in your system. Now, create an environment file .env in the root of the project folder and set these data in it:

DB_HOST=
DB_USER=
DB_PASSWORD=
DB_NAME=
DB_PORT=
DATABASE_URL=

Using the other technologies (skippable) ↓

I am running the database in a docker container. So, the configuration looks like this:

DB_HOST=localhost
DB_USER=postgres
DB_PASSWORD=postgres
DB_NAME=blog
DB_PORT=5433
DATABASE_URL=postgresql://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}
......
...

I am running the database on a Docker container, so I need to create a Docker Compose file in the root of the project. In this tutorial, the project is a NextJS project. So, create a docker-compose file in the root of your NextJS project.

services:
  db:
    container_name: db
    image: postgres:16
    environment:
      - POSTGRES_USER=${DB_USER}
      - POSTGRES_PASSWORD=${DB_PASSWORD}
      - POSTGRES_DB=${DB_NAME}
    ports:
      - ${DB_PORT}:5432
    volumes:
      - db-data:/var/lib/postgresql/data

  adminer:
    image: adminer:latest
    container_name: adminer
    ports:
      - "8080:8080"
    depends_on:
      - db

volumes:
  db-data:

db service is pretty much understandable. adminer is a lightweight database management tool that is going to help us manage the Postgres database.

Now, install drizzle-zod : npm install drizzle-zod

drizzle-zod is a utility package that helps generate Zod schemas from Drizzle ORM schemas. It simplifies validation by automatically converting your Drizzle ORM table definitions into Zod validation schemas.

Installing eslint-plugin-drizzle, @typescript-eslint/eslint-plugin, @typescript-eslint/parser and tsx might also benefit in development. These packages help you enforce best practices when using drizzle in typescript and warn you for type-safety. I recommend installing them.

Add some path aliases in tsconfig.json for better development

// tsconfig.json
{
  compilerOptions: {
    "paths": {
      "@/*": ["./src/*"],
      "$/*": ["./*"]
    }
  }
}

Add these changes in .eslintrc.json as well:

// .eslintrc.json
{
  "root": true,
  "extends": ["plugin:drizzle/all", "next/core-web-vitals"],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "project": "./tsconfig.json"
  },
  "plugins": "drizzle"
}

Drizzle Config

Create a file drizzle.config.ts in the root of the project and include this code:

import { defineConfig } from "drizzle-kit"

import env from "@/lib/env"

export default defineConfig({
  schema: "./src/db/schema/index.ts",
  out: "./src/db/migrations",
  dialect: "postgresql",
  dbCredentials: {
    url: env.DATABASE_URL,
  },
  strict: true,
})

Here’s a quick breakdown of the properties in your Drizzle ORM config:

schema → Path to your database schema file. (index.ts inside src/db/schema/)
out → Directory where migration files will be generated. (src/db/migrations/)
dialect → Specifies the database type (postgresql in this case).
dbCredentials → Contains database connection details (e.g., DATABASE_URL from .env).
strict → If true, enables strict mode for extra type safety and validation.

This config helps Drizzle ORM know where to find the schema, how to generate migrations, and how to connect to the database.

Validating env variables (skippable) ↓

// @/lib/env
import { config } from "dotenv"
import { expand } from "dotenv-expand"
import { z, ZodError } from "zod"

const envSchema = z.object({
  AUTH_SECRET: z.string().min(1),
  AUTH_TRUST_HOST: z.string().min(1),
  DATABASE_URL: z.string().min(1),
})

expand(config())

try {
  envSchema.parse(process.env)
} catch (e) {
  if (e instanceof ZodError) {
    console.error("Environment validation error:", e.errors)
  }
}

export default envSchema.parse(process.env)

Install the necessary packages mentioned here: dotenv, dotenv-expand and zod

config() loads variables from the .env file into process.env. expand() allows variables to reference other variables inside .env. For example:

DATABASE_URL=postgres://user:password@localhost:5432/dbname
AUTH_SECRET=mysecret
AUTH_TRUST_HOST=${DATABASE_URL}

Without dotenv-expand, AUTH_TRUST_HOST would remain "${DATABASE_URL}" as a string. With dotenv-expand, it gets replaced with the actual DATABASE_URL value. So, expand(config()) ensures that referenced environment variables are properly expanded before validation with Zod.

Write Schema for Tables

Write schema for user in the location mentioned in the config:

// @/db/schema/user.ts
import {
  integer,
  pgTable,
  serial,
  timestamp,
  varchar,
} from "drizzle-orm/pg-core"

export const user = pgTable("user", {
  id: serial("id").notNull().primaryKey(),
  fullName: varchar("full_name", { length: 255 }).notNull(),
  age: integer("age").notNull(),
  password: varchar("password", { length: 255 }).notNull(),
  email: varchar("email", { length: 255 }).notNull().unique(),
  createdAt: timestamp("created_at", { mode: "string" }).notNull().defaultNow(),
  updatedAt: timestamp("updated_at", { mode: "string" }).notNull().defaultNow(),
})

There are 3 types of scenarios you would come across. They are one-to-one, one-to-many and many-to-many relations. How do they look like in drizzle ORM?

One-to-One Relation

This one has been taken from straight the documentation of drizzle-orm.

An example of a one-to-one relation between users and users, where a user can invite another (this example uses a self reference):

import { pgTable, serial, text, integer, boolean } from 'drizzle-orm/pg-core';
import { relations } from 'drizzle-orm';
export const users = pgTable('users', {
    id: serial('id').primaryKey(),
    name: text('name'),
    invitedBy: integer('invited_by'),
});
export const usersRelations = relations(users, ({ one }) => ({
    invitee: one(users, {
        fields: [users.invitedBy],
        references: [users.id],
    }),
}));

What’s Happening Here?

invitedBy column in users:

* This stores the `id` of another user who invited the current user.

* Basically, `invitedBy` acts as a **foreign key** referencing another user's `id`.

usersRelations defines a self-referencing relationship:

* `one(users, { fields: [users.invitedBy], references: [`[`users.id`](http://users.id)`] })` means:

    * The `invitedBy` field in a user **points to another user's** `id`.

    * Each user can have **one inviter** (but one user can invite multiple users).

One-to-Many Relation

Every post can have one user, but every user can have many posts.

// @/db/schema/post.ts
export const post = pgTable("post", {
  id: serial("id").primaryKey(),
  userId: integer("user_id")
    .notNull()
    .references(() => user.id),
  title: varchar("title", { length: 255 }).notNull(),
  shortDescription: text("short_description"),
  content: text("content").notNull(),
  createdAt: timestamp("created_at", { mode: "string" }).notNull().defaultNow(),
  updatedAt: timestamp("updated_at", { mode: "string" }).notNull().defaultNow(),
})

export const postRelations = relations(post, ({ one, many }) => ({
  user: one(user, {
    fields: [post.userId],
    references: [user.id],
  }),
  ......
  ...
}))

userId is the foreign key that demonstrates that this post has a user. In postRelations function, the user’s relation is defined. With that, we can have access to the user a post belongs to.

// @/db/schema/user.ts
export const user = pgTable("user", {
  ......
  ...
})

export const userRelations = relations(user, ({ many }) => ({
  posts: many(post),
}))

Here in the user schema, a user can have many posts and the relation has been defined here. So, every user can have a number of posts.

Many-to-Many Relation

By default, drizzle doesn’t support many-to-many relation. So, to have a many-to-many relation, we need to have a different table that helps establish such relations.

For example, a post can have many tags. Similarly, a tag can have many posts. So, create a schema file postTags whose name is postTags:

// @/db/schema/postTags.ts
export const postTags = pgTable(
  "post_to_tag",
  {
    postId: integer("post_id")
      .notNull()
      .references(() => post.id),
    tagId: integer("tag_id")
      .notNull()
      .references(() => tag.id),
  },
  (table) => ({
    pk: primaryKey({ columns: [table.postId, table.tagId] }),
  })
)

export const postTagsRelations = relations(postTags, ({ one }) => ({
  tag: one(tag, { fields: [postTags.tagId], references: [tag.id] }),
  post: one(post, { fields: [postTags.postId], references: [post.id] }),
}))

This one is pretty self-explanatory. Every postTag belongs to a tag and a post.

// @/db/schema/tag.ts
export const tag = pgTable("tag", {
  id: serial("id").primaryKey(),
  name: varchar("name", { length: 255 }).notNull().unique(),
})

export const tagRelations = relations(tag, ({ many }) => ({
  postToTag: many(postTags),
}))

// @/db/schema/post.ts
export const post = pgTable("post", {
  ......
  ...
})

export const postRelations = relations(post, ({ one, many }) => ({
  tags: many(postTags),
  ......
  ...
}))

Here, we can see a tag table can many posts as postToTag. On the other hand, a post can have many tags. Both of them are having postTags in reality of our code.

Zod Schema from Table Schema

You can skip this entire section if you are not interested in zod validation (skippable)

This section speaks about how you create a Zod schema from a table schema.

We can create a schema that denotes the type of table’s schema. It can be useful for NextJS projects where we can use these Zod schemas in the front-end part of the project.

// @/db/schema/category.ts
......
...
import { createInsertSchema } from "drizzle-zod"
import { z } from "zod"

......
...

export const categorySchema = createInsertSchema(category)
export type CategorySchema = z.infer<typeof categorySchema>

We can override the default Zod behavior of a schema.

export const commentSchema = createInsertSchema(comment, {
  postId: (schema) =>
    schema.postId.min(1, { message: "the postId must be provided" }),
})

Here, we can override the default error message of zod with our message. We can pick properties for Zod’s validation as well. So, only picked properties are going to be type-checked by zod:

export const commentSchema = createInsertSchema(comment, {
  postId: (schema) => schema.postId.min(1),
  content: (schema) => schema.content.min(1),
  userId: (schema) => schema.userId.min(1),
}).pick({
  postId: true,
  content: true,
  userId: true,
  parentId: true,
  id: true,
})

Overall, the zod schema will look like this:

// @/db/schema/comment.ts
......
...

export const commentSchema = createInsertSchema(comment, {
  postId: (schema) => schema.postId.min(1),
  content: (schema) => schema.content.min(1),
  userId: (schema) => schema.userId.min(1),
}).pick({
  postId: true,
  content: true,
  userId: true,
  parentId: true,
  id: true,
})

export type CommentSchema = z.infer<typeof commentSchema>

Zod schema can be created in 2 separate modes. For example, the code below is for a post:


const baseSchema = createInsertSchema(post, {
  title: (schema) => schema.title.min(1),
  shortDescription: (schema) => schema.shortDescription.min(1).max(255),
  userId: (schema) => schema.userId.min(1),
  categoryId: (schema) => schema.categoryId.min(1),
}).pick({
  title: true,
  shortDescription: true,
  userId: true,
  categoryId: true,
  content: true,
})

export const postSchema = z.union([
  z.object({
    mode: z.literal("create"),
    title: baseSchema.shape.title,
    shortDescription: baseSchema.shape.shortDescription,
    userId: baseSchema.shape.userId,
    categoryId: baseSchema.shape.categoryId,
    content: baseSchema.shape.content,
    tagIds: z.array(z.number()),
  }),
  z.object({
    mode: z.literal("edit"),
    id: z.number().min(1),
    title: baseSchema.shape.title,
    shortDescription: baseSchema.shape.shortDescription,
    userId: baseSchema.shape.userId,
    categoryId: baseSchema.shape.categoryId,
    content: baseSchema.shape.content,
    tagsId: z.array(z.number()),
  }),
])

export type PostSchema = z.infer<typeof postSchema>
export type SelectPostModel = InferSelectModel<typeof post>

create mode is applied for creating a post and edit mode is for editing posts.

Configuring DB Object

Now, we need to configure a db object which will be used for accessing the db to make CRUD operations across the project.

// @/db/index.ts
import { drizzle } from "drizzle-orm/node-postgres"
import { Pool } from "pg"

import * as schema from "@/db/schema"
import env from "@/lib/env"

const pool = new Pool({
  connectionString: env.DATABASE_URL,
})

export const db = drizzle(pool, { schema, logger: true })

export type DB = typeof db

This db Object is going to be used in getting data and updating the database.

Database Migration

After making or updating the database structure, we need to migrate its core SQL file to a location that has been fixed in the drizzle’s config file. So, now we need to configure that migrate file:

// @/db/migrate.ts
import config from "$/drizzle.config"
import env from "@/lib/env"
import { migrate } from "drizzle-orm/node-postgres/migrator"
import { Pool } from "pg"
import { drizzle } from "drizzle-orm/node-postgres"

const pool = new Pool({
  connectionString: env.DATABASE_URL,
})

const db = drizzle(pool)

async function main() {
  if (config.out) {
    await migrate(db, { migrationsFolder: config.out })
    console.log("Migration done!")
  }
}

main()
  .catch((e) => {
    console.error(e)
  })
  .finally(async () => {
    await pool.end()
  })

main function makes the migration.

Script for Migration

Now we need a command for generating the sql file and another command for migrating the generated code to the database system:

// package.json
{
    "scripts": {
    ......
    ...,
    "db:generate": "drizzle-kit generate",
    "db:migrate": "tsx src/db/migrate.ts",
    "db:update": "npm run db:generate && npm run db:migrate"
  },
}

Usually, you compile the TypeScript code and then run the compiled JavaScript code from the Dist folder at runtime.

So, instead of doing:

tsc && node dist/db/migrate.js

You can just do:

tsx src/db/migrate.ts

db:update command runs both of them in one go.

Before you run the command, db:migrate make sure the database system is up and running on your system. For example, here in this case, I am running docker (skippable)

docker compose up -d

CRUD Operations Using DB Object

There are two ways you can make CRUD operations. They are SQL-style Query Builder and ORM-style Query API. I will be demonstrating both types of CRUD operations below:

Get Data

Getting data in ORM-style Query API:

import { db } from "@/db"

export async function getCategories() {
  return await db.query.category.findMany()
}

The following is how you filter the data. This code is not necessarily the same data as getCategories function. However, you can understand how you can filter them out.

import {eq} from "drizzle-orm"

export async function getRelatedPostsByCategoryId(categoryId: number) {
  return executeQuery({
    queryFn: async () =>
      await db.query.post.findMany({
        limit: 4,
        where: eq(post.categoryId, categoryId),
        columns: {
          id: true,
          title: true,
          updatedAt: true,
          shortDescription: true,
        },
      }),
    serverErrorMessage: "getRelatedPostsByCategoryId",
    isProtected: false,
  })
}

This approach looks more like Prisma ORM

The same thing can be achieved in the SQL-style Query Builder. By the way, the code below doesn’t necessarily get the same data as getRelatedPostsByCategoryId function.

export async function getPosts(
  page: number,
  limit: number,
  searchTerm?: string
) {
  return executeQuery({
    queryFn: async () =>
      await db
        .select()
        .from(post)
        .orderBy(desc(post.createdAt))
        .limit(limit)
        .offset(page * limit)
        .where(ilike(post.title, `%${searchTerm || ""}`)),
    serverErrorMessage: "getPosts",
    isProtected: false,
  })
}

Here, the dot notations resemble the SQL code. That’s why the terms mean the same as SQL.

Create / Post Data

The following is SQL-style Query Builder. That’s why it uses insert to create or post new data like SQL.

import { db } from "@/db"
import { post, postSchema, PostSchema } from "@/db/schema/post"

export async function createPost(data: PostSchema) {
  return executeAction({
    actionFn: async () => {
      const validatedData = postSchema.parse(data)

      const { postId } = (
        await db
          .insert(post)
          .values(validatedData)
          .returning({ postId: post.id })
      )[0]
    },
  })
}

Here’s how you can rewrite the createPost function using the .query API:

import { db } from "@/db"
import { post, postSchema, PostSchema } from "@/db/schema/post"

export async function createPost(data: PostSchema) {
  return executeAction({
    actionFn: async () => {
      const validatedData = postSchema.parse(data)

      const { id: postId } = await db.query.post.insert({
        values: validatedData,
        returning: { id: true },
      })
    },
  })
}

Update Data

The following is SQL-style Query Builder. That’s why it uses update like SQL.

import { db } from "@/db"
import { post, postSchema, PostSchema } from "@/db/schema/post"
import { eq } from "drizzle-orm"

export async function updatePost(data: unknown) {
  return executeAction({
    actionFn: async () => {
      const validatedData = postSchema.parse(data)

      if (validatedData.mode === "edit") {
        await db
          .update(post)
          .set(validatedData)
          .where(eq(post.id, +validatedData.id))
      }
    },
  })
}

Here’s the equivalent function using the .query API:

import { db } from "@/db"
import { post, postSchema } from "@/db/schema/post"
import { eq } from "drizzle-orm"

export async function updatePost(data: unknown) {
  return executeAction({
    actionFn: async () => {
      const validatedData = postSchema.parse(data)

      if (validatedData.mode === "edit") {
        await db.query.post.update({
          where: eq(post.id, +validatedData.id),
          data: validatedData,
        })
      }
    },
  })
}

Delete Data

SQL-style Query Builder:

await db.delete(postTags).where(eq(postTags.postId, +validatedData.id))

The .query API:

await db.query.postTags.delete({
  where: eq(postTags.postId, +validatedData.id),
})

Difference Between SQL-style Query Builder And ORM-style Query API

Drizzle provides two ways to interact with the database:

SQL-style Query Builder (select(), insert(), update(), delete())
ORM-style Query API (db.query.table.findMany(), db.query.table.insert(), etc.)

SQL-style Query Builder

This approach resembles raw SQL but in a type-safe and programmatic way. It gives developers full control over queries while keeping the syntax close to actual SQL. Let’s say you want to count how many posts a user has:

const postCount = await db
  .select({ count: count() })
  .from(post)
  .where(eq(post.userId, userId))

This directly translates to SQL:

SELECT COUNT(*) FROM post WHERE userId = ?

It’s clean, efficient, and doesn’t require ORM-style object structures.

Now, if you tried this with .query, you might have to fetch all posts first and then count them in JavaScript, which is inefficient.

Complex Query with .select(): Imagine fetching posts along with the number of likes:

const postsWithLikes = await db
  .select({
    postId: post.id,
    title: post.title,
    likes: count(),
  })
  .from(post)
  .leftJoin(like, eq(post.id, like.postId))
  .groupBy(post.id)

Equivalent SQL:

SELECT post.id, post.title, COUNT(like.id) as likes 
FROM post 
LEFT JOIN like ON post.id = like.postId 
GROUP BY post.id

If you were using .query, you’d likely need extra processing after fetching the data, which is unnecessary here.

Without Using a Schema

Drizzle allows you to write raw SQL-like queries without needing predefined models.

Using Schema (`post` table object)

await db.select().from(post).where(eq(post.userId, userId))

This works because post is a Drizzle-defined table object.

Without Using a Schema

await db.select().from(sql`post`).where(eq(sql`user_id`, userId))

Here, instead of using the post schema, we pass raw SQL strings (sqlpost\).
This works even if you don’t define post using pgTable().

ORM-style Query API

This approach provides a more object-oriented, structured way to interact with the database, similar to how Prisma or other ORMs work.

await db.query.post.findMany({
  where: eq(post.userId, userId),
  with: { category: true, user: { columns: { id: true, fullName: true } } },
})

More structured API – Queries are built with a predefined structure, making them easier to read and write. You can fetch related data easily using with: {}.

Conclusion

Whether you prefer the SQL-style API for precise control over queries or the Query API for a more structured, object-based approach, Drizzle ensures efficiency, scalability, and developer-friendly workflows.

Infinite Scrolling of TanStack Query 🌸

Abdul Ahad Abeer — Tue, 04 Mar 2025 07:24:47 +0000

This article is a continuation of the previous article. So, check that out before you continue.

For infinite scrolling, create an axios function for api calling:

export const getProducts = async ({ pageParam }: { pageParam: number }) => {
  return (
    await axiosInstance.get<Product[]>(
      `products?_page=${pageParam + 1}&_limit=3`
    )
  ).data
}

Now, we need to define an infinite-scrolling specific query:

export function useProducts() {
  return useInfiniteQuery({
    queryKey: ["products"],
    queryFn: getProducts,
    initialPageParam: 0,
    getNextPageParam: (lastPage, allPages, lastPageParam) => {
      if (lastPage.length === 0) {
        return undefined
      }
      return lastPageParam + 1
    },
    getPreviousPageParam: (firstPage, allPages, firstPageParam) => {
      if (firstPageParam <= 1) {
        return undefined
      }
      return firstPageParam - 1
    },
  })
}

Here, we can replace unused parameters with underscores like the following:

getNextPageParam: (lastPage, _, lastPageParam) => {

// -------------------------------------------------

getPreviousPageParam: (_, __, firstPageParam) => {

The properties of useInfiniteQuery are pretty much self-explanatory. Now, implement the infinite query mechanisms in the react component: (This one is long. There will be some explanation after the code)

import { FC, Fragment, useState } from "react"
import { useProduct, useProducts } from "../services/queries"

interface ComponentProps {}

const Products: FC<ComponentProps> = () => {
  const [selectedProductId, setSelectedProductId] = useState<number | null>(
    null
  )

  const productsQuery = useProducts()
  const productQuery = useProduct(selectedProductId)

  return (
    <>
      {/* page data rendered here */}
      {productsQuery.data?.pages.map((page, index) => (
        <Fragment key={index}>
          {page.map((product) => (
            <Fragment key={product.id}>
              {/* click button to see in detail */}
              <button onClick={() => setSelectedProductId(product.id)}>
                {product.name}
              </button>
              <br />
            </Fragment>
          ))}
        </Fragment>
      ))}
      <br />

      {/* button to load to the next page */}
      <div>
        <button
          onClick={() => productsQuery.fetchNextPage()}
          disabled={
            !productsQuery.hasNextPage || productsQuery.isFetchingNextPage
          }
        >
          {productsQuery.isFetchingNextPage
            ? "Loading more..."
            : productsQuery.hasNextPage
            ? "Load More"
            : "Nothing more to load"}
        </button>
      </div>

      {/* selected product in detail */}
      <div>Selected product:</div>
      {JSON.stringify(productQuery.data)}
    </>
  )
}

export default Products

useProducts is used for making pagination api call. So, we get data of the first page and render them initially.

Then, another mechanism is added to select a product and see data in detail. In the rendered page data, there is a button to select, and its data is shown in the bottom. The selected data comes from useProduct api calling. The following is how it works:

// api.ts
export const getProduct = async (id: number) => {
  return (await axiosInstance.get<Product>(`products/${id}`)).data
}

// queries.ts
export function useProduct(id: number | null) {
  const queryClient = useQueryClient()

  return useQuery({
    queryKey: ["product", { id }],
    queryFn: () => getProduct(id!),
    enabled: !!id,
    placeholderData: () => {
      const cachedProducts = (
        queryClient.getQueryData(["products"]) as {
          pages: Product[] | undefined
        }
      )?.pages?.flat(2)

      if (cachedProducts) {
        return cachedProducts.find((item) => item.id === id)
      }
    },
  })
}

Here getProduct is for making the api call.

We call the api through useProduct. this api calling works only when there is an id passed through, as enabled is set to id’s existence.

placeholderData sets cached data when data is being fetched and fills the place with cached data.

Tanstack Query / React Query 🌸

Abdul Ahad Abeer — Sun, 02 Mar 2025 13:52:44 +0000

Intro

This article is more like a note or cheatsheet. I hope this approach is not going to be confusing for you if you are already familiar with redux or such libraries before.

Most of it is actually noted from the Code Genix’s Tutorial.

export function useTodosIds() {
  return useQuery({
    queryKey: ["todos"],
    queryFn: getTodosIds,
  })
}

The useQuery part is the most basic of tanstack-query.

Here. queryFn is the query function. Here getTodosIds is the function that mainly makes the API call. Here is its definition:

import axios from "axios"
import { Todo } from "../types/todo"

const BASE_URL = "http://localhost:8080"
const axiosInstance = axios.create({
  baseURL: BASE_URL,
})

export const getTodosIds = async () => {
  return (await axiosInstance.get<Todo[]>("todos")).data.map((todo) => todo.id)
}

There are other options in the useQuery object as well. Some of them are refetchOnWindowFocus and enabled:

export function useTodosIds(something: boolean) {
  return useQuery({
    queryKey: ["todos"],
    queryFn: getTodosIds,
    refetchOnWindowFocus: false,
    enabled: something, // place a boolean value.
  })
}

if refetchOnWindowFocus is true, it will make an api call whenever you get back to the app window.

if enabled is true, this query is going to work. Otherwise, it won’t.

By the way, the default value of refetchOnWindowFocus and enabled are always true.

Setup

Wrap your main ui or the App.tsx file with queryClientProvider and add the query client to it.

In the query-client object, there are many options. I incorporated 2 of them here:

import { StrictMode } from "react"
import { createRoot } from "react-dom/client"
import "./index.css"
import App from "./App.tsx"
import { QueryClient, QueryClientProvider } from "@tanstack/react-query"

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: 5,
      retryDelay: 1000,
    },
  },
})

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <QueryClientProvider client={queryClient}>
      <App />
    </QueryClientProvider>
  </StrictMode>
)

Here, you can add Devtools as well (Tanstack-query specific)

import { ReactQueryDevtools } from "@tanstack/react-query-devtools"

<QueryClientProvider client={queryClient}>
      <App />
      <ReactQueryDevtools initialIsOpen={false} />
</QueryClientProvider>

The notable thing here is that initialIsOpen's value of true means the dev tools will be open by default, while its value of false means they will not be open by default.

Rendering The Query Content

You can write useQuery right into the component where the query value is used. But separating them into a different module could be the better approach. With that, we get different states of the query in status form like .isPending and .isError

import { FC } from "react"
import { useTodosIds } from "../services/queries"

interface ComponentProps {}

const Todo: FC<ComponentProps> = () => {
  const todosIdsQuery = useTodosIds()

  if (todosIdsQuery.isPending) return <span>loading...</span>

  if (todosIdsQuery.isError) return <span>there is an error!</span>

  return (
    <>
      {todosIdsQuery.data.map((id) => (
        <p key={id}>{id}</p>
      ))}
    </>
  )
}

export default Todo

We can look at those query state things more closely.

`isLoading` vs `isPending` vs `isFetching`, `fetchStatus`, `status`

const {data, isLoading, isPending, isFetching, isError, error, status} = useQuery({
    ...
    ......
})

`status`

status has 3 possible values →

pending = when there's no cached data and no query attempt was finished yet.

error = when the query attempt resulted in an error. error property has the error received from the attempted fetch

success = when the query has received a response with no errors and is ready to display its data.

`fetchStatus`

fetchStatus is another thing that tells you the current status of data fetching.

const todosIdsQuery = useTodosIds()

return (
    <>
      <p>Query function status: {todosIdsQuery.fetchStatus}</p>
      {todosIdsQuery.data.map((id) => (
        <p key={id}>{id}</p>
      ))}
    </>
  )

Normally, it returns idle as value when nothing is happening. But when the fetching is going on, it returns fetching.

`isLoading` vs `isPending` vs `isFetching`

isLoading: It gets true during the first fetch when no cached data exists.

isPending: It is not typically used for queries in TanStack Query (React Query). It is primarily used for mutations to indicate that a mutation is in progress (e.g., a POST or PUT request is being sent).

isFetching: Indicates active data fetching. This flag is true when queryFn is being executed, either for the first time or during background re-fetching.

Parallel queries with `useQueries`

With useQueries we can make multiple queries simultaneously and get the result in an array.

Example of useQueries Fetching Multiple APIs at the Same Time:

const results = useQueries({
  queries: [
    { queryKey: ["todos"], queryFn: getTodos },
    { queryKey: ["users"], queryFn: getUsers },
    { queryKey: ["posts"], queryFn: getPosts },
  ],
})

// Each query runs in parallel
const todos = results[0].data
const users = results[1].data
const posts = results[2].data

Another way of doing it could be the following:

export function useTodos(ids: (number | undefined)[] | undefined) {
  return useQueries({
    queries: (ids ?? []).map((id) => {
      return {
        queryKey: ["todo", id],
        queryFn: () => getTodo(id!),
      }
    }),
  })
}

This example serves a different purpose here.

`useMutation()` used for posting, updating and deleting

useQuery and useQueries Both are used to fetch data from the server. But useMutation() is used to make any change in the data saved in the server.

// ./api.ts
export const createTodo = async (data: Todo) => {
  await axiosInstance.post("todos", data)
}

// ./mutations.ts
export function useCreateTodo() {
  return useMutation({
    mutationFn: (data: Todo) => createTodo(data),
  })
}

But this is not what Tanstack-query was built for.

You can intercept the process of making the mutation request to the server by different other life-cycle events/callbacks like onMutate, onError, and so on:

export function useCreateTodo() {
  return useMutation({
    mutationFn: (data: Todo) => createTodo(data),
    onMutate: () => {
      console.log("mutate")
    },
    onError: () => {
      console.log("error")
    },
    onSuccess: () => {
      console.log("success")
    },
    onSettled: () => {
      console.log("settled")
    },
  })
}

onMutate: This callback is triggered immediately before the mutation function (mutationFn) is fired. It's often used to update the UI.
onError: This callback is triggered if the mutation encounters an error. You can also use this to revert optimistic updates or show error messages to the user.
onSuccess: This callback is triggered when the mutation gets completed successfully.
onSettled: This callback is triggered once the mutation is either successfully completed or encounters an error (like how finally in try-catch block works).

`onSettled`

onSettled has some useful parameters.

onSettled: (data, error, variables) => {
      console.log("mutate")
    },

Here, data is the returned data and variables is the parameter you pass through mutationFn function.

Invalidating Queries

onSettled can be very useful. Within this callback, we can invalidate data.

export function useCreateTodo() {
  const queryClient = useQueryClient()

  return useMutation({
    mutationFn: (data: Todo) => createTodo(data),
    ...
    onSettled: async (_, error) => {
      console.log("settled")
      if (error) {
        console.log(error)
      } else {
        await queryClient.invalidateQueries({ queryKey: ["todos"] })
      }
    },
  })
}

So, here it refetches the query with query key ‘todos’ with the latest included data.

The following is how you would use the mutation in a React component:

const createTodoMutation = useCreateTodo()

const handleCreateTodoSubmit: SubmitHandler<TodoType> = (data) => {
   createTodoMutation.mutate(data)
}

Update Data with `useMutation`

// api.ts
export const updateTodo = async (data: Todo) => {
  await axiosInstance.put(`todos/${data.id}`, data)
}

// mutations.ts
export function useUpdateTodo() {
  const queryClient = useQueryClient()

  return useMutation({
    mutationFn: (data: Todo) => updateTodo(data),
    onSettled: async (_, error, variables) => {
      if (error) {
        console.log(error)
      } else {
        await queryClient.invalidateQueries({ queryKey: ["todos"] })
        await queryClient.invalidateQueries({
          queryKey: ["todo", { id: variables.id }],
        })
      }
    },
  })
}

Here, we are invalidating the whole to-do list and the single to-do we updated.

The earlier example shows how to use this mutation in a React component.

Delete Data with `useMutation`

export const deleteTodo = async (id: number) => {
  await axiosInstance.delete(`todos/${id}`)
}

export function useDeleteTodo() {
  const queryClient = useQueryClient()

  return useMutation({
    mutationFn: (id: number) => deleteTodo(id),

    onSuccess: async (_, error) => {
      if (error) {
        console.log(error)
      } else {
        await queryClient.invalidateQueries({ queryKey: ["todos"] })
      }
    },
  })
}

If you want to do something after the mutation, use mutateAsync instead of mutate like this:

  const handleDeleteTodo = async (id: number) => {
    await deleteTodoMutation.mutateAsync(id)
  }

placeholderData: keepPreviousData

export const getProjects = async (page = 1) => {
  ;(await axiosInstance.get<Project[]>(`projects?_page=${page}&limit=3`)).data
}

export function useProjects(page: number) {
  return useQuery({
    queryKey: ["projects", { page }],
    queryFn: () => getProjects(page),
    placeholderData: keepPreviousData,
  })
}

placeholderData: keepPreviousData

This keeps the previous data in the matter of pagination. It keeps the previous page data even when the next page data has not been fetched yet.

Pagination

Define mutation:

export const getProjects = async (page = 1) => {
  return (await axiosInstance.get<Project[]>(`projects?_page=${page}&_limit=3`))
    .data
}

export function useProjects(page: number) {
  return useQuery({
    queryKey: ["projects", { page }],
    queryFn: () => getProjects(page),
    placeholderData: keepPreviousData,
  })
}

Now, use this mutation in the React component for pagination:

import { useState } from "react"
import { useProjects } from "../services/mutations"

export default function Projects() {
  const [page, setPage] = useState(1)

  const { data, isPending, error, isError, isPlaceholderData, isFetching } =
    useProjects(page)

  return (
    <div>
      {isPending ? (
        <div>loading...</div>
      ) : isError ? (
        <div>Error: {error.message}</div>
      ) : (
        <div>
          {data.map((project) => (
            <p key={project.id}>{project.name}</p>
          ))}
        </div>
      )}
      <span>Current page: {page}</span>
      <button onClick={() => setPage((old) => Math.max(old - 1, 0))}>
        Previous Page
      </button>{" "}
      <button
        onClick={() => {
          if (!isPlaceholderData) {
            setPage((old) => old + 1)
          }
        }}
        disabled={isPlaceholderData}
      >
        Next Page
      </button>
      {isFetching ? <span>Loading...</span> : null}
    </div>
  )
}

React 19 - Get A Clear Understanding

Abdul Ahad Abeer — Thu, 21 Nov 2024 09:12:32 +0000

React 19 came out on April 25, 2024. The JavaScript world changes so quickly that it can sometimes feel overwhelming to keep up. But when these changes are meant to make your life as a React developer easier, it’s worth taking a look, right? Since React is such an important part of this ecosystem, staying updated is a must.

The best part about React 19 is that it focuses on making things simpler. The updates are designed to make learning React easier and let you spend more time creating instead of dealing with tricky setups. Some of the new features are really game-changers and could make a big difference in how you work, so you definitely don’t want to miss them.

I always try to explain things in a way that’s easy to understand, without throwing in complicated words. This article is no exception. My goal is to make sure you get everything clearly, so let’s explore the awesome updates in React 19 together!

Remember, React 19 is not quite stable yet. Currently it’s called React Canary. So, keep in mind that it’s not actually recommended for production.

React Compiler

To optimize our React applications, we use some inbuilt methods like useMemo, useCallback or memo. This tells React not to compile the code again if the inputs don’t change. But if you forget to apply memoization, it results in wasting React resources and computational power. To deal with this, React 19 introduced React Compiler. React’s new compiler is the eyeball of the 19th version’s new release. The new compiler optimizes your code behind the scenes, so you can drop these hooks and focus on writing beautiful, clean React components.

In short, you don’t need to wrap your functions with useMemo or useCallback for optimized performance, and you also don’t need to wrap your component with memo to prevent re-rendering your components.

Actions (`useTransition` hook)

Let’s talk some gibberish 😀!! Have you noticed how the useTransition hook was barely mentioned before React 19 came out? Or is it just me? Well, at least that’s what I noticed, especially among Junior Developers. Anyway, let me give you an idea of how it worked in the previous version and then we’ll see why it’s such an important feature now.

useTransition returns an array with two elements, startTransition function and isPending boolean. You can wrap your state updates inside the startTransition function to mark them as transitions (less priority code). Which means the part wrapped with startTransition starts to work after the other continuous tasks get completed.

In React 18, the startTransition function did not support async functions directly. This was a limitation because startTransition was designed to mark updates as low-priority but couldn't handle asynchronous logic natively.

In React 19, this limitation has been addressed. Now, startTransition supports async functions, meaning you can perform asynchronous tasks inside it (e.g., data fetching) while keeping those updates marked as transitions. This enhancement allows for more flexible and intuitive usage of startTransition, making it feel like a "new" feature even though it's technically an improvement to an existing one.

💡
By convention, functions that use async transitions are called “Actions”.

For example, you could handle the pending and error state in useState:

// Before Actions
function UpdateName({}) {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, setIsPending] = useState(false);

  const handleSubmit = async () => {
    try {
      setIsPending(true);
      await updateName(name); // Expect success or a thrown error
      setIsPending(false);
      redirect("/path");
    } catch (error) {
      setError(error.message || "An unexpected error occurred.");
    }
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

React 19 supports using async functions in transitions to handle pending states, errors, forms, and optimistic updates automatically. For example, you can use useTransition to handle the pending state for you:

// Using pending state from Actions
function UpdateName({}) {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();

  const handleSubmit = () => {
    startTransition(async () => {
      try {
        await updateName(name); // Expect success or a thrown error
        redirect("/path");
      } catch (error) {
        setError(error.message || "An unexpected error occurred.");
      }
    })
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

The async transition will immediately set the isPending state to true, make the async request(s), and switch isPending to false after any transitions. This allows you to keep the current UI responsive and interactive while the data is changing.

`<form>` Actions

The React team added support for passing functions as the action.

export default function App() {
    const [name, setName] = useState(
        () => JSON.parse(localStorage.getItem("name")) || "Anonymous user"
    )

    async function formAction(formData){
        try {
            const newName = await updateNameInDB(formData.get("name"))
            setName(newName)
        }
    }

    return (
        <>
            <p className="username">
                Current user: <span>{name}</span>
            </p>
            <form action={formAction}>
                <input
                    type="text"
                    name="name"
                    required
                />
                <button type="submit">Update</button>
            </form>
        </>
    )
}

The formAction function (you can name anything) gets you the form data within its parameter. Each field denoted by name attribute and so you got to be careful in naming inputs. the formData parameter is actually the native FormData Web API object. You can find it out on mdn web docs. Another good thing is you don’t need to apply event.preventDefault() as it is handled by React.

When a form Action succeeds, React automatically resets the form. But if you want to reset the <form> manually, you can call the new requestFormReset React DOM API.

New Hook: `useActionState`

💡
React.useActionState was previously called ReactDOM.useFormState in the Canary releases, but it has been renamed and deprecated useFormState.

useActionState tracks component state, pending status and provides a wrapped action function for use in form or any other place we might want to perform a mutation.

Here is an example to break it down more descriptively:

import { useActionState } from "react"
import { updateNameInDB } from "../api/user"

export default function App() {
    const [user, formAction, isPending] = useActionState(insertName, {
        name: "John Doe",
        error: null
    })

    async function insertName(prevState, formData){
        try {
            const response = await updateNameInDB(formData.get("name"))
            return {name: response.name}
        }catch(error){
            return {...prevState, error: error.error}
        }
    }

    return (
        <>
            {user?.name && (
                <p style={{ color: "green" }}>
                    Current user: <span>{user.name}</span>
                </p>
            )}
            {user?.error && <p style={{ color: "red" }}>{user.error}</p>}

            <form action={formAction}>
                <input
                    type="text"
                    name="name"
                    required
                />
                <button type="submit">Update</button>
            </form>
        </>
    )
}

How this hook works is described with reference to the example:

The first argument of the useActionState hook is the "Action" function, which is defined here as insertName.
The second argument is the initial state, which is accessible through the first element of the result array. In this example, the initial state includes name and error, and the state is represented as user in the component.
The insertName function returns the updated state. If the operation is successful, it updates the name property. If an error occurs, it updates the error property while preserving the rest of the previous state.
The result of the useActionState hook is an array with three elements:
- The current state (user): Reflects the latest state of the data.
- A dispatchable function (formAction): Triggers the action when called, as seen in the form element's action attribute.
- A pending state (isPending): Tracks whether the action is currently in progress, useful for managing transitions or loading indicators.

New Hook: `useOptimistic`

When it’s performing a data mutation and to show the final state right after the user instructs (could be a tap on a button) or you could say optimistically while the async request is underway, you need to use this hook. Here is a demonstration how you can do this:

function ChangeName({currentName, onUpdateName}) {
  const [optimisticName, setOptimisticName] = useOptimistic(currentName);

  const submitAction = async (formData) => {
    const newName = formData.get("name");
    setOptimisticName(newName);
    const updatedName = await updateName(newName);
    onUpdateName(updatedName);
  };

  return (
    <form action={submitAction}>
      <p>Your name is: {optimisticName}</p>
      <p>
        <label>Change Name:</label>
        <input
          type="text"
          name="name"
          disabled={currentName !== optimisticName}
        />
      </p>
    </form>
  );
}

The useOptimistic hook will immediately render the optimisticName while the updateName request is in progress. When the update finishes React will insert the updated value in currentName or if the update gets errors, React will automatically switch back to the currentName value.

New Hook: `useFormStatus`

useFormStatus hook helps you keep track of your form submissions. Wait a minute 🤔! is it another hook to track the async transition? well the answer is ‘yes’ and ‘no’ both. As you have already learnt the useActionState hook, you could say this is another hook for tracking the async transition. But The useFormStatus doesn’t cause any action to happen, rather it provides status information of the last form submission.

import { useFormStatus } from "react-dom";
import action from './actions';

function Submit() {
  const status = useFormStatus();
  return <button disabled={status.pending}>Submit</button>
}

export default function App() {
  return (
    <form action={action}>
      <Submit />
    </form>
  );
}

Well, I would say the most important thing to notice here is useFormStatus hook actually comes from react-dom, not react.

useFormStatus reads the status of the parent <form> as if the form was a Context provider. To get status information, the Submit component must be rendered within a <form>. The Hook returns information like the pending property which tells you if the form is actively submitting.

In the above example, Submit uses this information to disable <button> presses while the form is submitting.

New API: `use`

you can read a promise with use, and React will Suspend the Component until the promise resolves:

import {use} from 'react';

function Comments({commentsPromise}) {
  // `use` will suspend until the promise resolves.
  const comments = use(commentsPromise);
  return comments.map(comment => <p key={comment.id}>{comment}</p>);
}

function Page({commentsPromise}) {
  // When `use` suspends in Comments,
  // this Suspense boundary will be shown.
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Comments commentsPromise={commentsPromise} />
    </Suspense>
  )
}

The example above demonstrates the use case of the use API. ‘Comments’ is a component that consumes a promise called ‘commentsPromise’. The promise is consumed by the new use API which makes it suspend the component. By the way, you have to wrap the component with Suspense fallback.

The use API has a limitation which you must be aware of. The limitation is every time the use API containing component re-renders it creates another promise which lead to bad performance. So, basically it doesn’t have caching mechanism. Here is their cautious note from the release blog:

use API reads data from context as well. For instance, to read context values, we simply pass the context to use(), and the function traverses the component tree to find the closest context provider.

Unlike the useContext() Hook to read context, the use() function can be used within conditionals and loops in our components!

import { use, createContext } from 'react';

const Context = createContext({ data: "Data from context" });

// nested component
function NestedChildComponent({ value }) {
  if (value) {
    const context = use(Context);
  }
}

`ref` as a prop (No `forwardRef`)

In React 19, you can pass refs just like any other prop which leads to deprecation of forwardRef . This streamlines your component code and makes ref handling a breeze. 🧹

function MyInput({placeholder, ref}) {
  return <input placeholder={placeholder} ref={ref} />
}

//...
<MyInput ref={ref} />

The React team has decided to make forwardRef deprecated in the upcoming versions.

React Server Components

By the way, know that React Server Components (RSCs) are a React feature that supports server-side rendering, but frameworks like Next.js have embraced RSCs and integrated them seamlessly into their workflow. If you are new-comer to the ecosystem, get clarified this thing beforehand jumping into studying its mechanism.

React Server Components are a new capability being introduced in React 19 that allows us to create stateless React components that run on the server.

Since React Server Components are able to run on a web server, they can be used to access the data layer without having to interact with an API!

import db from "./database";

// React Server Component
async function BlogPost({ postId }) {
  // Load blog post data from database
  const post = await db.posts.get(postId);

  // Load comments for the post from database
  const comments = await db.comments.getByPostId(postId);

  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.content}</p>

      <h3>Comments</h3>
      <ul>
        {comments.map((comment) => (
          <li key={comment.id}>
            <Comment {...comment} />
          </li>
        ))}
      </ul>
    </div>
  );
}

With this, we don’t have to expose an API endpoint or use additional client-side fetching logic to load data directly into our components. All the data handling is done on the server.

Keep in mind that Server Components are run on the server and not the browser. As a result, they’re unable to use traditional React component APIs like useState. To introduce interactivity to a React Server Component setting, we’ll need to leverage Client Components that complement the Server Components for handling interactivity.

When working with React Server Components, “use client” denotes that the component is a Client Component, which means it can manage state, handle user interactions, and use browser-specific APIs. This directive explicitly tells the React framework and bundler to treat this component differently from Server Components, which are stateless and run on the server.

// React Client Component
"use client"

export function Comment({ id, text }) {
  const [likes, setLikes] = useState(0);

  function handleLike() {
    setLikes(likes + 1);
  }

  return (
    <div>
      <p>{text}</p>
      <button onClick={handleLike}>Like ({likes})</button>
    </div>
  );
}

On the flip-side, React Server Components are the default so we don’t state “use server” at the top of Server Component files. Instead, “use server” should only be used to mark server-side functions that can be called from Client Components.

"use client"

export default function FormComponent() {
  async function handleSubmit(formData) {
    "use server"
    const name = formData.get("name")
    console.log(`Form submitted with name: ${name}`)
    return { success: true, message: `Hello, ${name}!` }
  }

  return (
    <form action={handleSubmit}>
      <label>
        Name:
        <input type="text" name="name" required />
      </label>
      <button type="submit">Submit</button>
    </form>
  )
}

I think this example clarifies it well.

Conclusion

React 19 is still called React Canary. So, it will not be a good idea to use it for production. But embrace the future with React 19 and make your development experience smoother and more enjoyable.

Dockerize PERN-TypeScript App Using Prisma ORM With Docker Compose

Abdul Ahad Abeer — Wed, 16 Oct 2024 15:31:59 +0000

Introduction

This article won't go into detailed explanations. Instead, I’ll just provide the code snippets you need to dockerize a PERN stack application. If you want a more detailed explanation, check out this article where I’ve covered everything in more depth.

The Project Structure

pern-project/
--- frontend/
------ .dockerignore
------ frontend.dockerfile
------ ...
--- backend/
------ .dockerignore
------ backend.dockerfile
------ ...
--- docker-compose.yml

Code Backend

Create a node.js-express.js app first:

mkdir backend && cd backend
npm init -y

Install all the necessary dependencies from npm:

npm install express dotenv cors

Install Typescript related dev dependencies as well:

npm install --save-dev typescript ts-node @types/express @types/node @types/cors

Generate tsconfig.json file:

tsc --init

Replace everything inside tsconfig.json with this piece of code in the following:

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "rootDir": "./src",
    "outDir": "./dist",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*.ts", "data-types.d.ts"]
}

Create src folder and index.ts file inside src folder. So, now the backend folder structure:

backend/
--- node_modules/
--- src/
------ index.ts
--- package.json
--- tsconfig.json
--- ...

Integrate Postgres With Prisma

Install Prisma and Prisma Client first:

npm i @prisma/client
npm i --save-dev prisma

Generate a prisma folder:

npx prisma init

Write a User model in the schema.prisma file:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id        String   @id @default(uuid())
  name      String
  username  String
  email     String
  password  String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  @@map("users")
}

Set DATABASE_URL in the .env file:

DATABASE_URL=postgresql://postgres:postgres@db:5432/pern_db?schema=public

Create a file prismadb.ts in the src folder:

import { PrismaClient } from "@prisma/client"
import "dotenv/config"

// Extend the global object with PrismaClient
declare global {
  var prisma: PrismaClient | undefined
}

// Prevent multiple instances of Prisma Client in development
const prisma = global.prisma || new PrismaClient()

if (process.env.NODE_ENV !== "production") global.prisma = prisma

export default prisma

Define /register endpoint in the index.ts file. The index.ts file:

import express, { Request, Response } from "express"
import "dotenv/config"
import cors from "cors"
import { corsOptions } from "./constants/config"

const app = express()
const PORT = process.env.PORT || 3000

app.use(express.json())
app.use(express.urlencoded({ extended: true }))
app.use(cors({
    const corsOptions = {
    origin: process.env.CLIENT_URL || 'http://localhost:5173',
    credentials: true,
  }
}))

app.get("/", (req: Request, res: Response) => {
  res.json({
    message: "Hello, TypeScript with Express! Updated!",
  })
})

app.post("/register", async (req: Request, res: Response) => {
  const { name, username, email, password } = req.body

  await prisma.user.create({
    data: {
      name,
      username,
      email,
      password,
    },
  })

  res.json({
    message: "User created successfully",
  })
})

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`)
})

Backend Dockerfile

Create a file naming backend.dockerfile in the root of the backend directory and write:

FROM node:20
WORKDIR /app
COPY package*.json .
RUN npm install
COPY prisma ./prisma
RUN npx prisma generate
COPY . .
EXPOSE 3000
RUN npm install -g nodemon ts-node
CMD ["nodemon", "src/index.ts"]

To exclude node_modules, create a .dockerignore file:

node_modules

Code Frontend

Create the frontend:

npm create vite@latest frontend -- --template react-ts

Make API call in the React app:

// App.tsx

import { FormEvent, useEffect, useState } from "react"
....

function App() {
  const [name, setName] = useState("")
  const [username, setUsername] = useState("")
  const [email, setEmail] = useState("")
  const [password, setPassword] = useState("")

  const saveUser = async (e: FormEvent) => {
    e.preventDefault()
    await fetch("http://localhost:3000/register", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        name,
        username,
        email,
        password,
      }),
    })
      .then((res) => res.json())
      .then((data) => console.log(data))
  }

  useEffect(() => {
    fetch("http://localhost:3000")
      .then((res) => res.json())
      .then((data) => console.log(data))
  }, [])

  return (
    <>
      <form onSubmit={saveUser}>
        <input
          type="text"
          onChange={(e) => setName(e.target.value)}
          placeholder="Enter your name"
        />
        <input
          type="text"
          onChange={(e) => setUsername(e.target.value)}
          placeholder="Enter your username"
        />
        <input
          type="email"
          onChange={(e) => setEmail(e.target.value)}
          placeholder="Enter your email"
        />
        <input
          type="password"
          onChange={(e) => setPassword(e.target.value)}
          placeholder="Enter your password"
        />
        <button type="submit">Submit</button>
      </form>
    </>
  )
}

export default App

Frontend Dockerfile

Create a file naming frontend.dockerfile in the root of the frontend directory and write:

FROM node:20
WORKDIR /app
COPY package*.json .
RUN npm install
EXPOSE 5173
COPY . .
CMD [ "npm", "run", "dev" ]

Docker-Compose file

Add the following in the .env file of the backend folder:

// backend/.env

POSTGRES_USER=postgres
POSTGRES_PASSWORD=postgres
POSTGRES_DB=pern_db

DATABASE_URL=postgresql://postgres:postgres@db:5432/pern_db?schema=public

The docker-compose.yml file:

services:
  frontend:
    container_name: frontend
    build:
      context: ./frontend
      dockerfile: frontend.dockerfile
    ports:
      - "5173:5173"
    networks:
      - pern_net
    volumes:
      - ./frontend:/app
      - /app/node_modules
    depends_on:
      - server

  backend:
    container_name: backend
    build:
      context: ./backend
      dockerfile: backend.dockerfile
    env_file:
      - ./backend/.env
    ports:
      - "3000:3000"
    networks:
      - pern_net
    volumes:
      - ./backend:/app
      - /app/node_modules
    depends_on:
      - db

  db:
    container_name: db
    image: postgres:14
    restart: always
    ports:
      - "5432:5432"
    networks:
      - pern_net
    env_file:
      - ./backend/.env
    volumes:
      - pgdata:/data/db

networks:
  pern_net:
    driver: bridge

volumes:
  pgdata: {}

Run this command:

docker compose up -d

Migrate the prisma schema:

docker backend -it backend npx prisma migrate dev --name init

Simplifying Type Narrowing and Guards in TypeScript

Abdul Ahad Abeer — Wed, 09 Oct 2024 07:15:45 +0000

Introduction to Narrowing Concept

Typescript documentation explains this topic really well. I am not going to copy and paste the same description here, rather I want to make it even simpler and shorter. Let’s look at a problem and see how the concept of narrowing helps us when coding in TypeScript.

Look at the code very carefully. The explanation is written below the code snippet.

function padLeft(padding: number | string, input: string): string {
    return " ".repeat(padding) + input;
}

If padding is a number, it will be treated as the number of spaces we want to prepend to input since padding passed through repeat means padding has to be a number value.

Now, the moment padLeft function is called, it throws an error which looks somewhat like this:

"Argument of type 'string | number' is not assignable to parameter of type 'number'. Type 'string' is not assignable to type 'number'."

TypeScript is warning us that we’re passing a value with type number | string to the repeat function, which only accepts a number, and it’s right. In other words, we haven’t explicitly checked if padding is a number first, nor are we handling the case where it’s a string, so let’s do exactly that.

function padLeft(padding: number | string, input: string): string {
  if (typeof padding === "number") {
    return " ".repeat(padding) + input;
  }
  return padding + input;
}

When we write if (typeof padding === "number"), TypeScript knows we are checking if padding is a number. This kind of check is called a "type guard." TypeScript looks at the code and tries to figure out the exact type of a value. When TypeScript makes a type more specific through these checks, it’s called "narrowing."

Type Guards

Type Guards are runtime checks that allow TypeScript to infer a more specific type of a variable within a conditional block. TypeScript uses these checks to "guard" against invalid operations by ensuring that the variable has the expected type.

The most common built-in type guards in TypeScript are:

typeof: Checks if a variable is a primitive type (e.g., string, number, boolean, etc.)
instanceof: Checks if a variable is an instance of a class or constructor function.

There is an example of typeof in the previous section where you can see how typeof narrows down a union type to a specific one.

But here is an example of using instanceof:

class Dog {
  bark() {
    console.log("Woof!");
  }
}

class Cat {
  meow() {
    console.log("Meow!");
  }
}

function animalSound(animal: Dog | Cat) {
  if (animal instanceof Dog) {
    animal.bark(); // TypeScript knows `animal` is a `Dog` here
  } else {
    animal.meow(); // TypeScript knows `animal` is a `Cat` here
  }
}

In this example, instanceof is used to narrow the type of animal to either Dog or Cat. This allows us to safely call the appropriate method (bark() or meow()) based on the type of animal.

Truthiness narrowing

Truthiness might not be a word you’ll find in the dictionary, but it’s very much something you’ll hear about in JavaScript.

Truthiness narrowing in TypeScript refers to the way TypeScript refines types based on conditions (&&s, ||s, if statements, Boolean negations (!), and more) that check if a value is "truthy" or "falsy." Values like false, 0, null, undefined, NaN, and "" (empty string) are considered falsy, while all other values are truthy.

When you use an if statement, TypeScript automatically narrows the type by excluding falsy values from the possible types.

function printMessage(message: string | null) {
  if (message) {
    // TypeScript knows 'message' can't be null here, it's narrowed to 'string'
    console.log(message.toUpperCase());
  } else {
    console.log("No message provided.");
  }
}

printMessage("Hello");   // Output: HELLO
printMessage(null);      // Output: No message provided.

In the if (message) block, TypeScript narrows the type from string | null to just string, since null is falsy and won't pass the condition.

You can always convert a value to a boolean by using the Boolean function or by using !! (double negation). The !! method has an advantage: TypeScript understands it as a strict true or false, while the Boolean function just gives a general boolean type.

const value = "Hello";

// Using Boolean function
const bool1 = Boolean(value);  // type: boolean

// Using double negation (!!)
const bool2 = !!value;         // type: true

To be specific understand this:

bool1's value is a boolean type value, meaning it can be either true or false. TypeScript just knows it's a boolean, but it doesn't specify which one.
bool2's value is considered a literal type—either exactly true or exactly false, depending on the value of !!value. In this case, since "Hello" is truthy, bool2 will be of type true.

Equality Narrowing

Equality narrowing in TypeScript happens when TypeScript refines the type of a variable based on an equality check (like === or !==). This means that after the check, TypeScript can "narrow" the possible types of a variable because it now knows more about it.

function example(value: string | number) {
  if (typeof value === "number") {
    // Here, TypeScript knows value is a number
    console.log(value.toFixed(2));  // Safe to use number methods
  } else {
    // In this block, TypeScript narrows value to string
    console.log(value.toUpperCase());  // Safe to use string methods
  }
}

The `in` operator narrowing

The in operator narrowing in TypeScript helps us figure out if an object has a specific property, and it also helps TypeScript refine (narrow) the types based on that check.

When you use "propertyName" in object, TypeScript checks if the object (or its prototype) has the property. Based on whether the check is true or false, TypeScript can understand more about the type of that object.

If the check is true (the property exists), TypeScript narrows the object’s type to include the types that have this property (either required or optional).
If the check is false (the property doesn't exist), TypeScript narrows the type to exclude types that have this property.

type Cat = { meow: () => void };
type Dog = { bark: () => void };

function speak(animal: Cat | Dog) {
  if ("meow" in animal) {
    // TypeScript now knows 'animal' must be a Cat
    animal.meow();
  } else {
    // TypeScript now knows 'animal' must be a Dog
    animal.bark();
  }
}

In the if ("meow" in animal) check, TypeScript checks if the animal has the meow method. If it does, TypeScript knows the animal is a Cat. If not, TypeScript knows it’s a Dog.

Using type predicates

Type predicates in TypeScript are a way to narrow down the type of a variable using a function that returns a boolean. They help TypeScript understand what type a variable is after the check.

A type predicate is written as parameterName is Type. When you use this in a function, TypeScript knows that if the function returns true, the parameter is of that specific type.

type Fish = { swim: () => void };
type Bird = { fly: () => void };

function isFish(animal: Fish | Bird): animal is Fish {
  return (animal as Fish).swim !== undefined;  // Check if animal has a swim method
}

function move(animal: Fish | Bird) {
  if (isFish(animal)) {
    // TypeScript knows 'animal' is a Fish here
    animal.swim();
  } else {
    // TypeScript knows 'animal' is a Bird here
    animal.fly();
  }
}

Simple explanation:

The isFish function checks if the animal has a swim method.
If it does, the function returns true, and TypeScript understands that animal is a Fish.
If it doesn't, TypeScript knows it's a Bird.

Discriminated unions

Discriminated Unions are a pattern in TypeScript where you can use a common property (called a "discriminant") to differentiate between different object types in a union.

Look at the following example.

interface Car {
  kind: "car";
  drive: () => void;
}

interface Bike {
  kind: "bike";
  pedal: () => void;
}

type Vehicle = Car | Bike;

function operateVehicle(vehicle: Vehicle) {
  switch (vehicle.kind) {
    case "car":
      vehicle.drive(); // TypeScript knows `vehicle` is a `Car` here
      break;
    case "bike":
      vehicle.pedal(); // TypeScript knows `vehicle` is a `Bike` here
      break;
  }
}

Here, the kind property is the discriminant. TypeScript uses it to narrow the Vehicle type to either Car or Bike based on the value of kind.

Exhaustiveness checking

Exhaustiveness checking in TypeScript ensures that all possible cases of a union type are handled in your code. When you use type narrowing (like with if statements or switch cases), TypeScript checks if all types in a union have been considered. If any case is missing, TypeScript will give you an error, helping you catch potential bugs.

type Cat = { type: "cat"; meow: () => void };
type Dog = { type: "dog"; bark: () => void };
type Animal = Cat | Dog;

function makeSound(animal: Animal) {
  switch (animal.type) {
    case "cat":
      animal.meow();  // TypeScript knows 'animal' is Cat here
      break;
    case "dog":
      animal.bark();  // TypeScript knows 'animal' is Dog here
      break;
    default:
      // This will give an error if we add more animal types
      const _exhaustiveCheck: never = animal;
      throw new Error(`Unknown animal: ${animal}`);
  }
}

The Animal type is a union of Cat and Dog. In the makeSound function, we check the type property of animal.

Exhaustiveness Check:

If we handle both cat and dog, everything is fine.
If we later add another animal type, like Bird, and forget to update the switch statement, TypeScript will show an error at the default case. This error happens because the default case is assigned a never type, meaning it shouldn’t happen if all possible types are accounted for.

Other Ways of Type Narrowing

Assignments: when we assign to any variable, TypeScript looks at the right side of the assignment and narrows the left side appropriately.

let x = Math.random() < 0.5 ? 10 : "hello world!";

Type narrowing with never type: The never type in TypeScript represents values that never occur. It is often used to indicate unreachable code, such as when a function always throws an error or has an infinite loop. When TypeScript recognizes a never type, it can narrow down types effectively.

function assertIsString(value: string | number) {
  if (typeof value !== "string") {
    // If value is not a string, throw an error
    throw new Error("Not a string!");
  }
  // Here, TypeScript knows 'value' is a string
  console.log(value.toUpperCase());
}

In the assertIsString function, if value is not a string, we throw an error. TypeScript understands that if it reaches the console.log, value must be a string. If it were anything else, the function would not complete normally, leading to a never type.

Last Words

I am sure you got the point of narrowing concept. We can have other possible ways to narrow down types. But I believe the explanation and knowledge you have gained so far from this article is more than enough to grasp the concept and utilize it. Let me know if this was beneficial for you.

The Simplest Zustand Tutorial

Abdul Ahad Abeer — Wed, 02 Oct 2024 16:01:49 +0000

Zustand is a small, fast, and scalable state-management library for React, which serves as an alternative to more complex solutions like Redux. The main reason Zustand gained so much traction is its small size and simple syntax compared to Redux.

Understand Zustand Setup

First, you need to install Zustand and TypeScript if you haven't already.

npm install zustand
'or'
yarn add zustand

Zustand provides a create function to define your store. Let's walk through a basic example where we store and manipulate a count value.

Let’s create a file called store.ts where we have a custom hook useCounterStore():

import { create } from "zustand"

type CounterStore = {
    count: number
    increment: () => void
    resetCount: () => void
}

export const useCounterStore = create<CounterStore>((set) => ({
    count: 0
    increment: () => set((state) => ({ count: state.count + 1 })),
    resetCount: () => set({ count: 0 })
}))

In this example:

count is a piece of state.
increaseCount and resetCount are actions that modify the state.
set is a function provided by Zustand to update the store.

Using the Store in a React Component

import React from 'react'
import { useCounterStore } from './store'

const Counter: React.FC = () => {
  const count = useCounterStore((state) => state.count) // Get count from the store
  const increment = useCounterStore((state) => state.increment) // Get the action

  return (
    <div>
      <h1>{count}</h1>
      <button onClick={increment}>Increase Count</button>
    </div>
  )
}

export default Counter;

Here, Counter is a React Component. As you can see, useCounterState() is used to access count and increment.

You can destructure the state instead of getting them directly like how it is in the following:

const {count, increment} = useCounterStore((state) => state)

But this approach makes it less performant. So, the best practice is to get access to the state directly like how it is shown before.

Asynchronous Actions

Making asynchronous action or calling API request to the server is also pretty simple in Zustand. Here, the following code explains it all:

export const useCounterStore = create<CounterStore>((set) => ({
    count: 0
    increment: () => set((state) => ({ count: state.count + 1 })),
    incrementAsync: async () => {
        await new Promise((resolve) => setTimeout(resolve, 1000))
        set((state) => ({ count: state.count + 1 }))
    },
    resetCount: () => set({ count: 0 })
}))

Doesn’t it seem like a generic async function in JavaScript? First of all it runs the asynchronous code and then it sets the state with the given value.

Now, let’s see how you can use it on a react component:

const OtherComponent = ({ count }: { count: number }) => {
  const incrementAsync = useCounterStore((state) => state.incrementAsync)

  return (
    <div>
      {count}
      <div>
        <button onClick={incrementAsync}>Increment</button>
      </div>
    </div>
  )
}

How to access the state outside React Component

Until now, you've only accessed state inside React components. But what about accessing state from outside of React components? Yes, with Zustand you can access state from outside React Components.

const getCount = () => {
  const count = useCounterStore.getState().count
  console.log("count", count)
}

const OtherComponent = ({ count }: { count: number }) => {
  const incrementAsync = useCounterStore((state) => state.incrementAsync)
  const decrement = useCounterStore((state) => state.decrement)

  useEffect(() => {
    getCount()
  }, [])

  return (
    <div>
      {count}
      <div>
        <button onClick={incrementAsync}>Increment</button>
        <button onClick={decrement}>Decrement</button>
      </div>
    </div>
  )
}

Here, you can see getCount() is accessing to state by getState()

We can set count as well:

const setCount = () => {
  useCounterStore.setState({ count: 10 })
}

Persist Middleware

The persist middleware in Zustand is used to persist and rehydrate the state across browser sessions, typically using localStorage or sessionStorage. This feature allows you to keep the state even after a page reload or when the user closes and reopens the browser. Here’s a detailed breakdown of how it works and how to use it.

Basic Usage of `persist`

Here’s how to set up a Zustand store with persist:

import create from 'zustand';
import { persist } from 'zustand/middleware';

// Define the state and actions
interface BearState {
  bears: number;
  increase: () => void;
  reset: () => void;
}

// Create a store with persist middleware
export const useStore = create<BearState>(
  persist(
    (set) => ({
      bears: 0,
      increase: () => set((state) => ({ bears: state.bears + 1 })),
      reset: () => set({ bears: 0 }),
    }),
    {
      name: 'bear-storage', // Name of the key in localStorage
    }
  )
);

The state is saved under the key "bear-storage" in localStorage. Now, even if you refresh the page, the number of bears will persist across reloads.

By default, persist uses localStorage, but you can change it to sessionStorage or any other storage system. There are many things to cover on the topic of persisting state in Zustand. You will get a detailed tutorial/post on this topic, which will follow this post.

Conclusion

We all know how great is Redux as a state management tool. But Redux possess a kinda complex and large boilerplate. That is why more and more developers are choosing Zustand as their state management tool which is simple and scale-able.

But still you will see Redux is more recommended for seriously complex and nested state management.

DEV Community: Abdul Ahad Abeer

Edge Runtime and Edge Functions in Next.js — Explained the Easy Way

What is Edge Computing?

What is Edge Runtime?

What are Edge functions?

Why Route Handlers Are the "Main" Home for Edge Functions

Conclusion

Cache Components and Partial Pre-Rendering (PPR) in Next.js 16

Cache Components

How to enable cacheComponents

use cache Directive

cacheLife Function

Must-Known Facts

cacheTag Function

Partial Pre-Rendering

The Binary Choice Problem

The Concept of Partial Prerendering

Suspense Boundary ( React )

Enabling the Feature

How This Looks in Practice

Last Words

Everything you need to know on JWT Authentication

Stateful Authentication

Problems with Storing Server-Side Sessions

Stateless Authentication

Dissect JWT

How signature is created?

How to create JWT Authentication

Code - Project-wise

Authorization

How to make refreshToken work along?

How would the frontend (React) send refresh request behind the scene?

All You Need to Know About the useCallback Hook

What is Function Recreation in React Components?

Why is Function Recreation a Problem?

Problem 1: Function Recreation Causes Unnecessary Child Re-renders

What's Wrong Here?

Problem 2: Function Recreation Causes Unnecessary useEffect Runs

What's Wrong Here?

How useCallback Solves Function Recreation

When It Needs to Re-create Functions

TanStack Table - Quick Learning

Basic React Table

Render Rows and Cells

Set Footer

Custom Cell Rendering

Accessor Function - accessorFn

Header Groups with Child Columns

Pagination

Sorting

Filtering

Master Drizzle ORM

A Few Important Words

Introduction

Prerequisites

Setup

Drizzle Config

Write Schema for Tables

One-to-One Relation

One-to-Many Relation

Many-to-Many Relation

Zod Schema from Table Schema

Configuring DB Object

Database Migration

Script for Migration

CRUD Operations Using DB Object

Get Data

Create / Post Data

Update Data

Delete Data

Difference Between SQL-style Query Builder And ORM-style Query API

SQL-style Query Builder

Without Using a Schema

Using Schema (post table object)

Without Using a Schema

ORM-style Query API

Conclusion

Infinite Scrolling of TanStack Query 🌸

Tanstack Query / React Query 🌸

Intro

`use cache` Directive

`cacheLife` Function

`cacheTag` Function

Problem 2: Function Recreation Causes Unnecessary `useEffect` Runs

How `useCallback` Solves Function Recreation

Using Schema (`post` table object)

`isLoading` vs `isPending` vs `isFetching`, `fetchStatus`, `status`

`status`

`fetchStatus`

`isLoading` vs `isPending` vs `isFetching`

Parallel queries with `useQueries`

`useMutation()` used for posting, updating and deleting

`onSettled`

Update Data with `useMutation`

Delete Data with `useMutation`

Actions (`useTransition` hook)

`<form>` Actions

New Hook: `useActionState`

New Hook: `useOptimistic`

New Hook: `useFormStatus`

New API: `use`

`ref` as a prop (No `forwardRef`)

The `in` operator narrowing

Basic Usage of `persist`