DEV Community: Ferry Ananda Febian

I Stopped Using useEffect for Data Fetching in React

Ferry Ananda Febian — Tue, 23 Dec 2025 04:11:08 +0000

For a long time, useEffect was my default tool for handling data fetching in React. It worked but it never felt right.

After adopting SWR, especially its mutate API, I realized something important:

Data fetching is not a side effect.

Once I embraced that idea, useEffect slowly disappeared from my data-fetching logic.

The Problem with `useEffect` for Fetching Data

Using useEffect to fetch data usually looks like this:

Track dependencies carefully
Handle loading state manually
Handle error state manually
Prevent infinite loops
Sync UI updates with async behavior

As the application grows, this approach becomes:

Hard to reason about
Easy to break
Difficult to reuse

Most of the complexity comes from treating data fetching as an imperative side effect, rather than part of application state.

SWR Changed My Mental Model

With SWR, data fetching becomes declarative.

Instead of asking:

“When should I fetch this data?”

You describe:

“This component needs this data.”

SWR handles:

Caching
Revalidation
Deduplication
Loading and error states

And most importantly, it exposes mutate.

Why `mutate` Replaced `useEffect` for Me

mutate allows you to:

Update cached data directly
Perform optimistic updates
Revalidate data with a single function call

This means:

No manual refetch logic
No dependency arrays
No duplicated fetching code

Fetching and updating data becomes intent-based, not lifecycle-based.

`useEffect` vs `mutate` (SWR)

`useEffect`

Imperative data fetching
Manual dependency management
Boilerplate for loading and error state
Prone to race conditions
Fetch logic often scattered across components

`mutate` (SWR)

Declarative data updates
Built-in cache and revalidation
One-line refetch or optimistic update
Centralized and reusable logic
UI stays in sync with cache automatically

When I Still Use `useEffect`

I still use useEffect but only for true side effects, such as:

Event listeners
Subscriptions
Timers
Direct DOM interactions

Not for data fetching.

Final Thoughts

Once you treat data as state, not a side effect, your React code becomes:

Cleaner
More predictable
Easier to maintain

If you’re still relying heavily on useEffect for data fetching, I highly recommend trying SWR and its mutate API.

You might never look back 🚀

https://swr.vercel.app/

🚀 My Experience Switching from VS Code to Zed

Ferry Ananda Febian — Sun, 19 Oct 2025 07:57:18 +0000

Over the past few weeks, I’ve been experimenting with a new IDE Zed after years of using Visual Studio Code. And honestly, I was surprised by how different (in a good way) the experience felt.

I’ve relied on VS Code for so long that I thought it would be hard for any other IDE to compete. But after spending some time with Zed, I can see why so many developers are starting to talk about it.

✨ Minimal and Distraction-Free

Zed feels incredibly minimalistic. The interface is clean, distraction-free, and helps me stay focused on writing code not managing a sea of tabs or extensions.

⚡ Lightning-Fast Performance

The next thing I noticed was speed. Everything just feels snappy file navigation, search, autocomplete all happen almost instantly. Even with heavier projects, Zed maintains smooth performance where VS Code sometimes slows down with too many extensions.

🧠 Built-in MCP Integration

What impressed me the most is that Zed comes with built-in MCP (Model Context Protocol) support. This allows seamless AI integration directly inside the IDE with real context from your code without needing extra setup or third-party extensions like in VS Code.

🎯 Final Thoughts

VS Code is still an amazing editor with its massive ecosystem and community. But if you’re looking for something that’s lighter, faster, and helps you stay in the flow, Zed is absolutely worth a try.

Sometimes, the right tools don’t just make you more productive they make coding enjoyable again. 💡

Have you tried Zed yet? Would love to hear what you think!

📷Building a Face Recognition Attendance System with Next.js, TypeScript, face-api.js, and Supabase

Ferry Ananda Febian — Wed, 15 Oct 2025 04:36:16 +0000

Hi, Devs! 👋

In this article, I want to share my experience building a modern attendance system that leverages face recognition technology on the web. This project was developed using Next.js (a React framework), TypeScript, face-api.js for face detection, and Supabase for backend and data storage.

I designed this system to be easily integrated into various digital attendance needs whether for offices, schools, or communities with a modern user experience and seamless verification process.

🔍 Background

Manual attendance especially with signatures or conventional fingerprint scanners can be slow and even lead to proxy attendance issues. I saw an opportunity for face recognition to solve these problems, providing a faster, more accurate, and contactless attendance experience.

⚙️ Tech Stack & Workflow

This project is powered by several key technologies:

Next.js: For building fast, scalable, SEO-friendly web apps.
TypeScript: For structured development and fewer bugs.
face-api.js: A lightweight JavaScript library for in-browser face detection and recognition.
Supabase: Backend as a Service supporting auth, database, and storage no need to build your own backend from scratch.

How It Works (Overview):

User face registration
Users simply face their device camera. The system captures their face and stores the face descriptor in Supabase.
Attendance with face recognition
For check-in, users only need to open the attendance page. The system automatically detects the face, matches it against saved data, and logs attendance if there’s a match.
Data storage & querying
Attendance records and user info are stored neatly in Supabase (PostgreSQL + Storage), making it easy to access for both internal dashboards and further analytics.

✨ Key Features

Live Face Recognition: Check-in with your face, no need for manual logins.
Real-time Feedback: The system instantly notifies whether the face is recognized.
Lightweight Dashboard: Admins can view attendance history and user data through a simple web dashboard.
Data Security: Raw face photos are never stored only encrypted face descriptors.
Cross-Device: Works from desktop or mobile browsers.

🚀 Why face-api.js & Supabase?

face-api.js
This library is battle-tested, delivers solid performance for attendance use cases, and runs entirely client-side (in the browser), so there’s no need for a dedicated inference server and user privacy is enhanced.
Supabase
Offers a complete stack for authentication, data, and storage, all ready-to-use. Integration is smooth, documentation is developer-friendly, and features like row-level security keep user data private.

🛠️ Quick Glimpse at the Implementation

The app is modular by design. Here’s an overview of the main architecture and flow:

Frontend:
Built with Next.js and face-api.js, users can scan their face directly in the browser.
Auth & Data:
User authentication and attendance data management are handled via Supabase Auth and tables.
Face Recognition Integration:
face-api.js performs live face detection and compares the captured descriptor with those in Supabase. If there’s a match, attendance is automatically recorded.
Dashboard:
Admins can view and download attendance records or manage users through a simple UI.

💡 Challenges & Solutions

Face Detection Accuracy:
The main challenge is optimizing lighting and face positioning for accurate detection. The app provides real-time guidance and tips during the scan.
Data Privacy:
Only face descriptors are stored (never raw photos), ensuring stronger privacy for users.
Cross-Platform Compatibility:
In-browser face recognition can be tricky across devices. By using face-api.js, I was able to optimize performance and provide fallback options for unsupported devices.

🎯 Who Is This Project For?

Developers interested in face recognition integration in modern web apps.
Startups/Companies needing fast, efficient, contactless attendance solutions.
Communities/Organizations wanting a plug-and-play attendance system just a browser and webcam needed.

🧑‍💻 Example Code Snippets

1. Initializing face-api.js in a Next.js Component

import { useEffect } from 'react';
import * as faceapi from 'face-api.js';

export default function FaceScanner() {
  useEffect(() => {
    const loadModels = async () => {
      await faceapi.nets.tinyFaceDetector.loadFromUri('/models');
      await faceapi.nets.faceRecognitionNet.loadFromUri('/models');
      await faceapi.nets.faceLandmark68Net.loadFromUri('/models');
    };
    loadModels();
  }, []);

  return (
    <div>
      {/* ... Camera & UI elements here */}
    </div>
  );
}

2. Capturing and Generating a Face Descriptor

async function handleCapture() {
  const video = document.getElementById('videoElement') as HTMLVideoElement;
  const detection = await faceapi
    .detectSingleFace(video, new faceapi.TinyFaceDetectorOptions())
    .withFaceLandmarks()
    .withFaceDescriptor();

  if (detection) {
    // The descriptor is saved to Supabase
    const { descriptor } = detection;
    await saveFaceDescriptor(descriptor);
  } else {
    alert('Face not detected, please try again.');
  }
}

3. Saving a Face Descriptor to Supabase

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_KEY!
);

async function saveFaceDescriptor(descriptor: Float32Array) {
  const { data, error } = await supabase
    .from('users')
    .update({ face_descriptor: Array.from(descriptor) })
    .eq('id', userId);

  if (error) throw error;
  return data;
}

4. Attendance Check: Face Matching Logic

function isMatch(inputDescriptor: Float32Array, storedDescriptor: number[]): boolean {
  // face-api.js has a helper for euclideanDistance
  const distance = faceapi.euclideanDistance(inputDescriptor, new Float32Array(storedDescriptor));
  // Threshold can be adjusted (e.g., 0.5)
  return distance < 0.5;
}

5. Querying Attendance Data from Supabase

async function fetchAttendanceHistory(userId: string) {
  const { data, error } = await supabase
    .from('attendance')
    .select('*')
    .eq('user_id', userId)
    .order('created_at', { ascending: false });

  if (error) throw error;
  return data;
}

🔗 Demo & Preview Video

Want to see it in action?
Check out my short preview video showcasing the app’s features and workflow:

Short Preview Video Showcasing

Preview Reports

Thanks for reading!
If you have questions or feedback, feel free to drop a comment below.
Happy coding & stay creative! 🚀

Source Code: https://github.com/ferryops/facial-recognition-attendance-system

[Boost]

Ferry Ananda Febian — Mon, 08 Sep 2025 02:35:59 +0000

🚀 From 2–5 Minutes to < 1 Second: How a Small Nginx Config Change Boosted My Website

Ferry Ananda Febian ・ Sep 8 '25

#nginx #webdev #backend #programming

🚀 From 2–5 Minutes to < 1 Second: How a Small Nginx Config Change Boosted My Website

Ferry Ananda Febian — Mon, 08 Sep 2025 00:03:57 +0000

A few days ago, I was puzzled about why the website I built felt extremely slow when loading a JavaScript file.

Imagine this: a file of just 2 MB took 2–5 minutes to load in the browser. 😅

After digging into it, the issue turned out to be simple: I forgot to enable gzip in my Nginx configuration.

What is gzip?

gzip is a compression method that allows the server to send smaller-sized files to the browser.

Instead of downloading the full raw file, the browser only needs to fetch the compressed version.

The Fix

I added the following config to my Nginx Proxy Manager:

gzip on;
gzip_comp_level 6;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
gzip_types
    text/plain
    text/css
    application/json
    application/javascript
    application/x-javascript
    text/javascript
    application/xml
    application/rss+xml
    application/atom+xml
    application/vnd.ms-fontobject
    application/x-font-ttf
    font/opentype
    image/svg+xml
    image/x-icon;

The Result

The website performance improved instantly:
From 2–5 minutes → to less than 1 second for a 2 MB file.

Key Takeaways

Small optimizations can lead to massive improvements.
Never underestimate basic server configuration.
A single setting can completely transform user experience.

Sometimes it’s not expensive hardware or the latest framework that makes a website faster, but rather a simple config tweak like this.

So, if your website feels slow, it might be worth checking whether gzip is enabled on your server.

Have you ever found a performance bottleneck where the solution turned out to be this simple?

[Boost]

Ferry Ananda Febian — Tue, 19 Aug 2025 05:57:55 +0000

Monolith vs Microservices: Kenapa Sebaiknya Mulai dari Monolith?

Ferry Ananda Febian ・ Aug 19 '25

#programming #webdev #architecture #indonesia

Monolith vs Microservices: Kenapa Sebaiknya Mulai dari Monolith?

Ferry Ananda Febian — Tue, 19 Aug 2025 01:14:55 +0000

Dalam dunia pengembangan software, dua arsitektur yang paling sering dibandingkan adalah monolith dan microservices. Keduanya memiliki kelebihan dan kekurangan masing-masing, tetapi menurut saya ada satu prinsip penting yang sering dilupakan: setiap project cukup dimulai dengan monolith.

Apa Itu Monolith dan Microservices?

Monolith adalah arsitektur di mana seluruh aplikasi dibangun sebagai satu kesatuan utuh. Semua fitur, logika bisnis, dan database biasanya terhubung dalam satu codebase.
Microservices adalah pendekatan di mana aplikasi dipecah menjadi layanan-layanan kecil yang independen, masing-masing bisa dikembangkan, dideploy, dan diskalakan secara terpisah.

Daya Tarik Microservices

Microservices memang terdengar modern dan keren. Banyak perusahaan besar seperti Netflix, Amazon, atau Gojek menggunakannya. Skalabilitas yang fleksibel, tim yang bisa bekerja paralel, serta kebebasan memilih teknologi per layanan sering dijadikan alasan untuk mengadopsinya sejak awal.

Namun, ada sisi lain yang jarang dibicarakan: yaitu kompleksitas. Microservices butuh orkestrasi yang rumit, monitoring, logging, komunikasi antar-service, hingga pengelolaan database terdistribusi. Hal-hal ini bisa menjadi beban besar untuk project yang masih kecil atau baru dimulai.

Kenapa Sebaiknya Mulai dari Monolith?

Lebih Cepat dalam Validasi Ide
Di tahap awal, fokus utama bukanlah skala, melainkan apakah produk kita dipakai orang atau tidak. Monolith memungkinkan pengembangan lebih cepat karena tidak perlu memikirkan pembagian service, deployment, dan integrasi.
Lebih Mudah Dikelola Tim Kecil
Startup atau project baru biasanya dimulai dengan tim kecil. Monolith lebih mudah dipahami karena semua kode ada dalam satu tempat. Tidak ada overhead komunikasi antar-service yang bisa memperlambat proses belajar tim.
Lebih Murah secara Infrastruktur
Microservices sering kali butuh banyak server, container, dan sistem pendukung. Sementara monolith bisa jalan di satu mesin atau instance kecil. Dengan begitu, biaya awal jauh lebih rendah.
Refactor ke Microservices Bisa Datang Belakangan
Jika nantinya produk tumbuh dan memang benar-benar butuh skalabilitas lebih, monolith tetap bisa di-split menjadi microservices secara bertahap. Banyak perusahaan besar pun awalnya lahir sebagai monolith sebelum berevolusi.

Microservices Bukan Musuh

Bukan berarti microservices buruk. Untuk aplikasi dengan traffic sangat besar, tim besar, atau kebutuhan integrasi yang kompleks, microservices bisa jadi solusi terbaik. Tetapi memulai dari awal justru bisa memperlambat perjalanan menuju product-market fit.

Kesimpulan

Membangun software itu mirip dengan membangun rumah. Kita tidak langsung memikirkan bagaimana jika rumah ini jadi hotel 100 lantai, yang penting adalah apakah rumahnya nyaman ditinggali dulu.

Karena itu, menurut saya:
👉 Setiap project sebaiknya dimulai dengan monolith.
Sederhana, cepat, dan hemat. Kalau nanti skalanya memang menuntut, selalu ada jalan untuk berevolusi ke microservices.

Tambah Fitur di Aplikasi Malah Bikin Bagian Lain Error?

Ferry Ananda Febian — Tue, 12 Aug 2025 02:30:04 +0000

Pernah nggak ngalamin, mau nambah satu fitur di aplikasi, eh tiba-tiba bagian lain ikut error? 😅 Rasanya kayak narik satu kabel di meja, terus semua kabel lain ikut ketarik.

Semakin gede proyeknya, biasanya makin rawan efek domino begini. Ujung-ujungnya, kerjaan nambah fitur malah jadi kerjaan padamkan kebakaran.

Nah, salah satu “jurus” biar kode nggak gampang berantakan adalah pakai SOLID Principles. Berikut contoh nya untuk project React + Vite:

1. S — Single Responsibility

Satu file, satu tugas.

// services/userService.js
export const fetchUsers = async () => fetch("/api/users").then(r => r.json());

// pages/Dashboard.jsx
import { fetchUsers } from "../services/userService";
import UserList from "../components/UserList";

2. O — Open/Closed

Bisa nambah fitur tanpa bongkar yang lama.

export default function Button({ type="primary", children }) {
  const styles = { primary: "bg-blue-500", secondary: "bg-gray-200" };
  return <button className={styles[type]}>{children}</button>;
}

3. L — Liskov Substitution

Komponen turunan harus bisa gantiin induknya.

function BarChart(props) { return <BaseChart {...props} />;}

4. I — Interface Segregation

Props sesuai kebutuhan, jangan kebanyakan fungsi yang nggak dipakai.

5. D — Dependency Inversion

Bergantung ke service, bukan langsung ke API.

// services/productService.js
export const getProducts = async () => fetch("/api/products").then(r => r.json());

Kalau prinsip ini dipakai, kode jadi lebih rapi, gampang dikembangin, dan nggak gampang bikin pusing kepala. Proyek pun bisa tumbuh tanpa bikin programmernya stres. Dan yang paling penting… kita masih bisa ngopi santai sambil lihat build sukses tanpa drama. ☕🚀

SOLID versi politik 🤭

🏃Pakai Tanstack Query, Waktunya Meninggalkan useState dan useEffect

Ferry Ananda Febian — Wed, 07 May 2025 00:03:52 +0000

Dalam dunia React, salah satu pola yang paling sering kita jumpai ketika berinteraksi dengan API adalah kombinasi useState dan useEffect. Namun, dengan hadirnya TanStack Query (dulu dikenal sebagai React Query), pendekatan tersebut kini terasa kuno. TanStack Query menawarkan cara yang lebih deklaratif, efisien, dan mudah untuk melakukan fetching, caching, dan updating data async.

Kenapa Harus Meninggalkan `useState` dan `useEffect`?

Biasanya, untuk mengambil data dari API, kita menulis kode seperti ini:

const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

useEffect(() => {
  fetch('/api/data')
    .then((res) => res.json())
    .then(setData)
    .catch(setError)
    .finally(() => setLoading(false));
}, []);

Kode ini berfungsi, tapi repetitif dan rawan kesalahan, terutama jika kita ingin menambahkan fitur seperti refetch otomatis, caching, stale data control, dan synchronization antar komponen.

Dengan TanStack Query, kita bisa menyederhanakannya menjadi:

import { useQuery } from '@tanstack/react-query';

const fetchData = async () => {
  const res = await fetch('/api/data');
  if (!res.ok) throw new Error('Network response was not ok');
  return res.json();
};

function MyComponent() {
  const { data, error, isLoading } = useQuery({
    queryKey: ['myData'],
    queryFn: fetchData
  });

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return <pre>{JSON.stringify(data, null, 2)}</pre>;
}

Dari potongan kode di atas, kita bisa lihat bahwa kode menjadi lebih declarative dan maintainable. TanStack Query mengelola state secara otomatis, dan kita hanya perlu fokus pada fetching data.

Manfaat Utama TanStack Query

1. Caching Otomatis

TanStack Query menyimpan hasil fetch di cache. Kalau komponen di-unmount dan kemudian di-mount kembali, Tanstack bisa menampilkan data lama dulu sambil mem-fetch yang baru.

2. Refetch Otomatis

TanStack Query secara otomatis bisa melakukan refetch data saat user kembali ke tab browser atau saat koneksi internet pulih. Ini salah satu fitur yang saya sukai.

3. Pengelolaan Status Lebih Mudah

Status isLoading, error, dan data sudah tersedia langsung dari useQuery. Kita tidak perlu lagi membuat banyak useState.

4. Shared State Antar Komponen

Data yang di-fetch oleh satu komponen bisa langsung digunakan oleh komponen lain tanpa refetch, selama memakai queryKey yang sama.

5. Devtools

TanStack Query menyediakan devtools untuk debugging query, melihat cache, dan memantau status request secara visual.

QueryClient dan useQueryClient

Untuk penggunaan lanjutan, kita bisa menggunakan QueryClient untuk mengatur global config, dan useQueryClient untuk mengakses atau memodifikasi cache langsung:

import { QueryClient, QueryClientProvider, useQueryClient } from '@tanstack/react-query';

const queryClient = new QueryClient();

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <MyComponent />
    </QueryClientProvider>
  );
}

function RefetchButton() {
  const queryClient = useQueryClient();

  return <button onClick={() => queryClient.invalidateQueries(['myData'])}>Refresh Data</button>;
}

Kesimpulan

TanStack Query adalah jawaban modern untuk manajemen data async di React. Dengan hanya mengganti useState dan useEffect ke useQuery, kita bisa mendapatkan banyak fitur powerful yang biasanya membutuhkan banyak boilerplate. Jadi, kalau teman-teman masih pakai useEffect buat fetching data — mungkin ini saatnya move on.

Terima kasih sudah mampir ke blog saya, sampai ketemu di blog berikutnya!

Ternyata Selama Ini Saya Fetching Data Tidak Efisien di React

Ferry Ananda Febian — Sat, 22 Mar 2025 05:08:18 +0000

Lebih dari setahun sudah saya bekerja dengan React, membuat berbagai macam website dan aplikasi, namun akhir-akhir ini saya menyadari bahwa saya belum menggunakan cara yang efisien dalam melakukan fetching data. Saya sering menggunakan axios atau fetch secara manual, tanpa memperhatikan caching, revalidasi, atau optimasi lainnya.

Baru-baru ini, saya menemukan sebuah pustaka yang menarik untuk melakukan data fetching di React, yaitu SWR. Saya ingin berbagi pengetahuan ini kepada teman-teman, agar juga bisa memanfaatkan SWR untuk membuat aplikasi React yang lebih cepat dan responsif.

SWR (Stale-While-Revalidate) adalah pustaka React yang dikembangkan oleh Vercel untuk melakukan data fetching secara efisien. SWR menawarkan solusi yang cepat, otomatis, dan mudah digunakan dalam pengambilan data dari API.

1. Apa Itu SWR?

SWR menggunakan strategi Stale-While-Revalidate, yaitu:

Mengembalikan data dari cache terlebih dahulu (stale)
Kemudian melakukan fetch ulang untuk memperbarui data (revalidate)
Memperbarui state jika ada perubahan data

Strategi ini membuat aplikasi terasa lebih responsif karena pengguna tidak perlu menunggu data terbaru sebelum melihat konten.

2. Menggunakan `useSWR`

useSWR adalah hook utama yang digunakan untuk mengambil data. Contoh penggunaannya:

import useSWR from 'swr';

const fetcher = (url: string) => fetch(url).then((res) => res.json());

function MyComponent() {
  const { data, error, isLoading } = useSWR('/api/users', fetcher);

  if (isLoading) return <p>Loading...</p>;
  if (error) return <p>Error loading data</p>;

  return <div>{JSON.stringify(data)}</div>;
}

3. Menggunakan `mutate`

mutate atau bahasa Indonesia nya mutasi, digunakan untuk memperbarui cache secara manual dan melakukan re-fetching data setelah perubahan. Contoh implementasi:

import useSWR, { mutate } from 'swr';

const fetcher = (url: string) => fetch(url).then((res) => res.json());

function MyComponent() {
  const { data } = useSWR('/api/users', fetcher);

  const updateData = async () => {
    // Memperbarui cache sebelum fetch ulang
    mutate('/api/users', { name: 'John Doe' }, false);

    // Melakukan re-fetching data
    await mutate('/api/users');
  };

  return (
    <div>
      <p>Data: {JSON.stringify(data)}</p>
      <button onClick={updateData}>Update Data</button>
    </div>
  );
}

4. Kelebihan SWR

Otomatis caching dan revalidasi
Mendukung pagination dan infinite loading
Polling otomatis untuk data real-time
Optimistic UI updates dengan mutate

Cara saya fetching data sebelum menggunakan SWR:

import { useState, useEffect } from 'react';

function MyComponent() {
  const [data, setData] = useState(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true;

    const fetchData = async () => {
      try {
        setIsLoading(true);
        const response = await fetch('/api/users');
        if (!response.ok) {
          throw new Error('Network response was not ok');
        }
        const result = await response.json();
        if (isMounted) {
          setData(result);
          setIsLoading(false);
        }
      } catch (err) {
        if (isMounted) {
          setError(err);
          setIsLoading(false);
        }
      }
    };

    fetchData();

    return () => {
      isMounted = false;
    };
  }, []);

  if (isLoading) return <p>Loading...</p>;
  if (error) return <p>Error loading data: {error.message}</p>;

  return <div>{JSON.stringify(data)}</div>;
}

Setelah implementasi SWR:

import useSWR, { mutate } from 'swr';
import { useMemo } from 'react';
import { fetcher } from 'utils/axios';

export type ModuleType = {
  id?: number;
  label: string;
  name: string;
  allowed_actions: string[];
  status?: boolean;
};

type ModuleList = ModuleType[];

export const endpoints = {
  key: 'api/v1/modules'
};

export function useGetModules(search = '', page = 1, limit = 10) {
  const key = `${endpoints.key}?search=${search}&page=${page}&limit=${limit}`;

  const { data, error } = useSWR(key, fetcher, {
    revalidateIfStale: false,
    revalidateOnFocus: false,
    revalidateOnReconnect: false
  });

  return useMemo(
    () => ({
      lists: (data?.data?.modules as ModuleList) ?? [],
      totalPages: data?.data?.total_pages || 1,
      totalItems: data?.data?.total_items || 10,
      isLoading: !error && !data,
      isError: error
    }),
    [data, error]
  );
}

Kekurangan Cara Lama:

Tidak Ada Caching Otomatis → Setiap kali komponen dirender ulang, data akan selalu di-fetch ulang dari server.
Harus Mengelola State Secara Manual → Perlu membuat useState untuk menyimpan data, error, dan status loading.
Tidak Ada Revalidasi Otomatis → Jika data berubah di server, komponen tidak akan tahu dan tidak akan memperbarui datanya.
Tidak Ada Fetch Deduplication → Jika banyak komponen mem-fetch data yang sama, setiap komponen akan melakukan request terpisah.

Kesimpulan

SWR adalah solusi yang efisien untuk data fetching di React. Dengan caching otomatis dan fitur mutate, SWR membuat aplikasi lebih cepat dan responsif tanpa perlu konfigurasi kompleks. Jika ingin meningkatkan performa aplikasi dengan cara yang sederhana, SWR adalah pilihan yang tepat!

Sekian artikel keren saya kali ini, semoga bermanfaat dan terima kasih sudah membaca!

🚀TypeScript 10x Lebih Ngebut: Inovasi Gede Buat Developer JavaScript

Ferry Ananda Febian — Sun, 16 Mar 2025 03:43:17 +0000

Siapa sih yang gak kenal TypeScript, TypeScript sudah jadi salah satu tools utama buat developer JavaScript, ngasih pengalaman ngoding yang lebih enak lewat sistem tipe yang kuat.

Buat yang belum tau apa itu sistem tipe, yaitu static type system yang dipakai oleh TypeScript. Berbeda dengan JavaScript yang bersifat dynamically typed (tipe data bisa berubah-ubah saat runtime), TypeScript memperkenalkan static typing yang memungkinkan pengecekan tipe data sebelum kode dijalankan.

Dengan munculnya update ini, artinya error akan 10x lebih cepat terdeteksi, dan kode jadi lebih aman dan mudah dipelihara. Update ini dinamakan TypeScript 7.0 (native), yang bakal bikin performa TypeScript jadi 10x lebih cepat dari sebelumnya.

Kenapa Harus Implementasi Native?

Saat ini, TypeScript jalan di atas JavaScript, yang menyebabkan munculnya batasan performa, terutama buat proyek besar. Jadi implementasi native ini bakal ngebantu dengan:

Mempercepat waktu muat editor secara drastis.
Build lebih cepat, sampai 10x lipat!
Konsumsi memori lebih kecil, jadi lebih ringan dipakai.
Dukungan lebih mantap buat AI tools yang butuh akses cepat ke kode.

Seberapa Ngebut Emang?

Tim TypeScript udah ngetes implementasi native ini di beberapa proyek open-source gede di GitHub. Nih hasil perbandingan waktu eksekusi tsc (TypeScript Compiler) antara versi lama dan versi native:

Proyek	Ukuran (LOC)	Sekarang	Native	Lebih Cepat
VS Code	1.505.000	77,8s	7,5s	10,4x
Playwright	356.000	11,1s	1,1s	10,1x
TypeORM	270.000	17,5s	1,3s	13,5x
date-fns	104.000	6,5s	0,7s	9,5x
tRPC	18.000	5,5s	0,6s	9,1x
rxjs	2.100	1,1s	0,1s	11,0x

Hasilnya, peningkatan performanya gila-gilaan! Proses build dan cek tipe jadi jauh lebih cepat.

Editor Jadi Lebih Ringan dan Responsif

Sebagian besar waktu developer dihabisin di editor kode, jadi kalau makin cepat, makin enak. Dengan implementasi native ini, waktu muat proyek di editor kayak VS Code berkurang dari 9,6 detik jadi 1,2 detik—hampir 8x lebih cepat! Selain itu:

Konsumsi memori turun sampai 50%.
Autocomplete, go to definition, dan find all references jadi lebih responsif.
Integrasi lebih baik dengan Language Server Protocol (LSP), jadi bisa dipakai di lebih banyak editor.

Jadwal Rilis TypeScript Baru

Tim TypeScript udah nentuin roadmap buat transisi ini:

TypeScript 6.x masih bakal berbasis JavaScript dengan update rutin.
TypeScript 7.0 (native) bakal dirilis setelah fitur-fiturnya setara dengan versi lama.
Nama kode proyek ini "Corsa", yang jadi dasar TypeScript ke depan.
Bakal tetap kompatibel sama proyek lama, meskipun mungkin ada beberapa penyesuaian.

Apa Selanjutnya?

Tim TypeScript punya rencana buat:

Ngerilis versi preview buat type-checking di CLI pertengahan 2025.
Meluncurin versi penuh dengan fitur build dan layanan bahasa akhir 2025.
Ngadain sesi AMA (Ask Me Anything) sama komunitas TypeScript 13 Maret 2025.
Ngasih update rutin soal progres proyek di GitHub.

Kesimpulan

Implementasi native TypeScript ini bakal bawa perubahan gede buat dunia JavaScript. Dengan kecepatan 10x lipat, konsumsi memori lebih kecil, dan editor yang lebih ngebut, developer bisa kerja lebih efektif dan nyaman. Ini juga bakal ngebuka peluang baru buat AI tools, analisis kode lebih dalam, dan refactoring yang lebih smooth.

Buat kalian yang sering pakai TypeScript, siap-siap aja buat pengalaman ngoding yang jauh lebih cepat! 🚀

Dikutip dari:

🔁Cara Mudah Reverse Proxy di cPanel dengan Nginx

Ferry Ananda Febian — Sat, 15 Mar 2025 01:45:23 +0000

Kendala Reverse Proxy dengan Apache di cPanel

Ketika saya pertama kali mencoba melakukan reverse proxy untuk aplikasi Node.js khususnya Next.js di server cPanel, saya mengalami kendala karena default web server di cPanel adalah Apache. Apache memang powerful, tetapi konfigurasi reverse proxy di Apache bisa lebih kompleks dibandingkan Nginx.

Setelah mencari solusi, saya menemukan cara yang lebih mudah yaitu menggunakan Engintron. Engintron for cPanel/WHM adalah cara termudah untuk mengintegrasikan Nginx sebagai reverse proxy di server cPanel/WHM.

Cara Kerja Engintron

Dengan Engintron, kita bisa mengatur reverse proxy dengan lebih fleksibel dan meningkatkan performa server secara signifikan.

Cara Install Engintron di cPanel

Untuk menginstal Engintron di server cPanel/WHM, ikuti langkah-langkah berikut:

Masuk ke server melalui SSH sebagai root.
Jalankan perintah berikut untuk mengunduh dan menginstal Engintron:

cd /;
rm -f engintron.sh;
wget --no-check-certificate https://raw.githubusercontent.com/engintron/engintron/master/engintron.sh;
bash engintron.sh install

Setelah instalasi selesai, login ke WHM melalui browser dengan mengakses: https://yourserver.com:2087
Buka menu Plugins.
Cari dan buka Engintron for cPanel/WHM.
Engintron sudah aktif dan siap digunakan untuk mengatur reverse proxy.

Tampilan Engintron di WHM

Mengatur Custom Rules di Engintron

Setelah Engintron terpasang, kita dapat menyesuaikan konfigurasi Nginx agar bekerja sesuai dengan kebutuhan kita. Salah satunya adalah mengatur redirect domain dan konfigurasi reverse proxy untuk aplikasi Node.js.

Redirect domain.com ke www.domain.com

Jika ingin mengalihkan semua permintaan dari domain.com ke www.domain.com, tambahkan aturan berikut di konfigurasi Nginx:

# Redirect domain.com to www.domain.com
if ($host = "domain.com") {
    return 301 https://www.domain.com$request_uri;
}

Reverse Proxy ke Aplikasi Node.js

Misalkan aplikasi Node.js berjalan di port 3000, kita bisa mengatur Nginx untuk meneruskan permintaan ke aplikasi tersebut:

# Proxy rules for www.domain.com
if ($host = "www.domain.com") {
    set $PROXY_SCHEME "http";
    set $PROXY_TO_PORT 3000;
}

Dengan aturan di atas, semua request ke www.domain.com akan diteruskan ke aplikasi Node.js yang berjalan di port 3000.

Kesimpulan

Menggunakan Engintron di cPanel sangat membantu dalam mengelola reverse proxy dengan Nginx tanpa perlu konfigurasi manual yang rumit. Dengan sedikit penyesuaian pada custom rules, kita bisa dengan mudah mengarahkan domain, meningkatkan performa, dan mengoptimalkan server sesuai kebutuhan.

Jika ingin menjalankan aplikasi Node.js atau layanan lain dengan reverse proxy di cPanel, Engintron adalah solusi terbaik yang patut dicoba!

Selamat bereksperimen dan terima kasih sudah mampir di artikel keren saya. Semoga bermanfaat!

Referensi:
[1] https://engintron.com/

DEV Community: Ferry Ananda Febian

I Stopped Using useEffect for Data Fetching in React

The Problem with useEffect for Fetching Data

SWR Changed My Mental Model

Why mutate Replaced useEffect for Me

useEffect vs mutate (SWR)

useEffect

mutate (SWR)

When I Still Use useEffect

Final Thoughts

🚀 My Experience Switching from VS Code to Zed

✨ Minimal and Distraction-Free

⚡ Lightning-Fast Performance

🧠 Built-in MCP Integration

🎯 Final Thoughts

📷Building a Face Recognition Attendance System with Next.js, TypeScript, face-api.js, and Supabase

🔍 Background

⚙️ Tech Stack & Workflow

How It Works (Overview):

✨ Key Features

🚀 Why face-api.js & Supabase?

🛠️ Quick Glimpse at the Implementation

💡 Challenges & Solutions

🎯 Who Is This Project For?

🧑‍💻 Example Code Snippets

1. Initializing face-api.js in a Next.js Component

2. Capturing and Generating a Face Descriptor

3. Saving a Face Descriptor to Supabase

4. Attendance Check: Face Matching Logic

5. Querying Attendance Data from Supabase

🔗 Demo & Preview Video

[Boost]

🚀 From 2–5 Minutes to < 1 Second: How a Small Nginx Config Change Boosted My Website

Ferry Ananda Febian ・ Sep 8 '25

🚀 From 2–5 Minutes to < 1 Second: How a Small Nginx Config Change Boosted My Website

What is gzip?

The Fix

The Result

Key Takeaways

[Boost]

Monolith vs Microservices: Kenapa Sebaiknya Mulai dari Monolith?

Ferry Ananda Febian ・ Aug 19 '25

Monolith vs Microservices: Kenapa Sebaiknya Mulai dari Monolith?

Apa Itu Monolith dan Microservices?

Daya Tarik Microservices

Kenapa Sebaiknya Mulai dari Monolith?

Microservices Bukan Musuh

Kesimpulan

Tambah Fitur di Aplikasi Malah Bikin Bagian Lain Error?

1. S — Single Responsibility

2. O — Open/Closed

3. L — Liskov Substitution

4. I — Interface Segregation

5. D — Dependency Inversion

🏃Pakai Tanstack Query, Waktunya Meninggalkan useState dan useEffect

Kenapa Harus Meninggalkan useState dan useEffect?

Manfaat Utama TanStack Query

1. Caching Otomatis

2. Refetch Otomatis

3. Pengelolaan Status Lebih Mudah

4. Shared State Antar Komponen

5. Devtools

QueryClient dan useQueryClient

Kesimpulan

Ternyata Selama Ini Saya Fetching Data Tidak Efisien di React

1. Apa Itu SWR?

2. Menggunakan useSWR

3. Menggunakan mutate

4. Kelebihan SWR

Kesimpulan

🚀TypeScript 10x Lebih Ngebut: Inovasi Gede Buat Developer JavaScript

Kenapa Harus Implementasi Native?

Seberapa Ngebut Emang?

Editor Jadi Lebih Ringan dan Responsif

Jadwal Rilis TypeScript Baru

Apa Selanjutnya?

Kesimpulan

🔁Cara Mudah Reverse Proxy di cPanel dengan Nginx

Kendala Reverse Proxy dengan Apache di cPanel

Cara Install Engintron di cPanel

The Problem with `useEffect` for Fetching Data

Why `mutate` Replaced `useEffect` for Me

`useEffect` vs `mutate` (SWR)

`useEffect`

`mutate` (SWR)

When I Still Use `useEffect`

Kenapa Harus Meninggalkan `useState` dan `useEffect`?

2. Menggunakan `useSWR`

3. Menggunakan `mutate`