คู่มือ: เผยแพร่เว็บไซต์แรกของคุณ

สี่คลิกก็ขึ้นออนไลน์ สามสิบวินาที จากเริ่มจนเสร็จ หนึ่งแอปที่รองรับด้วยเซิร์ฟเวอร์ต่อบัญชีในระดับฟรี ครึ่งวินาทีของความหน่วงเพิ่มเติมสำหรับคำขอแรกที่ซับโดเมนใหม่เอี่ยมให้บริการ และไม่มีอีกเลยหลังจากนั้น สามในตัวเลขเหล่านี้เป็นเรื่องเกร็ดเล็กน้อย — แบบที่คุณพยักหน้ารับแล้วก็ลืมไปเมื่อถึงบทถัดไป แต่ "หนึ่ง" คือตัวเลขที่เปลี่ยนวิธีการทำงานของคุณจริง ๆ ดังนั้นนี่คือสิ่งที่ผมอยากใช้เวลาส่วนใหญ่ของบทนี้พูดถึง

ทำไมข้อจำกัดถึงเป็นหนึ่ง ไม่ใช่ศูนย์และไม่ใช่ไม่จำกัด

เครื่องมือ no-code ส่วนใหญ่ที่ให้คุณเผยแพร่หน้าเว็บฟรีมักไม่แตะต้องแอปที่รองรับด้วยเซิร์ฟเวอร์เลย หรือไม่ก็จำกัดการใช้งานอย่างเข้มงวดจนคำว่า "ฟรี" เป็นแค่รูปแบบเท่านั้น ที่นี่ build ที่มีระบบบัญชี ฐานข้อมูล หรือสถานะแบบผู้ใช้หลายคน เผยแพร่ผ่านปุ่ม Publish ปุ่มเดียวกันกับหน้าเว็บแบบสแตติก และฝั่งเซิร์ฟเวอร์ก็ถูกโฮสต์และจัดการเป็นส่วนหนึ่งของการกระทำครั้งเดียวนั้น — ไม่ต้องตั้งค่าฐานข้อมูลแยก ไม่ต้องเชื่อมต่อตัวแปรสภาพแวดล้อม ไม่ต้องมาพบทีหลังว่าการล็อกอินใช้ได้ในพรีวิวแต่ error 500 ในโปรดักชันเพราะแบ็กเอนด์ไม่เคยถูกดีพลอยจริง นี่คือของจริง และนี่คือเหตุผลที่ผู้คนแปลกใจเมื่อชนเพดาน: ทุกอย่างก่อนหน้านั้นให้ความรู้สึกว่าไม่มีขีดจำกัด

มันไม่ได้เป็นแบบนั้น คุณได้แอปที่รองรับด้วยเซิร์ฟเวอร์ที่ออนไลน์อยู่ได้เพียงหนึ่งแอปในระดับฟรี build แบบสแตติกไม่นับรวมในข้อจำกัดนี้ — เผยแพร่หน้าการตลาดหรือเว็บไซต์พอร์ตโฟลิโอได้มากเท่าที่ต้องการ ไม่มีขีดจำกัด แต่ build ตัวที่สองที่ต้องการฐานข้อมูลของตัวเองหรือโปรเซสที่ทำงานต่อเนื่อง ต้องรอคิว โดยที่มันถูกสร้างเสร็จสมบูรณ์และพรีวิวได้ เพียงแต่ไม่ได้ออนไลน์ที่ URL ของมัน ถ้าคุณกำลังทำโปรโตไทป์ไอเดีย SaaS สามอันในสัปดาห์เดียวกัน จะมีเพียงอันเดียวที่ได้ครองพื้นที่ประมวลผลจริง ส่วนอีกสองอันเป็นผลิตภัณฑ์ที่เสร็จสมบูรณ์แต่ไม่มีที่อยู่ ผมคิดว่าเส้นแบ่งนี้ถูกวางไว้อย่างสมเหตุสมผล — การให้บริการไฟล์สแตติกที่ edge แทบไม่มีต้นทุนกับแพลตฟอร์ม ในขณะที่โปรเซสเซิร์ฟเวอร์ที่พร้อมทำงานตลอดเวลานั้นมี — แต่มันหมายความว่าการตัดสินใจว่าไอเดียไหนสมควรได้ช่องนี้ ต้องเกิดขึ้นก่อนที่คุณจะกด Publish ไม่ใช่หลังจากที่คุณผูกพันกับการมีสองแอปออนไลน์พร้อมกันไปแล้ว

สี่คลิกนั้น เพื่อให้ครบถ้วน

• บนการ์ดของ build เลือก Publish
• เลือกสลัก — ชื่อผู้ใช้ของคุณ ใน yourname.buildmidas.comสลักที่ถูกใช้แล้วจะแนะนำทางเลือกอื่นให้
• ยืนยัน
• คัดลอก URL จากการ์ด หรือหาได้ภายหลังในหน้า Published ของคุณ

ไม่มี DNS ไม่มีบัญชีภายนอก ไม่ต้องรอการ propagation แล้วเรื่องครึ่งวินาทีนั้นล่ะ มันไม่ใช่คิวหรือการดีเลย์แบบ "ตรวจสอบอีก 24 ชั่วโมงข้างหน้า" แต่เป็นเพียงการวอร์มแคช CDN ตามปกติ ผู้เข้าชมคนแรกของซับโดเมนใหม่อาจเจอความหน่วงเพิ่มขึ้นเล็กน้อยขณะที่ edge node ที่ใกล้ที่สุดดึงชุดไฟล์มา ผู้เข้าชมคนที่สองและทุกคนหลังจากนั้นจะได้รับจากแคช ในทางปฏิบัติคุณจะไม่สังเกตเห็นเลย — คุณจะเผยแพร่ แตะลิงก์ แล้วมันจะรู้สึกเร็วทันทีอยู่แล้ว ผมพูดถึงเรื่องนี้ก็เพราะสักวันจะมีคนที่แคปหน้าจอเวลาโหลดเป็นอาชีพมาถามว่าทำไมคำขอที่หนึ่งกับคำขอที่สิบถึงไม่เหมือนกัน ตอนนี้คุณก็รู้แล้ว

สลักที่ควรใช้เวลาคิดให้รอบคอบ

ทุกอย่างในขั้นตอนนี้เป็นกลไก ยกเว้นสลักที่เป็นส่วนที่มนุษย์ต้องพูดออกเสียงหรือพิมพ์จากความจำ จึงคุ้มค่าที่จะคิดสักครู่ "demo-v2-final-final" เหมาะสำหรับการทดสอบภายในแต่แย่มากถ้าจะส่งให้ลูกค้า ลองพูด URL ให้ตัวเองฟังก่อนยืนยัน — riverside-cafe.buildmidas.com อ่านลื่นไหล riverside-cafe-mvp2.buildmidas.com ไม่ลื่นไหล คำสั้น ๆ ทั่วไปมักถูกใช้ไปแล้วอย่างรวดเร็วบนแพลตฟอร์มที่เปิดมานาน ซึ่งเป็นเหตุผลที่สลักที่ถูกใช้แล้วจะได้คำแนะนำแทนที่จะเป็นข้อผิดพลาดเปล่า ๆ จะเลือกอันหนึ่งหรือปฏิเสธก็ได้ แต่ควรตัดสินใจอย่างตั้งใจ — ผมเคยเห็นคนหยิบเอาสิ่งที่กล่องเสนอมาระหว่างสาธิตเพราะต้องการลิงก์ทันที แล้วต้องอยู่กับชื่อที่ดูแปลก ๆ ไปหลายเดือน เพราะไม่เคยมีจังหวะธรรมชาติที่จะกลับไปแก้ไข

การเผยแพร่ซ้ำจะไม่แตะต้องสิ่งที่ออนไลน์อยู่ จนกว่าคุณจะสั่งเอง

นี่คือข้อเท็จจริงที่ควรจดจำไว้แต่เนิ่น ๆ: การแก้ไข build ที่เผยแพร่แล้วไม่ได้ทำให้เว็บไซต์ที่ออนไลน์อยู่เปลี่ยนแปลงไป คุณสามารถทำพัง ลองเปลี่ยนเลย์เอาต์แบบสุดโต่ง ทำซ้ำไปเรื่อย ๆ ได้เป็นสัปดาห์ — URL ที่ลูกค้าบันทึกไว้แล้วยังคงให้บริการสิ่งที่คุณเผยแพร่ล่าสุดต่อไป จนกว่าคุณจะตั้งใจเผยแพร่อีกครั้ง

นั่นคือเรื่องราวการย้อนกลับทั้งหมดของคุณ และมันดีเพราะมันน่าเบื่อพอดี เวอร์ชัน 6 มีบั๊ก — ฟอร์มที่หยุดส่งข้อมูลอย่างเงียบ ๆ — และคุณไม่ต้องใช้คำสั่ง revert หรือแจ้ง support ticket คุณเปิดประวัติเวอร์ชัน หาเวอร์ชัน 5 แล้วเผยแพร่ใหม่ ปุ่มเดียวกัน ไฟล์เก่ากว่า URL ที่ออนไลน์เปลี่ยนกลับทันที จากนั้นคุณแก้เวอร์ชัน 6 โดยไม่มีความกดดันเลย เพราะโปรดักชันไม่ได้เสียหายขณะที่คุณทำงาน ต้นทุนของวิธีนี้คือหนึ่งคลิกเพิ่มต่อการปล่อยแต่ละครั้ง เพราะคุณต้องจำไว้ว่าต้องเผยแพร่จริง ๆ แทนที่จะสันนิษฐานว่าการแก้ไขจะออกไปอัตโนมัติ เทียบกับเครื่องมือที่ทุกการบันทึกออนไลน์ทันที — ดีตอนสาธิต แต่ลำบากเมื่อใช้งานจริงไปสามสัปดาห์ — คลิกเพิ่มนั้นคุ้มค่าที่จะแลกทุกครั้ง

Unpublish หมายถึง URL หยุดทำงาน ไม่ใช่แค่ "หยุดถูกแสดงรายการ"

แพลตฟอร์มจำนวนมากใช้คำว่า "unpublish" หมายถึงการซ่อนจากหน้าแกลเลอรี ในขณะที่ URL ยังคงให้บริการอย่างเงียบ ๆ ที่นี่มันหมายถึงที่อยู่นั้นดับสนิท จบ — ไม่มีหน้าแคช ไม่มีตัวยึดที่ว่าง ไม่มีอะไรทำงานเลย ตัว build เองยังคงอยู่พร้อมทุกเวอร์ชันครบถ้วน เผยแพร่ใหม่ในภายหลัง แล้วสลักเดิมก็จะกลับมาที่จุดเดิมพอดี ผมเคยใช้วิธีนี้ด้วยเหตุผลธรรมดา ๆ (งานกับลูกค้าจบลง ไม่มีใครอยากให้โลโก้เก่าลอยอยู่ที่ลิงก์สาธารณะ) และด้วยเหตุผลที่ไม่ธรรมดานัก (build รั่วไหลบางอย่างที่ไม่ควร และต้องออฟไลน์ในเวลาที่ใช้คลิกปุ่มเดียว ไม่ใช่เวลาที่ใช้ยื่นเรื่องกับผู้ให้บริการโฮสติ้ง) ทั้งสองสถานการณ์ต้องการการรับประกันแบบเดียวกัน และทั้งคู่ก็ได้รับมัน

อีกเรื่องหนึ่งที่ไม่ควรสับสนกัน: การเผยแพร่ทำให้ URL ออนไลน์สำหรับทุกคนที่มีลิงก์ ส่วนว่ามัน ถูกค้นพบได้ หรือไม่ — ถูกแสดงรายการต่อสาธารณะ บางครั้งปรากฏใน Showcase — เป็นสวิตช์แยกต่างหากโดยสิ้นเชิง เว็บไซต์ที่เผยแพร่แล้วจำนวนมากควรอยู่ในสถานะเข้าถึงได้เฉพาะผู้มีลิงก์ตลอดไป และ build ที่เลือกให้แสดงรายการสาธารณะก็ยังคงเป็นเว็บไซต์ที่เผยแพร่แล้วธรรมดาข้างใต้ พร้อมประวัติเดียวกันและปุ่ม unpublish เดียวกัน