Series Cloud Database Supabase #2: Làm chủ luồng dữ liệu Real-time và "Sức mạnh ẩn" của Edge Functions

1. Real-time: Biến Database thành "Trái tim sống"

Hệ thống Real-time của Supabase dựa trên tính năng PostgreSQL Replication. Khi bạn thực hiện bất kỳ lệnh INSERT, UPDATE hay DELETE nào trên bảng gate_status (trạng thái cổng), Database sẽ tự động phát đi một thông điệp thông qua WebSockets.

Kích hoạt Real-time cho bảng: Bạn không cần code gì cả, chỉ cần vào Dashboard Supabase -> Database -> Replication -> Bật bảng cần theo dõi lên.

Lắng nghe từ Frontend hoặc Backend khác: Thay vì phải "Poll" (hỏi liên tục) xem giá vé đã đổi chưa, phía Client/Service sẽ "Sub" (đăng ký) nhận sự kiện:

// Ví dụ phía Frontend/Service nhận thay đổi trạng thái cổng
const channel = supabase
  .channel('gate-updates')
  .on(
    'postgres_changes',
    { event: 'UPDATE', schema: 'public', table: 'gate_status' },
    (payload) => {
      console.log('Cổng vừa đổi trạng thái:', payload.new);
      // Thực hiện logic cập nhật UI hoặc Trigger cảnh báo ngay lập tức
    }
  )
  .subscribe();

Với cấu hình này, khi trung tâm điều hành update trạng thái cổng trong DB, màn hình của mọi nhân viên trực ca sẽ cập nhật ngay trong tích tắc mà không cần F5.

2. Edge Functions: Xử lý logic mà không cần Server

Một vấn đề xảy ra: Nếu bạn cần gọi một API bên thứ 3 (ví dụ: gửi thông báo qua Telegram hoặc gọi API Hitachi) mỗi khi một giao dịch được ghi vào Database, bạn không nên để logic đó chạy trực tiếp trong Database (vì PostgreSQL không phải là nơi để chạy logic phức tạp).

Edge Functions của Supabase chính là câu trả lời. Nó là các hàm TypeScript/JavaScript chạy trên nền tảng V8 (tương tự Cloudflare Workers), cực kỳ nhanh và không bị giới hạn bởi độ trễ địa lý.

Ví dụ viết một Edge Function để gửi cảnh báo:

import { serve } from "https://deno.land/std@0.168.0/http/server.ts"

serve(async (req) => {
  const { record } = await req.json() // Nhận dữ liệu từ Database (Webhook)

  // Gọi API Telegram/Hitachi
  const res = await fetch("https://api.hitachi.partner/notify", {
    method: "POST",
    body: JSON.stringify({ transaction_id: record.id }),
  })

  return new Response("OK", { status: 200 })
})

3. Kết hợp Database Webhook & Edge Functions (Cú đấm thép)

Đây là quy trình làm việc chuẩn cho hệ thống AFC Metro:

1. Dữ liệu đến: Laravel ghi giao dịch vào bảng transactions trên Supabase.
2. Kích hoạt: Database Webhook của Supabase phát hiện có bản ghi mới -> Tự động gọi Edge Function.
3. Xử lý: Edge Function gọi API của đối tác.
4. Kết quả: Nếu thành công, Edge Function cập nhật lại cột sync_status trong bảng transactions.

Ưu điểm: Laravel không phải chờ đợi API đối tác phản hồi (giảm tải cho Laravel). Nếu API đối tác bị treo, hàm Edge Function sẽ chạy độc lập, không làm ảnh hưởng đến tiến trình chạy của Laravel.

4. Tối ưu hóa "Sâu": Partitioning cho bảng dữ liệu tỷ dòng

Khi bảng transactions của bạn đạt con số 100 triệu dòng, việc truy vấn theo thời gian sẽ rất chậm, dù bạn có Index tốt thế nào.

Supabase hỗ trợ Table Partitioning (Chia nhỏ bảng) cực tốt. Bạn có thể chia bảng transactions theo tháng (transactions_2026_07, transactions_2026_08).

-- Chỉ cần cấu hình trên PostgreSQL chuẩn
CREATE TABLE transactions (
    id uuid NOT NULL,
    created_at timestamptz NOT NULL,
    ...
) PARTITION BY RANGE (created_at);

CREATE TABLE transactions_2026_07 PARTITION OF transactions
    FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');

Lợi ích: Khi bạn query tìm giao dịch tháng 7, Database chỉ phải quét đúng bảng transactions_2026_07. Tốc độ query sẽ cực nhanh vì tập dữ liệu nhỏ đi hàng chục lần.

Tổng kết Bài 2

Chúng ta đã biến Supabase từ một "Kho lưu trữ" thành một "Hệ thống điều hành Real-time" với sức mạnh của WebSockets và Serverless Edge Functions. Việc kết nối dữ liệu giữa các dịch vụ giờ đây diễn ra tự động, không còn phụ thuộc vào độ trễ của code PHP nữa.

Để khép lại series về Supabase này ở Bài 3, bạn muốn chúng ta đi sâu vào kỹ thuật "Database Migration & CI/CD tự động" (để mỗi khi code xong, DB tự động update cấu trúc trên Cloud), hay muốn tìm hiểu cách "Xây dựng hệ thống phân quyền phức tạp (Complex RLS)" (ví dụ: cho phép Trưởng trạm xem dữ liệu của toàn bộ các Cổng trong ga của họ, nhưng nhân viên kỹ thuật chỉ được xem lỗi của cổng họ phụ trách)?