Bốn lần click để lên sóng. Ba mươi giây, từ đầu đến xong. Một app có server đang chạy trên mỗi tài khoản ở gói miễn phí. Nửa giây độ trễ thêm cho request đầu tiên mà một subdomain hoàn toàn mới phục vụ, và không có sau đó. Ba trong số các con số đó chỉ là chi tiết vụn vặt — kiểu bạn gật đầu rồi quên ngay chương sau. Nhưng con số "một" mới là con số thực sự thay đổi cách bạn nên làm việc, nên đó là nơi tôi muốn dành phần lớn chương này.
Vì sao giới hạn là một, không phải không, không phải vô hạn
Hầu hết các công cụ no-code cho phép xuất bản frontend miễn phí đều hoặc không chạm vào app có server, hoặc đo lường chúng gắt gao đến mức "miễn phí" chỉ là hình thức. Ở đây, một build có tài khoản, database, hoặc trạng thái multiplayer được xuất bản qua đúng nút Publish giống như một trang tĩnh, và phần server được host và quản lý như một phần của hành động đó — không cần cấp phát database riêng, không cần khai báo biến môi trường, không phát hiện ba ngày sau rằng đăng nhập hoạt động ở preview nhưng lỗi 500 ở production vì backend chưa hề triển khai thực sự. Điều đó là thật, và đó là lý do người dùng bất ngờ khi chạm giới hạn: mọi thứ trước đó cảm giác như vô hạn.
Không phải vậy. Bạn có đúng một app có server đang chạy tại một thời điểm ở gói miễn phí. Các build tĩnh không tính vào giới hạn này — xuất bản bao nhiêu trang marketing hay portfolio tùy ý, không giới hạn ở đó. Nhưng build thứ hai cần database riêng hoặc tiến trình liên tục phải chờ đến lượt, được build đầy đủ và xem trước được, chỉ không chạy trực tiếp tại URL của nó. Nếu bạn đang thử nghiệm ba ý tưởng SaaS trong cùng một tuần, chỉ một được chiếm slot tính toán thực; hai cái còn lại là sản phẩm hoàn chỉnh nhưng không có địa chỉ. Tôi nghĩ ranh giới được đặt ở vị trí hợp lý — một bundle tĩnh gần như không tốn gì để phục vụ tại edge, một tiến trình server luôn sẵn sàng thì không — nhưng điều đó có nghĩa là quyết định ý tưởng nào đáng được slot phải diễn ra trước khi bạn nhấn Publish, không phải sau khi bạn đã gắn bó với việc có hai cái chạy cùng lúc.
Bốn lần click, để ghi lại cho rõ
- Trên thẻ của build, chọn Publish.
- Chọn một slug — tên người dùng của bạn trong
yourname.buildmidas.com. Các slug đã được sử dụng sẽ gợi ý phương án khác. - Xác nhận.
- Sao chép URL từ thẻ, hoặc tìm nó sau trên trang Published của bạn.
Không cần DNS, không cần tài khoản bên ngoài, không cần chờ propagation. Còn về nửa giây đó: đó không phải là hàng đợi hay độ trễ "kiểm tra lại sau 24 giờ", chỉ là quá trình làm nóng cache CDN thông thường. Người truy cập đầu tiên vào một subdomain mới có thể gặp một khoảnh khắc độ trễ thêm khi edge node gần nhất tải bundle tài nguyên; người truy cập thứ hai, và mọi người sau đó, nhận từ cache. Trong thực tế bạn sẽ không nhận ra — bạn sẽ xuất bản, chạm vào liên kết, và nó đã cảm giác ngay lập tức. Tôi chỉ đề cập vì ai đó chụp màn hình thời gian tải để sống sẽ sớm hỏi vì sao request một và request mười không giống nhau, và giờ bạn đã biết.
Slug là quyết định duy nhất đáng dừng lại để suy nghĩ
Mọi thứ khác trong luồng này đều máy móc; slug là phần con người phải nói ra hoặc gõ từ ký ức, nên đáng dừng lại suy nghĩ một chút. "demo-v2-final-final" phù hợp cho thử nghiệm nội bộ và là điều tệ để gửi qua text cho khách hàng. Tự đọc URL trước khi xác nhận — riverside-cafe.buildmidas.com nghe gọn gàng, riverside-cafe-mvp2.buildmidas.com thì không. Các từ ngắn, thông dụng sẽ hết nhanh trên một nền tảng đã tồn tại lâu, đó là lý do một slug đã dùng sẽ cho bạn gợi ý thay vì lỗi trơn. Chấp nhận một gợi ý hoặc từ chối nó, nhưng hãy quyết định có chủ đích — tôi đã thấy người ta lấy bất cứ gì hộp thoại đề xuất giữa lúc demo vì họ cần liên kết ngay lập tức, rồi sống với một cái tên khó chịu suốt nhiều tháng vì không bao giờ có thời điểm tự nhiên để sửa nó.
Republish không ảnh hưởng đến bản đang chạy trực tiếp cho đến khi bạn nói vậy
Đây là một sự thật nên nắm sớm: chỉnh sửa một build đã xuất bản không làm thay đổi site đang chạy trực tiếp. Bạn có thể làm hỏng thứ gì đó, thử một thay đổi bố cục điên rồ, lặp lại trong một tuần — URL mà khách hàng đã bookmark vẫn phục vụ bất cứ thứ gì bạn xuất bản lần cuối, cho đến khi bạn chủ động xuất bản lại.
Đó là toàn bộ câu chuyện rollback của bạn, và nó tốt chính vì nó nhàm chán. Phiên bản 6 phát hành một lỗi — một form âm thầm ngừng gửi — và bạn không cần dùng lệnh revert hay ticket hỗ trợ. Bạn mở lịch sử phiên bản, tìm phiên bản 5, republish nó. Cùng một nút, artifact cũ hơn, URL đang chạy đảo ngược ngay lập tức. Sau đó bạn sửa phiên bản 6 mà không có áp lực gì, vì production không bị hỏng trong lúc bạn làm việc. Chi phí cho việc này là một lần click thêm mỗi lần phát hành, vì bạn phải nhớ thực sự xuất bản thay vì cho rằng một chỉnh sửa tự động được đưa ra. So sánh với các công cụ nơi mỗi lần lưu đều lên trực tiếp — tuyệt trong demo, khó khăn ba tuần vào việc sử dụng thật — và lần click thêm đó là một đánh đổi đáng thực hiện mọi lúc.
Unpublish có nghĩa là URL ngừng phân giải, không phải "ngừng được liệt kê"
Nhiều nền tảng dùng "unpublish" để nghĩa là ẩn khỏi trang gallery trong khi URL vẫn âm thầm tiếp tục phục vụ. Ở đây nó có nghĩa là địa chỉ tắt hoàn toàn, dứt điểm — không trang cache, không placeholder, không gì phân giải. Build vẫn tồn tại với mọi phiên bản còn nguyên; republish sau đó và slug giống hệt trở lại đúng chỗ bạn đã rời đi. Tôi đã dùng điều này cho lý do bình thường (một hợp đồng khách hàng kết thúc, không ai muốn logo cũ của họ trôi lơ lửng tại một liên kết công khai) và cho lý do ít bình thường hơn (một build làm rò rỉ thứ gì đó không nên, và cần offline trong thời gian bằng một lần click nút, không phải thời gian mở ticket với nhà cung cấp hosting). Cả hai tình huống đều muốn cùng một đảm bảo, và cả hai đều nhận được nó.
Một điều nữa đáng không nhầm lẫn: xuất bản làm cho một URL chạy trực tiếp cho bất kỳ ai có liên kết; việc nó có được phát hiện hay không — được liệt kê công khai, đôi khi xuất hiện ở Showcase — là một công tắc hoàn toàn riêng biệt. Rất nhiều site đã xuất bản hợp lệ nên mãi chỉ dùng liên kết, và một build được chọn liệt kê công khai vẫn chỉ là một site đã xuất bản thông thường bên dưới, với cùng lịch sử và cùng nút unpublish.
