DEV Community: Ango Jeffrey

Shipping My First Production Site with Lovable: What I Learned

Ango Jeffrey — Sun, 19 Apr 2026 15:46:51 +0000

I’ve spent the better part of my career building things the traditional way: hand-coding components, managing state, and meticulously translating Figma files into code. However, for a recent project, we decided to try a different workflow to build and ship a production level website using an AI tool.

We used Lovable to see if we could bridge the gap between design and production faster. It was an eye-opening experience. In this post, I'll break down our process, where the tool truly surprised us, and the specific areas where an engineer’s touch remains non-negotiable.

The Workflow: Designer in the Driver's Seat

In a typical sprint, a designer would hand me a file and I’d spend days or weeks recreating it. With Lovable, the roles shifted significantly. The designer was able to handle most of the actual UI implementation directly within the tool.

Faster Iterations: Instead of waiting for me to "code it up" to see how a layout flowed, the designer could iterate in real-time.
Rapid Feedback: We could look at a live URL within minutes of an idea being sparked.

This shift allowed us to focus on the user experience rather than the implementation details during the early stages.

Where the Developer Comes In: Guiding the AI

There’s a misconception that AI-driven tools make developers obsolete. In reality, they just change our focus. While Lovable handled the bulk of the UI, I had to step in as the architect to ensure the site was professional, functional, and scalable.

1. Responsive UI Fixes

AI is powerful, but it doesn't always account for every edge case. I guided Lovable through specific responsive fixes to ensure that complex layouts didn't break on tablets or ultra-wide monitors. This required a solid understanding of CSS Flexbox and Grid to tell the AI exactly how to restructure elements for those tricky breakpoints.

2. Global State Management

This is where the difference between a "working" site and a "well-engineered" site becomes clear. Initially, the AI wanted to duplicate modal code across multiple pages. I stepped in and instructed it to implement a Global State Management pattern using React Context.

I specifically chose React Context because I wanted to keep the codebase lean and simple without the overhead of heavier state management libraries. By managing the modal state at the Layout level, we prevented code duplication and kept the app performant and easy to maintain.

3. API Integration

A production site needs to actually function. I handled the heavy lifting of connecting the UI to our backend services, which involved structuring data fetching logic, handling loading states, and ensuring secure communication between the frontend and our APIs.

4. Hardening SEO for Production

AI tools often provide the "bones" of a site but rarely give you the necessary visibility. To make this site production-ready, I manually guided the implementation of:

Meta & Open Graph Tags: Ensuring the site looks professional on social media with custom OG images.
Schema Structured Data: Helping search engines understand the content hierarchy.
Technical SEO Assets: Generating a sitemap.xml, a robots.txt file, and a site.webmanifest.

The Professional Bridge: GitHub & CI/CD

The last and most important step was the GitHub sync. For this to be a professional project, it couldn't live in a silo.

I synced the Lovable project to a GitHub repository, which allowed me to review the generated code for quality, add custom logic, and set up GitHub Workflows for automated deployment. Now, every significant change triggers a proper CI/CD pipeline to keep our production environment up to date.

The Verdict: The Tool vs. The Craftsman

Lovable is an absolute game-changer for websites and straightforward web apps. It allowed us to ship at a speed that would have been impossible just a few months ago. It empowered the designer to be more involved in the build and allowed me to focus on high-level engineering.

A Note on Stack & Constraints

One caveat I had with Lovable was the stack limitation. Given the choice, I would have preferred to use Astro for this project. Astro’s SEO-friendly architecture, faster deployment build times, and high level of customizability make it an ideal choice for content-heavy sites. However, Lovable doesn't support it currently, so we optimized within the React ecosystem.

Looking Ahead

While this worked perfectly for this project, more complex applications still demand intricate knowledge of state management and component architecture. As an engineer, you still need to know:

Component Strategy: Determining what should be a reusable component to avoid duplication.
Complex State: Knowing how to structure data flow beyond simple contexts.
Optimization: Preventing unnecessary re-renders in data-heavy environments.

The takeaway is clear: AI builds the house, but the engineer ensures the foundation is solid. You still need to know what you’re doing to achieve the best results.

Have you tried building with Lovable yet? I’d love to hear how your workflow changed in the comments!

Why We Think in Systems: The Blueprint for Sustainability

Ango Jeffrey — Thu, 02 Apr 2026 12:10:44 +0000

We humans have a natural obsession with order. From the way we map the stars to the way we structure a workday, we are constantly searching for "the system." But thinking in systems isn't just about being organised, it is a fundamental strategy for predictability, scalability, and long-term survival.

Here is a breakdown of why systems are the essential foundation for any successful endeavour.

1. The Power of Predictability

The core premise of a system is that it reveals patterns. When we view a challenge through a systemic lens, we move away from reacting to isolated incidents and toward understanding the underlying mechanics.

2. Engineering for the Future (Maintainability)

In the world of software engineering, code is rarely a "write once and forget" task. A developer’s goal is to build something that lasts.

The Hand-off: Writing code within a system (using established frameworks and documentation) ensures that the next engineer can understand the logic.
Legacy: Systems prevent "knowledge silos." When the system is the source of truth, the project doesn't collapse just because the original creator moved on.

3. Business Scalability and SOPs

A successful business is rarely the result of a single person’s daily brilliance; it is the result of Standard Operating Procedures (SOPs). Without them, a business is just a series of lucky breaks that cannot be scaled.

Why successful businesses lean on systems: Codifying the "Secret Sauce": SOPs take the intuitive knowledge of a founder and turn it into a manual. This ensures that the quality remains consistent whether the CEO is in the room or not.
The Repeatability Factor: Systems ensure that tasks are performed with the same level of excellence every single time. This predictability is what allows a small startup to grow into a global enterprise.
Removing "Hero Dependence": When a business relies on one "hero" employee to save the day, it is fragile. Systems move the power from the individual to the process, ensuring longterm viability and health.
Key Takeaway: The goal of a business system is to make success a repeatable habit rather than a onetime event.

4. The Relationship Between Systems and Creativity

A common misconception in the dev community is that systems stifle creativity. In reality, systems provide the foundation that makes meaningful innovation possible.

The Architect Analogy
Think of an architect designing a high rise. The structural integrity, the plumbing, and the electrical grids are all rigid systems. These non negotiables don't stop the architect from being creative with the facade or the interior flow; instead, they provide the safety and stability required to explore bold new designs.

Creative Freedom: When the "boring" parts (the foundation) are handled by the system, your brain is free to innovate on the "user experience."
The Innovation Loop: New, proven innovations eventually become "best practices." Over time, today’s breakthrough becomes tomorrow’s system.

5. The Ultimate Goal: Sustainability

At its heart, the idea of a system is sustainability.

Whether it is a codebase that survives for a decade, a business that thrives across generations, or a creative process that never runs dry, systems allow us to build things that outlast our immediate efforts. We think in systems because we want the things we create to endure.

My Experience with Systems

Having spent over 6 years as a software engineer, I’ve seen projects at every stage of their lifecycle. Whether I’m joining a team to kick off a greenfield project or stepping into a decade-old brownfield codebase, my first instinct is always to reach for systems.

Here is how that looks in practice:

For New Projects: I leverage established systems and best practices honed from previous wins. Starting with a proven structure means I don't have to reinvent the wheel for every new feature.
For Brownfield Projects: I take the time to study the codebase to understand the existing patterns and conventions—assuming the previous engineers didn't leave a plate of spaghetti code behind 😅!

The ROI of Systems
Thinking this way isn't just about "neatness." It fundamentally improves the Developer Experience (DX). When the system is clear, you stop wrestling with the environment and start focusing on what actually matters: achieving business goals as fast as possible in the most scalable and secure way.

From Heavy to Lightweight: Compressing Images in Expo for Better Performance

Ango Jeffrey — Tue, 10 Feb 2026 09:34:40 +0000

Hey there, mobile dev 👋 Ever noticed how some apps load images instantly, while others leave you staring at a spinner or some other loading animation or worse just a blank screen? Yep image compression is often the unsung hero.

Big, unoptimised images can slow down your mobile app, eat up user data, and even make your app feel clunky. But don't worry, in this guide, we'll learn how to shrink those images down to size using Expo's powerful tools, making your app smoother and more professional.

Let's dive in!

Why Bother With Compression in the First Place?
Imagine your app is a fancy restaurant. If every dish is huge and takes ages to serve, customers will get impatient and leave! Similarly, if your app tries to load massive image files:

Slower Loading: Your users will stare at blank screens longer.

More Data Usage: Especially bad for users on limited data plans.

Increased Storage: Bigger app bundles.

Poor SEO (this one is for web apps): Search engines prefer fast-loading websites.

By compressing images, we make them "lighter," so they load faster and provide a better experience for everyone.

Our Goal: The 100KB Sweet Spot

For many mobile and web images, you really want to hit that sweet spot of 100 -200kb. This is often small enough to load quickly without sacrificing too much visual quality. In this guide we'll also be converting our images to WebP format, which is like a magic trick for better compression and it’s supported on most modern devices (Android, and iOS from version 14 and up).

The Tool: `expo-image-manipulator`

Since we did put expo in our title, it should be no surprise that our tool of choice is expo-image-manipulator, this tool lets us resize, crop, rotate, and compress images right on the user's device. No need to send images to a server just to shrink them!

Step 1: Install the Manipulator

First things first, let's get the tool:

npx expo install expo-image-manipulator

Step 2: The Core Idea - Iterative Compression

Instead of just trying to compress once and hoping for the best, we'll use an "iterative" approach. Think of it like a sculptor: they don't just whack off a huge chunk of marble; they chip away gradually until they get the perfect shape.

Our compression will:

Try to compress the image.
Check its size.
If it's still too big, try again with slightly lower quality or smaller dimensions.
Repeat until it's small enough or we decide it's "good enough."

Here’s a look at the logic we'll use:

import { ImageManipulator, SaveFormat } from 'expo-image-manipulator';
import * as FileSystem from 'expo-file-system';

/**
 * Compress image for SEO
 * Target: 100KB max size, iterative compression with quality and dimension reduction
 */
export const compressImageWithExpo = async (
  imageUri: string, // The local URI of the image (e.g., from ImagePicker)
  fileName: string   // The original file name (e.g., "my-photo.jpg")
): Promise<string | null> => {
  try {
    const targetMaxSizeKB = 100 * 1024; // 100KB in bytes
    let currentQuality = 0.85;        // Starting compression quality
    const reductionFactor = 0.9;      // How much to reduce dimensions each time
    const maxIterations = 7;          // Safety limit to prevent endless loops

    // 1. Get original image dimensions
    const imageInfo = await ImageManipulator.manipulate(imageUri, [], {
      compress: 1, // We just want info, not to compress yet
      format: SaveFormat.PNG // Format doesn't matter for info
    });

    // Default to common sizes if info is missing
    let currentWidth = imageInfo.width || 1920;
    let currentHeight = imageInfo.height || 1080;

    // Note: ImageManipulator.manipulate() automatically
 // closes the file handle after running so we dont have to worry 
// about memory leaks 

    // 2. Check original file size to decide if we need aggressive reduction
    let originalSize = 0;
    try {
      const info = await FileSystem.getInfoAsync(imageUri);
      if (info.exists) {
        originalSize = info.size || 0;
      }
    } catch (e) {
      console.warn("Could not get original file info:", e);
    }
    const needsAggressiveReduction = originalSize > 2 * 1024 * 1024; // > 2MB

    // This is our recursive function that keeps compressing
    const compressImageIteratively = async (
      width: number,
      height: number,
      quality: number,
      iteration: number = 0
    ): Promise<string> => {
      // Safety check: stop if we've tried too many times
      if (iteration >= maxIterations) {
        console.warn('Max compression iterations reached. Returning last best attempt.');
        // Even if over limit, return the last generated URI
        const finalResult = await ImageManipulator.manipulate(imageUri, [
          { resize: { width: width, height: height } }
        ], {
          compress: quality,
          format: SaveFormat.WEBP,
        });
        return finalResult.uri;
      }

      // Try compressing with current settings
      const compressedResult = await ImageManipulator.manipulate(imageUri, [
        { resize: { width: width, height: height } } // Resize first
      ], {
        compress: quality,             // Then compress
        format: SaveFormat.WEBP,       // And convert to WebP
      });

      // Get the size of the newly compressed image
      const fileInfo = await FileSystem.getInfoAsync(compressedResult.uri);
      const fileSize = fileInfo.exists ? (fileInfo.size || 0) : 0;

      // Check if we hit our target size
      if (fileSize <= targetMaxSizeKB) {
        console.log(`Image compressed to ${Math.round(fileSize / 1024)}KB`);
        return compressedResult.uri; // Success!
      } else if (width > 300 && height > 300 && quality > 0.4) {
        // Still too big, AND we have room to shrink further
        const widthReduction = needsAggressiveReduction && iteration === 0 ? 0.5 : reductionFactor;
        const heightReduction = needsAggressiveReduction && iteration === 0 ? 0.5 : reductionFactor;

        console.log(`Still too big (${Math.round(fileSize / 1024)}KB). Reducing dimensions and quality...`);

        // Call ourselves again with smaller dimensions and lower quality
        return compressImageIteratively(
          Math.floor(width * widthReduction),
          Math.floor(height * heightReduction),
          quality - 0.05, // Reduce quality slightly
          iteration + 1
        );
      } else {
        // We can't shrink it any further without making it tiny or ugly
        console.warn('Could not reach target size, returning best possible compression.');
        return compressedResult.uri;
      }
    };

    // Start the iterative compression process
    return await compressImageIteratively(currentWidth, currentHeight, currentQuality, 0);

  } catch (error) {
    console.error("Unable to compress image : ", error);
    return null; // Something went wrong
  }
};

Code Breakdown for Beginners:

targetMaxSizeKB: Our desired limit (100KB).
currentQuality: Starts high (0.85 means 85% quality) and goes down.
reductionFactor: Each time we retry, we multiply the width/height by 0.9 (making it 90% of its previous size).
maxIterations: If our loop runs 7 times and the image is still too big, we just stop and use the best result we got. This prevents endless loops!
FileSystem.getInfoAsync(uri): This is how we check the size of a file on the device. Super important!
ImageManipulator.manipulate(imageUri, actions, options): This is the core function.
- imageUri: The path to the image on the device, this will come from the image picker you're using (eg expo-image-picker)
- actions: An array of things to do (like { resize: { width: ..., height: ... } }).
- options: How to save it (like { compress: ..., format: SaveFormat.WEBP }).

SaveFormat.WEBP: This tells expo-image-manipulator to save the image as a WebP file, which is usually smaller than JPG or PNG for the same quality.

recursive function (compressImageIteratively): This function calls itself if the image is still too big, but with slightly smaller dimensions and lower quality. It's like saying, "Okay, that didn't work. Let's try again, but be a bit more aggressive this time!"

How to Use It in Your App

You'd typically use compressImageWithExpo after a user picks an image using expo-image-picker.

Here's a simplified example:

import React, { useState } from 'react';
import { View, Button, Image, ActivityIndicator, Text, Alert } from 'react-native';
import * as ImagePicker from 'expo-image-picker';
import { compressImageWithExpo } from './image-utils'; // Assuming your compression code is in image-utils.ts

export default function App() {
  const [pickedImageUri, setPickedImageUri] = useState<string | null>(null);
  const [compressedImageUri, setCompressedImageUri] = useState<string | null>(null);
  const [loading, setLoading] = useState(false);

  const pickImage = async () => {
    // Request camera roll permissions
    const { status } = await ImagePicker.requestMediaLibraryPermissionsAsync();
    if (status !== 'granted') {
      Alert.alert('Sorry, we need camera roll permissions to make this work!');
      return;
    }

    let result = await ImagePicker.launchImageLibraryAsync({
      mediaTypes: ImagePicker.MediaTypeOptions.Images,
      allowsEditing: true, // You can allow editing if needed
      aspect: [4, 3],
      quality: 1, // Get the highest quality original
    });

    if (!result.canceled) {
      const uri = result.assets[0].uri;
      setPickedImageUri(uri);
      setCompressedImageUri(null); // Clear previous compressed image
      await handleCompressImage(uri);
    }
  };

  const handleCompressImage = async (uri: string) => {
    setLoading(true);
    try {
      // Extract a simple filename (e.g., "photo.jpg")
      const filename = uri.split('/').pop() || 'image.jpg'; 
      const compressedUri = await compressImageWithExpo(uri, filename);
      if (compressedUri) {
        setCompressedImageUri(compressedUri);
        Alert.alert('Success!', 'Image compressed to WebP and saved locally.');
      } else {
        Alert.alert('Error', 'Image compression failed.');
      }
    } catch (error) {
      console.error('Compression process failed:', error);
      Alert.alert('Error', 'An error occurred during compression.');
    } finally {
      setLoading(false);
    }
  };

  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center', padding: 20 }}>
      <Button title="Pick an image from camera roll" onPress={pickImage} />

      {pickedImageUri && (
        <View style={{ marginTop: 20 }}>
          <Text style={{ fontWeight: 'bold' }}>Original Image:</Text>
          <Image source={{ uri: pickedImageUri }} style={{ width: 200, height: 150, marginTop: 10, borderWidth: 1, borderColor: 'gray' }} />
          <Text style={{ fontSize: 12, color: 'gray' }}>{pickedImageUri.split('/').pop()}</Text>
        </View>
      )}

      {loading && (
        <View style={{ marginTop: 20 }}>
          <ActivityIndicator size="large" color="#0000ff" />
          <Text>Compressing image...</Text>
        </View>
      )}

      {compressedImageUri && (
        <View style={{ marginTop: 20 }}>
          <Text style={{ fontWeight: 'bold' }}>Compressed WebP Image:</Text>
          <Image source={{ uri: compressedImageUri }} style={{ width: 200, height: 150, marginTop: 10, borderWidth: 1, borderColor: 'green' }} />
          {/* You can add a button here to upload this compressed image */}
          <Text style={{ fontSize: 12, color: 'green' }}>{compressedImageUri.split('/').pop()}</Text>
        </View>
      )}
    </View>
  );
}

Beyond Compression: Uploading to the Cloud

Once your image is perfectly compressed, you'll usually want to upload it to a cloud storage service like Amazon S3, Google Cloud Storage, or similar.

Wrapping Up

And thats it! You've taken your first steps into the world of image optimisation in Expo. By using expo-image-manipulator and an iterative compression strategy, you can dramatically improve your app's performance and give your users a much snappier experience.

Keep experimenting, and happy coding!

Optimizing Next.js Docker Images with Standalone Mode

Ango Jeffrey — Wed, 30 Jul 2025 10:28:53 +0000

Recently, I was discussing with the DevOps engineer at my company and he asked me why the Docker image for the Next.js frontend application was so large, we're talking over 2GB large, and I didn't have a good answer to that, I knew that because we were taking advantage of some Next.js features like middleware and redirects, we had to run the app as a server, which meant we couldn't serve the pages and assets as static exports, That would naturally make the image larger than a static export, but 2GB still felt excessive.
So, over the weekend I did a deep dive researching for possible causes for bloated Docker images and how to reduce the file size. After quite a bit of research and trial and error, I came across a very useful (and surprisingly under-discussed) feature: Next.js Standalone Mode.

What Is Standalone Mode?

Standalone mode strips out the irrelevant parts of your application from your build, such as unused node_modules files, unused component files and folders, giving you only the bare bones files needed to make your app work.

Implementing Standalone Mode Builds

To enable standalone mode you simply add this to your next.config.js:

const nextConfig: NextConfig = {
output: "standalone",

  /* ...other configurations */
}

Next, go to your Dockerfile and implement a multi stage build process to keep your image lean and efficient:

# Stage 0: Base image definition (optional, but good for consistency)
FROM node:18-alpine AS base

# Stage 1: Dependencies Installation
FROM base AS deps

RUN apk add --no-cache libc6-compat
WORKDIR /app

# Install dependencies (including devDependencies needed for the build)
COPY package.json yarn.lock* ./
RUN yarn --frozen-lockfile --prefer-offline --no-audit 

# Stage 2: Application Build
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY ./ ./ 

# build app
RUN yarn build

# Stage 3: Production Runner
FROM node:18-alpine AS runner

USER node

WORKDIR /app

COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public


EXPOSE 3000

CMD ["node", "server.js"]

✅ Note: The server.js file is generated automatically in the .next/standalone directory when using standalone mode.

Why this works

This Docker image uses a multi-stage build process to package a Next.js app in a way that’s both efficient and production-ready. It starts with a lightweight Node.js Alpine image and installs the app’s dependencies in a separate stage to keep things clean. Then, during the build stage, it compiles the app using yarn build, taking advantage of Next.js’s standalone mode, which bundles only the files and dependencies the app actually needs to run. Finally, the runner stage creates a clean, production ready image by copying only the standalone output (.next/standalone, .next/static, and public) into a fresh Node.js Alpine image. It sets the working directory, switches to a non-root node user for security, and runs the app with node server.js. By avoiding unnecessary files like full source code and unused node_modules, we end up with a much smaller image that’s faster to build, deploy, and run without sacrificing any of the dynamic features Next.js offers.

🚀The Results

Opting into Next.js standalone mode reduced our docker image size by over 90%, from over 2GB to less than 200MB!
Crazy right? Standalone mode is a nifty, underrated feature that deserves way more attention-especially if you're deploying server-rendered web apps with Docker.

Managing Async State with TanStack Query

Ango Jeffrey — Thu, 10 Apr 2025 19:37:50 +0000

For years, Redux has been my go-to library for managing complex application state, especially when dealing with asynchronous operations. Its predictable state management and centralised store have been invaluable for most of my projects. But I have to admit Redux does have its cons, a bit of boilerplate (though this has been somewhat reduced with Redux Toolkit), slow data update speed, the need for thunks/sagas when dealing with async data and if we're being honest it's a bit too complex a tool to use when working with simple applications.
Enter TanStack Query (formerly React Query), a powerful and elegant library specifically designed for managing, caching, synchronising, and updating server state in your web applications. When it comes to managing asynchronous data, it presents a strong substitute for Redux, requiring a lot less code and providing a more developer-friendly environment.

The Pain Points of Redux for Async Operations:

Before diving into TanStack Query, let's go over why managing async state with Redux can be challenging and tricky:

Significant Boilerplate: Fetching data typically involves defining action types, action creators (for request, success, and failure states), reducers to handle these actions, and often middleware like Redux Thunk or Redux Saga to orchestrate the asynchronous logic. This can lead to a lot of repetitive code.
Manual State Management: Developers are responsible for manually managing loading states, error states, and cached data within the Redux store. This requires careful implementation and can be prone to errors.
Complex Data Synchronization: Ensuring data consistency across different components and handling background updates often requires intricate logic within reducers and middleware.
Potential for Over-Engineering: For applications with primarily server-driven data, using the full power of Redux for every API call can feel like overkill.

Using Tanstack Query for server side state management

TanStack Query takes a different approach. It focuses specifically on simplifying the process of fetching, caching, and updating data from your backend. Here's how it shines as a Redux alternative for async state:

Declarative Data Fetching: Instead of manually dispatching actions and managing state transitions, TanStack Query allows you to declaratively define your data fetching logic using the useQuery hook. You provide a unique query key and a function that fetches your data, and TanStack Query handles the rest.

Automatic Caching and Deduping: TanStack Query intelligently caches fetched data in the background, preventing redundant API calls for the same data. It also automatically deduplicates concurrent requests for the same resource.
Background Updates and Refetching: The library provides mechanisms for automatic background updates based on various events (e.g., window focus, network reconnection) and offers easy ways to manually refetch data.
Optimistic Updates: TanStack Query facilitates optimistic updates, allowing you to immediately update the UI as if the mutation was successful, while handling potential errors in the background. Simplified Error Handling: Error states are automatically managed and readily accessible within the useQuery result.
Mutations for Data Modification: For POST, PUT, DELETE, and other data modification operations, TanStack Query offers the useMutation hook, which simplifies handling these asynchronous actions and updating the cache accordingly.

Working with TanStack Query a practical example

First things first, create a query client and pass it into a query client provider that's wrapped around your app

import {
  useQuery,
  QueryClient,
  QueryClientProvider,
} from '@tanstack/react-query'
import { getTodos, postTodo } from '../my-api'

// Create a client
const queryClient = new QueryClient()

function App() {
  return (
    // Provide the client to your App
    <QueryClientProvider client={queryClient}>
      <Main />
    </QueryClientProvider>
  )
}

Lets create a query to fetch a users profile data

// queries/user

const useGetUserProfile = () => {
  const GET_USER = async () => {
    return await axios.get("/user/profile");
  };

  const query = useQuery({
    queryKey: ["getUserProfile"],
    queryFn: GET_USER,
    staleTime: Infinity,
  });

  return {
    ...query,
    data: query.data?.data,
  };
};

Now we can import our query anywhere in our app to access our user data, for example

// components/accountDetails

import Spinner from "../loader-utils/spinner";

const AccountDetails = () => {
  const { data: user, isFetching } = useGetUserProfile();
  if (isFetching) {
    return <Spinner />;
  }

  return (
    <div>
      <p>{user.name}</p>
      <p>{user.role}</p>
    </div>
  );
};

Here in our AccountDetails component we are accessing the successfully fetched user data and even the loading state directly from our query hook, without needing to set state ourselves. And by setting the staleTime field to Infinity, we are telling TanStack Query that this query can be cached indefinitely, so we don't have to worry about our query refetching each time we call it in any component, although we can still set to behave like that if needed. If there are any updates to the data on the backend, all we need to do is to invalidate our user profile query cache and refetch the data, here is a quick example

// components/updateUser

const UpdateUser = ({ userName }) => {
  const [name, setName] = useState(userName);
  // Access the client
  const queryClient = useQueryClient();
  // update user mutation
  const { mutateAsync } = useMutation({
    mutationFn: async (data) => {
      return await axios.post("/user", data);
    },
  });
  const handleUpdateName = async () => {
    try {
      await mutateAsync({
        userName: name,
      });
// manually invalidate the cached getUserProfile query
      await queryClient.invalidateQueries({
        queryKey: ["getUserProfile"],
      });
    } catch {}
  };

  return (
    <div>
      <input value={name} onChange={(e) => setName(e.target.value)} />
      <button onClick={handleUpdateName}>Update Name</button>
    </div>
  );
};

After making our mutation, we immediately invalidate our getUserProfile query cache; this tells TanStack Query that we want this query to be refetched as the data is now stale.

As you can see this is way less code and complexity than if we used Redux, TanStack Query handles the loading and error states, caching, and even background refetching automatically.

TanStack Query and Redux can still coexist peacefully in the same application. You might use TanStack Query for managing server state and Redux for managing global client-side UI state or other application-specific data.

Caching on the frontend

Ango Jeffrey — Tue, 01 Apr 2025 06:07:21 +0000

Caching, at its core, is about storing frequently accessed data closer to where it's needed, minimising the time and resources required to retrieve it. Think of it as keeping frequently used tools on your workbench instead of retrieving them from a distant toolbox every time.

In the world of web development, speed is king. Users expect lightning-fast load times, and even a few extra milliseconds can impact engagement and conversion rates. This is where caching comes in, a powerful technique to optimize your frontend and deliver a smoother, more responsive user experience.

Why is Caching Important on the Frontend?

Performance
When we cache a resource we reduce the time taken to access it the next time it’s needed, thereby improving the user experience and reduce the strain on the server (as we only need to make a connection to it once).

Reduced Bandwidth Usage
Caching static assets and API responses and serving them when next the user requires them, minimizes data transferred, saving bandwidth for both the user and the server.

Enhanced user experience
Users experience snappier applications, leading to higher engagement and satisfaction.

Offline access
Mobile apps and progressive web apps (PWA) can leverage caching to provide limited functionality even without an internet connection or areas with poor data connectivity.

Caching strategies on the frontend

Browser caching: Leveraging HTTP headers (e.g., Cache-Control, Expires, ETag and Last-Modified) to store static assets (images, CSS, JavaScript) in the user's browser. These headers are used to instruct the browser how to cache resources and though similar have different meanings and some have more priority over others;

a. Cache-Control: Controls caching behavior, specifying how long a resource can be cached, whether it can be cached by intermediaries, and more. Common directives include max-age, no-cache, and no-store. It has a higher priority over the Expires header.
b. Expires: Specifies a date and time after which the resource is considered stale.
c. ETag and Last-Modified: Used for conditional requests, allowing the browser to check if a cached resource is still up-to-date before fetching it from the server.

Service workers: These are JavaScript files that run in the background, independent of the web page. They are sort of like personal assistants that can help reduce the load on the main thread. This allows the main thread to focus on rendering your web page while service workers run tasks like caching resources and fetching required data in the background on a different thread. Service workers are non-blocking and fully asynchronous.You can use them to add offline capabilities and advanced caching strategies for your web applications.

LocalStorage/ SessionStorage / IndexedDB: These are storage solutions that allow you to store application data locally(in your browser) for faster access. Local storage and Session storage are similar except that while localStorage data has no expiration time, sessionStorage data gets cleared when the page session ends — that is, when the page is closed. IndexedDB on the other hand is a much larger storage solution when compared with local or session storage and allows you to store not only more files but also more complex data such as images, audio and video files. IndexedDB is more commonly used in web apps that need to have offline functionality ie Progressive Web Apps (PWA).

Content Delivery Networks(CDN): Distributing static files over many servers to lower latency. CDNs store a cached version of content from the original server. When a user requests a resource, the CDN serves it from the nearest server, reducing latency.

Custom cache solutions: You can implement a simple in-memory solution to cache data using a key value pair collection such as a map this is very fast, but is lost on page refresh.

Best Practices for Frontend Caching

Use Cache-Control headers effectively: Set appropriate max-age values for your resources.
Leverage CDNs: Distribute your static assets globally for faster delivery.
Use content hashing (e.g., file versioning): Append a hash to filenames to force the browser to fetch new versions of resources when they change. Although with modern applications we don't have to worry about this as bundlers such as webpack take care of this for us.
Cache API responses: Store API data in the browser's cache to reduce server requests.
Monitor cache performance: Use browser developer tools and performance monitoring tools to track cache hit rates and identify potential issues.
Always invalidate stale caches: Make sure that when the content of a cached resource changes, that the client receives the updated resource at all times. If the underlying data changes on the server, the cached version on the browser becomes stale, potentially leading to inconsistencies and errors. This is where cache invalidation comes into play. There are several cache invalidation strategies to choose from, some of them include;

Time-Based Invalidation (TTL - Time To Live): This is the simplest approach, setting a fixed expiration time for cached data.
Event-Based Invalidation: This approach invalidates the cache when a specific event occurs, such as a data update on the server. This requires a mechanism for the server to notify the client or cache when data changes, such as web sockets or push notifications.
Version-Based Invalidation: When the server data changes, the api version number changes, or a version hash is added to the api url. This forces the client to get the new version of the data, and disregard the old cached version. One major limitation of this is that it requires strict version control of the api.

In conclusion, Caching is a powerful tool that can significantly improve the performance, scalability, and user experience of any application. By understanding the various caching strategies and techniques, and by carefully considering the key considerations, you can effectively leverage caching to build faster, efficient, and more reliable systems.

Code Grooming: Principles for Long-Term Software Health

Ango Jeffrey — Mon, 24 Mar 2025 09:09:53 +0000

We've all been there before whether you're working on a fresh project that you built from scratch or maintaining a brownfield project, and realising it's become a tangled mess. Over time, even code written with good intentions can become an unmanageable, complex mess, if not properly maintained. Like an overgrown garden, these codebases become difficult to navigate, update, and maintain.

The truth is, software development is a journey of continuous learning. What seemed like the perfect solution a year ago might now appear clunky and inefficient. Lets face it future you will always be more knowledgeable and experienced than the present you. Your future self, armed with more experience, will inevitably find improvements to code that past you wrote.

Code grooming is essential as software engineers, adding new features is nice and important too, but you need to ensure that your existing code is clean, efficient and follows the latest standards, sure it works, but why leave it at that when you can make it better. Obviously I'm not asking you to update your codebase on a weekly basis or even biweekly, that would be impractical, as professional software engineers we have to think of the businesses need first, Nevertheless we need to create time to groom our codebase, to review past decisions, if they're are not up to par improve them.

There are principles you should adhere to or follow that make the process of updating a codebase easier and not seem so daunting, you want to make life a bit easier for the next guy that has to work on the project, these are a few of them;

Minimize Interdependence (Low Coupling, High Cohesion):

Instead of tightly coupled components that trigger cascading changes, aim for independent modules. Changes in one module should minimally impact others.
Stick to a Style (Coding Standards):

Maintaining a consistent and readable codebase is paramount for long-term health and collaborative efficiency. To achieve this, establish and enforce coding standards using tools like linters (e.g., ESLint), formatters (e.g., Prettier), and style guides. .Having consistent naming conventions, formatting, and overall structure greatly enhance readability, simplifying collaboration amongst developers. To make sure these standards are consistently applied, integrate these tools into your CI/CD pipeline, automating style checks and preventing deviations from the established guidelines.
Explain the 'Why' (Helpful Comments):

Comments should explain the "why" behind the code, not just the "what." Document architectural decisions, complex logic, and edge cases. Skip the comments that just tell you exactly what the code does, we can already see that.
Write tests:

no matter how you sweat it the best guarantee that a pice of code works is if the tests written for it are passing, tests are important for you as a developer because how would you know that your updates didn't break the codebase if there are no existing tests.
Stay Secure:

Don't forget to check for security issues when you're cleaning up your code. That means adding security checks to your process and keeping all those extra code bits (dependencies) up-to-date. Fix any security problems as soon as you find them. Doing this helps keep your code safe and prevents potential problems.

These are just a few ways to keep your codebase healthy and make future updates easier. Remember, maintaining existing code is just as important as writing new features. It's about building sustainable software.