5 điểm bởi GN⁺ 2023-12-02 | 1 bình luận | Chia sẻ qua WhatsApp

Độ phức tạp của quản lý dữ liệu

  • Các kỹ sư frontend dần nhận ra sự cần thiết phải cache dữ liệu API.
  • Ban đầu mọi thứ bắt đầu từ việc lưu trữ dữ liệu đơn giản, nhưng khi số lượng yêu cầu tính năng tăng lên, họ sẽ phải triển khai cache dữ liệu, chỉ mục thủ công, optimistic mutations và vô hiệu hóa cache đệ quy.
  • Những tính năng này tương tự như cách hoạt động bên trong của cơ sở dữ liệu, và trong các ứng dụng frontend phức tạp, cuối cùng bạn sẽ tự tạo ra một cơ sở dữ liệu chuyên biệt theo miền.

Cơ bản về cache

  • Mọi thứ bắt đầu bằng việc lưu kết quả của yêu cầu API vào biến cục bộ.
  • Trong các ứng dụng web sử dụng framework khai báo, dữ liệu được lưu trong biến để tránh các yêu cầu API không cần thiết.
  • Bước tiếp theo là đưa cache lên lớp cao hơn hoặc tách nó ra ngoài cây UI.

Tăng tốc bằng chỉ mục

  • Bằng cách tổ chức dữ liệu theo một cách nhất định, có thể giảm khối lượng công việc của ứng dụng và cải thiện trải nghiệm người dùng.
  • Tác giả nhận ra rằng tối ưu hóa dữ liệu ở frontend rất giống với cách vận hành bên trong của kho lưu trữ cơ sở dữ liệu.
  • Cấu trúc dữ liệu được cải thiện bằng cách lưu dữ liệu theo ID và tạo chỉ mục để tra cứu nhanh các mục theo ngày.

Optimistic mutations

  • Đây là việc mô phỏng hiệu ứng của một thao tác cụ thể ở máy cục bộ mà không cần chờ phản hồi từ máy chủ.
  • Cách này khiến giao diện người dùng trông như phản hồi ngay lập tức, nhưng nếu kết quả khác với máy chủ thì UI phải hoàn tác các thay đổi.
  • Có nhiều thách thức như sao chép logic giữa client và server, xử lý lỗi bất đồng bộ, và điều chỉnh thay đổi sau khi ứng dụng khởi động lại.

Vô hiệu hóa cache đệ quy

  • Dữ liệu xuất hiện ở nhiều vị trí trong cache, nên sau khi cập nhật cần vô hiệu hóa cache đúng cách để khớp với máy chủ.
  • UI phải biết phần nào của cache liên quan tới từng mutation, và điều này có thể trở nên mong manh khi quy mô tăng lên.
  • Khi kết hợp với optimistic mutations, việc sao chép logic phía server để dự đoán thay đổi ở phía client càng trở nên khó khăn hơn.

Đang xây dựng cơ sở dữ liệu?

  • Trong các ứng dụng frontend đủ phức tạp, cuối cùng bạn sẽ phải tự xây rất nhiều chức năng quản lý dữ liệu, và điều đó lấy đi thời gian lẽ ra nên dùng để làm người dùng hài lòng và giải quyết vấn đề kinh doanh.
  • Bài viết đưa ra một phương án thay thế là stack cơ sở dữ liệu được tối ưu cho frontend.

Giới thiệu SQLSync

  • Tác giả phát triển SQLSync, một stack cơ sở dữ liệu được tối ưu cho frontend dựa trên SQLite.
  • SQLSync được thiết kế để giải quyết các vấn đề quản lý dữ liệu và giúp nhà phát triển tập trung vào các tính năng độc đáo của ứng dụng.
  • SQLSync cung cấp cache bền vững, toàn bộ khả năng của SQLite, optimistic mutations, vô hiệu hóa cache thông minh và reactive queries.

Ý kiến của GN⁺

Điểm quan trọng nhất của bài viết này là hiện tượng các nhà phát triển tự triển khai những chức năng giống cơ sở dữ liệu khi độ phức tạp của ứng dụng frontend tăng lên. Công việc này tiêu tốn thời gian của họ và khiến họ rời xa việc phát triển những tính năng thực sự mang lại giá trị cho người dùng. Một stack cơ sở dữ liệu tối ưu cho frontend như SQLSync đưa ra một cách tiếp cận đổi mới nhằm giải quyết vấn đề này. Điều khiến bài viết thú vị là nó chỉ ra vấn đề cốt lõi của các phương pháp quản lý dữ liệu truyền thống và tìm kiếm một lời giải mới để nhà phát triển có thể làm việc hiệu quả hơn.

1 bình luận

 
GN⁺ 2023-12-02
Ý kiến trên Hacker News
  • Hiểu về người bạn là tác giả của dự án

    • SQLsync là công cụ cho phép các lập trình viên frontend truy vấn và cập nhật cơ sở dữ liệu từ xa ngay trong trình duyệt.
    • Nó hoạt động bằng cách tận dụng sức mạnh của WASM để truyền cơ sở dữ liệu SQLite vào trình duyệt.
    • Nó sử dụng thuật toán phản ứng để đồng bộ giữa nhiều client.
    • Đây là một cách tiếp cận mang tính đột phá để giải quyết bài toán đồng bộ dữ liệu cho lập trình viên.
  • Kinh nghiệm với phần mềm quản lý dự án ở công ty cũ

    • Đã dùng cơ chế check-in/check-out để đồng bộ dữ liệu, nhưng bị xem là lỗi thời khi các ứng dụng cập nhật thời gian thực xuất hiện.
    • Từ kinh nghiệm xây dựng ứng dụng web SPA suốt 10 năm, cảm thấy cơ chế đồng bộ dữ liệu như vậy đã đi trước thời đại.
  • Những vấn đề sẽ biến mất nếu từ bỏ SPA

    • Dùng các giải pháp như Hotwire hay htmx sẽ giúp đơn giản hóa truy vấn phía server, và bài toán làm cho chúng nhanh hơn cũng đã được hiểu rõ hơn.
  • Ý kiến của tác giả SQLSync

    • Sẽ trả lời nhiều câu hỏi và định kỳ kiểm tra những câu hỏi đã bỏ lỡ.
    • Rất vui khi có thảo luận về bài đăng đầu tiên tập trung vào động lực tạo ra SQLSync.
    • Sẽ giải thích cách SQLSync hoạt động trong bài đăng tiếp theo.
  • Đừng trao cho người dùng một mô hình tinh thần khác với thực tế

    • Đồng bộ cơ sở dữ liệu có thể phức tạp hơn mô hình client-server.
    • Khi cần UI nhanh, cảm thấy dùng các thành phần cơ bản của CRDT sẽ an toàn hơn.
  • Nguyên tắc cái gì đo được thì được quản lý và ngụy biện chi phí chìm

    • Độ phức tạp của cơ sở dữ liệu là vấn đề.
    • Cú pháp SQL là vấn đề, và nếu việc dùng cơ sở dữ liệu quan hệ cơ bản là một trải nghiệm dễ chịu, thì sức hút dùng DB thay vì tự tạo cơ sở dữ liệu riêng sẽ càng lớn.
    • Cơ sở dữ liệu tốt thì dùng SQL, và để đạt hiệu quả thì phải dùng ngôn ngữ của cơ sở dữ liệu.
  • Vấn đề đồng bộ trạng thái giữa client và server

    • Quay lại mô hình PHP/SSR có thể lách được vấn đề bằng cách hy sinh UX.
    • SPA thì tốt, nhưng việc gửi form nhiều phần vẫn tiếp tục hoạt động tốt.
    • Giữ toàn bộ trạng thái ở server và coi client như một terminal đơn giản sẽ cải thiện trải nghiệm phát triển.
  • So sánh với thư viện ORM

    • Câu hỏi so sánh SQLsync với việc dùng trực tiếp TypeORM và SQL.js có hỗ trợ trong trình duyệt.
  • Sự khác biệt giữa cơ sở dữ liệu frontend và backend

    • Cơ sở dữ liệu frontend có thể khác backend, và có nhu cầu quản lý trạng thái thời gian thực ở phía client tốt hơn.
    • Đang cân nhắc việc vô hiệu hóa cache bằng react query và WebSocket.
    • Ý tưởng của SQLsync cũng đáng để cân nhắc.
  • Một nỗ lực tương tự với SignalDB

    • SignalDB dùng tính phản ứng dựa trên signal và cú pháp truy vấn giống mongodb, không phụ thuộc framework.