Lý thuyết và thực tế của "website tĩnh"
(utcc.utoronto.ca)- Trái với quan điểm cho rằng ranh giới giữa website tĩnh và động đã trở nên mờ nhạt, trên trục thời gian vận hành dài hạn, website dựa trên tệp tĩnh vẫn có những đặc tính khác biệt
- Cách triển khai tệp đã tiếp nối từ buổi đầu của web và hiệu quả của phục vụ tệp tĩnh là lý do khiến website tĩnh dễ được duy trì lâu dài
- Website tĩnh có ranh giới trách nhiệm rõ ràng như hệ thống tệp giữa máy chủ web và nội dung, nên những gì hai bên cần biết về nhau là rất hạn chế
- Website động khó có được một ranh giới nhỏ gọn và đơn giản giữa máy chủ web với mã người dùng, và cũng khó tiêu chuẩn hóa ranh giới cùng API đó thành một
- Tiêu chí phân biệt không nằm ở khối lượng công việc hay tần suất thay đổi, mà ở chỗ ranh giới nằm ở đâu và mỗi phía phải quan tâm đến điều gì
Điểm khởi đầu của tranh luận về website tĩnh
- There is no such thing as a static website của Wesley Aptekar-Cassels cho rằng khác biệt giữa website tĩnh và website động nhỏ hơn mọi người vẫn nghĩ
- Website tĩnh động và phức tạp hơn vẻ bề ngoài
- Việc xây dựng và vận hành website động đã trở nên dễ hơn trước
- Từng luận điểm riêng lẻ được triển khai khá thuyết phục, nhưng không dẫn đến kết luận rằng khác biệt giữa website tĩnh và động đã thu hẹp lại
Khác biệt được tạo ra bởi độ bền và ranh giới trách nhiệm
- Trên trục thời gian dài, nội dung web dựa trên tệp tĩnh đã cho thấy độ bền cao
- Dù máy chủ web và nơi lưu trữ cụ thể có thay đổi, cách đặt tệp trong cây thư mục vẫn được duy trì từ buổi đầu của web
- Phục vụ tệp tĩnh cũng thường cần thiết và hiệu quả ngay cả với website động, nên các website chỉ có tệp tĩnh cũng tận dụng được cùng những lợi thế đó
- Chỉ cần cung cấp nội dung tĩnh thì việc tiếp tục vận hành sẽ dễ dàng hơn, tạo thành một website ổn định, điều mà về mặt lịch sử không đúng với website động
- Cốt lõi của website tĩnh là ranh giới trách nhiệm có sự cô lập đơn giản nhưng mạnh mẽ
- Một phía là độ phức tạp của máy chủ web tĩnh, bao gồm cả các cập nhật động như gia hạn chứng chỉ HTTPS
- Phía còn lại là các tệp tĩnh, và ở giữa là hệ thống tệp hoặc một thứ tương tự hệ thống tệp
- Những gì hai bên yêu cầu lẫn nhau là rất hạn chế
- Website động khó có được ranh giới nhỏ và rõ ràng như vậy giữa máy chủ web và mã người dùng
- Khả năng tiêu chuẩn hóa bằng một ranh giới và API duy nhất cũng thấp
- Xét ở một khía cạnh nào đó, web được thiết kế để phục vụ tệp tĩnh
- Khác biệt này khiến máy chủ web phục vụ tệp tĩnh thuận lợi hơn cho vận hành và di chuyển so với máy chủ web động và môi trường thực thi
- Máy chủ web tĩnh dễ tìm
- Ngay cả khi đơn vị vận hành hiện tại dừng hoạt động, website cũng dễ được chuyển sang nơi khác
- Độ bền này áp dụng ít nhất với các website tĩnh quy mô nhỏ và vừa có thể nằm trong một máy chủ duy nhất
- Sự phân biệt giữa website tĩnh và website động không hề mơ hồ
- Tiêu chí không phải là khối lượng công việc để tạo và vận hành website, hay lượng yếu tố thay đổi định kỳ như gia hạn chứng chỉ HTTPS
- Tiêu chí là ranh giới nằm ở đâu và mỗi phía cần quan tâm đến điều gì
- Website tĩnh có một ranh giới sắc nét cho phép xử lý hai phía một cách độc lập, còn website động vốn dĩ không có ranh giới như vậy nên nếu cần thì phải vạch ra một cách nhân tạo
1 bình luận
Ý kiến trên Hacker News
Tôi đang kiếm sống bằng một website nội dung, và năm nay đã chuyển từ Craft CMS sang một trình tạo site tĩnh tự làm
Giờ tôi không còn phải bận tâm đến máy chủ hay CMS, không cần cập nhật, cũng loại bỏ được cơ sở dữ liệu nặng nề và cấu hình cache phức tạp. Hiện giờ nó chỉ là một máy chủ phục vụ file tĩnh nên ổn định hơn và hầu như không cần bảo trì
Điểm tuyệt nhất là có thể làm việc offline. Chỉ cần trình soạn thảo văn bản, nên ngay cả chiếc Macbook 12" nhỏ cũng cho cảm giác rất nhanh
Quản lý phiên bản cũng cực kỳ hữu ích: có thể xem lại hoặc hoàn tác thay đổi, và tìm/thay thế bằng biểu thức chính quy trên toàn bộ nội dung. File văn bản rất dễ xử lý
Tôi đã viết ở đây về cảm giác của lần chuyển đổi này và vì sao nó hoạt động tốt: https://nicolasbouliane.com/projects/ursus
Tuy vậy, tôi mong công nghệ này trở nên dễ tiếp cận hơn cả với những người không có khả năng biên dịch lại và triển khai. Đây là cách dựng website nhanh và rẻ, nhưng các công cụ hiện có như Hugo đặt ra khá nhiều giả định với người dùng, tạo thành rào cản gia nhập
Bài viết cũng rất thú vị. Tôi là người đã tạo phiên bản gốc của html-to-markdown dùng cho việc migration, nên thấy nó vẫn còn hữu ích thì rất vui
Nhanh, có đầy đủ nội dung cần thiết, và không rườm rà
Cá nhân tôi muốn có thêm một mục về các TV series và phim lấy bối cảnh Berlin xưa và nay, kèm một đánh giá ngắn xem chúng mô tả Berlin ngoài đời thực tế đến mức nào
Có lẽ hơn 95% toàn bộ website chỉ cần cache 70% nội dung phổ biến trong RAM, còn 30% còn lại phục vụ từ SSD có khả năng đọc ngẫu nhiên 10.000 IOPS là đủ
Nếu bạn không liên tục mày mò thiết kế site, việc tạo site và HTML nên diễn ra trên máy cục bộ, và toàn bộ quá trình tạo nên dưới 1 giây
Nhưng cách tiếp cận xoay quanh GitHub, quản lý phiên bản và trình soạn thảo văn bản vẫn nghiêng về giới kỹ thuật và lập trình viên. Cần thứ gì đó giống WordPress dạng hosted, hoặc gần với thời Dreamweaver/Frontpage trước đây hơn
Tôi thích việc có thể đào sâu đến từng chi tiết khi muốn triển khai thứ gì đó đặc biệt. Ví dụ, tôi có thể thiết lập để khi chỉnh sửa bài Favorite Git Aliases thì nó được chuyển thành file
.bash_aliases, đẩy lên GitLab và cũng được mirror sang GitHubAi tò mò thì xem ở https://jdsalaro.com. Tôi chưa viết chi tiết về stack hay lý do, nhưng sẽ dần dần tài liệu hóa
Trước mắt tôi đã viết về Markdown cho Sphinx và cheat sheet Myst (https://jdsalaro.com/cheatsheet/sphinx-myst-cheat-sheet/) cũng như cách load
environment.pickle(https://jdsalaro.com/howto/sphinx-load-environment-pickle/)Điều đó cũng có nghĩa là dùng ít tài nguyên như điện hơn, phần cứng nhỏ hơn cũng đủ, và quan trọng nhất là bảo mật được cải thiện. Website tĩnh khó bị tấn công hơn, và các lỗi có thể có cũng chỉ giới hạn ở phía web server chứ không phải mã của website
Tôi thường dùng Hugo; nó rất giàu tính năng và hoàn thiện. Tôi cũng từng làm website đa ngôn ngữ
Cũng đáng cân nhắc tích hợp Turbo Hotwired vào website tĩnh. Nó có thể tăng độ phản hồi khi điều hướng và giảm tải cho cả server lẫn client
Nếu cần, cũng có thể tích hợp Turbo với Mercure để streaming trang theo thời gian thực
Khác biệt lớn nhất giữa site tĩnh và site động là bề mặt tấn công bảo mật
Web server của site tĩnh, trong trường hợp tệ nhất, chỉ có thể bị dụ phục vụ sai file, và có thể giảm thiểu bằng cách ngay từ đầu chỉ đưa lên server những file được phép phục vụ
Site động có thể bị dụ chạy mã, cũng có thể bị khiến trả về dữ liệu sai từ cơ sở dữ liệu có thể truy cập, hoặc bị khiến sửa đổi dữ liệu
Việc WordPress bị xâm nhập xảy ra suốt, còn Nginx thì không như vậy
Về mặt kỹ thuật, không có website nào không chạy mã. Từ web server đến driver hệ thống file và hệ điều hành, tất cả đều là mã
File tĩnh làm giảm bề mặt tấn công là đúng, nhưng cần suy nghĩ sâu hơn vì sao lại như vậy và thiết kế các hệ thống động thông minh có được mức bảo mật của site tĩnh
Rốt cuộc, cốt lõi là input và cách xử lý input đó. Dù chạy mã phức tạp đến đâu, nếu hoàn toàn không nhận input thì không thể bị tấn công. Tất nhiên, nếu không có input thì cũng không biết phải hiển thị trang nào, nên site tĩnh cũng có input. Điểm phân biệt quan trọng nằm ở đây
Tôi đồng ý rằng bề mặt tấn công của site tĩnh nhỏ hơn, nhưng theo tôi lý do lớn hơn là nginx được rà soát nhiều hơn rất nhiều so với một tổ hợp plugin WordPress trung bình, và tốc độ phát triển cũng chậm hơn
Nếu bạn tự viết web server tĩnh, phiên bản đầu tiên có khả năng dễ bị tấn công hơn một bản cài WordPress mặc định
Về lý thuyết, site tĩnh có thể hoàn toàn không cần cập nhật. Chừng nào mục tiêu như phiên bản HTML không thay đổi, thì bản thân khái niệm cập nhật gần như không tồn tại
locationcó chỉ thịaliasTừ góc nhìn của lập trình viên, cách phân loại dựa trên lớp trừu tượng mà web cung cấp, tức hypermedia được cung cấp trên HTTP/S, khá gọn gàng
Ngữ nghĩa của lớp trừu tượng này là một cấu trúc trong đó yêu cầu có header và phần thân đi vào một đường dẫn cụ thể, rồi phản hồi có header và phần thân đi ra. Các chi tiết mạng trung gian như TLS được che giấu
Trên thực tế, các framework hiện đại tự động quản lý cả phiên xác thực lẫn header yêu cầu, che giấu nhiều thứ hơn với lập trình viên. Trong lớp trừu tượng này, cách phân biệt tiêu chuẩn “tĩnh là không phụ thuộc vào yêu cầu/trạng thái, động là có phụ thuộc” khá gọn gàng, nhưng sự phân biệt đó dựa vào ngữ nghĩa mà lớp trừu tượng cung cấp
Điều này giống như TCP hoạt động như một giao thức hướng kết nối trên hạ tầng bên dưới vốn về cơ bản là dựa trên gói tin. Có thể dùng TCP cho các ứng dụng cần truyền dữ liệu kiểu stream hoặc kiểu gói tin
Có thể lập luận rằng “thực ra nó nằm trên IP nên không có sự phân biệt”, nhưng đó là nhìn ở sai tầng trừu tượng
Nói vậy không có nghĩa là ý chính của bài viết sai. Lập trình viên luôn nên lưu ý đến tính có trạng thái nằm bên dưới một “website không trạng thái”, và tốt nhất là hiểu các lớp trừu tượng sâu hơn vài tầng so với mức mình nghĩ là cần thiết
Website cá nhân là sự pha trộn khá tinh tế giữa tĩnh và động. Phần lớn là tĩnh, nhưng phần blog thì là render động
Khi truy cập URL blog, nó lấy file Markdown từ đĩa, chuyển thành HTML, rồi đưa HTML đó vào template để tạo phần còn lại của trang cùng CSS, v.v.
Dù vậy nó vẫn nhanh và hiệu quả. Tuần trước, khi một bài blog của tôi lên hạng 1 trên HN, một người bạn nhắn rằng “hy vọng cậu đã cấu hình Cloudflare”. Tôi không cấu hình, nhưng tải trung bình của VPS 2 core, RAM 1GB vẫn không vượt quá 0,15
Kiểu như “phần lớn là HTML, nhưng khi đến dòng này trong file này thì chạy code để phân tích một file ở định dạng khác và chèn kết quả vào đầu ra”
Vào năm 2001, đây là cách rất hợp lý để tạo một website tĩnh có gắn những thứ như mục bình luận vào từng bài blog. PHP kiểu này đủ rẻ nên các ISP thông thường cũng hay cho phép đưa lên
/~userdir/và phơi ra Internet công cộngVới một cấu trúc hợp lý, không phụ thuộc quá nặng vào cơ sở dữ liệu, ngay cả một VPS nhỏ cũng có thể dễ dàng chịu được lưu lượng từ Hacker News
Nếu bạn ra mắt Threads thì sẽ cần cách mở rộng quy mô như Facebook làm, nhưng với một site chỉ đọc bình thường thì hoàn toàn không cần tiêu nhiều tiền
Tôi có thể nghĩ đến lý do như đưa nội dung động vào template, hoặc giảm thời gian build và độ phức tạp, nhưng cũng có thể có lý do khác mà tôi chưa nghĩ ra
Từ góc nhìn của một người ngoài chỉ đụng chút ít đến wasm, tôi không hiểu vì sao việc chạy mã của người dùng trên máy chủ để tạo trang web “động” lại tốt hơn một máy chủ tệp đơn giản
Tôi nghĩ phần động cứ chạy trong trình duyệt, còn máy chủ chỉ cần cung cấp tệp là được. Ngoại lệ là việc trình duyệt thập niên 90 rất tệ trong những tác vụ kiểu này
Về độ đơn giản và khả năng mở rộng thì không gì thắng được một máy chủ tệp đơn giản đặt sau CDN
Ngoài ra, việc có bao nhiêu công nghệ không phá hỏng các chức năng mặc định của trình duyệt cũng quan trọng
Nhân tiện, khi duyệt mã nguồn, GitHub vẫn làm hỏng nút quay lại trong môi trường của tôi khoảng 40% số lần. Tôi dùng Chrome trên OSX, mà cũng không hiểu làm sao lại thành ra như vậy
Theo trải nghiệm của tôi, các trang tạo HTML ở phía máy chủ cho cảm giác nhanh và ổn định hơn so với những trang dựa vào render phía client. Khi cache trình duyệt trống, mở một booru có hơn 50 ảnh mỗi trang luôn cho cảm giác nhanh và dễ chịu hơn so với mở một trang GitHub chỉ toàn văn bản, vốn đã được cache khắp nơi và không sửa gì suốt mấy ngày
Ví dụ, bạn có thể muốn lưu nội dung do người dùng gửi lên vào cơ sở dữ liệu, có thể cần xác thực, hoặc phải cung cấp tìm kiếm toàn văn trên một tập dữ liệu vài GB. Bạn cũng có thể cần cung cấp giao diện cho những thứ trình duyệt không thể truy cập, hoặc kiểm chứng dữ liệu người dùng nhập vào
Tất cả những việc này đều cần mã của người dùng chạy trên máy chủ. Khi đó phải chuyển dữ liệu trên máy chủ thành một giao thức truyền tải được định nghĩa rõ để gửi cho client, rồi chuyển đổi lại và tạo thành HTML
Chiều ngược lại cũng vậy: để ngăn các client tùy biến độc hại, bạn phải kiểm chứng đầu vào ở cả client lẫn máy chủ
Hoặc bạn có thể tạo HTML ngay trên máy chủ và thế là xong. Khối lượng công việc ít hơn nhiều, và với phần lớn ứng dụng thì trải nghiệm thực tế là như nhau
Nếu có các giá trị bí mật cần che giấu như mật khẩu cơ sở dữ liệu, khóa API, khóa mã hóa, thì mã trên máy chủ phải xử lý chúng. Nếu toàn bộ mã chạy ở client, luôn có khả năng kẻ tấn công phát hiện ra các bí mật đó
Cung cấp cho client một API nhỏ hơn và bị giới hạn hơn cũng giúp giảm bề mặt tấn công dễ hơn. Nếu để client kết nối trực tiếp tới cơ sở dữ liệu, quyền hạn và cấu hình bảo mật phải thật chính xác và không có vấn đề; nhưng nếu ứng dụng chỉ cung cấp danh sách sách hoặc phim mà nó quản lý thì việc xuyên thủng phòng thủ sẽ khó hơn
Việc cung cấp lần tải ban đầu dưới dạng một khối dữ liệu có thể dùng ngay cũng thường khiến trang có cảm giác phản hồi tốt hơn. Dù thời gian thực tế bằng với cách tải ứng dụng xuống, hiển thị chỉ báo đang tải rồi lấy dữ liệu để hiển thị, người dùng vẫn cảm thấy cách trước nhanh hơn
Máy chủ thường nằm cạnh cơ sở dữ liệu và các máy chủ cần thiết khác, nên tải những thứ cần ở phía trước có thể nhanh hơn. Các lời gọi mạng trong môi trường này ổn định hơn. Nếu đẩy toàn bộ xử lý về phía người dùng, bạn phải xử lý những lời gọi chậm hơn và kém ổn định hơn
Máy chủ nhiều khả năng là một nền tảng nhất quán hơn nhiều so với trình duyệt của người dùng. Trình duyệt đã tốt hơn, nhưng vẫn còn nhiều khác biệt tinh vi. Trên máy chủ, bạn có thể chỉ định chính xác công cụ và phiên bản runtime cần dùng, đồng thời cập nhật một cách quyết định hơn
Tất nhiên không phải lúc nào mọi điều này cũng đúng, và vẫn có ngoại lệ. Tôi chủ yếu làm ứng dụng front-end, nhưng những ứng dụng được thiết kế tốt, thực hiện phần lớn hoặc toàn bộ công việc trong trình duyệt, cũng có giá trị lớn. Chỉ là thường chúng là web app khá phức tạp, hoặc dù sao cũng cần một mức độ render nào đó trong trình duyệt
Việc tạo trang chỉ diễn ra một lần và kết thúc rất nhanh. Sau đó, từ góc nhìn người dùng, rất nhiều ưu điểm của trang tĩnh vẫn được giữ nguyên
Mức dùng tài nguyên thấp hơn vài bậc độ lớn và trang phản hồi tốt hơn nhiều. Trải nghiệm người dùng cũng vượt trội hơn hẳn, nhưng trong 10 năm qua chúng ta không mấy quan tâm đến điều đó
rsyncđẩy lên máy chủ web. Tất cả các trang đều được render độngƯu điểm là sau khi thiết lập một lần, tôi đúng nghĩa không phải bận tâm lại về website nữa, chỉ cần viết bằng Markdown mình thích
Rất tuyệt. Cho đến khi nhà cung cấp web hosting bỏ PHP
Vì những lý do này, tôi rất thích xuất trang tĩnh của NextJS
Build rồi triển khai chỉ các tệp
.html,.js,.csstĩnh lên CDN hoặc máy chủ web tĩnh tùy ý. Từng trang và route được prerender trong quá trình build, nên lần tải đầu rất nhanh và công cụ tìm kiếm cũng có thể lập chỉ mụcCách NextJS chia nhỏ mã
.jsthành các chunk và preload cũng góp phần tạo trải nghiệm tải nhanh. Nếu cần tính năng phong phú, bạn có thể nối với REST API tùy ý để làm nó động bao nhiêu cũng đượcDùng plugin MDX thì cũng dễ tạo các khu vực hoàn toàn tĩnh hoặc site thiên về nội dung trong cùng một dự án
Tuy nhiên, từ khi app router v13 xuất hiện, tôi có cảm giác họ không còn chăm chút đủ cho tính năng xuất tĩnh. Trong các tính năng từng có ở page router, shallow routing và rewrite/redirect tĩnh đã bị thiếu trong xuất tĩnh
Nếu dùng xuất tĩnh thì hoàn toàn không cần sản phẩm thương mại Vercel, nên tôi lo rằng về dài hạn họ có thể loại bỏ hẳn tính năng này
Phần lớn thậm chí không cần JavaScript, cũng không cần React, JSX, middleware hay render phía máy chủ
Thật khó tưởng tượng việc bảo trì dài hạn một thứ có nhiều bộ phận chuyển động và phụ thuộc npm như vậy. Không phải là nó không có chỗ dùng, nhưng trước khi lao vào một dự án có Git checkout 1.8 GiB và 828.128 dòng mã chỉ để làm một landing page, nên chọn cách đơn giản
Có thể xem ví dụ của Dan Abramov: https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343...
Không phải vì mô hình kinh doanh của Vercel, mà vì xét theo tỷ lệ sử dụng Next.js thì trường hợp sử dụng này ít phổ biến hơn
Tôi không rõ “rewrite tĩnh” nghĩa là gì. Chẳng phải việc đó được xử lý bằng middleware sao?
Vào một thời điểm nào đó trong thập niên 90, trước khi nghe đến cụm “trình tạo website tĩnh”, tôi đã dùng m4 để tạo site của mình
Sau đó chuyển sang PHP, Python, rồi giờ dùng Jekyll và quay lại hướng tĩnh
Nếu có thể làm được thì cách tĩnh tốt hơn nhiều. Trừ chứng chỉ SSL ra, tôi có thể sửa mọi thứ theo lịch của mình
So với tình huống một thứ gì đó hỏng vì nâng cấp PHP thì phải sửa ngay lập tức, và site bị sập cho đến khi sửa xong
Với site tĩnh, ngay cả khi trình tạo bị hỏng thì kết quả lỗi cũng chỉ là nó vẫn ở trạng thái tĩnh. Nếu không cần đăng bài mới thì không có vấn đề gì
Kể cả máy chủ nổ tung, chỉ cần nhờ bạn bè host giúp vài file là được. Không cần phải hỏi “Bạn đang chạy PHP phiên bản X với cấu hình Y chứ? Có cả postgres chứ?”
Một số bạn bè có thể nói “Tôi không muốn cài PHP lên máy của mình”
Về độ phức tạp, tôi thấy nó chỉ hơn
sed "s/VERSION/1.2.3/g"một bậc. Nếu có thể xử lý mọi thứ bằng lệnh shell bên ngoài thì không cần cài thứ như PythonTrong vài năm qua, tôi đã khám phá các mẫu kiến trúc mang lại cả ưu điểm của tĩnh lẫn động
Đó là cách vẫn có thể chạy mã phía máy chủ động, nhưng chi phí mở rộng rất thấp và nếu có gì hỏng thì tự phục hồi
Tôi gọi nó là mẫu Baked Data: https://simonwillison.net/2021/Jul/28/baked-data/
Ý tưởng cốt lõi là triển khai một bản sao chỉ đọc đầy đủ của dữ liệu site dưới dạng tài sản được đóng gói cùng ứng dụng
Giống như site hoàn toàn tĩnh, mỗi khi có thay đổi phải triển khai lại toàn bộ site, nên không phù hợp với các site được cập nhật liên tục
Ưu điểm là có thể triển khai lên hosting động scale-to-zero giá rẻ như Vercel, có thể chạy nhiều bản sao ứng dụng để xử lý mọi mức lưu lượng, và nếu app chết thì host có thể tự động khởi động lại
Tôi từng thấy các site tĩnh có tìm kiếm phía máy chủ hoặc hệ thống bình luận, trong đó mỗi bài viết hay bình luận được gửi lên như một file phẳng riêng, rồi từ đó tự động tái tạo các trang tĩnh
Có lẽ khác biệt là lưu trong sqlite thay vì file Markdown rồi build từ đó. Khi so với một site tĩnh có các chức năng backend/phía máy chủ thông thường, đó có vẻ là khác biệt có ý nghĩa duy nhất dễ nhận thấy
Trong các file thực thi nhị phân đã biên dịch, việc nhúng tài nguyên nhị phân đã mã hóa như file hoặc hình ảnh không phải là hiếm. Chỉ là không nhúng quá nhiều vì kích thước file thực thi sẽ tăng lên
Ví dụ C hoặc C++: https://github.com/graphitemaster/incbin
Điểm thú vị là người ta tạo chương trình sao cho dữ liệu bên trong file thực thi không thay đổi. Mã đã biên dịch chạy trên máy, và về mặt bảo mật điều đó cũng hợp lý
Nhưng nếu nghĩ đến container, chẳng hạn docker, thì container đang chạy cũng giống một file thực thi đã được đóng gói, nhưng còn có cả hệ thống file
Đưa dữ liệu vào container là một khái niệm tương tự tài nguyên được nhúng trong file thực thi, khác ở chỗ dữ liệu đó có thể thay đổi
Tuy nhiên, ngay cả khi dữ liệu thay đổi lúc runtime bên trong container, nếu không gắn lưu trữ bền vững thì nó sẽ không được giữ lại
Gần đây tôi tự hỏi tại sao chưa có một thứ giống như file đơn “chứa cả file thực thi và không gian dữ liệu tạm thời bên trong file thực thi”. Chẳng hạn chương trình và dữ liệu kiểu cơ sở dữ liệu có thể được kết hợp thành một file
Đây là suy nghĩ có liên quan phần nào đến “Baked Data”. Nhúng tài nguyên vào file thực thi rốt cuộc cũng là đưa dữ liệu đã mã hóa vào trong file thực thi
Với ngôn ngữ script, có thể tạo một file script chứa trực tiếp dữ liệu mã hóa base64 trong một biến
Hai cách phía sau chỉ phù hợp với dữ liệu tĩnh tương đối nhỏ, nhưng sẽ rất thú vị nếu tạo được công nghệ bằng cách nào đó gỡ bỏ các hạn chế như vậy của file thực thi
Trang dự án của tôi cũng được host theo cách này: https://usmanity.com/projects
Vì tôi không muốn chỉnh sửa trực tiếp file HTML mỗi khi thêm dự án mới vào danh sách hoặc thay đổi chi tiết của mục hiện có, nên tôi dùng Notion và bake dữ liệu vào trước khi commit lên GitHub
Khi bật lên, nó bake tất cả trang của site thành HTML trong một thư mục, rồi thay đổi
.htaccessđể chuyển toàn bộ lưu lượng sang đó. Khi cập nhật nội dung thì bake lại tất cảhttps://www.drupal.org/project/boost
Phần còn thiếu khá lớn ở site tĩnh, theo tôi, là host CMS dùng để biên tập ở đâu
Nếu tôi sai thì mong được sửa, nhưng Decap CMS (trước đây là Netlify CMS) chạy trong trình duyệt, có thể đọc/chỉnh sửa thông qua GitHub rồi kích hoạt build lại và triển khai. Tuy nhiên, vì CORS nên trình duyệt không thể giao tiếp trực tiếp với GitHub API, vì vậy tôi nghĩ vẫn cần một máy chủ nhỏ hoặc proxy
Netlify có host backend GitHub để proxy các request, nhưng như vậy bạn sẽ bị ràng buộc vào Netlify và các thay đổi chính sách giá của họ
GitLab và BitBucket có lẽ cũng gặp vấn đề tương tự: https://github.com/isomorphic-git/isomorphic-git#cors-suppor...
Có cách đơn giản nào giải quyết được với cấu hình tối thiểu không? Có thể dùng extension trình duyệt để nới lỏng CORS có chọn lọc, nhưng như vậy không lý tưởng
Một CMS có chỉnh sửa Markdown và xem trước trực tiếp, gắn với static site generator dựa trên Git, chạy trong trình duyệt và ít bị ràng buộc về hosting/server, có vẻ sẽ phù hợp với vô số website nhỏ và blog
Static generator chỉ cần đọc dữ liệu đó qua thứ như JSON feed rồi tạo trang. Ví dụ, mỗi bản ghi sản phẩm có thể chứa phần mô tả nội dung ở định dạng HTML
Như vậy, dù người khác cập nhật thông tin sản phẩm, website vẫn giữ trạng thái tĩnh. Tôi từng nghĩ Airtable sẽ phù hợp, nhưng bất ngờ là nó không hỗ trợ tốt trường HTML
Bạn cứ xây website theo cách mình muốn, kết nối Surreal qua FTP, rồi cho người dùng hoặc khách hàng chỉ chỉnh sửa những phần được phép
12 USD/tháng là rất rẻ cho việc không còn phải lo lắng, và bạn có thể cung cấp một trình biên tập WYSIWYG hoàn chỉnh cho người dùng không chuyên kỹ thuật
[1] https://www.surrealcms.com
Hiện extension này hoạt động trên VS Code cài cục bộ trong laptop, nhưng không hoạt động trên GitHub Codespaces
Nếu có thể làm cho nó chạy trong mức miễn phí của GitHub Codespaces, với giới hạn thời gian sử dụng hợp lý, thì có vẻ đây sẽ là lựa chọn thắng. Bạn sẽ có một cấu hình hoàn toàn online và được quản lý phiên bản mà không cần cài môi trường phát triển lên máy mình, static site thì được phục vụ từ nơi như S3, nhưng vẫn có trải nghiệm CMS đầy đủ
Điểm rất quan trọng của site tĩnh là có thể đưa lên rồi quên đi dễ hơn nhiều
Nếu đưa lên nơi như một S3 bucket site thì gần như không phải lo gì
Nếu làm một site “đưa lên rồi quên” bằng PHP, hoặc tệ hơn là WordPress tự host, thì trong lúc bạn không kiểm tra vài tháng một lần, nó có thể bị nhồi đầy quảng cáo khiêu dâm Nga
Tôi đang vận hành vài site tĩnh, và cảm giác biết rằng chúng luôn online và không cần sửa thật sự rất tốt. Ngược lại, với site động thì cần cảnh báo để kiểm tra xem nó có bị sập không