การผงาดของ Hybrid PHP: การผสาน PHP เข้ากับ Go และ Rust

 (yekdeveloper.com)
14 คะแนน โดย GN⁺ 2025-09-02 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • ช่วงหลังมานี้ แนวทางแบบไฮบริดที่ผสาน Go และ Rust เป็นภาษาส่วนขยายภายใน สถาปัตยกรรม PHP monolith กำลังได้รับความสนใจ
  • ก่อนหน้านี้ การผสานระหว่าง Go microservices กับ PHP 8.3 monolith ช่วยสร้างสมดุลระหว่าง ประสิทธิภาพการพัฒนา และ สมรรถนะสูง ได้อย่างลงตัว
  • ตาม กฎของพาเรโต (80% ของทราฟฟิกกระจุกอยู่ที่ 20% ของ API) การปรับแต่ง endpoint จุดร้อนเป็นสิ่งจำเป็น และในอดีตมักรับมือด้วย caching หรือ แยกบริการ Go ออกไป แต่สิ่งนี้ก็เพิ่มความซับซ้อน
  • ช่วงหลัง การเติบโตของ ecosystem ของ PHP ทำให้เกิดเทคนิคอย่าง FFI, Rust extension และ Go extension (FrankenPHP) ซึ่งช่วยยกระดับประสิทธิภาพภายใน monolith ได้อย่างมาก
  • Rust extension มอบทั้งความปลอดภัยด้านหน่วยความจำและความเร็ว ขณะที่ FrankenPHP แสดงให้เห็นถึง ประสิทธิภาพที่เพิ่มขึ้นมากกว่า 4 เท่า ผ่าน worker mode และส่วนขยายที่อิงกับ Go
  • โดยไม่ต้องแบกรับ ต้นทุนและความเสี่ยงของการเขียนใหม่ทั้งหมด เป็น Go/Rust แนวทาง Hybrid PHP ช่วยให้ได้ทั้ง ประสิทธิภาพการพัฒนาและความเร็ว

ภูมิหลังและสถาปัตยกรรมเดิม

  • เดิมทีใช้ แอปพลิเคชัน DDD monolith (mother) เป็นศูนย์กลาง และพัฒนา microservice ที่อิงกับ Go (children) แยกออกมาต่างหากเพื่อปรับแต่งฟังก์ชันเฉพาะบางส่วน
  • Go microservices รับหน้าที่ ประมวลผลทราฟฟิกสมรรถนะสูง ขณะที่ PHP 8.3 monolith มอบ การพัฒนาฟีเจอร์ที่รวดเร็วและความเชื่อถือได้ในการ deploy ในบริบทของทีม backend ขนาดเล็ก
  • โครงสร้างเช่นนี้เป็นจุดสมดุลที่ช่วยให้ได้ทั้ง ความเร็ว เสถียรภาพ และผลิตภาพ

คอขวดด้านประสิทธิภาพและวิธีรับมือแบบเดิม

  • มักพบ หลักการพาเรโต ที่ว่า 80% ของทราฟฟิกกระจุกตัวอยู่ที่ 20% ของ API endpoint
  • สำหรับช่วง 20% ที่มีความสำคัญด้านประสิทธิภาพสูงสุด จึงมีการใช้หลายวิธี เช่น การเขียนโค้ดปรับแต่ง, เพิ่มชั้น caching, และ แยกเป็น Go microservice
  • แต่ก็มีข้อจำกัดในด้านความซับซ้อนและภาระการดูแลระบบ

ตัวเลือกแบบไฮบริดใน ecosystem PHP ยุคใหม่

  • ปัจจุบันมีเทคโนโลยีที่ช่วย ปรับปรุงประสิทธิภาพได้โดยตรงภายใน PHP monolith เพิ่มขึ้น

  • 1. FFI (Foreign Function Interface)

    • ความสามารถ FFI ของ PHP ทำให้สามารถเรียก โค้ด C ได้โดยตรงจาก PHP
    • จึงสามารถนำ logic ระดับระบบหรือส่วนที่ performance-critical มาใช้งานภายในโปรเจกต์ PHP ได้
    • อย่างไรก็ตาม ควรใช้เฉพาะในสถานการณ์ที่เหมาะสม โดยคำนึงถึง ต้นทุนของ context switching
    โฆษณา

  • 2. ส่วนขยายที่อิงกับ Rust

    • สามารถพัฒนา PHP extension ด้วย Rust (หรือ Zig) ได้
    • การ offload ส่วนที่มีภาระงานสูงไปยัง Rust extension ซึ่งมีทั้ง ความปลอดภัยของหน่วยความจำ และ สมรรถนะจากการคอมไพล์ ช่วยให้ได้ทั้ง ความน่าเชื่อถือและความเร็วสูง

  • 3. ส่วนขยายที่อิงกับ Go: FrankenPHP

    • หลังเปลี่ยนมาใช้ FrankenPHP เมื่อทำงานใน worker mode พบว่า เร็วขึ้นมากกว่า 4 เท่า เมื่อเทียบกับเดิม
    • ในรีลีสล่าสุด ยังสามารถ เขียน PHP extension ด้วย Go ได้อีกด้วย
    • ทำให้สามารถใช้ สมรรถนะด้าน API ของ Go ได้โดยตรงภายใน PHP monolith และ ผสานผลิตภาพกับความเร็วได้โดยไม่ต้องแยกภาษาออกจากกัน
โฆษณา

เหตุผลที่ไม่ย้ายทั้งหมดไปเป็น Go หรือ Rust

  • ต้นทุนและความเสี่ยงของการเขียนใหม่ทั้งระบบ สูง
    • การเปลี่ยนแอปพลิเคชันที่มีขนาดใหญ่และเสถียรอยู่แล้วทั้งหมดไปเป็น Go หรือ Rust มีทั้งความเสี่ยงและการใช้ทรัพยากรสูง
  • PHP เองก็ยังมีจุดแข็งอยู่
    • สำหรับงานส่วนใหญ่ ความรวดเร็วในการพัฒนา ecosystem ที่เป็นมิตร และความเร็วที่เพียงพอของ PHP ยังถือว่าแข่งขันได้
    • หากนำ Go หรือ Rust มาใช้แบบไฮบริดเฉพาะในบางส่วนที่ต้องการ ขีดจำกัดด้านประสิทธิภาพอย่างแท้จริง ก็สามารถลดความจำเป็นในการย้ายทั้งระบบได้

บทสรุป: คุณค่าของ Hybrid PHP

  • ecosystem PHP ยุคใหม่ มอบทั้ง ผลิตภาพในการพัฒนาที่รวดเร็ว และตัวเลือกในการเชื่อมต่อส่วนขยายสมรรถนะสูงอย่าง C, Rust และ Go
  • โครงสร้างแบบไฮบริดเช่นนี้ช่วยให้ได้ทั้ง ความเร็วและผลิตภาพ
  • เป็นการนำเสนอ paradigm สถาปัตยกรรมแบบใหม่ที่ยังคงการพัฒนาโดยมี PHP เป็นศูนย์กลาง พร้อม ขยายด้วยภาษาอื่นแบบเลือกใช้ตามความจำเป็น ได้

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

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

 
naearu 2025-09-02

ดูเหมือนว่ามันกำลังเปลี่ยนไปในทำนองเดียวกับที่ JavaScript เปลี่ยนไปนะ
 
skageektp 2025-09-02

ถ้าเป็น nodejs กับ rust ก็ว่าไปอย่าง;; สำหรับผม PHP ที่ต้องใช้ $ ตลอดมันเลยดูพิมพ์โค้ดลำบากนิดหน่อย คนที่ใช้คล่อง ๆ กันนี่โดยมากไม่ได้รู้สึกว่าไม่สะดวกเท่าไหร่ใช่ไหมครับ?
 
proinworks 2025-09-03

ถึงจะรู้สึกไม่สะดวก แต่พอใช้ไปสักพักก็จะคุ้นเคยได้อย่างรวดเร็วไม่ใช่หรือ?
มนุษย์เป็นสัตว์ที่ปรับตัวเก่ง
 
nemorize 2025-09-02

ผมไม่เคยรู้สึกไม่สบายใจกับการใช้เครื่องหมาย $ เลยสักครั้ง จะมีก็แค่รู้สึกขัดใจกับแนวคิดเรื่องตัวแปร/ฟังก์ชันของ PHP เองมากกว่า

บอกว่าใช้ไม่ได้เพราะอึดอัดกับเครื่องหมายดอลลาร์ หรือ ~~พวกที่ใช้เครื่องหมายดอลลาร์เลยหาเงินเก่ง, ไม่ใช่ดอลลาร์สหรัฐแต่เป็นดอลลาร์ซิมบับเวเลยหาได้ไม่มาก~~ อะไรทำนองนั้น เดิมทีก็เป็นแค่มุกขำ ๆ ไม่ใช่เหรอ...
 
GN⁺ 2025-09-02
ความเห็นบน Hacker News

  • ฉันเริ่มรู้สึกไม่ชอบเฟรมเวิร์กแบบอเนกประสงค์มากขึ้นเรื่อย ๆ (เช่น Spring, Laravel, Phoenix ฯลฯ) ตอนเริ่มต้นมันทำงานได้ดีมากและเพิ่มประสิทธิภาพสูง แต่พอเป็นโปรเจ็กต์เลกาซี ปัญหาเดิม ๆ ก็มักจะวนกลับมาเสมอ แต่ละโปรเจ็กต์มีสภาพแวดล้อมอินฟราหรือเงื่อนไขทางธุรกิจต่างกัน จึงทำตามแนวทางที่เฟรมเวิร์กแนะนำได้ไม่หมด สุดท้ายก็ต้องมีแพตช์เพิ่มหรือใช้ลูกเล่นพึ่งพาไลบรารีตามจุดต่าง ๆ มากขึ้นเรื่อย ๆ พอจะอัปเกรดภาษาใหม่หรือเวอร์ชันใหม่ ส่วนที่คัสตอมเหล่านี้ก็มักพังหมด สุดท้ายไม่มีใครอัปเดต จนกระทั่งอินฟราไม่สามารถรันมันได้อีกแล้วค่อยย้ายระบบกันแบบน้ำตาซึม วิธีประกอบหลายไลบรารีแล้วสร้าง abstraction เองอาจใช้เวลามากกว่า แต่สามารถอัปเกรดได้อย่างยืดหยุ่นเป็นส่วน ๆ และเปลี่ยนทิศทางได้เร็ว ฉันเลยมองว่า ecosystem ของ Go เหมาะมากในแง่นี้ ตอนแรกไม่คุ้น แต่ตอนนี้กลับชอบวิธีนี้มากกว่า

    • สำหรับเว็บเฟรมเวิร์ก ฉันรู้สึกแรงมากว่ามันเป็นแนว "ช่วงแรกดีมาก แต่พอถึงจุดหนึ่งก็เริ่มอึดอัด" ตอนทำแอปง่าย ๆ อะไรแบบ Rails ที่ว่า "สร้างบล็อกได้ใน 15 นาที" มันดูเหมือนเวทมนตร์ แต่พอระบบซับซ้อนขึ้น เฟรมเวิร์กกลับกลายเป็นอุปสรรค ส่วนตัวฉันสบายใจกับการตั้งค่า HTTP ระดับ "กลาง ๆ" แบบ Express + Node.js หรือ Vert.x + Java มากกว่า

    • ใน Python อาจแบ่งได้เป็น microframework (สาย Flask) กับ macroframework (Django) ฉันเลือก Django ตลอด เพราะ Flask แทบไม่เสนออะไรให้เลย ทำให้ทุกโปรเจ็กต์กลายเป็น snowflake ที่แต่งขึ้นใหม่ทุกครั้ง มันทำให้เกิด decision fatigue ว่าจะเลือกอะไรดีจากตัวเลือกเป็นสิบ ๆ อย่าง เช่น auth, template, cookie, email ฯลฯ โดยเฉพาะไลบรารีเหล่านี้จำนวนมากมักพัฒนาโดยคนเดียว คุณภาพด้านการดูแลรักษา/ความปลอดภัยจึงไม่สม่ำเสมอ ตรงกันข้าม Django ทำให้โปรเจ็กต์ส่วนใหญ่หน้าตาคล้ายกัน และให้ฟีเจอร์พื้นฐานแทบทั้งหมดมาใช้งานได้ทันที ที่ฉันจะใช้ไลบรารีเสริมก็เฉพาะตอนมีความต้องการพิเศษเท่านั้น ส่วนที่มีการดูแลและตรวจสอบโดยตรงมีเยอะ จึงรู้สึกว่าความน่าเชื่อถือของโค้ดและความปลอดภัยสูงกว่า

    • เหตุผลที่ Go ไม่มีเฟรมเวิร์กขนาดยักษ์ เป็นเพราะ type system ของภาษายังไม่สมบูรณ์พอมาก การสร้างไลบรารีซับซ้อนที่ทำงานร่วมกันได้ดีจึงทำได้ลำบาก ฉันรออยู่ตั้ง 9 ปีกว่าจะใช้ generics ได้ แล้วถึงได้สร้าง database toolkit สำหรับ Go เป็นครั้งแรก แม้มันจะประสบความสำเร็จ แต่ก็ยังรู้สึกว่าสมัยทำสิ่งนี้ใน Java นั้นดีกว่า ถ้าสามารถ map/filter/reduce result type ไปเป็น generic type อื่นได้ โลกมันจะต่างไปเลย ถ้ามีแค่ความสามารถในการระบุ union type ก็แทบไม่ต้องใช้ any แล้ว แค่รองรับ overloading ได้ โค้ดก็น่าจะสะอาดขึ้นมาก แต่ type system ของ Go ยังต้องพัฒนาอีก

    • ในสายงานของฉัน มีแค่ Go กับ Rust ที่มีประโยชน์ ฉันไม่ค่อยเข้ากับวัฒนธรรมของเฟรมเวิร์กที่มีแนวทางตายตัวแรง ๆ ฉันคิดว่า Rails, Laravel, Django ยอดเยี่ยมมากเมื่อสถานการณ์ชัดเจนว่าเป็นงาน CRUD บนฐานข้อมูลเชิงสัมพันธ์

    • ตลอด 5 ปีที่ผ่านมา ฉันใช้แต่คอมโพเนนต์ที่เข้ากันได้กับ PSR (Php Standards Recommendation) โดยไม่ใช้เฟรมเวิร์กเลย เหตุผลคือเฟรมเวิร์กใหญ่ ๆ พอใช้ไปนาน ๆ แล้วสุดท้ายมันจะไม่พอดี มันมีข้อจำกัดเยอะ และดูแลกับอัปเดตยากมาก ไม่ว่าจะเป็นโปรเจ็กต์องค์กรขนาดใหญ่หรือบริการส่วนตัว ฉันรู้สึกว่าสถาปัตยกรรมที่เน้นคอมโพเนนต์ PSR ดีกว่า

  • ฉันเข้าใจว่าถ้าเป็นโค้ดเบสขนาดใหญ่จนเขียนใหม่ทั้งก้อนไม่ได้ แนวทาง hybrid (ใช้ C, Rust, Go หรือภาษาสายประสิทธิภาพควบคู่กับ PHP) ก็อาจมีเหตุผล แต่ถ้าไม่จำเป็นจริง ๆ จากประสบการณ์ของฉัน C# API ให้ทั้งความเร็วในการพัฒนาและประสิทธิภาพตอนรันได้พร้อมกัน แทบไม่เคยต้องไปถึง C++ หรือ Rust เลย PHP ก็ดี แต่ยังไม่มีอะไรอย่าง typed array ตัวอย่างเช่น มันเป็นภาษาที่แม้จะมีสตริงปะปนมาในอาร์เรย์วันที่ก็ไม่ปฏิเสธ

    • ฉันใช้ C# มานานและมีประสบการณ์กับเว็บ/API framework หลายตัว ถ้าลองขุดดูดี ๆ PHP มีฟังก์ชัน built-in พื้นฐานสำหรับเว็บเยอะมาก ซึ่งดีมาก มันก็มีข้อเสีย แต่ถ้าต้องทำอะไรให้เสร็จเร็ว ในความเห็นฉัน PHP คือผู้ชนะ

    • จริงที่ PHP ยอมให้มี type ผิดในอาร์เรย์ได้ (เช่น มีสตริงในอาร์เรย์วันที่) บางครั้งจึงเกิดพฤติกรรมประหลาดหรือบั๊กโผล่มาได้ เมื่อไม่นานมานี้ฉันเจอบั๊กจาก json_decode() ที่เมื่อ decode แล้ว ถ้า key เป็นตัวเลขจะเข้ามาเป็น int แต่ถ้าไม่ใช่จะเป็น string ทำให้ชนิดของ key ปะปนกัน รายละเอียดพวกนี้อาจแปลกประหลาดอยู่บ้าง แต่ถึงอย่างนั้น PHP ก็ยังเป็นภาษาแฟรงเกนสไตน์ที่มีเสน่ห์มากจริง ๆ

    • ในทางปฏิบัติ ถ้าใช้ static analyzer ก็กัน type error แบบนั้นได้อยู่แล้ว และมีโอกาสสูงที่ PHP จะรองรับ generics ในเร็ว ๆ นี้ ดูข่าวที่เกี่ยวข้องได้ใน บล็อก thephp.foundation

    • ฉันเป็นคนเขียนบทความ ขอบคุณที่อ่าน จริง ๆ ไม่จำเป็นต้องเขียนใหม่ทั้งระบบเลย ถ้ารัน PHP บน runtime แบบ worker-based อย่าง swoole หรือ frankenphp ก็ได้ประสิทธิภาพระดับ Node ประเด็นเรื่อง typed array หรือ generics นั้น static analyzer อย่าง phpstan รองรับอยู่แล้ว และถ้าใช้ type annotation ก็ช่วยเพิ่ม type safety ได้ชัดเจน

    • ตั้งแต่ VB6 เลิกซัพพอร์ตมา ฉันก็ตัดสินใจว่าจะไม่ใช้ภาษาในฝั่ง Microsoft อีกเลย มีแต่ภาษาโอเพนซอร์สเท่านั้นที่ดีต่อสุขภาพจิต

  • ตอนฉันเข้าทำงานที่ {{company}} ทั้งองค์กรยังอยู่บน PHP 5.4 และตอนนั้นกระแสไม่ชอบ PHP มีมากเหลือเกิน แต่พอได้ลอง PHP สมัยใหม่ ฉันกลับรู้สึกว่าในจังหวะที่เรากำลังจะออกจาก PHP กันอยู่ตอนปลายทางนี้ การย้ายครั้งนี้กลับดูเหมือนเป็น "ถอยหลัง" มากกว่า ทุกคนยังตัดสิน PHP จากยุค 5.x อยู่ แต่ตอนนี้มันต่างไปโดยสิ้นเชิง

    • ฉันมองต่างออกไปนิดหนึ่ง ถ้าดูตลาดแรงงานยังไงก็ยังมีภาพจำเกี่ยวกับ PHP (ไม่ว่าดีหรือร้าย) ซึ่งจำกัดการจ้างนักพัฒนาชั้นดี ถึงในเชิงเทคนิค PHP จะไม่ได้แย่อย่างเมื่อก่อนแล้ว แต่ในแง่ภาพลักษณ์องค์กร การออกจาก PHP ก็ยังมีความหมายอยู่

    • ฉันไม่เห็นด้วยกับคำว่า "PHP ตอนนี้ awesome แล้ว" มันดีขึ้นแน่ ๆ แต่คำว่า awesome ดูเกินไปหน่อย

    • PHP กำลังดีขึ้นเรื่อย ๆ ฉันคิดว่าอีกไม่นานคงต้องลองดูให้ลึกกว่านี้

    • เราก็มีความกังวลแบบเดียวกันเมื่อ 4 ปีก่อน และสุดท้ายก็ตัดสินใจอัปเกรดเป็น PHP 8 แล้วใช้งานต่อ สำหรับทีมเรา การตัดสินใจนั้นเข้าท่ามากในช่วงหลายปีที่ผ่านมา

  • Pasir คล้าย frankenphp แต่ทำบน Rust ดูมีอนาคตมาก แต่ยังอยู่ช่วงเริ่มต้นของการพัฒนา

  • Pasir github Pasir ใช้การแปลง Zend API binding เป็น Rust

  • Zend API Rust binding ยังมีการทดลองน่าสนใจอย่าง ngx-php ด้วย ซึ่งเป็นโครงสร้างที่ฝัง PHP ผ่าน Zend API ไว้ในไบนารีของ nginx

  • ngx-php github workerman ใช้ backend แบบ hybrid ที่อิงกับ asio เพื่อสร้าง runtime ที่เร็วมาก

  • workerman github

    • สงสัยว่า Pasir, frankenphp และตัวอื่น ๆ แบบนี้รองรับโมดูล PHP เดิมด้วยหรือเปล่า

    • ขอบคุณสำหรับคำแนะนำ ดูเท่มากจริง ๆ แต่ก็เห็นด้วยตามที่บอกว่ายังห่างจากระดับ production อยู่มาก สุดท้ายเราเลือก frankenphp ที่ได้รับการสนับสนุนจาก php foundation

  • หลายครั้งความซับซ้อนด้านการดีบักหรือการบำรุงรักษามักถูกมองข้าม แต่ถ้ามีทางเลือก ฉันคิดว่าควรหลีกเลี่ยงการเลือกการผสมแบบนี้

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

  • ฉันก็เคยเขียนแอปใหม่จาก PHP ไปเป็น Go และมันเป็นการลงทุนที่คุ้มค่าสำหรับบริษัท ฉันลดโค้ด PHP 20,000 บรรทัดให้เหลือ Go 4,000 บรรทัด และเพิ่มประสิทธิภาพได้มาก ถ้าเป็นบริษัทสาย PHP ฉันแนะนำมากให้วางแผนเขียนใหม่ครั้งใหญ่ แล้วทำควบคู่กับการเพิ่ม test (ซึ่งใน Go ง่ายกว่า) ฉันคิดว่าดีกว่าต้องมาทนทุกข์กับการดูแลหลายภาษาอย่าง Rust/PHP หรือ Go/PHP

    • อยากรู้ว่าการย้ายจาก PHP ไป Go ทำให้จำนวนบรรทัดโค้ดลดลงได้ขนาดนั้นได้อย่างไร ฉันมองว่า Go เป็นภาษาที่ verbose มาก ประสบการณ์ของฉันคือ PHP อยู่ระดับกลาง ๆ ส่วน Haskell กระชับที่สุด และ Java/Go กลับยาวกว่าเพราะเรื่องอย่างการจัดการ error

    • ฉันยังนึกไม่ออกว่าการย้ายจาก PHP ไป Go แล้วจำนวนบรรทัดจะลดลง 5 เท่าได้อย่างไร PHP มี syntax ย่อหลากหลาย แต่ใน Go รู้สึกว่าแทบไม่มีเลย

    • ฉันคิดว่าจุดสำคัญเสมอคือ ประสิทธิภาพและความคุ้มค่าที่ดีขึ้นจากการเขียนใหม่ เกิดจาก "ตัวภาษา" หรือจาก "การปรับปรุงสถาปัตยกรรมที่ใส่เข้าไปใหม่"

    • ตอนจะเขียนใหม่เป็น Go ฉันคิดว่าแค่ pattern if err != nil ก็คงทำให้โค้ดบวมขึ้นอีก 10 เท่าแล้ว ฉันเคยย้ายไป Python ซึ่ง Python เองก็ทำให้โค้ดยาวขึ้นมากเหมือนกัน และพวก pattern อย่าง dependency injection ก็ยุ่งยากเวลาเทสต์

    • ฉันไม่ได้แนะนำให้เขียนใหม่เสมอไป (แม้ฉันจะเคยทำสำเร็จมาแล้วสองครั้ง แต่ก็คงไม่เลือกเอง) ทุกวันนี้ PHP runtime เร็วมากจริง ๆ จึงคุ้มค่าที่จะลอง โดยเฉพาะถ้าใช้ประโยชน์จาก task cache ของ swoole เต็มที่ บางกรณีก็เร็วพอ ๆ กับ Go ได้เลย (แนะนำให้ดู benchmark)

  • บางครั้งฉันคิดว่าเราควรกลับไปยึดพื้นฐานจริง ๆ: พิกเซล, ข้อมูล, latency/bandwidth ท้ายที่สุดแล้วเว็บก็คือ "ปัญหาการเพิ่มประสิทธิภาพเพื่อแสดงพิกเซลที่ถูกต้องให้ตาคนเห็นได้เร็วพอ ภายใต้ทรัพยากรเครือข่ายที่มี" ควรเข้าหามันด้วยคำถามอย่าง "พิกเซลอะไรที่ผู้ใช้กำลังจะเห็น", "ต้องใช้ข้อมูลอะไรเพื่อวาดมัน", "มีข้อมูลที่น่าจะใช้ต่อไหม จะ prefetch ไว้ก่อนหรือเปล่า"

    • ฉันกำลังทำ alumina-ui ด้วย egui สำหรับ WASM โดยไม่ต้องรู้เรื่องเว็บที่ซับซ้อนอย่าง HTML, JavaScript, CSS ก็แค่มีแคนวาสขนาดพอดีกับเบราว์เซอร์หนึ่งอัน แล้วเรนเดอร์ผ่าน WebGL ตรง ๆ ได้เลย มันสะดวกมากที่ได้สร้างกราฟิกแบบเร่งความเร็วด้วย GL อย่างรวดเร็วด้วยภาษาที่ฉันชอบ ฉันชอบ WASM/WebGL มากเพราะ abstraction แบบนี้

    • การโฟกัสแค่พิกเซลที่ผู้ใช้เห็นเป็นมุมมองที่แคบเกินไป ในโปรเจ็กต์ซอฟต์แวร์ เราต้องเพิ่มประสิทธิภาพไม่ใช่แค่ UX ทันทีตรงหน้า แต่รวมถึงเวลาพัฒนาด้วย ความหน่วงก่อนหน้าจอแรกจะโผล่ กับเวลาที่ใช้พัฒนาจริง ไม่ได้แปรผันตรงกันเลย

  • FrankenPHP ดูน่าสนใจมาก แต่ในทางปฏิบัติก็มีความแปลกอยู่พอสมควร ไม่มีใครใช้ PHP โดยไม่มีโมดูล PHP หรอก แต่รายชื่อโมดูล PHP ที่ FrankenPHP รองรับก็ไม่ชัดเจน และก็ไม่แน่ใจว่าฉันจะ build โมดูลแยกที่ต้องการแล้วเพิ่มเข้าไปได้ไหม มันผูกกับ Caddy ค่อนข้างแน่น แต่ฉันไม่คุ้นกับเว็บเซิร์ฟเวอร์นี้และชอบ nginx มากกว่า เพราะไม่มีคู่มือ ฉันจึงไม่รู้ว่ามันใช้แทน php-fpm บน nginx ได้หรือไม่ แถม Docker image ของ Caddy หรือ FrankenPHP ก็เหมือนตั้งต้นจากกรณีใช้ใบรับรอง Let's Encrypt อย่างเดียว ถ้าจะตั้ง SSL เองหรือจะรันแบบ HTTP ล้วน ๆ มันชวนงงมาก

    • เรื่องโมดูล PHP ปกติก็ build เองใน Dockerfile นั่นแหละ เช่น ถ้าจะเพิ่มโมดูล pgsql ก็แค่ติดตั้ง dependency ด้วย apt, ติดตั้งโมดูลด้วย docker-php-ext-install, แล้วค่อยลบ/ทำความสะอาด dependency ตอนจบ ส่วนการตั้งค่า HTTP ก็แค่เปิดพอร์ต 80 ตรง ๆ ใน Caddyfile

    • static build จะรวมโมดูลหลักของ PHP หลายสิบตัวมาให้โดยปริยาย ดูรายชื่อโมดูลและสคริปต์ build ได้ที่ frankenphp build-static.sh

  • อยากรู้ว่าต้องเป็น workload แบบไหนถึงจำเป็นต้องใช้ language extension อย่าง C/Rust/Go จริง ๆ เข้าใจว่ามันมีกรณีใช้อยู่ แต่ก็อยากรู้มากขึ้นว่าทำไมต้องเพิ่มความซับซ้อนระดับนี้เข้าไปในสแตก และเหตุใดวิธีอื่นถึงแก้ไม่ได้

  • สิ่งที่ฉันเกลียดที่สุดใน PHP คือทุก HTTP request จะต้อง bootstrap แอปทั้งก้อนใหม่หนึ่งรอบ และมีการ autoload กับประเมิน config ใหม่ทุกครั้ง แน่นอนว่ามี cache อยู่บ้าง แต่เมื่อเทียบกับแบบ Go ที่เอนจินลอยอยู่ตลอด มันก็ยังฟังไม่สมเหตุสมผลอยู่ดี

    • จริง ๆ แล้วมีไลบรารีที่เอกสารค่อนข้างดีอยู่หลายตัว ซึ่งช่วยให้รันเซิร์ฟเวอร์แบบ standalone ด้วย PHP ล้วนได้ และใช้ใน production ก็ได้จริง ประสิทธิภาพ JIT ของ PHP ก็น่าประทับใจพอตัว

  • reactphp.org

  • php.net ev module

  • pecl-event

  • workerman.net

    • ไม่จำเป็นต้องทำแบบนั้นเสมอไป (รันใหม่ทุก request) PHP runtime บางตัวรองรับให้การรันสคริปต์หนึ่งครั้งจัดการ HTTP request ได้หลายรายการ

  • เอกสาร frankenphp worker

    • ฉันกลับคิดว่านี่คือข้อดีที่สุดของ PHP เลย มันทำให้ scale out ง่ายมหาศาล

    • ฉันกลับชอบโครงสร้างแบบนี้ มันบังคับให้สถานะภายในระบบมีน้อยโดยธรรมชาติ (ในระดับหนึ่ง)

    • คุณพูดถูก วิธีนี้แย่มากจริง ๆ ยิ่งเวลาที่ PHP ถูกใช้เป็น template language ของตัวเองยิ่งเป็นปัญหา template engine แบบคัสตอมหรือ runtime แบบรันค้างเพื่อแก้เรื่องนี้ สุดท้ายก็แค่ "แต่งหน้าศพหมู" ทางที่ดีควรเลือกภาษาที่ไม่ได้เริ่มต้นมาจากชื่อ Personal HomePage ตั้งแต่แรก