Trong một kỷ nguyên bị thống trị bởi các framework JavaScript phức tạp và kiến trúc microservices, một xu hướng đáng ngạc nhiên đang gia tăng sức hút trong cộng đồng nhà phát triển: chuyển logic ứng dụng web trực tiếp vào tầng cơ sở dữ liệu. Derek Sivers, được biết đến với những cách tiếp cận không theo lối mòn trong công nghệ, gần đây đã chia sẻ phương pháp luận phát triển web tập trung vào PostgreSQL của mình, thứ đã khơi mào một cuộc thảo luận sôi nổi khắp cộng đồng nhà phát triển. Cách tiếp cận của ông thách thức những giả định cơ bản về nơi logic nghiệp vụ nên tồn tại trong các ứng dụng web hiện đại.
Triết lý Ưu tiên Cơ sở dữ liệu
Sivers đã xây dựng các ứng dụng web tập trung vào PostgreSQL trong chín năm, ban đầu để PostgreSQL trả về dữ liệu JSON sau đó sẽ được xử lý bởi các controller Ruby. Sự tiến hóa hiện tại của ông đưa khái niệm này đi xa hơn bằng cách nhúng trực tiếp việc phân tích mẫu Mustache vào trong các hàm của PostgreSQL. Điều này có nghĩa là cơ sở dữ liệu không chỉ phục vụ dữ liệu—mà nó còn tạo ra các phản hồi HTML hoàn chỉnh sẵn sàng để gửi đến trình duyệt. Cách tiếp cận này loại bỏ các tầng middleware truyền thống, với các hàm PostgreSQL trả về trực tiếp cả HTTP headers và nội dung HTML body.
Ứng dụng của bạn đang ngồi trên một cỗ máy tính toán kiểu Ferrari!
Quan điểm này làm nổi bật điều mà những người ủng hộ cho là tiềm năng chưa được khai thác của các hệ thống cơ sở dữ liệu hiện đại. Thay vì coi cơ sở dữ liệu chỉ là nơi lưu trữ dữ liệu, họ lập luận rằng các cơ sở dữ liệu quan hệ như PostgreSQL chứa các công cụ tính toán tinh vi mà hầu hết các ứng dụng đang sử dụng chưa hết công suất.
Các Thành Phần Kỹ Thuật trong Phương Pháp của Sivers:
- Phân tích cú pháp template Mustache trong PostgreSQL
- pgTAP để kiểm thử các hàm cơ sở dữ liệu
- HTTP headers và mã trạng thái được trả về từ các hàm cơ sở dữ liệu
- Cơ sở dữ liệu kiểm thử riêng biệt (siverstest) để kiểm thử độc lập
- Đồng bộ hóa template từ hệ thống tệp tin vào các bảng cơ sở dữ liệu
Các Tiền lệ Lịch sử và Phản ứng Hiện đại
Khái niệm đặt logic nghiệp vụ trong stored procedure không hoàn toàn mới. Một số bình luận viên nhớ lại các cách tiếp cận tương tự từ đầu những năm 2000, đặc biệt là với cơ sở dữ liệu Oracle. Một nhà phát triển lưu ý rằng công việc đầu tiên của họ vào khoảng năm 2007 liên quan đến việc làm trên một ứng dụng Delphi nơi tất cả logic nghiệp vụ đều nằm trong các stored procedure của Oracle. Bối cảnh lịch sử này cung cấp một góc nhìn quan trọng về việc liệu chúng ta đang chứng kiến sự đổi mới hay sự tái khám phá.
Phản ứng từ các nhà phát triển đã sống qua kỷ nguyên stored procedure của những năm 1990 rất đa dạng. Một số tỏ ra hoài nghi dựa trên những trải nghiệm đau đớn với các ứng dụng cơ sở dữ liệu được kết hợp chặt chẽ, vốn trở thành cơn ác mộng về bảo trì. Tuy nhiên, Sivers và những người khác lập luận rằng PostgreSQL đại diện cho một mô hình hoàn toàn khác—linh hoạt hơn và thân thiện với nhà phát triển hơn so với các hệ thống Oracle đã tạo ra danh tiếng xấu cho stored procedure.
Dòng thời gian Bối cảnh Lịch sử:
- Cuối những năm 1990: Các stored procedure của Oracle được dùng cho business logic
- Đầu những năm 2000: Sự kết hợp Delphi/Oracle phổ biến
- 2007: Vẫn còn thịnh hành trong môi trường doanh nghiệp
- 2016: Sivers bắt đầu phát triển tập trung vào PostgreSQL (9 năm trước)
- 2024: Thảo luận hiện tại và chia sẻ framework
Triển khai Kỹ thuật và Công cụ
Việc triển khai thực tế liên quan đến một số đổi mới thông minh. Các mẫu HTML được lưu trữ trực tiếp trong cơ sở dữ liệu nhưng được chỉnh sửa cục bộ trong các tệp, sau đó đồng bộ hóa bằng các script tùy chỉnh. Các hàm của PostgreSQL xử lý việc phân tích mẫu bằng cú pháp Mustache, trả về các phản hồi HTTP hoàn chỉnh bao gồm mã trạng thái, tiêu đề và nội dung HTML. Hệ thống sử dụng pgTAP để kiểm thử, duy trì các cơ sở dữ liệu kiểm thử riêng biệt để đảm bảo độ tin cậy của hàm mà không ảnh hưởng đến dữ liệu sản xuất.
Kiến trúc này thể hiện một sự đơn giản hóa triệt để của mô hình ứng dụng web ba tầng truyền thống. Bằng cách thu gọn tầng ứng dụng vào trong cơ sở dữ liệu, các nhà phát triển giảm số lượng thành phần chuyển động và các điểm hỏng tiềm ẩn. Cách tiếp cận này đặc biệt phù hợp với các ứng dụng nơi các mối quan hệ dữ liệu và quy tắc nghiệp vụ phức tạp, tận dụng các tính năng xử lý giao dịch mạnh mẽ và tính toàn vẹn dữ liệu của PostgreSQL.
Các Dự án Cộng đồng với Tinh thần Tương tự
Cuộc thảo luận đã tiết lộ một số dự án khác cũng đang khám phá lãnh thổ tương tự. PostgREST thường xuyên được nhắc đến như một dự án tự động tạo ra các REST API trực tiếp từ lược đồ cơ sở dữ liệu PostgreSQL. Những người khác tham chiếu đến SpacetimeDB, thứ đưa khái niệm cơ-sở-dữ-liệu-như-máy-chủ-ứng dụng đi xa hơn nữa. Một nhà phát triển đã chia sẻ cách tiếp cận thử nghiệm của chính họ khi phục vụ lưu lượng web trực tiếp từ SQLite, chứng minh bề rộng của sự quan tâm đến các kiến trúc lấy cơ sở dữ liệu làm trung tâm.
Các dự án này chia sẻ một triết lý chung: nếu cơ sở dữ liệu của bạn có khả năng xử lý các thao tác phức tạp một cách hiệu quả, tại sao lại thêm các tầng không cần thiết vốn làm phức tạp hóa và tạo ra các điểm nghẽn hiệu suất tiềm ẩn? Phong trào này thách thức sự khôn ngoan thông thường rằng cơ sở dữ liệu chỉ nên là các hệ thống lưu trữ ngu ngốc trong khi các máy chủ ứng dụng xử lý tất cả logic.
Các Dự Án Framework Web PostgreSQL Chính Được Đề Cập:
- sivers/sivers: Framework web PostgreSQL tùy chỉnh của Derek Sivers với templating Mustache
- PostgREST: Tự động tạo REST API từ schema PostgreSQL
- SpacetimeDB: Database-engine được thiết kế đặc biệt cho logic ứng dụng
- rumca-js/web_link_browser: Ví dụ về ứng dụng web lấy SQLite làm trung tâm
Tương lai của Phát triển Full-Stack
Cuộc trò chuyện chạm đến các xu hướng rộng lớn hơn trong phát triển web, bao gồm sự hồi sinh của kết xuất phía máy chủ và sự phân chia lao động giữa các nhà phát triển frontend và backend. Khi các tiêu chuẩn web phát triển để xử lý việc cập nhật nội dung động mà không cần tải lại toàn bộ trang, một số nhà phát triển đặt câu hỏi liệu chúng ta có còn cần sự phức tạp của việc quản lý trạng thái client-side rộng lớn hay không.
Cách tiếp cận lấy cơ sở dữ liệu làm trung tâm có khả năng thu hẹp khoảng cách giữa các vai trò frontend và backend, cho phép các nhà phát triển tập trung vào các trường hợp sử dụng nghiệp vụ hơn là các hợp đồng API giữa các hệ thống riêng biệt. Điều này có thể dẫn đến trải nghiệm phát triển gắn kết hơn và có khả năng là các chu kỳ lặp nhanh hơn đối với một số loại ứng dụng nhất định.
Cuộc thảo luận đang diễn ra cho thấy chúng ta có thể đang ở điểm khởi đầu của một sự đánh giá lại rộng rãi hơn về kiến trúc ứng dụng web. Khi các cơ sở dữ liệu trở nên có khả năng hơn và các nhóm phát triển tìm cách giảm thiểu sự phức tạp, các cách tiếp cận khai thác khả năng của cơ sở dữ liệu một cách đầy đủ hơn có thể được áp dụng rộng rãi hơn. Liệu điều này có đại diện cho một sự thay đổi cơ bản hay chỉ là một cách tiếp cận thích hợp cho các trường hợp sử dụng cụ thể vẫn còn phải chờ xem, nhưng cuộc thảo luận đầy nhiệt huyết chỉ ra rằng chủ đề này chạm đến những câu hỏi quan trọng về cách chúng ta xây dựng phần mềm trong kỷ nguyên hiện đại.
Tham khảo: sivers/sivers