Empat klik untuk tayang. Tiga puluh detik, dari awal sampai selesai. Satu aplikasi berbasis server yang aktif per akun di tingkat gratis. Setengah detik latensi tambahan pada permintaan pertama yang pernah dilayani subdomain baru, dan tidak ada lagi setelahnya. Tiga angka itu hanyalah trivia — jenis yang Anda anggukkan lalu lupakan di bab berikutnya. Namun angka "satu" itu yang sebenarnya mengubah cara Anda seharusnya bekerja, jadi di situlah saya ingin menghabiskan sebagian besar bab ini.
Mengapa batasnya satu, bukan nol dan bukan tak terbatas
Sebagian besar alat no-code yang membiarkan Anda mempublikasikan frontend secara gratis, entah sama sekali tidak menyentuh aplikasi berbasis server, atau membatasinya begitu ketat sehingga "gratis" hanya formalitas. Di sini, build dengan akun pengguna, database, atau status multiplayer dipublikasikan lewat tombol Publish yang sama persis dengan halaman statis, dan sisi servernya di-hosting dan dikelola sebagai bagian dari satu tindakan itu — tanpa provisioning database terpisah, tanpa variabel lingkungan yang harus disambungkan, tanpa baru menyadari tiga hari kemudian bahwa login berfungsi di pratinjau tapi error 500 di produksi karena backend tidak pernah benar-benar ter-deploy. Itu nyata, dan itulah sebabnya orang terkejut saat menabrak batasnya: sampai titik itu semuanya terasa tak terbatas.
Tidak. Anda mendapat tepat satu aplikasi berbasis server yang aktif sekaligus di tingkat gratis. Build statis tidak terhitung dalam batas ini — publikasikan sebanyak apa pun halaman pemasaran dan situs portofolio yang Anda mau, tidak ada batas di situ. Tapi build kedua yang butuh database atau proses persisten sendiri harus menunggu giliran, tetap terbangun penuh dan bisa dipratinjau, hanya saja tidak tayang di URL-nya. Jika Anda sedang membuat prototipe tiga ide SaaS dalam minggu yang sama, hanya satu yang bisa menempati komputasi sungguhan; dua lainnya adalah produk jadi tanpa alamat. Menurut saya batasan ini masuk akal — bundel statis nyaris tidak membebani platform untuk dilayani di edge, sedangkan proses server yang tetap aktif jelas berbeda — tapi ini berarti keputusan ide mana yang layak mendapat slot harus diambil sebelum Anda menekan Publish, bukan setelah Anda terlanjur ingin dua-duanya tayang sekaligus.
Empat klik itu, untuk catatan
- Di kartu build, pilih Publish.
- Pilih slug — nama-anda di
yourname.buildmidas.com. Slug yang sudah dipakai akan disarankan alternatifnya. - Konfirmasi.
- Salin URL dari kartu, atau temukan nanti di halaman Published Anda.
Tanpa DNS, tanpa akun eksternal, tanpa menunggu propagasi. Dan soal setengah detik itu: itu bukan antrean atau penundaan "cek lagi dalam 24 jam," itu hanya pemanasan cache CDN biasa. Pengunjung pertama ke subdomain baru mungkin merasakan sedikit tambahan latensi saat node edge terdekat menarik bundel aset; pengunjung kedua, dan setiap orang setelahnya, mendapatkannya dari cache. Dalam praktiknya Anda tidak akan menyadarinya — Anda akan mempublikasikan, mengetuk tautan, dan itu sudah terasa instan. Saya hanya menyebutkannya karena seseorang yang pekerjaannya memotret waktu muat akan bertanya suatu saat mengapa permintaan pertama dan kesepuluh tidak identik, dan sekarang Anda sudah tahu.
Slug adalah satu-satunya keputusan yang layak dipikirkan pelan-pelan
Semua hal lain dalam alur ini bersifat mekanis; slug adalah bagian yang harus diucapkan atau diketik dari ingatan oleh manusia, jadi layak dipikirkan sejenak. "demo-v2-final-final" boleh untuk pengujian internal tapi buruk untuk dikirim ke klien lewat teks. Ucapkan URL-nya pada diri Anda sendiri sebelum mengonfirmasi — riverside-cafe.buildmidas.com terdengar bersih, riverside-cafe-mvp2.buildmidas.com tidak. Kata-kata pendek dan umum cepat habis di platform yang sudah lama berjalan, itulah sebabnya slug yang sudah dipakai memberi Anda saran, bukan sekadar error. Ambil salah satu atau tolak, tapi putuskan dengan sengaja — saya pernah melihat orang mengambil apa pun yang ditawarkan kotak itu di tengah demo karena mereka butuh tautan segera, lalu hidup dengan nama yang canggung selama berbulan-bulan karena tidak pernah ada momen alami untuk memperbaikinya.
Menerbitkan ulang tidak menyentuh apa yang sedang tayang sampai Anda memerintahkannya
Ini fakta yang layak diinternalisasi sejak awal: mengedit build yang sudah dipublikasikan tidak memindahkan situs yang sedang tayang. Anda bisa merusak sesuatu, mencoba perubahan tata letak yang liar, beriterasi selama seminggu — URL yang sudah di-bookmark klien tetap menyajikan apa pun yang terakhir Anda publikasikan, sampai Anda dengan sengaja mempublikasikan lagi.
Itulah keseluruhan cerita rollback Anda, dan bagusnya justru karena membosankan. Versi 6 dirilis dengan bug — sebuah formulir yang diam-diam berhenti mengirim — dan Anda tidak perlu mencari perintah revert atau tiket dukungan. Anda buka riwayat versi, temukan versi 5, publikasikan ulang. Tombol yang sama, artefak lebih lama, URL yang tayang langsung berbalik. Lalu Anda perbaiki versi 6 tanpa tekanan, karena produksi tidak rusak selama Anda bekerja. Pajaknya adalah satu klik ekstra per rilis, karena Anda harus ingat untuk benar-benar mempublikasikan, bukan mengira sebuah edit otomatis tayang. Bandingkan dengan alat di mana setiap penyimpanan langsung tayang — bagus untuk demo, canggung setelah tiga minggu pemakaian nyata — dan klik ekstra itu adalah pertukaran yang layak diambil setiap saat.
Unpublish berarti URL berhenti mengarah, bukan "berhenti dicantumkan"
Banyak platform menggunakan "unpublish" untuk berarti menyembunyikan dari halaman galeri sementara URL diam-diam tetap melayani. Di sini artinya alamatnya benar-benar mati, titik — tidak ada halaman cache, tidak ada placeholder, tidak ada yang mengarah. Build itu sendiri tetap ada dengan setiap versi utuh; publikasikan lagi nanti dan slug yang sama kembali persis di tempat Anda meninggalkannya. Saya pernah memakai ini untuk alasan sepele (kerja sama dengan klien berakhir, tak ada yang mau logo lamanya masih mengambang di tautan publik) dan untuk yang tidak sepele (sebuah build membocorkan sesuatu yang seharusnya tidak, dan itu harus offline dalam waktu sekali klik, bukan waktu untuk mengajukan tiket ke penyedia hosting). Kedua situasi ingin jaminan yang sama, dan keduanya mendapatkannya.
Satu hal lagi yang layak tidak dicampuradukkan: mempublikasikan membuat URL tayang untuk siapa pun yang punya tautannya; apakah URL itu bisa ditemukan — dicantumkan secara publik, kadang muncul di Showcase — adalah pengaturan yang sama sekali terpisah. Banyak situs yang dipublikasikan secara sah seharusnya tetap hanya-lewat-tautan selamanya, dan build yang dipilih untuk pencantuman publik tetap hanyalah situs terpublikasi biasa di baliknya, dengan riwayat yang sama dan tombol unpublish yang sama.
