DEV Community: CodeZera

Build a Bulletproof Retry Mechanism

CodeZera — Thu, 17 Apr 2025 15:03:59 +0000

Alright, lets build something interesting.

I'm pretty sure if you have worked with web applications then you might have noticed some failed fetch operations, its is very common.

A good production app will always have a retry mechanism to handle failed request that will just retry the request with same payload if something goes wrong.

Let's walk through building a retry mechanism using RxJS from scratch. We'll start simple, and then level up to a more advanced, production-ready solution.

The Problem

You call an API. It fails. That's it. You're stuck unless you handle that failure.

Let's say you're using fetch to call an API endpoint. If it fails even once, your stream dies unless you explicitly handle retries. Here's a simple solution to fix that.

Solution-1: Simple Retry Mechanism

import { from, throwError } from "rxjs";
import { switchMap, retry, catchError } from "rxjs/operators";

const fetchData = () => {
  return from(fetch("https://jsonplaceholder.typicode.com/todos/1")).pipe(
    switchMap((response) => {
      if (!response.ok) {
        return throwError(
          () => new Error(`HTTP error! status: ${response.status}`)
        );
      }
      return from(response.json());
    }),
    retry(3)
  );
};
fetchData().subscribe({
  next: (data) => console.log("Fetched data:", data),
  error: (err) => {
    console.error("Request failed after 3 retries:", err);
    console.error("Final error:", err);
  },
});

Lets understand this step by step.

from: Converts the fetch() promise into an observable so we can use rxjs operators on it.
switchMap: Takes the Response object, starts a inner loop(a function in this case) and returns another observable from response.json(), basically flattening the result.
retry: Pretty self explanatory, if for some reason pipeline throws an error, it will retry upto 3 times before stopping.
subscribe: Triggers the stream and handles success and failure.

This works fine but its still pretty basic. No backoff, no timeout, no typesafety. All errors are treated equally.

Lets build a advanced version of this.

Solution 2: Advanced Retry Mechanism

import { from, throwError, timer, Observable } from "rxjs";
import {
  switchMap,
  retryWhen,
  timeout,
  catchError,
  mergeMap,
} from "rxjs/operators";

function fetchWithRetry<T>(
  url: string,
  options?: RequestInit,
  maxRetries = 3,
  timeoutMs = 10000
): Observable<T> {
  return from(fetch(url, options)).pipe(
    timeout(timeoutMs),
    switchMap((response) => {
      if (!response.ok) {
        if (response.status >= 400 && response.status < 500) {
          return throwError(
            () => new Error(`Client error: ${response.status}`)
          );
        }
        return throwError(() => new Error(`Server error: ${response.status}`));
      }
      return from(response.json() as Promise<T>);
    }),
    retry({
      count: maxRetries,
      delay: (error, attempt) => {
        if (error.message.includes("Client error")) {
          return throwError(() => error);
        }

        // 2 seconds backoff time
        return timer(2000);
      },
    })
  );
}
interface Todo {
  userId: number;
  id: number;
  title: "string;"
  completed: boolean;
}
fetchWithRetry<Todo>("https://jsonplaceholder.typicode.com/todos/1").subscribe({
  next: (data) => console.log("Success:", data),
  error: (err) => console.error("Error:", err.message),
  complete: () => console.log("Complete"),
});

Don't worry this just looks complicated its actually very easy when you understand it. Lets understand this step by step!

timeout: Pretty self explanatory, if the request hangs longer than expected we just back off.
switchMap: Same role -> Flattening response.json() from promise to observable.
retry with custom delay: we first enter the number of tries in the count and in the delay function we first check if the error is from client, if yes then throw error and exit otherwise retry after 2 seconds
subscibe: then finally we just subscribe to this stream and listen for events like next, error, and complete which are just simple callbacks you get to perform further operations.

You might be confused on why we return sometimes a function sometimes called timer function and sometimes a throwError function. Why cant we just throw errors directly.

Just remember one small thing, rxjs operators and functions works with respect to time. So all of the things returned are just observables.

I know this can be a lot in starting but trust me read this a couple of times, this stuff is actually very easy and interesting once you start understanding the individual pieces.

Wrapping Up

Retries aren't optional anymore. With RxJS, you get fine-grained control over retry logic and once you understand the building blocks like switchMap, retryWhen, and timer, it becomes surprisingly clean to implement.

Start simple. Then level up as your app's needs evolve.

Connect with Me

If you enjoyed this post and want to stay in the loop with similar content, feel free to follow and connect with me across the web:

Twitter: Follow me on Twitter for bite-sized tips, updates, and thoughts on tech.
Medium: Check out my articles on Medium where I share tutorials, insights, and deep dives.
Email: Got questions, ideas, or just want to say hi? Drop me a line at codezera3@gmail.com.

Your support means a lot, and I'd love to connect, collaborate, or just geek out over cool projects. Looking forward to hearing from you!

WTF IS UTF?

CodeZera — Sun, 13 Apr 2025 16:20:44 +0000

So you’re a frontend dev and you’ve seen “UTF-8” all over the place, but never really understood what the hell it is or why you should care. Yeah, I was in the same boat. Let’s fix that once and for all.

ASCII

Before we dive into UTF madness, we need to talk about ASCII (American Standard Code for Information Interchange), which was basically the start of character encoding.

ASCII was created way back in the 60s when computers were the size of rooms and programmers thought 128 characters would be plenty for everyone. It uses 7 bits to represent each character, giving us those 128 possible values.

Here’s what ASCII covers:

English letters (A-Z, a-z)
Numbers (0–9)
Basic punctuation (!,?.-)
Some control characters (like line breaks and tabs)
ASCII worked fine for a while if you were an English-speaking guy. But here’s where things got messy…

The Problem: ASCII Is Super Limited

Imagine you’re Spanish and need to use “ñ” or German and need “ß”. Or maybe you’re coding in Japanese, Chinese, Arabic, or Hindi? Sorry, ASCII says “nope, not my problem!”

As computers went global, ASCII was like that American tourist who only speaks English and expects everyone else to understand them.

Different countries started making their own encoding standards, and that’s when the real problem began. You’d get documents that looked fine on one computer but showed up as gibberish on another. Ever seen something like “Th��s �s messed �p” in an email or website? Yeah, that’s encoding gone wrong.

UTF: The Universal Translator

UTF stands for “Unicode Transformation Format,” and it’s part of the Unicode standard that was created to solve this mess. The whole point of Unicode is to have ONE standard that works for EVERY character in EVERY possible language (even emojis like 💩).

Unicode assigns a unique code point (a number) to every character, regardless of platform, program, or language. This is huge it means no matter what language you’re using, computers can understand each other.

But there’s a problem storing all these possible characters efficiently. That’s where the different UTF formats come in.

The Different UTF Flavors

UTF-8

This is the star of encoding and what you see everywhere on the web. Here’s why it’s awesome:

It uses a variable number of bytes (1 to 4) per character ASCII characters only need 1 byte (making it backward compatible with ASCII)
Non-ASCII characters use more bytes as needed
It’s space-efficient for English text
No byte order issues (more on that in a sec)

UTF-16

This format uses at least 2 bytes per character, and sometimes 4 bytes for the less common characters.

Most common characters use 2 bytes
Less common ones use 4 bytes
It’s the default in Windows, Java, and JavaScript internally
Less efficient for English text than UTF-8
Has byte order issues (needs a BOM — Byte Order Mark)

UTF-32

The big boy of the group:

Uses a fixed 4 bytes for EVERY character
Simplest to process (fixed width)
SUPER wasteful for most text
Also has byte order issues
Rarely used in practice

Why UTF-8 Is the King of the Web

So why do we see UTF-8 everywhere? There are a few solid reasons:

Backward Compatibility: ASCII characters in UTF-8 are identical to regular ASCII. This made transition from ASCII to UTF-8 painless.
Storage Efficiency: English websites save a TON of space with UTF-8 compared to UTF-16 or UTF-32. For primarily English content (which is a lot of the early web), this was a big deal.
No Byte Order Mark Required: UTF-16 and UTF-32 have this thing called a Byte Order Mark (BOM) that indicates whether the bytes are stored in big-endian or little-endian order. UTF-8 doesn’t need this, making it simpler to use.
Network Friendly: When transmitting data, UTF-8’s design means any errors only affect individual characters, not the entire string.

In Practice: What You Need to Know

As a frontend dev, here’s what matters:

Always specify the encoding: In your HTML, make sure you have:

<meta charset="UTF-8">

Save your files as UTF-8: Most modern editors default to this now, but double-check.
Database connections: Make sure your database connections specify UTF-8 encoding.
API responses: Check that your APIs include the proper content type with charset=utf-8.
Form submissions: Ensure your forms submit with the proper encoding.

Conclusion

UTF-8 isn’t just some random setting it’s what makes the modern, global web possible. Without it, we’d still be stuck in encoding hell, unable to properly share content across languages.

When someone asks you “WTF is UTF?” now you can tell them it’s literally what makes the web worldwide.

Any other encoding questions? Drop them in the comments, and we’ll figure it out together!

Connect with Me

If you enjoyed this post and want to stay in the loop with similar content, feel free to follow and connect with me across the web:

Twitter: Follow me on Twitter for bite-sized tips, updates, and thoughts on tech.
Medium: Check out my articles on Medium where I share tutorials, insights, and deep dives.
Email: Got questions, ideas, or just want to say hi? Drop me a line at codezera3@gmail.com.

Your support means a lot, and I'd love to connect, collaborate, or just geek out over cool projects. Looking forward to hearing from you!

The Power of Facades

CodeZera — Fri, 11 Apr 2025 18:49:57 +0000

Introduction to Facades

Facades are a design pattern that provide a simplified interface to complex subsystems. Think of them as friendly front-desks that hide messy back-offices. Instead of dealing with the nitty-gritty details of a system's implementation, you get a clean, easy-to-use interface that handles the complexity for you.

The concept comes from architecture (literally the "face" of a building), but in software, facades serve as an abstraction layer that:

Hides complexity
Reduces dependencies between code
Makes your system more modular
Improves readability
Provides a consistent interface

Why Facades Become Essential as Projects Grow

When starting a new project, it's tempting to skip facades. The codebase is small, you understand every part of it, and adding abstractions might feel like unnecessary overhead. But as your project grows, facades become lifesavers.

Here's why facades are worth implementing early:

Future-proofing: As your system grows, underlying implementations will change. With facades, these changes are isolated.
Maintainability: New team members can understand how to use complex subsystems without diving into implementation details.
Testing: Facades make it easier to mock dependencies and test in isolation.
Migration path: Need to swap out a library or service? Change the facade's implementation, not all the code that uses it.
Consistency: Enforces a standard way to interact with a subsystem across your application.

Often, developers only realize they need facades when technical debt piles up and changing anything becomes horrible. Starting with facades might seem like extra work, but it's an investment that pays off exponentially when your codebase expands.

Some facades I use in all of my projects

Let's look at some facades I've either built myself or copied from some youtube videos or blogs:

1. Error Handling Facade

I love this one, this is not mine i copied it from a famour youtuber theo, you might know him from his T3 stack.
Error handling is repetitive and clutters business logic. This facade provides a clean way to handle async operations and their potential errors:

// Types for the result object with discriminated union
type Success<T> = {
  data: T;
  error: null;
};

type Failure<E> = {
  data: null;
  error: E;
};

type Result<T, E = Error> = Success<T> | Failure<E>;

interface TryCatchOptions<T> {
  onSuccess?: (data?: T) => void;
  onError?: (error: unknown) => void;
}

// Main wrapper function
export async function tryCatch<T, E = Error>(
  promise: Promise<T>,
  options: TryCatchOptions<T> = {}
): Promise<Result<T, E>> {
  try {
    const data = await promise;
    if (options.onSuccess) {
      options.onSuccess(data);
    }
    return { data, error: null };
  } catch (error) {
    if (options.onError) {
      options.onError(error);
    }
    return { data: null, error: error as E };
  }
}

Using this facade turns messy try-catch blocks into clean, consistent error handling:

// Before
async function fetchUser(id) {
  try {
    const user = await api.getUser(id);
    return user;
  } catch (error) {
    console.error("Failed to fetch user:", error);
    return null;
  }
}

// After
async function fetchUser(id) {
  const { data, error } = await tryCatch(api.getUser(id), {
    onError: (e) => console.error("Failed to fetch user:", e)
  });
  return data;
}

2. HTTP Client Facade

HTTP clients often need consistent error handling, authentication, and request formatting. This facade abstracts all that complexity:

import { clientEnv } from "@/clientEnv"
import axios from "axios"
import { getSession, signOut } from "next-auth/react"

const axiosClient = axios.create({
  baseURL: clientEnv.NEXT_PUBLIC_API_ROOT_URL,
  timeout: 30000,
  headers: {
    "Content-Type": "application/json",
  },
})

axiosClient.interceptors.request.use(async (config) => {
  const session = await getSession()
  let jwtToken = session?.user?.jwtToken
  if (jwtToken) {
    // Verify token expiration
    const payloadBase64 = jwtToken.split(".")[1]
    const decodedPayload = JSON.parse(atob(payloadBase64))
    const exp = decodedPayload?.exp * 1000
    if (Date.now() >= exp) {
      await signOut()
      return Promise.reject("Session expired")
    }
    config.headers = {
      ...config.headers,
      authorization: jwtToken,
    }
  }
  return config
})
axiosClient.interceptors.response.use(
  (response) => {
    if (response && response.data) {
      return response.data
    }
    return response
  },
  (error) => {
    return Promise.reject(error)
  }
)
export default class HttpClient {
  static async get<T>(url: string, params?: unknown) {
    const response = await axiosClient.get<T>(url, { params })
    return response
  }
  static async post<T>(url: string, data: unknown, options?: any) {
    const response = await axiosClient.post<T>(url, data, options)
    return response
  }
  static async put<T>(url: string, data: unknown) {
    const response = await axiosClient.put<T>(url, data)
    return response
  }
  static async patch<T>(url: string, data: unknown) {
    const response = await axiosClient.patch<T>(url, data)
    return response
  }
  static async delete<T>(url: string) {
    const response = await axiosClient.delete<T>(url)
    return response
  }
}

Using this facade turns complex API calls with authentication, error handling, and data extraction into simple, clean one-liners.

// Before
import axios from "axios";
// Or whatever you use
import { getSession } from "next-auth/react";

async function fetchUsers() {
 try {
   const session = await getSession();
   const response = await axios.get("https://api.example.com/users", {
     headers: {
       "Content-Type": "application/json",
       authorization: session?.user?.jwtToken
     }
   });
   return response.data;
 } catch (error) {
   console.error("Failed to fetch users:", error);
   return [];
 }
}

// After
import HttpClient from "@/lib/HttpClient";

async function fetchUsers() {
 try {
   const users = await HttpClient.get("/users");
   return users;
 } catch (error) {
   console.error("Failed to fetch users:", error);
   return [];
 }
}

3. Storage Facade

Here's a storage facade I built that abstracts away different storage mechanisms:

interface StorageProvider {
  get<T>(key: string): T | null;
  set<T>(key: string, value: T): void;
  remove(key: string): void;
  clear(): void;
}

class LocalStorageProvider implements StorageProvider {
  get<T>(key: string): T | null {
    try {
      const item = localStorage.getItem(key);
      return item ? JSON.parse(item) : null;
    } catch {
      return null;
    }
  }
  set<T>(key: string, value: T): void {
    localStorage.setItem(key, JSON.stringify(value));
  }
  remove(key: string): void {
    localStorage.removeItem(key);
  }
  clear(): void {
    localStorage.clear();
  }
}
class MemoryStorageProvider implements StorageProvider {
  private store: Record<string, string> = {};
  get<T>(key: string): T | null {
    try {
      const item = this.store[key];
      return item ? JSON.parse(item) : null;
    } catch {
      return null;
    }
  }
  set<T>(key: string, value: T): void {
    this.store[key] = JSON.stringify(value);
  }
  remove(key: string): void {
    delete this.store[key];
  }
  clear(): void {
    this.store = {};
  }
}
export class Storage {
  private provider: StorageProvider;
  constructor(providerType: 'local' | 'memory' = 'local') {
    this.provider = providerType === 'local' 
      ? new LocalStorageProvider() 
      : new MemoryStorageProvider();
  }
  get<T>(key: string): T | null {
    return this.provider.get<T>(key);
  }
  set<T>(key: string, value: T): void {
    this.provider.set<T>(key, value);
  }
  remove(key: string): void {
    this.provider.remove(key);
  }
  clear(): void {
    this.provider.clear();
  }
}

Using this facade turns complex storage interactions with different storage providers, type safety, and error handling into a simple, consistent API that works across environments.

// Before
function saveUserPreferences(theme: string, fontSize: number, notifications: boolean) {
  try {
    localStorage.setItem('userTheme', theme);
    localStorage.setItem('userFontSize', fontSize.toString());
    localStorage.setItem('userNotifications', JSON.stringify(notifications));
  } catch (e) {
    console.error('Failed to save preferences:', e);
  }
}

function getUserPreferences() {
  try {
    const theme = localStorage.getItem('userTheme') || 'light';
    const fontSize = Number(localStorage.getItem('userFontSize')) || 16;
    const notifications = localStorage.getItem('userNotifications') === 'true';
    return { theme, fontSize, notifications };
  } catch (e) {
    console.error('Failed to get preferences:', e);
    return { theme: 'light', fontSize: 16, notifications: true };
  }
}

// After
import { Storage } from '@/lib/Storage';

const storage = new Storage('local');

function saveUserPreferences(theme: string, fontSize: number, notifications: boolean) {
  storage.set('userPreferences', { theme, fontSize, notifications });
}

function getUserPreferences() {
  return storage.get<{ theme: string, fontSize: number, notifications: boolean }>('userPreferences') || 
    { theme: 'light', fontSize: 16, notifications: true };
}

4. Logger Facade

Another useful facade is a centralized logging system:

type LogLevel = 'debug' | 'info' | 'warn' | 'error';

interface LoggerOptions {
  minLevel?: LogLevel;
  enableConsole?: boolean;
  enableRemote?: boolean;
  appVersion?: string;
}
export class Logger {
  private static instance: Logger;
  private minLevel: LogLevel;
  private enableConsole: boolean;
  private enableRemote: boolean;
  private appVersion: string;

  private readonly levelPriority: Record<LogLevel, number> = {
    debug: 0,
    info: 1,
    warn: 2,
    error: 3
  };
  private constructor(options: LoggerOptions = {}) {
    this.minLevel = options.minLevel || 'info';
    this.enableConsole = options.enableConsole ?? true;
    this.enableRemote = options.enableRemote ?? false;
    this.appVersion = options.appVersion || 'unknown';
  }
  static getInstance(options?: LoggerOptions): Logger {
    if (!Logger.instance) {
      Logger.instance = new Logger(options);
    }
    return Logger.instance;
  }
  private shouldLog(level: LogLevel): boolean {
    return this.levelPriority[level] >= this.levelPriority[this.minLevel];
  }
  private async sendToRemote(level: LogLevel, message: string, data?: any) {
    if (!this.enableRemote) return;

    try {
      await fetch('/api/logs', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          level,
          message,
          data,
          timestamp: new Date().toISOString(),
          appVersion: this.appVersion
        })
      });
    } catch (e) {
      // Fail silently to prevent logging loops
    }
  }
  debug(message: string, data?: any): void {
    if (!this.shouldLog('debug')) return;

    if (this.enableConsole) {
      console.debug(`[DEBUG] ${message}`, data);
    }

    this.sendToRemote('debug', message, data);
  }
  info(message: string, data?: any): void {
    if (!this.shouldLog('info')) return;

    if (this.enableConsole) {
      console.info(`[INFO] ${message}`, data);
    }

    this.sendToRemote('info', message, data);
  }
  warn(message: string, data?: any): void {
    if (!this.shouldLog('warn')) return;

    if (this.enableConsole) {
      console.warn(`[WARN] ${message}`, data);
    }

    this.sendToRemote('warn', message, data);
  }
  error(message: string, error?: any): void {
    if (!this.shouldLog('error')) return;

    if (this.enableConsole) {
      console.error(`[ERROR] ${message}`, error);
    }

    this.sendToRemote('error', message, error);
  }
}

Using this facade turns inconsistent logging across your application with different formats and destinations into a centralized, configurable system with consistent formatting and remote reporting capabilities.

// Before
function processOrder(order) {
  console.log("Processing order:", order.id);

  try {
    // Order processing logic
    if (!order.paymentConfirmed) {
      console.warn("Payment not confirmed for order:", order.id);
      return false;
    }

    // Some More processing...
    console.log("Order processed successfully:", order.id);
    return true;
  } catch (error) {
    console.error("Failed to process order:", order.id, error);
    return false;
  }
}

// After
import { Logger } from '@/lib/Logger';

const logger = Logger.getInstance({
  minLevel: 'info',
  enableRemote: true,
  appVersion: '1.2.3'
});

function processOrder(order) {
  logger.info("Processing order", { orderId: order.id });

  try {
    // Order processing logic
    if (!order.paymentConfirmed) {
      logger.warn("Payment not confirmed", { orderId: order.id });
      return false;
    }

    // SOme More processing...
    logger.info("Order processed successfully", { orderId: order.id });
    return true;
  } catch (error) {
    logger.error("Failed to process order", { orderId: order.id, error });
    return false;
  }
}

The Facade Mindset

Beyond specific implementations, adopting a "facade mindset" is about identifying which parts of your system benefit from abstraction. When you notice repetitive pattern or complexity that others struggle with, that's your hint to build a facade.

Good facade opportunities include:

Third-party services integration
Database operations
Authentication/Authorization systems
File operations
Complex algorithms

Conclusion

Facades aren't just fancy design patterns they're practical tools that save time, reduce bugs, and make codebases more maintainable. While they might seem like unnecessary abstraction at first, facades become invaluable as your project evolves.

The examples I've shared are just starting points. The best facades solve specific problems in your domain, creating a language that speaks directly to your business needs while hiding technical complexity.

Next time you write repeated boilerplate or explain a complex subsystem to a teammate for the third time, consider creating a facade. Your future self (and team) will thank you.

Connect with Me

If you enjoyed this post and want to stay in the loop with similar content, feel free to follow and connect with me across the web:

Twitter: Follow me on Twitter for bite-sized tips, updates, and thoughts on tech.
Medium: Check out my articles on Medium where I share tutorials, insights, and deep dives.
Email: Got questions, ideas, or just want to say hi? Drop me a line at codezera3@gmail.com.

Your support means a lot, and I'd love to connect, collaborate, or just geek out over cool projects. Looking forward to hearing from you!

The Cleanest Way to Use React Query

CodeZera — Thu, 10 Apr 2025 18:09:04 +0000

React Query is honestly one of the best things that's happened to frontend devs. If you've ever felt the pain of managing loading states, caching, refetching, pagination, or syncing server data with your UI… this thing just saves your soul.

So What exactly is React Query?

React Query is a data-fetching library that helps you manage server state or you can say managing fetch, cache, and update data in your React apps without managing all the state manually.

Why React Query is the best

Automatic Caching: You hit an API once, and it remembers the result.
Auto Refetching: Keeps your data fresh without manual effort.
Built-in loading & error states: No more spaghetti isLoading logic.
Mutations: Super clean way to do POST/PUT/DELETE requests.
Devtools: Easily inspect and debug queries and mutations.

BUT…

Once your app grows, your React Query setup can get messy real quick like 30 different query keys, functions all over the place, no organization, types all mismatched.

Let me show you a better way. A scalable way. A way that won't make you hate yourself six months from now.

Step 1: Organize Your Query Keys

Most people start by writing things like:

useQuery(['posts'], fetchPosts)
useQuery(['post', id], fetchPostById)

Looks simple, until you end up with a million of these and have no idea what keys you've already used.

Instead, create a central file like query-keys.ts and define your keys properly.

Let's say we're building a simple Todo App instead of properties:

// query-keys.ts
export const QueryKeys = {
  TODO: {
    GET_ALL: ['TODO_GET_ALL'],
    GET_BY_ID: (id: string) => ['TODO_GET_BY_ID', id],
    CREATE: ['TODO_CREATE'],
    UPDATE: ['TODO_UPDATE'],
    DELETE: ['TODO_DELETE'],
  },
  USER: {
    PROFILE: ['USER_PROFILE'],
  },
};

Now you always use QueryKeys.TODO.GET_ALL or QueryKeys.TODO.GET_BY_ID(id) consistently.

Step 2: Create a query-options Folder

Inside your src/ folder (or root, up to you), create a query-options/ directory. This is where all your fetch logic lives.

Then create files per domain so for example todo.ts.

Example: query-options/todo.ts

We'll use a basic /api/todos structure and walk through the common operations.

Get all todo

// Types
type Todo = {
  id: string;
  title: string;
  completed: boolean;
};

export const getAllTodosOptions = (): QueryOptions<Todo[]> => {
  return {
    queryKey: QueryKeys.TODO.GET_ALL,
    queryFn: async () => {
      const { data } = await axios.get<Todo[]>("/api/todos");
      return data;
    },
  };
};

Create a todo

type CreateTodoInput = {
  title: string;
};

export const createTodoOptions = (): MutationOptions<
  Todo, // success response from api
  AxiosError, // error type from axios can be anything you want 
  CreateTodoInput // input type which you send to backend
> => {
  const queryClient = useQueryClient();
  return {
    mutationFn: async (values) => {
      const { data } = await apiClient.post<Todo>("/api/todos", values);
      return data;
    },
    onSuccess: () => {
      queryClient.invalidateQueries({
        queryKey: QueryKeys.TODO.GET_ALL,
      });
    },
  };
};

Update a todo

type UpdateTodoInput = {
  id: string;
  title: string;
  completed: boolean;
};

export const updateTodoOptions = (): MutationOptions<
  Todo, // success response
  AxiosError, // error type
  UpdateTodoInput // input type
> => {
  return {
    mutationFn: async ({ id, ...rest }) => {
      const { data } = await apiClient.patch<Todo>(`/api/todos/${id}`, rest);
      return data;
    },
  };
};

Usage in Your Components

Instead of creating custom hooks like useGetTodos, I like to just use it directly in the component keeps everything close and readable.

import { useQuery, useMutation } from "@tanstack/react-query";
import {
  getAllTodosOptions,
  createTodoOptions,
} from "@/query-options/todo";

export default function TodoList() {
  const { data: todos, isLoading } = useQuery(getAllTodosOptions());
  const { mutate: createTodo, isPending } = useMutation(createTodoOptions());
  return (
    <>
      {isLoading ? (
        <p>Loading...</p>
      ) : (
        todos?.map((todo) => <div key={todo.id}>{todo.title}</div>)
      )}
      <button
        disabled={isPending}
        onClick={() => createTodo({ title: "New Todo" })}
      >
        Add Todo
      </button>
    </>
  );
}

Bonus: Extend Query Options Inside Components

Let's say you wanna pass some custom stuff only in one place like inital data or pagination limit:

const { data, isLoading } = useQuery({
  ...getAllTodosOptions(),
  initialData: [],
  staleTime: 1000 * 60
});

This is why I love this pattern you keep flexibility in the component but the logic stays organized in one place.

Conclusion

React Query is awesome, but only if you keep it tidy. Once your app grows, you need:

Centralized query keys
Domain-based query-options
Avoid unnecessary custom hooks (unless you need them)
Type everything your future self will thank you

Hope this helps you write more scalable and clean React Query code.
And if your project's already a mess… it's never too late to clean it up 😉

Connect with Me

If you enjoyed this post and want to stay in the loop with similar content, feel free to follow and connect with me across the web:

Twitter: Follow me on Twitter for bite-sized tips, updates, and thoughts on tech.
Medium: Check out my articles on Medium where I share tutorials, insights, and deep dives.
Email: Got questions, ideas, or just want to say hi? Drop me a line at codezera3@gmail.com.

Your support means a lot, and I'd love to connect, collaborate, or just geek out over cool projects. Looking forward to hearing from you!

SQL is Great - Just Not for Searching

CodeZera — Wed, 09 Apr 2025 18:43:18 +0000

Look, I've been a Postgres fanboy for years. It's my go-to database for nearly everything I build. Rock-solid reliability, fantastic scaling, killer features, what's not to love? But there's one hill I will die on: SQL databases absolutely suck at text searching.

The Text Search Nightmare

Anyone who's ever tried to build a decent search feature using just SQL has probably wanted to throw their laptop out the window at some point. I know I have.

Last month, I was working on a website with just 500 items. I thought the data is not much and I just wanted searching on multiple fields so I implemented the search using Prisma ORM. It took like 2–3 seconds for just some simple searches which is obv not good for such small data.

And that's not even the worst part! The search was painfully basic - no fuzzy matching, no handling of spelling mistakes, no synonyms, nothing. Type "labtop" instead of "laptop"? Zero results. Search for "t-shirt" when the database had "tshirt"? Sorry, nothing found. It was like working with a search engine from 1995.

Why SQL Databases Fall Flat on Text Search

After many late nights, several Reddit threads, and a minor existential crisis, I tried to figure out why SQL databases are so terrible at this:

They're Built for a Different World SQL databases were designed in the 70s to handle structured data with clear relationships, think accounting records and inventory systems. They weren't built with the idea that someday we'd be throwing massive amounts of unstructured text at them and expecting instant results.
Brute Force is Painful When you run something like a Prisma query with contains: 'coffee', under the hood it's still using WHERE description LIKE '%coffee%'. Your database has no choice but to read EVERY SINGLE ROW and check if that string appears anywhere. It's like searching for a specific sentence in a library by reading every book cover to cover. No shortcuts.
Traditional Indexes Don't Help The regular B-tree indexes that make your primary key lookups lightning fast? Nearly useless for text searching. They're amazing for exact matches and ranges (like finding all products between $10-$20), but they fall apart with substring searching.

I tried every indexing strategy I could find with Prisma. The improvements were minimal at best.

The Hybrid Approach That Saved My Sanity

After two weeks of fighting with Prisma and Postgres, I finally convinced the client to let me integrate a dedicated search engine, we chose Meilisearch. Setup took an afternoon, and suddenly our searches were blazing fast (25–50ms!) AND more relevant.

Tutorial: Implementing a Basic Search with Prisma vs Meilisearch

Prisma Search Implementation

Here's how I initially implemented search with Prisma:

// Basic Prisma search query
async function searchProducts(query: string) {
  return prisma.product.findMany({
    where: {
      OR: [
        { name: { contains: query, mode: 'insensitive' } },
        { description: { contains: query, mode: 'insensitive' } }
      ]
    }
  });
}

This approach has several issues:

Cannot use indexes effectively with contains
No relevance ranking
Extremely slow on larger datasets
No fuzzy matching or handling of typos

Setting Up Meilisearch with Prisma

Now let's look at setting up Meilisearch as an alternative.
Run the following docker commands to start a meilisearch instance locally.

Reference: https://www.meilisearch.com/docs/learn/self_hosted/install_meilisearch_locally

# Fetch the latest version of Meilisearch image from DockerHub
docker pull getmeili/meilisearch:v1.13

# Launch Meilisearch in development mode with a master key
docker run -it --rm \
    -p 7700:7700 \
    -e MEILI_ENV='development' \
    -v $(pwd)/meili_data:/meili_data \
    getmeili/meilisearch:v1.13
# Use ${pwd} instead of $(pwd) in PowerShell

Install the meilisearch package

npm install meilisearch

Initialize the client:

import { MeiliSearch } from 'meilisearch';
const client = new MeiliSearch({
  host: 'http://localhost:7700'
});

Creating a index in meilisearch:

const productsIndex = client.index('products')
A helper function to add existing data in meilisearch

async function syncProductsToMeilisearch() {
  const products = await prisma.product.findMany();
  await productsIndex.addDocuments(products);
}

Adding a search route at /api/search/route.ts

import { NextRequest, NextResponse } from "next/server";

export async function GET(request: NextRequest) {
  const searchParams = request.nextUrl.searchParams;
  const query = searchParams.get('q') || '';

  try {
    const results = await productsIndex.search(query, {
      attributesToHighlight: ['name', 'description']
    });

    return NextResponse.json(results);
  } catch (error) {
    console.error('Search error:', error);
    return NextResponse.json({message: "Internal Server Error"}, {status:500})
  }
}

Benefits of this approach:

Blazing fast results (typically 25–50ms)
Typo tolerance out of the box
Relevance ranking designed for search
Highlights in the results
Easy filtering and faceting

The Takeaway

Don't repeat my mistake. If search is important to your application, recognize early that SQL databases have fundamental limitations here. They're amazing tools, just not for this specific job.

Use SQL databases with Prisma for what they excel at, and pair them with a dedicated search solution (Elasticsearch, Meilisearch, Algolia, etc.) for text searching. Your users will thank you, your servers will thank you, and your future self will definitely thank you.

Your sanity is worth the extra infrastructure complexity. Trust me on this one.

Connect with Me

If you enjoyed this post and want to stay in the loop with similar content, feel free to follow and connect with me across the web:

Twitter: Follow me on Twitter for bite-sized tips, updates, and thoughts on tech.
Medium: Check out my articles on Medium where I share tutorials, insights, and deep dives.
Email: Got questions, ideas, or just want to say hi? Drop me a line at codezera3@gmail.com.

Your support means a lot, and I'd love to connect, collaborate, or just geek out over cool projects. Looking forward to hearing from you!

Using Shadcn Forms in Big Projects

CodeZera — Tue, 08 Apr 2025 19:32:29 +0000

If you’ve been building stuff with Next.js, I’m pretty sure you’ve come across shadcn/ui. It’s kinda become the go-to component library for a lot of devs (myself included), and for good reason — the components look great and you can tweak them however you want.

But man, I’ve got a bone to pick with how they handle forms. Don’t get me wrong, it works fine when you’re just messing around with a small project. But once you start building something serious? That’s when the headaches begin.

Let me show you what I mean. Here’s what you need just to add ONE input field with their approach:

<FormField
  control={form.control}
  name="username"
  render={({ field }) => (
    <FormItem>
      <FormLabel>Username</FormLabel>
      <FormControl>
        <Input placeholder="shadcn" {...field} />
      </FormControl>
      <FormDescription>This is your public display name.</FormDescription>
      <FormMessage />
    </FormItem>
  )}
/>

Like… seriously? All that for one input? 🤦‍♂️

This is fine when you’re throwing together a quick login form or something. But I’m currently working on an enterprise app with about 30 different forms, some with 20+ fields each. Using the standard shadcn approach would mean writing a novel’s worth of TSX.

Why This Drove Me Crazy

After copy-pasting similar form code for the hundredth time, I started noticing some really annoying problems:

Our codebase was getting bloated with basically the same form boilerplate everywhere.
Different devs on the team were handling error states differently
When design wanted to change how form fields looked, we had to update stuff in like 50 different places.
I wasted an entire weekend refactoring a bunch of forms that should’ve taken me a few hours. That’s when I decided enough was enough.

The Better Way

So I spent some time thinking about how to fix this mess without throwing away shadcn (because the components themselves are actually great). What I came up with has saved me tons of time.

Here’s the basic idea — instead of writing out every form field manually, what if we just described what we wanted and let the code handle the rest?

How I Fixed It

First we need to create some from elements, you can add these anywhere i like to add them inside my components folder -> form-elements.

Here’s what my input element code looks like

import { useFormContext } from 'react-hook-form'
import { FormControl, FormDescription, FormField, FormItem, FormLabel, FormMessage } from '@/components/ui/form'
import { Input } from '@/components/ui/input'
import { cn } from '@/lib/utils'

interface InputElementProps extends React.InputHTMLAttributes<HTMLInputElement> {
  name: string  
  label?: string
  description?: string
  isOptional?: boolean
  inputClassName?: string
  labelClassName?: string
}

const InputElement: React.FC<InputElementProps> = ({ name, label, placeholder, description, isOptional, labelClassName, inputClassName, ...props }) => {
  const { control } = useFormContext();

  return (
    <FormField
      control={control}
      name={name}
      render={({ field }) => (
        <FormItem className={cn('', props.className)}>
          {label && (
            <FormLabel className={cn('', labelClassName)}>
              {label}
              {isOptional && (
                <span className="text-neutral-400"> (optional)</span>
              )}
            </FormLabel>
          )}
          <FormControl>
            <Input
              {...field}
              placeholder={placeholder}
              className={cn('', inputClassName)}
              type={props.type || 'text'}
              disabled={props.disabled}
              value={props.value || field.value}
              autoComplete={props.autoComplete}
              onChange={props.onChange}
            />
          </FormControl>
          {description && (
            <FormDescription>
              {description}
            </FormDescription>
          )}
          <FormMessage />
        </FormItem>
      )}
    />
  )
}

export default InputElement

Thats basically it, we now have all the input element attributes as props and we dont even have to pass the form states inside each element, we just need to wrap the forms inside the Form component from shadcn ui.

The Difference Is Huge

Check this out. Here’s what our login-form looks like now.

"use client"

import { zodResolver } from "@hookform/resolvers/zod"
import { useForm } from "react-hook-form"
import { Form } from "@/components/ui/form"
import InputElement from "@/components/form-elements/input-element"
import { Button } from "@/components/ui/button"
import { LoginRequest, LoginSchema } from "@/zod-schemas/auth/login.schema"
import Link from "next/link"
import { PageRoutes } from "@/constants/page-routes"

const LoginForm = () => {
  const form = useForm<LoginRequest>({
    resolver: zodResolver(LoginSchema),
    defaultValues: {
      email: "",
      password: "",
    }
  })

  const onSubmit = async (values: LoginRequest) => {
    console.log("Form submitted with values:", values)
  }

  return (
    <Form {...form}>
      <form onSubmit={form.handleSubmit(onSubmit)} className="space-y-6">
        <div className="space-y-4">
          <InputElement
            label="Email"
            name="email"
            placeholder="johndoe@gmail.com"
          />
          <InputElement
            label="Password"
            name="password"
            type="password"
            placeholder="********"
          />
          <Button variant="link" size="sm" className="px-0 h-fit" asChild>
            <Link href={PageRoutes.AUTH.FORGOT_PASSWORD}>
              Forgot Password?
            </Link>
          </Button>
        </div>

        <Button type="submit" className="w-full" size="lg">
          Login
        </Button>
      </form>
    </Form>
  )
}

export default LoginForm

Way better, right?

Was It Worth It?

100%. What used to take me an entire day now takes about 10–20 minutes. Even the junior devs on our team can crank out complex forms without breaking a sweat.

The best part? When design wanted to update our form styles recently, I made the changes in ONE file instead of hunting down form fields across our entire app.

If you’re building anything beyond a tiny project with shadcn, trust me — spend a day setting up something like this. Your future self will thank you.

I’ve put together a github gist with all of the elements i use in my projects, if you wanna check it out here.

Let me know if this helps or if you’ve come up with an even better approach!

Connect with Me

If you enjoyed this post and want to stay in the loop with similar content, feel free to follow and connect with me across the web:

Twitter: Follow me on Twitter for bite-sized tips, updates, and thoughts on tech.
Medium: Check out my articles on Medium where I share tutorials, insights, and deep dives.
Email: Got questions, ideas, or just want to say hi? Drop me a line at codezera3@gmail.com.

Your support means a lot, and I'd love to connect, collaborate, or just geek out over cool projects. Looking forward to hearing from you!

Integrating Mixpanel with Next.js

CodeZera — Mon, 07 Apr 2025 17:48:18 +0000

Let’s be real, If your app has even slightly more going on than a basic CRUD, you’ll 100% want some kind of analytics. Whether it’s to track what features users actually use, or where they drop off, or even just how many people clicked that shiny new button you spent 3 hours designing, analytics help you understand what is going on with your website.

Today, we’re gonna look at how to integrate Mixpanel, one of the most powerful analytics platforms out there, with Next.js, which is kind of the go-to full stack framework these days.

I’m assuming you already have a nextjs project setup and a mixpanel account, you can signup on https://mixpanel.com/register/ its free .

🧩 Installing Dependencies

First things first, we need to get Mixpanel into our project. Fortunately, there’s an official SDK for the web which works great with Next.js.

Here’s the command you’ll need:

npm install mixpanel-browser

Initializing Mixpanel

Great, now lets initialize mixpanel in our app.

Lets start simple, we’ll just create a function called initMixpanel.


import mixpanel from 'mixpanel-browser';

const MIXPANEL_TOKEN = process.env.NEXT_PUBLIC_MIXPANEL_TOKEN;

export const initMixpanel = () => {
  if (!MIXPANEL_TOKEN) {
    console.warn('Mixpanel token is missing!');
    return;
  }
  mixpanel.init(MIXPANEL_TOKEN, { debug: true });
}

Just make sure you add NEXT_PUBLIC in front of the env var name like we have in the snipped above, so that it is accessible on the client.

Now lets, add this to our root layout, but most probably you'll have a metadata object in your root layout and if you try to initialize it there with a useEffect you'll get a error.

You can create a providers.tsx and add the following code there

"use client"
import { useEffect, useState } from "react";
import { initMixpanel } from "@/lib/mixpanel";
import mixpanel from "mixpanel-browser";

export default function Providers({ children }: { children: React.ReactNode }) {

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

  return (
    {children}
  )
}

Now we can wrap our root layout with this providers component like this.

import "./globals.css";
import Providers from "@/providers";
import type { Metadata } from "next";

export const metadata: Metadata = {
  title: "Mixpanel Example",
  description: "Mixpanel Nextjs example application",
};

export default function RootLayout({ children }: Readonly<{ children: React.ReactNode; }>) {
  return (
    <html lang="en">
      <body>
        <Providers>
          {children}
        </Providers>
      </body>
    </html>
  );
}

If you are worried about wrapping your server components, then let me tell you one thing, you can wrap server components under a client component, nextjs will handle that for you.

🔑 Getting Your Mixpanel Token

If you haven't already set up a Mixpanel project, go do that now, it's free to start.

Once thats done, head over to your mixpanel dashboard:

Click on the gear icon on bottom right
Go to settings -> Project Settings
Scroll down a bit you'll see a section for Access Keys you can copy the project token and add it to your .env file with the variable name NEXT_PUBLIC_MIXPANEL_TOKEN

📈 Tracking Events

Keep in mind: Mixpanel uses a lot of event-based analytics, so it helps to come up with a consistent naming system for your events. Don't be random like "CLICKED THINGY" in one place and "User Clicked Important Button" somewhere else. Future you will thank you.

Here's a example enum for how you can keep your event names consistent:

export enum TRACK_EVENT {
  PAGE_VIEW = "page_view",
  SIGN_IN = "sign_in",
  SIGN_UP = "sign_up",
  SIGN_OUT = "sign_out",
  USER_PROFILE_UPDATE = "user_profile_update",
}

You can obviously add more according to your requirements.

Alright, now the fun part begins, tracking some stuff.

Let's say you wanna track whenever someone clicks a button, submits a form, views a page, whatever.

Here's what that might look like for a page view event:

import mixpanel from "mixpanel-browser";
import { TRACK_EVENT } from "@/types/enums";

const HomePage = () => {
  useEffect(() => {
    mixpanel.track(TRACK_EVENT.PAGE_VIEW)
  }, [])

  return (
    {/* Your jsx here */}
  )
}

export default HomePage;

Here's how you can use it in a function:

const handleUserLogin = async (values) => {
  mixpanel.track(TRACK_EVENT.SIGN_IN, {
    email: values.email,
  })
  // Your login logic goes here…
}

🙋 Identifying Users

Tracking anonymous users is fine at first, but to get real insights, you'll wanna associate events with actual users once they log in or sign up.

Lets say you call a login function and that will make a backend call, log the user in and then return the logged in user back to you, now with that user object you have to do something like this.

const user = axios.post("/api/account/login", values)
  mixpanel.identify(user?.id);
  mixpanel.people.set({
    "$email": user?.email,
    "$name": user?.name
 })

Important: Make sure you always call identify() before calling people.set(). Because let's say someone visits your site while logged out, they browse around, trigger some events, maybe even click a CTA or two. Mixpanel is already tracking those events and tying them to an anonymous device ID behind the scenes.

Now, if that person logs in and you call mixpanel.identify(userId), Mixpanel will go:

Ohhh, this device is now associated with user_123.

It stitches together all the events that happened before login and connects them to the actual user profile. Super helpful for seeing the full journey, not just post-login stuff.

So yeah, call identify() first, then people.set() to attach user properties like email, name, plan, whatever.

This lets you see how specific users behave over time, group them into cohorts, and get waaaay more out of Mixpanel.

🎉 Wrapping Up

That's pretty much it for getting started with Mixpanel in Next.js.

Just to recap:

Install mixpanel-browser
Initialize it (ideally with a singleton pattern)
Use your project token
Track some events
Identify your users

Once you get these basics in place, you can go wild with funnels, retention, A/B tests, whatever you need to make smarter product decisions.

Happy tracking!

Connect with Me

If you enjoyed this post and want to stay in the loop with similar content, feel free to follow and connect with me across the web:

Twitter: Follow me on Twitter for bite-sized tips, updates, and thoughts on tech.
Medium: Check out my articles on Medium where I share tutorials, insights, and deep dives.
Email: Got questions, ideas, or just want to say hi? Drop me a line at codezera3@gmail.com.

Your support means a lot, and I'd love to connect, collaborate, or just geek out over cool projects. Looking forward to hearing from you!

How I Lost 10 Hours of My Weekend Solving This PDF Generation Nightmare (So You Don’t Have To!)

CodeZera — Mon, 27 Jan 2025 07:15:05 +0000

Let me start by introducing myself and explaining how this problem occurred in the first place.

I'm a full-stack web developer, with a stronger focus on the frontend. About a year ago, I joined a company that was working on a mortgage application website for a client. Before I arrived, there was only one developer working on that project, and he wrote all the code for generating PDFs using Puppeteer and Mustache. (If you don’t know what these are, continue reading; I’ll explain briefly.) He left the company after a while, and now I’m responsible for maintaining it.

As a frontend developer, I had no idea what Puppeteer was or why we even needed it.

Our backend was deployed on a platform called Railway, which provides a great experience for deploying Dockerized applications. (I think you can also deploy directly, and they handle the Dockerizing part for you, but it’s better to create a Dockerfile on your own.)

The Problem

Recently, a problem occurred on the website: we were sending a generated PDF from our backend when a user listed a mortgage application, but the emails were not getting delivered.

At first, I thought it might be related to the plan expiration with our email provider, Brevo. However, I tested it on my local machine with a solid email setup using Gmail's SMTP server. (If you want to know more about how this works, stay tuned; I’ll post a detailed blog on how to set this up for your projects.) To my relief, it worked perfectly.

I was almost certain that the issue was 100% related to our Brevo account, so I decided to enjoy my weekend. But then my manager, who oversees all the accounts, confirmed that the Brevo plan was not expired and that the problem was related to our backend.

I was really confused about what to do because everything was working fine on my local setup. I even tried changing the SMTP credentials in the production environment, but still no luck.

Then, I thought it might be that Railway was blocking outgoing emails for some reason. I raised a ticket on their forum to ask if they had recently started blocking outgoing SMTP traffic. One of their employees replied that Railway doesn’t block any outgoing traffic on any port.

Now, I was back to square one: the email provider was working fine, there was no problem with Railway, and everything was still functioning well on my local machine.

The Investigation

So, I did what any professional developer would do: I wrote a ton of console.log statements in my branch (literally one for each line, one before the variable initialization and one after, because I was just so frustrated about what was going wrong in Railway that was working on my local machine). I pushed everything to the testing environment in Railway.

After hours of checking the logs and confirming everything, I discovered that the problem was related to a package called Puppeteer. Now, let me explain what Puppeteer is and why it was used in my project.

What is Puppeteer?

Puppeteer is a JavaScript library that provides a high-level API to control Chrome or Firefox over the DevTools Protocol or WebDriver BiDi. Puppeteer runs in headless mode (no visible UI) by default. (This is directly from their official website; I also don’t fully understand how it works!)

To understand why it is needed, consider that there is no easy way to convert HTML to PDF. It is straightforward to generate an HTML page with some dynamic data using Mustache (you just pass it a base template and the data you want in the required format, and it creates an HTML page with all the data you provided).

To convert the rendered HTML to PDF, you need something called Puppeteer. It runs a browser inside your container, creates a new browser tab, and allows you to perform many operations you would do with that opened tab, such as taking screenshots or downloading the page as a PDF. So, it creates a page using the HTML data you provide and generates a PDF for you, which you can then save to any folder you like using the fs module.

Puppeteer offers many more features beyond this, but this is essentially what we used it for.

The Solution

Now, let’s get back to why this was causing a problem for me and how I figured it out. While checking my logs, I consistently saw that everything was working fine, but the code was always stuck at the log I wrote before launching Puppeteer.

After searching on Google and my favorite, Stack Overflow, I found out that the version of Puppeteer we were using had two issues:

It was deprecated.
It worked fine on local machines but had some weird issues when trying to launch a browser through it in Railway.

After hours of research, I came across a GitHub repository called Browserless. It essentially removes the overhead of launching a browser through Puppeteer. Puppeteer can connect to it and execute headless work all inside Docker.

To my luck, I also found a premade template for Railway that you can deploy with just one click on their platform. Here are the links to that template and a Puppeteer example:

Conclusion

In the world of web development(especially the devil JS), unexpected challenges can arise at any moment, often leading to frustrating experiences. My weekend was spent troubleshooting the PDF generation issue taught me valuable lessons about persistence, the importance of understanding the tools we use, and the power of community resources like GitHub and Stack Overflow. By using the right tools and resources, I was able to resolve this issue and ensure that our application functions smoothly.

If you find yourself facing similar challenges, remember that you're not alone. Don't hesitate to reach out for help, whether through forums, documentation, or fellow developers.

And lastly, if you're interested in learning how to create PDFs using Puppeteer and Mustache, drop a comment below, and I'll be happy to share a detailed guide!

Until next time, happy coding!

Part-5: Functions and Comments in Rust

CodeZera — Wed, 31 Jan 2024 14:14:22 +0000

Hey folks, welcome to part-5 of my blog series on rust. In this series we are learning rust programming language from scratch, if you haven't read the previous parts then i highly recommend to read those first so that you get the context of what we are doing here. Read here.

So without wasting any time lets get started!

Functions

If you haven't noticed, You've already seen the usage of functions, in fact you've used it (if you read the previous parts here).

If you guessed it then you're correct its the main function , all of our code lives inside this main function.

You've also seen the fn keyword which allows us to write a new function.

Rust's convention is to write function and variable names in snake case (snake case is basically all lower case letters separated by underscores eg: this_is_a_function_name).

Lets write another function called printer function which will just print something in the terminal.

fn main() {
   printer_function();
}

fn printer_function() {
   println!("This function prints something!");
}

If you try to run the above code you'll see the statement printed in the terminal. Now lets see what all things are going on, skip the main function for now, below that we have declared a new function called printer_function which has a body inside the curly braces, which basically prints a string in the terminal. For defining a new function we first need to write fn keyword followed by a space followed by function's name (it can be anything) followed by a set of parenthesis and then a set of curly braces, inside this curly braces you can write whatever logic you want to run when this function is called.

Now lets go back to the main function, what main function is doing here is calling the printer_function to call a function you just need to type the function's name and followed by a set of parenthesis.

Note: We have defined printer_function after the main function thats not necessary we could've defined it before as well, rust simply doesn't care where you've defined your functions. Only thing that matters is its inside the scope that can be seen by the caller.

Parameters

We can also define functions to have some parameters, which are basically special variables that are part of a function's signature. When a function has parameters you can provide it with concrete values for those parameters. Technically, it is called arguments, but in the real world devs use parameters and arguments interchangeably.

Lets see how a function with parameters looks like:

fn main() {
    printer_function(5);
}

fn printer_function(x: i32) {
    println!("The value of parameter x is {x}");
}

Try running this program you'll see it ill print the given string in the terminal and the value of x will be 5.

Now lets understand how this is working, when we declared the printer_function we gave it a parameter inside the parenthesis called x(you can name it anything) which is of data type i32 (Don't know what a data type is? Check out my blog on data types in rust here), and we just use that parameter x in our functions logic.

And also if you see inside the main function where we called the printer_function we gave it a number 5 inside the parenthesis which is of type i32, and we have to give it a variable of type i32 only because we mentioned this in our functions parameter signature, now try to give it a string instead of a i32, you'll get an error because you have to provide a concrete value of the same data type with you mentioned in the functions parameters.

Statements and Expressions

Now this can be a bit confusing, if you're just starting with rust atleast for me it was hard to understand in the first try, lets try to simplify this as much as possible.

A function's body is made up of series of statements and the last line is basically called expression. Expression is basically like a return line, if you're familiar with coding and function then you know that a return statements just ends a function and that is called an expression in rust.

Lets understand a bit what is the difference between the two because this is a bit different from other programming languages:

Statements: These are instructions that perform some action and do not return a value.

Expressions: These evaluate to a resultant value.

Lets understand this with a example.

We've actually used statements in many places before, for example,

let x = 100;

This is a statement in itself, there is a simple trick to understand it better all the lines ending with a semi-colon are statements and one which does not have semi-colon in the end is an expression but that should be last line of function's body.

Now if we try something like following:

fn main() {

    let x = 100

    println!("The value of x is {x}");

}

Then we'll get an error because we can't write expressions in the middle of a function's body here the function is main we have to write the expressions in the end.

If we try to run the following code:

fn main() {
    let x = 100;

    println!("The value of x is {x}")
}

It will work perfectly fine, because expressions should be last line of the function.

Now you might be thinking that what if there are some conditionally situations in which i want to terminate a function which is pretty common in programming for that you can use the return keyword to terminate the function like following:

fn main() {
    fn another_function() -> i32 {
        let condition = true;
        if condition {
            return 10;
        } else {
            return 50;
        }
    }

    let x = another_function();

    println!("The value of x is {x}");
}

In the above example the value of x will be 10 because condition will always be true, one imp thing if you directly try to return something without specifying i32 or whatever is the return type of your function then you'll get an error.

Learn with more examples on statements and expressions here.

Comments

This topic is in almost all programming languages, and its a very easy one and if you're even a little bit familiar with coding then there are high chances you might actually know this.

Comments are basically lines which are ignored by your compiler. Now you might be thinking then why do we need them, sometimes when you want to explain your code you leave comments just for some more explanations for the person reading your code.

Here’s a simple comment:

// Hello, world!

You write a comment by adding two forward slashes and then write whatever you want after a space. That particular line is ignored by compiler. You can even write comments after a code line like following

let y = 7; // this assigns a value of 7 to variable y.

The comment will be ignored by the compiler and rest code will run as usual.

That's It!

That was a pretty big blog, i hope you liked it and learned something new, if you did then please react to this blog and leave a comment if you have any doubts or suggestions.

In the next blog we'll see control flow in rust. See you guys in the next one, Till then!

Happy Coding :)

You can find me on twitter here.

Part-4: Data Types in Rust

CodeZera — Sun, 28 Jan 2024 14:53:24 +0000

Hey folks, welcome to part-4 of my blog series on rust. In this series we are learning rust programming language from scratch, if you haven't read the previous parts then i highly recommend to read those first so that you get the context of what we are doing here. Read here.

So without wasting any time lets get started!

Every variable in Rust is of a certain data type, which basically tells Rust what kind of data is being specifit so it knows how to proceed with that data. We'll majorly see two data type subsets: scalar and compound.

Rust is a statically typed language so it should know the type of each variable at the compile time.

If you're already familiar with TypeScript then rust works something like that only. For example look at the following example:

let guess: u32 = "42".parse().expect("Not a number!");

Try pasting the above code in your text editor and then try to print it out like following:

println!("The value of guess is {guess}");

Voila! Everything works fine, but now try to remove the : u32 and then try to print it, you'll get an error, because you have to tell rust what do you expect.

So basically what the above code is doing is, there is a variable called guess and which is initially a string and we are trying to parse it (basically converting it into a number) and then we add a expect function, which basically expects the parsed value to be a u32 and if it is not a u32 then it will throw a error called Not a number!.

What is a Scalar Type?

A scalar type represents a single value. In rust there are four primary scalar types i.e. integers, floating-point numbers, Booleans and characters. If you're familiar with coding then you may recognise these are same in almost all programming languages.

Now lets see how they work in rust:

All the below data and images are directly from the rust programming language book. You can check this book out here.

1. Integer

An integer is a number without a fractional component. The type we used in the above example was of unsigned integer that takes up 32 bits of size (signed integer types start with i and unsigned start with u).

You can check the following table to know more about the different types of integers available in rust.

Signed basically means that integer can be negative as well, unsigned integers are always positive and therefore it can be written unsigned.

You can check more on integer types in the official rust programming language book here.

2. Floating Point Types

Rust also has two primitive types for floating-point numbers, which are numbers with decimal points. Rust’s floating-point types are f32 and f64, which are 32 bits and 64 bits in size, respectively. The default type is f64 because on modern CPUs, it’s roughly the same speed as f32 but is capable of more precision. All floating-point types are signed.

Rust also supports floating point numbers which are basically numbers with decimal points. There are only two types of floating point types in rust i.e. f32 and f64, which ig you'll guess at this point f32 is a 32 bit and f64 is 64 bit in size.

The default type is f64 in rust because on modern CPUs its roughly same speed as f32 but it is capable of more precision. All floating-point types are signed.

Numeric Operations

Rust supports all basic mathematic operations you'd expect for all number types.

fn main() {
    let sum = 5 + 10;

    let difference = 95.5 - 4.3;

    let product = 4 * 30;

    let quotient = 56.7 / 32.2;

    let truncated = -5 / 3;

    let remainder = 43 % 5;
}

3. Boolean Type

A boolean type in rust, just like in almost all programming languages, can have two values either true or false.

You can write a boolean as follows in rust:

let ironman = true;

let superman: bool = false; // Just with explicit type annotation

4. Character Type

Here are some examples of rust's character types.

let x = 'x';
let y: char = 'X'; // with explicit type annotation
let laugh = '😂';

Note there here the values are inside single quotes unlike other strings.

What is a Compound Type?

A compound type just groups multiple single scalar types. Rust have two compound types as primitives i.e. arrays and tuples.

1. Tuples

A tuple is a general way to group a number of scalar types into one single compound type.

We can create a tuple by writing a comma-separated list of values inside parentheses. Each position has its type and order matters in tuples, and also different values need not to have same type.

A simple example of a tuple is mentioned below:

let some_tup: (u32, f64, u8) = (500, 2.543, 1);

You can also extract values from tuple like following:

fn main() {
   let some_tup: (u32, f64, u8) = (500, 2.543, 1);

   let (a, b, c) = some_tup;

   println!("The value of b is {b}");
}

The above code first creates a tuple with some values of different types and then extracts or destructure the value from that tuple and then finally print a variable.

We can also extract a particular element directly using a . and then followed by its index(index starts from 0). You can do this like following:

For simplicity i've removed the main function, you need to wrap this with main function in order for this to work.

let some_tup: (u32, f64, u8) = (500, 2.543, 1);
let first = some_tup.0;
let third = some_tup.2;

println!("The value of first is {} and value of third is {}", first, third);

Learn more about tuples here.

2. Array Type

Another way to grouping multiple values together is an array. But there is one major difference between these two i.e. each element in a array must be of same type. Arrays are useful when you know the number of elements inside it won't change like days in a week or months in a year.

An array is declared like following:

let arr = [1,2,3,4,5];

Arrays are also very useful when you want the data to be stored in the stack rather than heap. We'll learn more about stack and heap in upcoming blogs, trust me its a very interesting topic.

You can access a particular element like following:

let arr = [1,2,3,4,5];

let first = arr[0];

let last = arr[4];

println!("The value of first is {first} and value of last is {last}");

Thats it!

Whew, that were so many data types for someone new in programming, but these are one of the most important topics for any programming language.

In the upcoming blogs, we'll see functions, comments and control flow in rust. Keep waiting for next one, Till then!

Happy Coding!

You can find me on twitter here.

Part-3: Variables and Mutability in Rust

CodeZera — Thu, 25 Jan 2024 14:25:10 +0000

Hey folks, welcome to part-3 of my blog series on rust. In this series we are learning rust programming language from scratch, if you haven't read the previous parts then i highly recommend to read those first so that you get the context of what we are doing here. Read here.

So without wasting any time lets get started!

Mutability

To understand mutability better, lets try to run a simple code. Paste the following code on your VS code or whatever IDE you use.

fn main() {
    let x = 1;
    println!("The value of x is: {x}");
    x = 2;
    println!("The value of x is: {x}");
}

What this code does is just assign x variable a value of 5 and then print it. After that we try to change the value of x to 6 and again print it.

Now if this would have been a language like javascript then where would have been no issues with this code but my friends with rust life is not that easy. Go ahead and try to compile this code (SPOILER: You'll get an error!).

You'll get get error message something like "cannot assign twice to immutable variable x".

This happened because by default all variables in rust are immutable, meaning you cannot change the value of a variable if you've declared it, but it does not mean you cannot change it by anyway. There is a way, try running the following code:

let mut x = 1;
println!("The value of x is {x}");

x = 2
println!("The new value of x is {x}");

Now the above code will work perfectly fine. Meaning you just have to specify while declaring the variable that it is mutable or not, by default all variables are immutable but you can change this behaviour by writing mut keyword just before the variables name.

When we code in rust compilers errors are actually good, it doesn't mean you're a bad developer, even the experts get compile time errors because rust tries to eliminate all possible bugs beforehand.

Constants

Constants are declared like following:

const x = 5;

Constants are just like immutable variables i.e. You are not allowed to change them but there are some differences.

First, You cannot use mut keyword with constants. Constants are always immutable, you cannot change this behaviour at all.

Second, Constants can be declared in any scope. Which is very useful especially when you want something like global variables.

Third, Constants can be set only to a constant expression, which basically means that you cannot set constant variables to a result which will be calculated at runtime.

Rust’s naming convention for constants is to use all uppercase with underscores between words.

Shadowing

In rust you can shadow variables meaning you can declare a new variable with the same name as the previous variable. This case is generally called Shadowing. An example of shadowing is mentioned below:

let x = 1;
let x = x + 1;

println!("The value of x is {x}");

We can say that first variable is shadowed by second, which basically means that compiler will see the second variable at the compile time.

Is shadowing same as mut?

You might be thinking shadowing is same as mut, but these both are actually different, because we'll get a compile time error if we accidentally try to reassign value to variable x without using the let keyword. By using let, we can perform transformations to the variable but it will be immutable after those transformations are done.

There is one more difference between mut and shadowing, you can also change the type of the variable when you do shadowing. You can understand this with the help of following example:

let x = "    ";
let x = x.len();

The first variable x is a string type(spaces are completely valid in rust and are treated as string) and second is number type. Basically you can change the type if you do shadowing. But if we try to do mutation here like following:

let x = "    ";
x = x.len();

We'll get compile-time error.

That's It!

Today we learned the concept of mutability in rust, also what are constants and the concept of shadowing in rust and how it is different from mut.

Thats it for this blog, see you guys in the next one. Till then!

Happy Coding!

You can find me on twitter here.

Part-2: Introduction to Cargo🚢

CodeZera — Fri, 19 Jan 2024 10:30:20 +0000

Hey folks, welcome to part 2 of my blog series on rust, where we'll learn the rust programming language from scratch. If you haven't read the first part then, i recommend you to read that first to install rust on your machine. Read part-1 here.

Lets start with part-2 of our series!

What is Cargo?

If you are familiar with nodejs and npm then its very easy for you to understand, cargo to rust is what npm is to js.

Cargo is Rust’s build system and package manager. Most Rustaceans, yeah this is what rust devs call themselves, the one who has written hello world is also a proud rustacean.

Rustaceans, use this tool to manage their Rust projects because Cargo handles a lot of tasks for you, such as building your code, downloading the libraries your code depends on, and building those libraries.

If you don't know what a package manager is then no worries let me explain, basically the idea here is no one should write everything by themselves, especially the code which other have written in a more effective way, suppose you are making a random number generator, now there are two options: one is you write all the logic by yourself or by installing something called a package in your code, which is nothing just some lines of code which will do your work very easily.

If still the picture is not clear to you, then i'll suggest just be patient, google things out and you'll understand it by time.

To check the verson of the cargo, place the following command in your terminal:

cargo --version

Creating your first project with Cargo

Let’s create a new project using Cargo and look at how it differs from our original “Hello, world!” project we discussed in our last blog. Enter the following command in your terminal and press enter:

cargo new hello_cargo

This will make a new folder called hello_cargo, now go to that folder by using the following command:

cd hello_cargo

Your directory should look like the following:

Lets understand this folder structure a bit,src folder is the place where all of your rust code will live. Initially it will have a main.rs file which will have the following code:

fn main() {
    println!("Hello, world!");
}

If you remember this is the same code which we wrote manually in our last blog. This code just prints Hello, world! in the console.

Moving on, you'll see a .gitignore file which if are familiar with git then you already know what it does. If not, then i highly highly recommend learn git, its a mandatory(not really but its like abcd for devs) skill for developers.

Next you'll see a Cargo.toml file, this file is in the TOML (Tom’s Obvious, Minimal Language) format, which is Cargo’s configuration format. This file is similar to package.json file, if you've used node before. This file basically have information about your project, for example name of your project, its version and edition.

Let me explain you the structure of this a bit, The first line, [package], is a section heading and whatever is below that will come under package until there is another section heading. As we add more information to this file, we’ll add other sections. You can see [dependencies] section heading this will contain all of your project dependencies or packages you'll install in future.

Building and Running a Cargo Project

For building and running there are two approaches, lets see both of those:

1. Manually Building and Running

To run the project you need to first build the project and then run it. To build the project use the following command:

cargo build

This will make you a binaries build which you can execute or run. Now when you'll run this command it will make a file inside the ./target/debug called hello_cargo, this file has the binary for the project. To run the binary you need to run the following command:

./target/debug/hello_cargo

If everything works fine, you'll see a Hello world! in the console.

2. Directly running the project

There is another command through which you can directly build and run the project. To do so run the following command:

cargo run

This command will directly build and run the project, and this command is used a lot when you're developing a project in rust.

Special Section

When your project is ready for release, you can use the following command:

cargo build --release

This command will build the project with optimizations. This command will create the binaries file inside the ./target/release directory instead of ./target/debug. These optimizations will make your rust code run faster. This command is not used while developing because it takes a bit longer than the normal cargo build command.

Why even use Cargo?

You might be thinking, why do we even need the cargo, why can't we write everything directly, like we did in our last blog. For now it won't make much sense but when your code will grow, cargo will help you a lot in managing your code.

Thats it!

You're already off to a great start on your rust journey, i hope you like this series, if you do then do like the blog and comment down below if you need any improvements in the blog.

Thats it for today, see you guys in the next one. Till then!

Happy Coding!

You can find me on twitter here.