Rust ต้องการเว็บเฟรมเวิร์กสำหรับนักพัฒนาสายขี้เกียจ

 (ntietz.com)
3 คะแนน โดย GN⁺ 2024-10-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้จะสร้างเว็บแอปขนาดเล็กด้วย Rust ก็ยังขาด ประสบการณ์แบบครบวงจรเหมือน Django ทำให้ภาระในการเชื่อม routing, login, DB และฟังก์ชันจัดการต่าง ๆ ด้วยตัวเองมีมากขึ้น
  • เฟรมเวิร์กที่ต้องการควรรวม routing/handler, template, การให้บริการไฟล์ static, login, authorization, DB interface, admin tool, WebSockets และ hot reloading ไว้เป็นพื้นฐาน
  • มี เฟรมเวิร์กแบบมินิมอล อย่าง actix-web และ axum รวมถึง SPA framework อย่าง Dioxus, Leptos และ Yew อยู่แล้ว แต่ไม่ได้ช่วยประกอบโครงสร้างเว็บแอปทั้งชุดให้แทน
  • starter template ช่วยลดการตั้งค่าเริ่มต้นได้ แต่หลังจากโปรเจกต์แยกทางไปแล้ว การ merge การเปลี่ยนแปลงและการอัปเดตไลบรารียังคงกลายเป็น ภาระการบำรุงรักษา
  • newt มุ่งเป็น web toolkit ที่รวม component ที่มีอยู่เดิมในแนวทางที่มีความเห็นชัดเจน โดยมีเป้าหมายให้เริ่มเว็บแอปขนาดเล็กได้ภายในไม่กี่นาที แทนที่จะใช้เวลาหลายวัน

จุดเริ่มต้นแบบครบวงจรที่ยังขาดในเว็บดีเวลลอปเมนต์ด้วย Rust

  • แม้แต่เว็บโปรเจกต์ขนาดเล็กที่สร้างด้วย Rust ก็ยังต้องใช้ งานเชื่อมต่อเริ่มต้น มากกว่า Django หรือเฟรมเวิร์กคล้ายกันอย่างมาก
  • แนวทางทั่วไปของชุมชน Rust ใกล้เคียงกับการนำชิ้นส่วนที่ต้องการมาเชื่อมเอง
    • Are We Web Yet? ก็ระบุว่าในการพัฒนาเว็บด้วย Rust โดยทั่วไปต้องเชื่อมเอง และควรคาดว่าจะมีงานตั้งค่าเพิ่มเติมตอนเริ่มต้น
  • งานเพิ่มเติมนี้ไม่ใช่แค่ระดับ “เพิ่มอีกนิดหน่อย” แต่มีรายการจำนวนมากที่ต้องจัดการก่อนจะเริ่มโปรเจกต์จริง
  • หากมีเว็บเฟรมเวิร์กแบบครบวงจร ก็จะโน้มน้าวให้ใช้ Rust กับเว็บแอปได้ง่ายขึ้น
    • ข้อดีของ Rust ที่ถูกกล่าวถึง ได้แก่ type system, performance และช่วงพักดื่มกาแฟระหว่างรอ compile

องค์ประกอบพื้นฐานที่เว็บแอปแทบทุกตัวต้องมี

  • Routing/Handler

    • ต้องส่ง request ที่เข้ามาไปยัง handler ที่เหมาะสม
    • ต้องจัดการ path parameter และจะดียิ่งขึ้นถ้ามี type information
    • ถ้ามีการจัดการ query parameter และ form ด้วยก็จะดี

  • Template

    • ต้องสร้าง HTML และในบางกรณีก็สร้าง JSON หรือ XML ด้วย
    • ต้องมี logic พื้นฐาน เช่น conditional, match/switch และ loop

  • การให้บริการไฟล์ static

    • ต้องให้บริการ asset อย่าง CSS
    • อาจแยกไปจัดการด้วย server อื่นได้ แต่ในการพัฒนา local และการ deploy ขนาดเล็ก การรวมไว้ใน web server เดียวกันจะสะดวก

  • Login

    • แอปมักเป็นระบบผู้ใช้หลายคน หรือถูก deploy บนเครือข่ายสาธารณะ จึงแทบต้องมีฟังก์ชัน login เสมอ
    • เนื่องจากการเชื่อมเองทุกครั้งยุ่งยาก จึงควรใช้งานได้ง่ายตั้งแต่แรก
    • ต้องสามารถ customize และ opt-out ได้

  • Authorization

    • ในระบบที่มีผู้ใช้หลายคน ข้อมูลที่เข้าถึงได้หรือ role จะแตกต่างกัน
    • แค่ pattern check(user, object, action) ก็พาไปได้ค่อนข้างไกลแล้ว

  • DB interface

    • ต้องมีวิธีเก็บข้อมูลของแอป
    • แนวทางที่ใกล้เคียง ORM อาจมีประโยชน์ แต่แนวทางที่เบากว่าก็เป็นไปได้เช่นกัน
    • สิ่งนี้กลายเป็นองค์ประกอบพื้นฐาน เพราะถูกใช้กับ login, authorization และ admin tool

  • Admin tool

    • เมื่อตั้งค่าแอปพลิเคชันใน local environment หรือ production ต้อง bootstrap ผู้ใช้อย่างน้อยหนึ่งคนหรือข้อมูลบางส่วน
    • งาน admin ทั่วไปบางส่วนควรมีมาในตัว เพื่อให้ประสบการณ์ราบรื่น

  • WebSockets

    • สามารถสร้างฟังก์ชันที่ push ข้อมูลไปยังผู้ใช้ที่เชื่อมต่ออยู่ได้แบบใกล้ real-time มากขึ้น

  • Hot reloading

    • การเปลี่ยนแปลง code หรือ template ควรถูกสะท้อนผลให้เร็วที่สุด จึงสำคัญมากต่อ developer experience

ฟังก์ชันเสริมที่จำเป็นสำหรับโปรเจกต์ที่อยู่ยาว

  • Background job

    • จะมีฟังก์ชันที่ต้องรันตาม schedule เกิดขึ้น ดังนั้นถ้ามีวิธีที่สอดคล้องกันก็จะทำให้พัฒนาง่ายขึ้น

  • Monitoring/Observability

    • จำเป็น เว้นแต่จะเป็นระบบที่เล็กที่สุดและมีความสำคัญต่ำ
    • มีประโยชน์มากในช่วงเวลาที่ต้องการมันจริง ๆ อย่างเร่งด่วน

  • Caching

    • มีวิธี implement หลายแบบ และทุกแบบเพิ่มความซับซ้อน ส่วนจะเร็วขึ้นหรือไม่ขึ้นอยู่กับสถานการณ์
    • ถ้ามีเรื่องเล่าในระดับ framework ก็จะดี แต่ผู้ใช้ก็จัดการเองได้เช่นกัน

  • Email และ notification

    • หากมีฟังก์ชัน login ฟังก์ชัน email อาจจำเป็นโดยพฤตินัยเพราะการ reset password
    • ส่วน notification อื่น ๆ เพิ่มเมื่อจำเป็นก็ไม่มีปัญหาใหญ่

  • Deployment tool

    • ถ้ามีวิธี deploy ไปยังตำแหน่งเฉพาะอย่างสอดคล้องกันก็จะดี
    • แค่มี Dockerfile ที่ generate อัตโนมัติและใช้ได้บน host ที่เลือก ก็มีประโยชน์แล้ว

  • CSS/JS bundling

    • ถ้า web tool รู้จัก CSS และ JS และรวมเข้าไปได้อย่างเป็นธรรมชาติก็จะดี
    • ยังไม่แน่ชัดว่าจำเป็นต้อง integrate หรือไม่

ช่องว่างที่ ecosystem เว็บของ Rust ในปัจจุบันทิ้งไว้

  • Rust มีเครื่องมือพัฒนาเว็บอยู่มากแล้ว แต่ไม่มีเครื่องมือที่ตั้งเป้าไปที่ประสบการณ์แบบครบวงจรตามที่ต้องการ

  • เว็บเฟรมเวิร์กแบบมินิมอล

    • actix-web และ axum ใกล้เคียงกับเฟรมเวิร์กขนาดเล็กอย่าง Flask, Sinatra
    • ใช้ประโยชน์จาก type system ของ Rust เพื่อมอบประสบการณ์พัฒนาเว็บที่ดี แต่แทบไม่มีฟังก์ชันเพิ่มเติมนอกเหนือจาก handler
    • โปรเจกต์ส่วนใหญ่สามารถสร้างด้วยเฟรมเวิร์กมินิมอลเหล่านี้ได้ แต่ก็ยังยุ่งยากเพราะต้องเชื่อมฟังก์ชันที่ต้องการเองทุกครั้ง

  • SPA framework

    • Dioxus, Leptos, Yew เติมเต็มพื้นที่ที่ใช้ Rust ทั้ง backend และ frontend และใช้ WebAssembly สำหรับการ render ฝั่ง frontend
    • ประสบการณ์ที่สร้าง digital vigil ด้วย Yew นั้นสนุก แต่ยังไม่แน่ใจว่าอยากใช้ในสภาพแวดล้อม production จริงหรือไม่
    • เฟรมเวิร์กเหล่านี้ก็ยอดเยี่ยมสำหรับเป้าหมายของตัวเอง แต่ยังต้องมีงานเชื่อมต่อจำนวนมากอยู่ดี

  • ชุดไลบรารีแยกชิ้น

    • มีไลบรารี template, login, authorization และ WebSocket จำนวนมาก
    • บางโปรเจกต์และตัวอย่าง integrate component บางอย่างเข้าด้วยกัน แต่หาแบบที่ integrate ชิ้นส่วนทั้งหมดที่ใช้ได้ยาก
    • เนื่องจากเป็น ecosystem ที่เคลื่อนไหวเร็ว ตัวอย่างบางส่วนอาจล้าสมัย
    • การ “แค่เชื่อมเข้าด้วยกัน” สุดท้ายแล้วกลายเป็นงานที่ต้องค้นคว้าและเข้าใจวิธีทำงานของแต่ละไลบรารีให้เพียงพอ

การบำรุงรักษาที่ starter template แก้ไม่ได้

  • วิธีเดิมโดยทั่วไปคือเลือก framework พื้นฐานอย่าง actix-web หรือ axum จากนั้นค้นหาชิ้นส่วนที่ต้องการ วางทับเข้าไป และเชื่อมเอง
  • starter template อาจลดความเจ็บปวดเริ่มต้นได้ แต่ ภาระการบำรุงรักษา ยังเหลืออยู่
    • ต้องรักษาไลบรารีให้ทันสมัย
    • ต้องรับมือกับ breaking change
    • เมื่อโปรเจกต์ออกนอกเส้นทางจาก template แล้ว ก็ยากที่จะ merge การเปลี่ยนแปลงของ template กลับเข้ามา
  • หากดูแลหลายโปรเจกต์ แทนที่จะอัปเดตเฟรมเวิร์กเดียว ก็ต้องอัปเดตเฟรมเวิร์กแบบปรับแต่งเองจำนวน n ชุดแยกกัน
  • เว็บเฟรมเวิร์กที่รับผิดชอบทั้งชุดและมี คำแนะนำการอัปเกรด ระหว่างเวอร์ชันจะดีกว่า
    • breaking change อาจเกิดขึ้นได้ แต่สามารถทำเอกสารกำกับได้
    • ลดสถานการณ์ที่เกิดปัญหาจากการเปลี่ยนแปลง interaction ระหว่าง component สองตัวที่ไม่รู้ว่าควรถูก integrate เข้าด้วยกัน

web toolkit ที่ newt มุ่งไปสู่

  • เว็บเฟรมเวิร์ก Rust ในอุดมคติควรมีฟังก์ชันที่กล่าวมาข้างต้น พร้อมเอกสารที่ดี changelog การจัดการเวอร์ชันอย่างรอบคอบ การรับมือ breaking change และชุมชน
  • ปัจจุบันยังไม่มีเครื่องมือเช่นนั้น และก็ไม่แน่ชัดว่ามีคนอื่นกำลังสร้างอยู่หรือไม่
  • เครื่องมือที่กำลังดำเนินการอยู่ใกล้เคียงกับ web toolkit ที่นำ building block เดิมมาเชื่อมในแนวทางที่มีความเห็นชัดเจน มากกว่าจะเป็น framework
  • toolkit นี้มีชื่อว่า nicole's web toolkit หรือย่อว่า newt
    • เปิดเผยอยู่ที่ public repository
    • ยังไม่อยู่ในสถานะที่ใช้งานได้ และการเปลี่ยนแปลงล่าสุดก็ยังไม่ได้ push
    • ยังไม่พร้อมรับ contribution
  • เป้าหมายของ newt คือเมื่อสร้างเว็บแอปขนาดเล็กตัวใหม่ ให้เริ่มงานโปรเจกต์จริงได้ภายในไม่กี่นาที แทนที่จะใช้เวลาหลายวันไปกับงานเชื่อมต่อ
  • องค์ประกอบบางส่วนมีแผนจะสร้างขึ้นใหม่ตั้งแต่ต้นตามความจำเป็น
    • เพราะวิธีนั้นอาจง่ายกว่า หรือเข้ากันได้อย่างมีเอกภาพมากกว่า
  • ecosystem ของ Rust จำเป็นต้องมีสภาพที่แข็งแรงซึ่งมี toolkit แบบนี้หลายตัว และคาดหวังว่าเครื่องมืออื่น ๆ จะออกมาพร้อมกันด้วย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-07
ความคิดเห็นจาก Hacker News

  • แปลกใจที่ Rocket(https://rocket.rs/) ไม่อยู่ในรายชื่อเฟรมเวิร์กที่ผู้เขียนลิสต์ไว้
    ผมยังไม่เคยลองใช้เอง และชอบ axum/actix-web ที่ไม่กำหนดแนวทางตายตัวมากกว่า แต่เท่าที่เข้าใจ เป้าหมายของ Rocket ใกล้เคียงกับ เฟรมเวิร์กแบบมีแบตเตอรี่ให้ครบ ที่ผู้เขียนต้องการมากกว่าเยอะ และก็เป็นโปรเจกต์ที่มีมานานพอสมควรแล้ว

    • Rocket เป็นหนึ่งในเฟรมเวิร์ก Rust ยุคแรก ๆ ที่ผลักดันประสบการณ์นักพัฒนาที่ดีด้วย procedural macro แต่ดูเหมือนความนิยมจะลดลงมากในหลายส่วนของชุมชน
      เป็นเวลานานมากที่การบิลด์ต้องใช้ nightly Rust และสำหรับคนที่อยากใช้เฟรมเวิร์กในสภาพแวดล้อม production นี่เป็นข้อเสียร้ายแรง
      อีกทั้งยังติดอยู่ในสถานะ release candidate ของ 0.5.0 ประมาณ 2 ปี และรีลีส stable ล่าสุดก็ล้าหลังกว่าเว็บเฟรมเวิร์ก Rust อื่น ๆ มาก ต้องใช้ nightly และยังไม่มีการรองรับ async
      ตอนนี้ที่ผ่านด่าน 0.5 มาแล้วอาจดีขึ้นแล้วก็ได้ แต่ประวัติการพัฒนาของ Rocket ทำให้ลังเลที่จะใช้เมื่อเทียบกับทางเลือกอย่าง Axum

  • มีอยู่ตัวหนึ่ง: Poem[1]
    ผู้เขียนพูดถึง Flask แต่ถ้าดูส่วน “สิ่งที่ต้องการ” แล้ว แม้แต่ Flask ก็ดูไม่น่าจะตอบโจทย์นั้นได้ แม้ผมจะไม่ชอบ Django เอามาก ๆ แต่สำหรับข้อกำหนดแบบนั้น สิ่งที่ใกล้เคียงที่สุดกับที่ผู้เขียนอธิบายก็น่าจะเป็น Django
    ในแง่นั้น Poem ก็ไม่ใช่ตัวเลือกที่ดีนัก โดยรวมแล้ว Poem ค่อนข้างคล้าย FastAPI และนี่เป็นคำชมมากกว่า ผมเคยใช้เว็บเฟรมเวิร์ก Rust มาห้าหกตัว ส่วนใหญ่ต้องยุ่งกับ boilerplate เยอะตั้งแต่การตั้งค่าเริ่มต้น ถ้าอยากได้ผลลัพธ์เร็ว ๆ นี่เป็นปัญหา และในจุดนี้ Poem ก็เข้ากันได้ดี
    actix มีประสิทธิภาพค่อนข้างดี แต่ถ้าไม่ได้ตั้งเป้าการตอบสนองต่ำกว่า 30ms ก็แทบไม่มีเหตุผลตั้งแต่แรกที่จะไปดู actix ถ้าต้องการอะไรแบบ Pydantic ก็มี crate ที่ช่วยได้ในระดับหนึ่ง: https://crates.io/crates/poem-openapi
    [1] https://github.com/poem-web/poem

    • ไม่ใช่แค่ Django แต่ Rails, ASP .NET Core และ เว็บเฟรมเวิร์กแบบ full-featured มีแบตเตอรี่ให้ครบ อื่น ๆ อีกมากมายก็เข้าข่าย
      ประเด็นสำคัญคือมันเป็น “เฟรมเวิร์ก”

  • F# ก็น่าลองดูเหมือนกัน
    มีลูกเล่นด้าน type system แทบทุกอย่างที่ต้องการ และมีเครื่องมือกับฟีเจอร์อำนวยความสะดวกที่จำเป็นด้วย ข้อเสียใหญ่คือการประมวลผล async กับการจัดการหน่วยความจำไม่ได้ดูดเวลาเท่า Rust เลยมีความเสี่ยงที่จะเผลอไปแก้โจทย์ทางธุรกิจจริง ๆ เข้า
    แต่ก็คิดว่าบางช่วงของการต้องรับมือกับ Microsoft อาจมาเติมเต็มช่องว่างนั้นได้

    • F# ไม่ต้องใช้ .NET virtual machine เหรอ? เท่าที่ผมรู้ คนที่เลือก Rust ส่วนใหญ่ชอบตรงที่มันคอมไพล์เป็น native code เสมอ ความคาดเดาได้ และไม่มีความสุ่มของช่วงฟื้นตัวจาก garbage collection
    • ผมลังเลมานานว่าจะลอง F# ดีไหม
      เทียบกับ OCaml หรือ Haskell แล้วเป็นอย่างไร?

  • ความเห็นที่อาจไม่เป็นที่นิยม: Rust เป็นภาษา systems และการทำ งานเว็บ ด้วย Rust คือการเสียแรงเปล่า
    มีภาษาและ ecosystem ที่ดีกว่าสำหรับงานนั้นมาก

    • ขอโต้แย้ง: การพัฒนาเว็บเซอร์วิสด้วย Rust ง่ายพอ ๆ กับทำด้วย Go หรือ Java แถมยังได้ type system ที่ยอดเยี่ยม (sum types!), package manager ที่ยอดเยี่ยม และประสิทธิภาพที่ดีมากด้วย
      ใน Rust ก็ทำ dependency injection เพื่อแชร์ connection pool ได้เหมือนใน Java และเขียนงานเบื้องหลังแบบใช้ thread ได้ง่ายมาก
      Google บอกในงานนำเสนอล่าสุดว่าได้วัดแล้วว่านักพัฒนา Rust ไม่ได้มีประสิทธิภาพหรือผลิตภาพด้อยกว่านักพัฒนา Go [1]
      Rust เป็นภาษาที่ยอดเยี่ยม และไม่มีเหตุผลเลยที่จะจำกัดไว้เฉพาะ systems programming มันทำอะไรได้มากกว่านั้นเยอะ
      [1] https://www.ardanlabs.com/news/2024/rust-at-google/
    • ผมใช้ C/C++ กับเว็บเซิร์ฟเวอร์เสมอ
      มันเบา เรียก C/C++ และโค้ดระดับต่ำได้ง่ายและเร็ว และให้การควบคุมด้าน networking เยอะ โดยไม่ต้องเรียนภาษาเฉพาะสำหรับแอปอย่าง PHP หรือไฟล์คอนฟิก nginx/apache ก็ทำได้แทบทุกอย่างด้วยวิธีทั่วไปและตรงไปตรงมา
      ถ้ามี ทางเลือกฝั่ง Rust ของอะไรแบบ libmicrohttpd ก็คงดี และถ้ามีก็น่าจะใช้
    • เห็นด้วยแทบทั้งหมด แต่ขอชี้ว่าจุดตัดระหว่าง systems programming กับ web programming ไม่ได้ว่างเปล่า
      จุดตัดระหว่าง embedded programming กับ web programming ก็เช่นกัน
      ถึงอย่างนั้น ถ้าเลือก Django, .Net, Go ได้ โดยทั่วไป Rust ก็น่าจะเป็นตัวเลือกที่แย่
    • เป็นการลงทุนด้าน ประสิทธิภาพพลังงาน
    • มันสมเหตุสมผลในระบบที่หน่วยความจำหรือ CPU ถูกจำกัดมากกว่ากรณีทั่วไป
      เว็บเฟรมเวิร์กที่คอมไพล์แบบ static สามารถใช้หน่วยความจำ/CPU ได้ง่าย ๆ แค่ 1/10 ถึง 1/100 เมื่อเทียบกับของอย่าง Rails, Django, Flask

  • Python มี Django, C# มี ASP .NET Core, Ruby มี Rails
    ถ้าอยากให้ Rust เติบโตอย่างมากในงานพัฒนาเว็บจริง ๆ ก็ต้องสร้าง โซลูชันแบบ full-featured
    Rocket อาจใกล้เคียงที่สุด แต่ก็ยังไม่ได้มีแบตเตอรี่ครบเท่าเฟรมเวิร์กที่พูดถึงข้างต้น

  • สิ่งที่ผู้เขียนตามหาคือ ASP.NET Core เวอร์ชัน Rust และนั่นก็ไม่ใช่ปัญหา
    บางคนชอบมีตัวเลือกและประกอบเอง แต่ในหลายสภาพแวดล้อม การมีคนคัดเลือกตัวเลือกแทนให้นั้นสร้างผลิตภาพได้มากกว่าเยอะ
    ปฏิกิริยาแบบ “ถ้าอยากได้ X อีกตัวล่ะ? มันอาจดีกว่า Y% ก็ได้!” นั้นพบได้บ่อย แต่พลาดประเด็นว่าการผสานรวมในตัวมันเองมีคุณค่ามหาศาล ไลบรารีแต่ละตัวอาจดีที่สุดเมื่อดูแยกกัน แต่ถ้ามันเข้ากันไม่ลื่นไหลก็อาจกลายเป็นกองขยะได้
    เหตุผลที่ผมชอบเขียนโปรแกรมด้วย ASP.NET 8 ก็เพราะไม่ต้องกังวลเลยว่า template system จะเข้ากับ authentication, injection, routing ฯลฯ ได้ดีไหม

  • ไม่มีการพูดถึง loco-rs, poem, rocket เหรอ? มีโปรเจกต์ค่อนข้างมากแล้วที่ตั้งเป้าให้ ประสบการณ์แบบมีแบตเตอรี่ให้ครบ
    จุดที่โปรเจกต์พวกนี้ต่างจากเฟรมเวิร์กอย่าง leptos คือมี CLI ที่ช่วยนำทางให้ นั่นก็เป็นสิ่งที่ผมชอบใน Symfony และเป็นส่วนที่ผมนึกถึงว่า “ขี้เกียจ”

  • มี https://shuttle.rs อยู่
    มันไม่ใช่แค่เฟรมเวิร์ก แต่ยังเป็นเครื่องมือที่ช่วยสร้างเว็บ boilerplate รอบ ๆ ให้ด้วย ดังนั้นตามมาตรฐานของผมถือว่าเป็น วิธีแบบขี้เกียจ พอแล้ว

  • บทความนี้พูดถึงประเด็นหลายอย่างพร้อมกัน ดังนั้นตามอุดมคติแล้วควรแยกพูดทีละประเด็น
    ถ้ามี pattern matching ก็ไม่จำเป็นต้องมี router เสมอไป แค่แยก URL แล้ว match ตัวแปรแบบ static/dynamic ตามที่ต้องการก็พอ
    เรื่อง authentication ไม่ว่าใช้ภาษาไหนก็มักจะสร้างเองหรือใช้ SaaS อย่าง Firebase/Auth0 ดังนั้นจึงไม่จำเป็นต้องเป็นปัญหาของภาษาหรือเฟรมเวิร์กเสมอไป
    เครื่องมือ CSS/JS ไม่ค่อยเข้ากับเฟรมเวิร์ก frontend ของ Rust หลายตัวอย่าง Dominator เท่าไร Dominator เขียนด้วย Rust ไม่ใช่ JS และมีแนวทาง styling ของตัวเอง เช่น ผูก style เข้ากับ signal เพื่อให้เปลี่ยนแบบ real-time
    ผมเข้าใจสิ่งที่ผู้เขียนต้องการสื่อ จริง ๆ แล้วผมเองก็เคยวนไปวนมาหลายครั้งเพื่อแก้หลายข้อในบทความนี้ และมันก็เจ็บปวดอยู่เหมือนกัน เช่น https://github.com/dakom/dominator-workers-fluent-auth จัดการงานหลายอย่างที่กล่าวถึงตรงนี้บนเฟรมเวิร์ก Cloudflare Workers และยังเพิ่มสิ่งที่อยากได้เพิ่มเติมอย่าง localization แบบใช้ Fluent ด้วย
    ถ้ามี full framework แบบ batteries included ที่ทำให้ทุกอย่างได้ก็คงดี แต่โปรเจกต์จริงจำนวนมากคงอยากเปลี่ยนการตัดสินใจเชิงกำหนดเหล่านั้น แล้วเลือกทางลงมือ implement เอง Rust โตพอแล้วแม้ในงานเว็บ frontend และถ้ารู้ว่าต้องดูตรงไหน ก็จัดการได้ทั้งหมดด้วย wasm-bindgen และเครื่องมืออื่น ๆ

    • การบอกว่า “ถ้ามี pattern matching ก็ไม่ต้องมี router” ยังไม่พอ
      เว็บเฟรมเวิร์กให้สิ่งต่าง ๆ มากกว่านั้นมาก เช่น URL redirection, การจัดการ trailing slash, การจัดการ URL ที่แยกแยะตัวพิมพ์ใหญ่เล็ก, การ match ด้วย regular expression ที่ซับซ้อน ฯลฯ
      การบอกว่า “authentication ไม่ว่าใช้ภาษาไหนก็มักจะสร้างเองหรือใช้ SaaS” นั้นไม่ถูกต้อง Django, Laravel, Rails และภาษาที่มีแนวทาง batteries included มี การจัดการ authentication ที่ดีมาก โดยส่วนตัวผมคิดว่าสำหรับองค์กร 90% การฝาก authentication ไว้กับผู้ให้บริการภายนอกเป็นความผิดพลาดอย่างใหญ่หลวง
      การที่นักพัฒนาเว็บที่ชำนาญสามารถทำ CRUD พื้นฐาน 10 ตัวให้รันขึ้นมาได้ในวันเดียวโดยไม่ต้องรับมือกับความซับซ้อนที่ไม่จำเป็น เป็นข้อได้เปรียบที่ยอดเยี่ยมจริง ๆ สำหรับธุรกิจขนาดเล็ก

  • ถ้าบทความนี้ไม่ได้โฟกัสที่ Rust แต่เป็น C++ สิ่งที่พูดโดยรวมจะยังใช้ได้เหมือนกันไหม?
    มันเป็น ภาษาเชิงระบบ ที่มีอุปสรรคในการเริ่มต้นสูง มีเวลา compile และเป็นภาษาที่ยังไม่ได้ถูกใช้อย่างแพร่หลายถึง 10 ปี การคาดหวังให้มันแข่งขันด้านความเข้าถึงง่ายกับสิ่งอย่าง Rails นั้นคงฝืนเกินไป