Forem: David J Song

Understanding "use client" in Next.js: What It Really Affects

David J Song — Mon, 03 Nov 2025 16:58:27 +0000

Many developers misunderstand how "use client" works in Next.js App Router (React Server Components).

It doesn’t make everything below it client-rendered. It only changes the behavior of the file itself and what it directly imports.

1. The Common Misconception

You might have heard:

“If you use "use client", all your child components become client components.”

That’s false.

2. The Real Rule

When you add "use client" at the top of a file:

✅ That file becomes a client component.
✅ Anything it imports becomes a client component too.
🚫 But components passed in as children props are not affected.

Children remain whatever they were defined as (server or client).

3. Example: Safe Provider Pattern

// app/providers.tsx
"use client";

import { ThemeProvider } from "@mui/material";
import { QueryClientProvider } from "@tanstack/react-query";

export function Providers({ children }: { children: React.ReactNode }) {
  return (
    <ThemeProvider>
      <QueryClientProvider>{children}</QueryClientProvider>
    </ThemeProvider>
  );
}

This Providers component is a client component, because it needs React context, hooks, and browser logic.

But {children} are not converted to client components — they stay server-rendered.

4. How It Works

When a server component (like your layout) calls a client component:

layout.tsx (server)
 └── Providers.tsx ("use client")
       └── children (server or client)

React Server Components serialize the child tree as HTML and pass it into the client boundary.

The Providers component doesn’t recompile or import the children — it just receives them as already-rendered markup.

5. Why This Matters

Keeping most of your UI as server components gives you:

Smaller JS bundles
Faster page load
Better SEO and streaming performance

Use "use client" only when you need:

Hooks like useState, useEffect
Event handlers (onClick, onChange)
Access to window or browser APIs

So now I am no more "use client"-phobic. 😂

NextAuth + Supabase: Handling Authentication in a Modern Full-Stack App

David J Song — Tue, 09 Sep 2025 16:47:39 +0000

When I built ONNS (옷늘날씨), I wanted sign-in to feel effortless. Nobody wants to manage yet another password, and I definitely did not want to spend weeks reinventing authentication. That is why I combined NextAuth with Supabase. Together, they allowed me to focus on building the fun parts of the app while still maintaining solid security.

Why This Combo?

NextAuth is the de facto standard for authentication in Next.js apps. It supports OAuth providers, session management, JWTs, and integrates seamlessly with App Router.
Supabase provides a complete Postgres backend with real-time and storage. Since user accounts and posts live in Supabase, tying authentication into the same ecosystem just made sense.

By combining them, I got the best of both worlds: flexible provider-based login through NextAuth, and user records managed in Supabase.

The Flow

A user clicks Sign in with Google (or another provider).
NextAuth handles the OAuth handshake.
On success, NextAuth calls a custom adapter that syncs the user with Supabase.
The session is then available across the app.

This way, authentication feels native, and all user-related data stays consistent in the database.

Example Implementation

NextAuth config:

// app/api/auth/[...nextauth]/route.ts
import NextAuth from "next-auth";
import GoogleProvider from "next-auth/providers/google";
import { SupabaseAdapter } from "@next-auth/supabase-adapter";

export const authOptions = {
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    }),
  ],
  adapter: SupabaseAdapter({
    url: process.env.SUPABASE_URL!,
    secret: process.env.SUPABASE_SERVICE_ROLE_KEY!,
  }),
  secret: process.env.NEXTAUTH_SECRET,
};

const handler = NextAuth(authOptions);
export { handler as GET, handler as POST };

Protecting a route:

// app/feed/page.tsx
import { getServerSession } from "next-auth";
import { authOptions } from "../api/auth/[...nextauth]/route";

export default async function FeedPage() {
  const session = await getServerSession(authOptions);

  if (!session) {
    return <p>Please sign in to view the feed.</p>;
  }

  return <p>Welcome, {session.user?.name}! Here is your personalized feed.</p>;
}

Benefits I Saw

Simplicity: I did not need to roll my own login system. NextAuth handled the heavy lifting.

Security: Supabase stored user records in Postgres, and I could enforce RLS (row-level security) policies.

Flexibility: Adding more providers (GitHub, Twitter) is almost copy-paste.

Integration: Since posts, comments, and profiles already lived in Supabase, user identities aligned perfectly with the data model.

A Quick Lesson

NextAuth and Supabase both support authentication separately. You could use Supabase Auth alone. However, by using NextAuth, I achieved tighter integration with Next.js features, such as middleware and server actions. The adapter pattern meant I did not have to pick one or the other—I could blend them.

Final Thought

Authentication is rarely the most exciting part of a project, but it is the part that can ruin the experience if it goes wrong. By leveraging NextAuth and Supabase, ONNS achieved smooth user authentication and a maintainable setup for me.

How do you usually handle authentication in your Next.js projects?

Why I Chose Clean Architecture for a Social Weather App

David J Song — Tue, 02 Sep 2025 12:32:02 +0000

When I started building ONNS (옷늘날씨), a weather-driven outfit community app, I had one recurring thought: “How do I stop my codebase from becoming a tangled ball of JavaScript spaghetti when I just want to tell people what to wear?”

That is when I decided to lean into Clean Architecture. Not because it is trendy, but because I wanted to keep things maintainable when features inevitably pile up such as comments, filters, login, and realtime updates.

Why Clean Architecture?

In short, it is all about boundaries. Just like you would not wear flip-flops in a snowstorm, you do not want your React components directly poking at your database.

Clean Architecture encourages you to separate your project into layers:

Domain: The pure business rules. For ONNS, that means things like OutfitPost, WeatherTag, and Comment.

Application: Use cases that orchestrate how features behave. For example, “create a new post tagged with today’s weather.”

Infrastructure: The part that talks to Supabase, Prisma, or any third-party service. The dirty work, kept isolated.

UI (App): Next.js pages, components, and hooks.

This way, if tomorrow I swap Supabase for Firebase or even raw SQL queries, the core logic does not care.

Example From the Repo

Here is a simplified example. Let us say I want to create a new post tagged with today’s weather.

Domain entity:

// backend/domain/entities/outfitPost.entity.ts
export interface OutfitPost {
  id: string;
  userId: string;
  imageUrl: string;
  feelsLike: number;
  season: 'SPRING' | 'SUMMER' | 'FALL' | 'WINTER';
  createdAt: Date;
}

Application use case:

// backend/application/usecases/createPost.ts
import { OutfitPostRepository } from "../repositories/OutfitPostRepository";
import { OutfitPost } from "../../domain/entities/outfitPost.entity";

export class CreatePost {
  constructor(private repo: OutfitPostRepository) {}

  async execute(input: Omit<OutfitPost, 'id' | 'createdAt'>): Promise<OutfitPost> {
    const post: OutfitPost = {
      ...input,
      id: crypto.randomUUID(),
      createdAt: new Date(),
    };
    return await this.repo.save(post);
  }
}

Infrastructure (Supabase adapter):

// backend/infrastructure/repositories/SupabaseOutfitPostRepository.ts
import { OutfitPost } from "../../domain/entities/outfitPost.entity";
import { OutfitPostRepository } from "../../application/repositories/OutfitPostRepository";
import { supabase } from "../../lib/supabase";

export class SupabaseOutfitPostRepository implements OutfitPostRepository {
  async save(post: OutfitPost): Promise<OutfitPost> {
    const { data, error } = await supabase.from('posts').insert(post).select().single();
    if (error) throw error;
    return data as OutfitPost;
  }
}

UI layer:

// app/components/NewPostForm.tsx
import { CreatePost } from "@/backend/application/usecases/createPost";
import { SupabaseOutfitPostRepository } from "@/backend/infrastructure/repositories/SupabaseOutfitPostRepository";

export default function NewPostForm() {
  async function handleSubmit(formData: FormData) {
    const repo = new SupabaseOutfitPostRepository();
    const usecase = new CreatePost(repo);
    await usecase.execute({
      userId: "123",
      imageUrl: formData.get("image") as string,
      feelsLike: 12,
      season: "WINTER",
    });
  }

  return (
    <form action={handleSubmit}>
      {/* input fields for image, tags, etc. */}
      <button type="submit">Post</button>
    </form>
  );
}

Notice how the NewPostForm does not know or care whether the data is going to Supabase, PostgreSQL, or even a JSON file on my desktop. That is the power of boundaries.

What This Bought Me

Maintainability: New features such as filtering outfits by season meant adding new use cases, not rewriting everything.

Flexibility: It could replace Supabase with another backend in theory without touching the UI or domain.

Clarity: When I opened the repo after two weeks, I did not feel like a stranger in my own house.

A Little Wit to End

Just like you would not layer a winter coat under your t-shirt, you should not jam your database calls inside your React components. Clean Architecture keeps your code dressed appropriately for any season.

And in ONNS, that is literally the point.

Have thoughts on Clean Architecture, or want to roast my choice of Supabase? Drop a comment!

ORMs and Prisma for Web Devs

David J Song — Tue, 22 Jul 2025 08:46:03 +0000

ORMs and Prisma

Object-Relational Mapping (ORM) is a programming technique that creates a bridge between object-oriented code and relational databases by mapping classes to tables, allowing developers to work with database records as native objects rather than writing raw SQL queries directly.
For web developers, Prisma is one of the choices out there for ORM. Prisma is an open-source, next-generation ORM for Node.js and TypeScript that uses a declarative schema file to generate a fully type-safe client, manage schema migrations, and provide a visual data browser via Prisma Studio.

What Is ORM

Object-Relational Mapping (ORM) automates the transfer of data between an application's in-memory objects and a relational database by using metadata to describe how classes map to tables and properties map to columns. With ORM, developers manipulate data through familiar object methods, rather than embedding SQL strings in code, effectively creating a "virtual object database" within the programming language.

Introducing Prisma

Prisma is a modern ORM designed specifically for TypeScript and JavaScript backends. It centers around a single schema.prisma file that serves as the source of truth for both your database schema and application models.

Prisma's Core Components

Prisma Client: An auto-generated, fully type-safe query builder that provides intuitive CRUD methods and rich filtering APIs
Prisma Migrate: A declarative migration tool that infers schema changes, generates SQL migration scripts, and applies them safely in development and production.
Prisma Studio: A GUI for visually browsing and editing your database records locally, streamlining data inspection without writing SQL.

Type Safety of Prisma

Prisma generates TypeScript types based on your schema, ensuring that all database operations are checked at compile time and reducing runtime errors. Its strong emphasis on type safety and end-to-end type inference helps catch mistakes early, enhancing both code quality and developer productivity.

Why Next.js?

David J Song — Tue, 24 Jun 2025 08:36:49 +0000

How Next.js Got Big

Next.js has rapidly become the go-to framework for building high-performance, SEO-friendly, React-based applications since its launch in 2016. Let me explain why and how it got so big in the web development scene now.

Flexible Rendering Strategies: SSR, SSG, ISR

Next.js stands out by offering multiple rendering modes in one framework:

Server-Side-Rendering (SSR): Fresh HTML is generated on each request, ideal for dynamic content or personalized pages.
Static Site Generation (SSG): Pages are pre-built at build time, perfect for blogs or documentation sites, and served fast via CDNs.
Incremental Static Regeneration (ISR): Combines the best of SSR and SSG. Static pages refresh in the background without complete rebuilds. These capabilities give developers control over performance, scalability, and content freshness per page.

SEO & Performance Gains

SEO-ready: SSR/SSG ensures search engines crawl full-rendered HTML, improving indexability.
Core Web Vitals: Features like image optimization, code-splitting, and Turbopack boost metrics like LCP, FCP, TTI.
In real-world cases, many teams meet Google's Core Web Vitals thresholds on first deployment (89%) with Next.js VS 52% with other frameworks.

Built-In Image Optimization

With the image component, Next.js delivers:

On-demand, responsive image
Lazy Loading
Modern formats like WebP
CLS prevention

Developer Experience & Productivity

Zero-config setup: File-based routing, type support, hot module reloading work out of the box.
Full-stack in a single repo: API routes, SSR/SSG, and middleware all coexist. No need for separate backend codebases.
Turbopack: Next-gen build tool (Rust-based) that dramatically accelerates builds, faster than Webpack and Vite.

Go For It

Next.js isn't just another React boilerplate. It is a full-featured, versatile application framework. Whether you are building a blog, e-commerce platform, marketing microsite, or full-stack application, Next.js delivers a powerful foundation, so you can focus on delivering value instead of wiring up infrastructure.

The Battle Between Interface and Type in TypeScript

David J Song — Mon, 23 Jun 2025 08:16:30 +0000

Where the Fight Begins

TypeScript's interface and type aliases overlap for defining object shapes. Their key distinction is that interfaces support declaration merging while type aliases offer richer expressiveness for unions, intersections, mapped, and conditional types.

In modern practice, many teams default to type for its flexibility, using interface only when they need merging or classic OOP-style contracts. Performance between the two is now virtually identical, so clarity and project conventions determine the choice.

Core Differences

Declaration Merging: Only interfaces can be reopened and extended across multiple declarations, while types cannot.
Expressiveness: Types can define primitives, unions, intersections, mapped types, and more, while interfaces are limited to object/function signatures.
Compiler Impact: There is no meaningful compile-time speed difference in current TypeScript versions.

Industry Practices

Default to types: Many codebases adopt type as the standard for general type definitions and advanced type manipulations.
Reserve interfaces: Use when you specifically need extends, implements, or declaration merging for library augmentation or OOP contracts.

Recommendations

Pick one by convention: Enforce your team's preferences via lint rules to ensure consistency.
Use type for flexibility: Leverage it for complex scenarios where unions, conditional types, or utility types are needed.
Use interface for merging: Opt for it when you need to augment or merge declarations, or when modeling class-like contracts.

Now You Know Which to Use

There is no absolute better choice. Choosing between interface and type should be guided by your project's style and needs. Choose type for its versatility, or interface when you require its unique merging capabilities or OOP semantics.

Understanding Multitasking, Processes, and Threads

David J Song — Fri, 20 Jun 2025 08:32:26 +0000

Multitasking is Not as Magical as You Might Think

Modern computers stream music, download files, and browse the internet simultaneously with a single CPU on the board. This seemingly magical ability is called multitasking, a cornerstone of modern operating systems. It may make computers seem as if they are magical beings, but it is not so different from how we humans multitask.

The Magic Behind the Scenes: Time-Sharing and Context Switching

With a single CPU, true simultaneous execution of multiple tasks is not possible. Instead, the operating system employs a clever technique called time-sharing, which lets the CPU switch between tasks rapidly. This happens so instantly that tasks are running concurrently.
When switching between tasks, the operating system saves the current progress and state of the active task and moves on to the next task by loading the saved progress and state of the next task. This is called context switching. This allows computers to pick up exactly where they left off on each task, ensuring a smooth transition and continuous progress.

The Foundation of Multitasking: Processes

To define what these 'tasks' are, we must discuss processes and threads. When a program runs, it is a process. When an application launches, the OS creates a process and allocates the necessary resources.
A key characteristic of a process is its isolation. Each process is granted its own independent memory space, a dedicated share of CPU time, and other system resources. This isolation is crucial for stability because it won't shut down the entire system in case of a process crash. The OS acts as a protector that keeps processes from accessing others' memory, creating a secure and reliable multitasking environment.

More and More: Threads

To further enhance efficiency, a process can be broken down into smaller units of execution called threads. If a process is a program in action, a thread is a distinct execution path within that program. A single process can contain multiple threads, all working in parallel to accomplish different parts of the main task.
Unlike processes, which are isolated from one another, threads within the same process share the resources allocated to that process. This shared environment allows for efficient communication and data exchange between threads. However, each thread maintains its unique stack, registers, and program counter to prevent collision.

Frontend Architectures

David J Song — Wed, 18 Jun 2025 07:04:10 +0000

Server-Side-Rendering

Instead of sending a bare HTML shell and letting JavaScript build the page in the browser, server-side rendering (SSR) uses JavaScript on the server to generate fully finished HTML (including actual content), then sends that complete HTML to the client. The browser can display it immediately without waiting for client-side rendering.
Server-side rendering provides better visibility to search engine bots, resulting in good SEO optimization, whereas Client-Side Rendering shows weakness.

MVC Architecture

M(odel) V(iew) C(ontroller)

MVC is a software architecture design that divides the UI logic into three layers. This provides a better maintenance and test-driven development environment.
- Model: Data and business logic
- View: UI
- Controller: Applying User Inputs to Model and View
- Data flow: Often bidirectional
- Environment: Works on both client and server, supported by frameworks like Rails and AngularJS.

Flux

Designed for unidirectional data flow in React apps.
- Action: User or system event
- Dispatcher: Central hub to send actions
- Store: Holds state and logic
- View: React components subscribe to stores
- Data flow: Strictly unidirectional
- Store: Supports multiple stores, logic resides in stores, not controllers
- Adaptations: Inspired libraries like Redux, offering a single store and centralized state management.
- Environment: Primarily for complex client-side apps (React, Vue, Angular) and not typically used on server-side