Mục lục nội dung

Đặt vấn đề: Thách thức về Trải nghiệm Người dùng trong Ứng dụng Di động

Trong kỷ nguyên di động hiện đại, người dùng kỳ vọng các ứng dụng phải phản hồi ngay lập tức, làm việc mượt mà ngay cả khi đi vào vùng sóng yếu (3G/4G chập chờn) hoặc mất kết nối Internet hoàn toàn (chế độ máy bay, tầng hầm, công trường). Cách tiếp cận truyền thống là phụ thuộc hoàn toàn vào REST API hoặc GraphQL – nơi mỗi thao tác người dùng đều phải chờ phản hồi từ Server (Online-First) – bộc lộ vô số điểm yếu: màn hình loading xoay liên tục, giao diện bị đơ (UI lag/freeze) và nguy cơ mất dữ liệu khi ứng dụng bị ngắt kết nối đột ngột.

Để giải quyết triệt để bài toán này, các hệ thống di động quy mô lớn chuyển sang kiến trúc Offline-First. Trong mô hình này, thiết bị di động coi Cơ sở dữ liệu nội cục (Local Database) là nguồn thực thể duy nhất ("Single Source of Truth") cho giao diện người dùng. Mọi thao tác Đọc/Ghi đều diễn ra tức thì tại Local DB với độ trễ 0ms, sau đó một Sync Engine (Động cơ đồng bộ) chạy ngầm sẽ chịu trách nhiệm đẩy dữ liệu thay đổi lên Cloud và kéo dữ liệu mới về khi có mạng.

Bài viết này sẽ phân tích chuyên sâu kỹ thuật thiết kế kiến trúc Offline-First cho React Native sử dụng WatermelonDB (Cơ sở dữ liệu reactive dựa trên SQLite dành cho React Native) kết hợp với RxJS và TypeScript để xây dựng một Sync Engine có khả năng chống đứt gãy kết nối, xử lý xung đột dữ liệu (Conflict Resolution) và tối ưu hóa bộ nhớ hiệu quả.

Tại sao là WatermelonDB mà không phải Async Storage, SQLite thuần hay Realm?

Khi xây dựng ứng dụng React Native cấp độ Enterprise, lựa chọn Local Storage đóng vai trò quyết định đến hiệu năng toàn bộ app. Hãy cùng phân tích bảng so sánh kỹ thuật dưới đây:

  • Async Storage: Dựa trên Key-Value lưu dạng String. Không hỗ trợ truy vấn phức tạp, không có indexing, và toàn bộ dữ liệu bị serialize/deserialize qua JavaScript Bridge làm nghẽn Main Thread khi dữ liệu đạt hàng nghìn bản ghi.
  • SQLite thuần (React Native SQLite Storage): Hỗ trợ SQL đầy đủ, nhưng thiếu cơ chế Observable (tự động re-render UI khi data đổi) và đòi hỏi phải tự viết câu lệnh SQL thủ công dài dòng, dễ gây lỗi memory leak nếu không quản lý cursor tốt.
  • Realm (MongoDB Realm): Rất nhanh và hỗ trợ sync sẵn, nhưng dung lượng binary app tăng nặng (bundle size lớn), cơ chế lock thread đôi khi gây crash không rõ nguyên nhân trên Android và mô hình dữ liệu bị phụ thuộc chặt vào hệ sinh thái của MongoDB.
  • WatermelonDB: Được xây dựng trên nền SQLite (hoặc LokiJS trên Web), tối ưu hóa riêng cho React Native. Nó sử dụng cơ chế Lazy Loading (chỉ load bản ghi vào bộ nhớ JS khi thực sự cần) và tích hợp sẵn RxJS Observables. Bạn có thể xử lý 10.000 đến 100.000 bản ghi mà dung lượng RAM tiêu thụ cực kỳ nhỏ.

Thiết lập Schema và Models mã hóa Type-Safe với WatermelonDB

Để bắt đầu triển khai, chúng ta cần định nghĩa Database Schema và các Data Model sử dụng TypeScript nhằm đảm bảo tính toàn vẹn dữ liệu từ tầng Local DB lên tới UI Components.

1. Định nghĩa Schema Database

Giả sử chúng ta xây dựng ứng dụng Quản lý Công việc (Task Management) với hai bảng chính: projects và tasks. Mỗi bản ghi bắt buộc có các trường phục vụ đồng bộ như created_at, updated_at.

import { appSchema, tableSchema } from '@nohost/watermelon-db';

export const databaseSchema = appSchema({
  version: 1,
  tables: [
    tableSchema({
      name: 'projects',
      columns: [
        { name: 'name', type: 'string' },
        { name: 'created_at', type: 'number' },
        { name: 'updated_at', type: 'number' },
      ],
    }),
    tableSchema({
      name: 'tasks',
      columns: [
        { name: 'title', type: 'string' },
        { name: 'is_completed', type: 'boolean' },
        { name: 'project_id', type: 'string', isIndexed: true },
        { name: 'created_at', type: 'number' },
        { name: 'updated_at', type: 'number' },
      ],
    }),
  ],
});

2. Định nghĩa TypeScript Model

WatermelonDB sử dụng ES6 Decorators để liên kết thuộc tính Class với cột trong SQLite. Chúng ta tạo các class Model đại diện cho từng bảng:

import { Model } from '@nohost/watermelon-db';
import { field, date, readonly, relation } from '@nohost/watermelon-db/decorators';
import { Associations } from '@nohost/watermelon-db/Model';

export class ProjectModel extends Model {
  static table = 'projects';

  static associations: Associations = {
    tasks: { type: 'has_many', foreignKey: 'project_id' },
  };

  @field('name') name!: string;
  @readonly @date('created_at') createdAt!: Date;
  @readonly @date('updated_at') updatedAt!: Date;
}

export class TaskModel extends Model {
  static table = 'tasks';

  static associations: Associations = {
    projects: { type: 'belongs_to', key: 'project_id' },
  };

  @field('title') title!: string;
  @field('is_completed') isCompleted!: boolean;
  @field('project_id') projectId!: string;
  @readonly @date('created_at') createdAt!: Date;
  @readonly @date('updated_at') updatedAt!: Date;

  @relation('projects', 'project_id') project!: any;
}

Xây dựng Động cơ Đồng bộ (Sync Engine) hỗ trợ Reconnection và Xử lý Xung đột

Trái tim của kiến trúc Offline-First chính là quy trình Push-Pull Synchronization. Cơ chế này hoạt động theo mô hình 2 bước định kỳ hoặc kích hoạt theo sự kiện (Event-driven):

  1. Pull Phase: Gửi mốc thời gian đồng bộ gần nhất (last_pulled_at) lên Backend. Backend trả về danh sách các bản ghi bị thay đổi/tạo mới (created/updated) và bị xóa (deleted) từ mốc thời gian đó đến hiện tại. Local DB cập nhật các thay đổi này vào SQLite.
  2. Push Phase: Gom toàn bộ các bản ghi được tạo mới, cập nhật hoặc đánh dấu xóa ở Local DB kể từ lần đồng bộ trước, đóng gói thành Payload và đẩy lên Backend API. Backend ghi nhận dữ liệu, giải quyết xung đột (nếu có) và trả về phản hồi thành công.

Triển khai hàm Sync chuẩn với WatermelonDB Sync Adapter

WatermelonDB cung cấp phương thức synchronize() rất mạnh mẽ. Dưới đây là mã nguồn minh họa cách viết hàm Sync tích hợp API Backend và TypeScript:

import { synchronize } from '@nohost/watermelon-db/sync';
import { database } from './database';
import { httpClient } from '../services/httpClient';

interface SyncPullResponse {
  changes: {
    [key: string]: {
      created: any[];
      updated: any[];
      deleted: string[];
    };
  };
  timestamp: number;
}

export async function performDatabaseSync(): Promise<void> {
  await synchronize({
    database,
    pullChanges: async ({ lastPulledAt, schemaVersion, migration }) => {
      const response = await httpClient.get<SyncPullResponse>('/sync/pull', {
        params: {
          last_pulled_at: lastPulledAt || 0,
          schema_version: schemaVersion,
        },
      });

      if (response.status !== 200) {
        throw new Error(`Pull failed with status code ${response.status}`);
      }

      const { changes, timestamp } = response.data;
      return { changes, timestamp };
    },
    pushChanges: async ({ changes, lastPulledAt }) => {
      const response = await httpClient.post('/sync/push', changes, {
        params: { last_pulled_at: lastPulledAt },
      });

      if (response.status !== 200) {
        throw new Error(`Push failed with status code ${response.status}`);
      }
    },
    sendCreatedAsUpdated: false,
    migrationsEnabledAtVersion: 1,
  });
}

Quản lý Trạng thái Mạng Tự động với RxJS và NetInfo

Một Sync Engine chuyên nghiệp không nên yêu cầu người dùng phải bấm nút "Sync" thủ công. Hệ thống cần lắng nghe trạng thái kết nối mạng của thiết bị. Khi mạng khôi phục từ trạng thái Offline sang Online, một luồng RxJS Stream sẽ kích hoạt quá trình sync với cơ chế debounceTime và retryBackoff nhằm tránh dội số lượng lớn request lên Backend (Thundering Herd Problem).

import NetInfo, { NetInfoState } from '@react-native-community/netinfo';
import { Observable, fromEventPattern } from 'rxjs';
import { filter, debounceTime, distinctUntilChanged, switchMap, retry } from 'rxjs/operators';
import { performDatabaseSync } from './syncEngine';

// Tạo Observable lắng nghe trạng thái NetInfo
const networkStatus$: Observable<NetInfoState> = fromEventPattern(
  (handler) => NetInfo.addEventListener(handler),
  (handler, unsubscribe) => unsubscribe()
);

export function initializeAutoSync() {
  networkStatus$
    .pipe(
      // Chỉ lấy trạng thái có mạng thực sự và Internet kết nối thành công
      filter((state) => Boolean(state.isConnected && state.isInternetReachable)),
      // Tránh phát sự kiện lặp lại khi trạng thái không đổi
      distinctUntilChanged((prev, curr) => prev.isConnected === curr.isConnected),
      // Đợi 2 giây sau khi mạng ổn định mới kích hoạt Sync
      debounceTime(2000),
      // Gọi hàm sync, nếu thất bại sẽ retry tối đa 3 lần với delay tăng dần
      switchMap(() =>
        fromEventPattern(async () => {
          console.log('Online status detected. Triggering auto-sync...');
          await performDatabaseSync();
        }).pipe(
          retry({
            count: 3,
            delay: 1000,
          })
        )
      )
    )
    .subscribe({
      next: () => console.log('Auto-sync completed successfully.'),
      error: (err) => console.error('Auto-sync failed after retries:', err),
    });
}

Chiến lược Xử lý Xung đột Dữ liệu (Conflict Resolution Strategies)

Trong kiến trúc Offline-First, xung đột dữ liệu là điều không thể tránh khỏi. Ví dụ: Người dùng A chỉnh sửa tên Task khi Offline lúc 10:00. Người dùng B chỉnh sửa cùng Task đó lúc 10:05 trên Web App. Đến 10:10, thiết bị của người dùng A có mạng trở lại và thực hiện Push. Dữ liệu nào sẽ được ưu tiên?

Dưới đây là 3 chiến lược phổ biến được áp dụng trong môi trường thực tế:

1. Last-Write-Wins (LWW) dựa trên Server Timestamp

Đây là chiến lược mặc định và đơn giản nhất. Server giữ vai trò quyết định tối cao. Khi nhận được bản ghi đẩy lên, Server so sánh timestamp updated_at của bản ghi từ Client và bản ghi hiện có trong DB Server. Bản ghi nào có updated_at lớn hơn sẽ đè lên bản ghi cũ.

2. Field-Level Merging (Hợp nhất theo từng trường)

Thay vì đè toàn bộ bản ghi, Backend sẽ phân tích sự thay đổi ở cấp độ từng trường (Column). Ví dụ: Người dùng A sửa trường title, người dùng B sửa trường is_completed. Server sẽ hợp nhất cả hai thay đổi mà không làm mất dữ liệu của bất kỳ ai.

3. Deterministic CRDTs (Conflict-free Replicated Data Types)

Đối với các ứng dụng đòi hỏi tính cộng tác thời gian thực cao (như Figma, Notion hoặc Google Docs), cấu trúc dữ liệu CRDT được áp dụng để tự động hợp nhất các trạng thái mà không cần Server làm trọng tài. Tuy nhiên, chi phí lập trình và dung lượng lưu trữ của CRDT khá lớn.

Kinh nghiệm Thực chiến & Best Practices khi Tối ưu hóa Offline-First

  • Cơ chế Batching Transactions: Khi thao tác với danh sách hàng nghìn items, luôn luôn bọc các câu lệnh ghi trong database.write(async () => { ... }). Việc gom nhiều truy vấn thành một Transaction duy nhất sẽ tăng tốc độ ghi của SQLite lên từ 10x đến 50x.
  • Xử lý File/Media Offline: Đừng bao giờ lưu mã hóa Base64 của ảnh hoặc file dung lượng lớn trực tiếp vào SQLite. Hãy lưu file vật lý vào thư mục Document Directory của ứng dụng (dùng react-native-fs hoặc expo-file-system), sau đó chỉ lưu đường dẫn cục bộ (Local URI) vào cột string trong WatermelonDB.
  • Quản lý Database Migration: Khi ứng dụng phát triển, Schema sẽ thay đổi (thêm cột, đổi tên bảng). WatermelonDB hỗ trợ Migration Schema rất chặt chẽ. Hãy luôn luôn viết script Migration tương ứng với từng phiên bản nâng cấp ứng dụng để tránh việc ứng dụng bị crash khi mở lại do mâu thuẫn cấu trúc DB.

Lời kết

Kiến trúc Offline-First không chỉ đơn thuần là một giải pháp phòng ngừa khi mất mạng, mà đó là tư duy thiết kế phần mềm hiện đại hướng tới trải nghiệm người dùng tối thượng (Zero-latency UI). Việc kết hợp tính sức mạnh lưu trữ SQLite của WatermelonDB, sự chặt chẽ về mặt dữ liệu của TypeScript và mô hình lập trình phản ứng với RxJS giúp bạn tự tin xây dựng những ứng dụng React Native cấp độ Enterprise, sẵn sàng scale lên hàng triệu người dùng mà vẫn đảm bảo tính ổn định tuyệt đối.

Để làm chủ hoàn toàn kỹ thuật này cùng các kiến trúc lập trình nâng cao khác trên di động, bạn có thể Tham khảo khóa học "Lập trình App Mobile với React Native + TypeScript" tại đây.