React คือฟูลสแตกเฟรมเวิร์ก (หรือกำลังจะเป็น)

• React ที่เพิ่ม Server Components และ Server Actions กำลังพัฒนาไปเป็นฟูลสแตกเฟรมเวิร์ก

สงครามเฟรมเวิร์กเริ่มต้นในปี 2010

• สงครามเฟรมเวิร์กที่เริ่มจาก Backbone, Knockout, Ember ในปี 2010 มี Angular และ React ตามมาอย่างรวดเร็ว และไม่มีใครคาดเดาผลลัพธ์ได้
• เป็นเวลานานที่แอปพลิเคชัน JavaScript แบบ client-side rendering (CSR) ครองตลาด
• แอปพลิเคชันเหล่านี้เรียกอีกอย่างว่า single-page application (SPA) และโดยทั่วไปประกอบด้วยไฟล์ HTML ขนาดเล็กกับไฟล์ JavaScript ขนาดใหญ่
• นั่นเป็นเช่นนั้นก่อนที่จะมีการนำ code splitting มาใช้

การแยกส่วนระหว่างฟรอนต์เอนด์และแบ็กเอนด์

• ในช่วงเวลานี้ การพัฒนาฟรอนต์เอนด์ถูกครอบงำโดยเฟรมเวิร์กและไลบรารี JavaScript หลากหลายตัว
• โดยทั่วไปแบ็กเอนด์ไม่ได้ผูกกับภาษาใดภาษาหนึ่ง และ REST ก็กลายเป็นมาตรฐานของการสื่อสารผ่าน API
• ในฐานะนักพัฒนาเว็บฟรีแลนซ์ ฉันทำงานร่วมกับแบ็กเอนด์ .NET, Java, Python, PHP เป็นหลัก
• ฉันเห็น TypeScript/JavaScript ฝั่งแบ็กเอนด์เฉพาะในโปรเจ็กต์ greenfield หรือโปรเจ็กต์เล็กที่สามารถควบคุมแบ็กเอนด์ได้เท่านั้น
• แต่การเติบโตของ React แบบฟูลสแตกอาจทำให้สิ่งนี้เปลี่ยนไป
• น่าสนใจที่นักพัฒนารับรู้ช่วงเวลาระหว่างปี 2010 ถึง 2020 ต่างกันตามช่วงเวลาที่เริ่มต้นอาชีพ
• นักพัฒนาที่เริ่มต้นก่อนปี 2010 เคยอยู่ในสภาพแวดล้อมแบบ server-side rendering (SSR) และดูจะสบายใจกับการหวนกลับไปใช้เทคโนโลยีฝั่งเซิร์ฟเวอร์ในช่วงหลังมากกว่า
• ในทางกลับกัน หลายคนแทบทำงานกับแอปพลิเคชันแบบ client-side rendering (CSR) ที่ใช้ REST API อย่างเดียวมาตลอดเกือบ 10 ปี
• ตอนนี้พวกเขาไม่รู้ว่าควรรับโลกใหม่ของ React แบบฟูลสแตกอย่างไร

TypeScript ก้าวขึ้นเป็นมาตรฐานอุตสาหกรรม

• ในช่วงไม่กี่ปีที่ผ่านมา TypeScript ก้าวขึ้นมาเป็นมาตรฐานของอุตสาหกรรม
• TypeScript มอบภาษาโปรแกรมที่มีระบบ type และทรงพลังให้แก่นักพัฒนาฟรอนต์เอนด์
• เมื่อนักพัฒนายอมรับ TypeScript แล้ว ก็เหมือนจะย้อนกลับไม่ได้อีก
• เป็นเรื่องน่าสนใจที่การเปลี่ยนแปลงเล็กน้อยในโค้ดสามารถส่งผลกระทบใหญ่หลวงได้ทั้งต่อบุคคลและอุตสาหกรรมโดยรวม

ความยากของ TypeScript กับ REST

• ผลกระทบของ TypeScript ต่อ REST เต็มไปด้วยวิธีแก้ปัญหาเฉพาะหน้า
• OpenAPI (เดิมคือ Swagger) มีไว้เพื่อการทำเอกสาร REST API แต่ตอนนี้ถูกใช้เป็นหลักเพื่อสร้าง type API interface
• แม้จะสามารถสร้าง type interface ที่สมบูรณ์ในสถาปัตยกรรม client-server ได้ แต่ก็ยังมีหลายโปรเจ็กต์ที่ล้มเหลวในการทำให้ถูกต้องตั้งแต่แรก

• บันทึกส่วนตัว: "อาจมีนักพัฒนาที่มีประสบการณ์ที่ดีกับสถาปัตยกรรมที่อิง OpenAPI แต่เสียดายที่ผู้เขียนไม่ใช่หนึ่งในนั้น"

TypeScript เปลี่ยนบรรยากาศ

• ค่อนข้างน่าสนใจที่จะเห็นว่า TypeScript เปลี่ยนบรรยากาศตรงนี้อย่างไร
• ด้านหนึ่ง SPA ที่ไม่มี type และใช้ REST (โดยมี OpenAPI เพื่อจุดประสงค์ด้านเอกสาร) ดูเหมือนจะ "โอเค"
• แต่เมื่อ TypeScript กลายเป็นมาตรฐานและถูกมองเป็นบรรทัดฐาน type interface ที่สร้างขึ้นกลับกลายเป็นสิ่งที่น่ารำคาญในการจัดการ เพราะโค้ดเบสฝั่งฟรอนต์เอนด์คุ้นชินกับมาตรฐานที่สูงกว่าแล้ว
• ข้อเสียของ type interface ที่สร้างขึ้นนั้นชัดเจน:
  • ต้องมีขั้นตอนการ generate เสมอ
  • เอาต์พุตที่ generate มีความซับซ้อน
  • โค้ดที่ generate ไม่ได้ถูกต้องเสมอไป ขึ้นอยู่กับการตั้งค่าเริ่มต้น

การมาของ RPC และ tRPC

• RPC ไม่ใช่แนวคิดใหม่ แต่ได้รับความนิยมในระบบนิเวศ React เพราะ tRPC
• จากประสบการณ์ทำงานคนเดียวเป็นเวลา 6 เดือนกับแอปพลิเคชันขนาด 80,000 บรรทัด การเรียกฟังก์ชันจากแบ็กเอนด์เพื่ออ่านและเขียนข้อมูลนั้นเหมือนการเปิดโลก
• ฉันไม่เคยรู้สึกว่าตัวเองทำงานได้มีประสิทธิภาพกว่านี้อีกแล้วกับการใช้ TypeScript ทั้งสองฝั่งของสแตก
• โดยส่วนตัวแล้ว ฉันเคยรู้สึกมีประสิทธิภาพใกล้เคียงกันแบบนี้เฉพาะกับสถาปัตยกรรม GraphQL แบบมี type (ที่ generate) เมื่อหลายปีก่อน
• ตลอดปี 2023 ฉันนึกไม่ออกเลยว่าจะมีอะไรดีกว่า tRPC
• การเรียกฟังก์ชันจากแบ็กเอนด์เพื่ออ่านและเขียนข้อมูลให้ความรู้สึกเหมือนการปฏิวัติ
• แต่นั่นคือทั้งหมดที่ฉันต้องการหรือเปล่า? ไม่ใช่

นวัตกรรมของ Server Components และ Server Actions

• สำหรับฉัน จุดเปลี่ยนที่แท้จริงมาถึงในปี 2024 กับ Server Components และ Server Actions
• สิ่งเหล่านี้ไม่ได้แค่เรียกเซิร์ฟเวอร์ แต่ยังเชื่อมช่องว่างกับเซิร์ฟเวอร์ด้วยการทำให้สามารถเขียนและรันโค้ดที่อีกฝั่งได้
• Server Components ทำให้สามารถรัน React component บนเซิร์ฟเวอร์ และเข้าถึงแหล่งข้อมูลโดยตรง (เช่น ฐานข้อมูล) ก่อนจะคืนค่า UI เป็น JSX
• Server Actions สร้าง HTTP API endpoint ไว้ภายใต้ hood ทำให้สามารถเรียกใช้ฟังก์ชันได้ในลักษณะเดียวกับ remote procedure call
• Server Components และ Server Actions กำลังเปลี่ยน React ให้กลายเป็นฟูลสแตกเฟรมเวิร์ก
• เป็นช่วงเวลาที่น่าตื่นเต้นของการ เปลี่ยนฟรอนต์เอนด์ให้เป็นสภาพแวดล้อมแบบฟูลสแตก

การรองรับ Server Components และ Server Actions ของ React

• ตัว React เองมีเพียงองค์ประกอบพื้นฐานและสเปกสำหรับ Server Components และ Server Actions เท่านั้น
• meta-framework ที่สร้างบน React สามารถเชื่อมช่องว่างนี้ได้ด้วย bundler ที่ตีความ directive ระหว่างไคลเอนต์กับเซิร์ฟเวอร์
• Next.js กำลังเป็นผู้นำในการใช้งาน Server Components และ Server Actions
• ก่อนหน้านี้ Next.js รองรับ server-side rendering (SSR) อยู่แล้ว แต่ตอนนี้ผ่าน Server Components และ Server Actions นักพัฒนาสามารถเข้าถึงทรัพยากรฝั่งเซิร์ฟเวอร์อย่างฐานข้อมูลและ message queue ได้

การเริ่มต้นของการพัฒนาแบบฟูลสแตก

• การพัฒนาแบบฟูลสแตกด้วย React เพิ่งอยู่ในช่วงเริ่มต้นเท่านั้น
• เมื่อนักพัฒนาเริ่มเข้าถึงฐานข้อมูลโดยตรงผ่าน Server Components และ Server Actions ก็จะมีช่วงของการเรียนรู้เพื่อรับมือกับความซับซ้อนที่เกินกว่าแอปพลิเคชัน CRUD ธรรมดา
• ด้วยการเรียนรู้อย่างจริงจัง นักพัฒนาฟรอนต์เอนด์จะเชี่ยวชาญการทำสถาปัตยกรรมแบ็กเอนด์โดยใช้เลเยอร์ แพตเทิร์นการออกแบบ และแนวปฏิบัติที่ดีได้ในไม่ช้า
• พูดตามตรง ไม่มีใครอยากเห็นการเรียกใช้ฟังก์ชัน ORM อยู่ใน React component หรอก

ความคาดหวังต่อการเปลี่ยนผ่านกระบวนทัศน์

• ฉันตื่นเต้นมากกับการเปลี่ยนผ่านกระบวนทัศน์ครั้งนี้
• เตรียมเข้าสู่ยุคใหม่ที่นักพัฒนา React จะสร้างฟีเจอร์แบบแนวตั้งตั้งแต่ UI ไปจนถึงฐานข้อมูลได้

[t7vonn]

ก็ทำฟูลสแตกได้หมดแล้วนี่

[wan2land]

ถ้าคิดถึงความเข้ากันได้กับภาษาอื่นด้วย อย่างการพัฒนาแอป ผมว่า tRPC ไม่ใช่ตัวเลือกที่ดีเท่าไหร่นะ 😅
ส่วนตัวผมคิดว่า GraphQL ดีที่สุดครับ

[click]

ผมคิดว่า nextjs server action มีปัญหาที่เปิดเผย API endpoint แบบสุ่มเป็นสาธารณะโดยที่นักพัฒนาไม่สามารถควบคุมได้ ซึ่งผมมองว่าเป็นจุดที่เปราะบางมาก

[pasg0725]

ขอทราบได้ไหมครับ/คะว่าช่องโหว่ที่คุณพูดถึงคืออะไร? พอลองค้นหาดูก็เจอว่ามีช่องโหว่ SSRF แต่ก็ไม่แน่ใจว่าใช่อันนั้นหรือเปล่า ตอนนี้กำลังศึกษา Next.js อยู่พอดีเลยสงสัยเลยมาถามครับ/ค่ะ

[savvykang]

ตั้งแต่แรก เจตนาของคนที่ผลักดัน SPA คืออะไรกันแน่? มันดีกว่ายุคที่คอยจัดการ DOM ด้วย jquery มากก็จริง แต่ดูเหมือนว่าแนวคิดที่จำเป็นต่อการออกแบบและพัฒนาแบ็กเอนด์กับฟรอนต์เอนด์ไม่ได้หายไปไหน แค่ย้ายตำแหน่งเท่านั้นเอง แม้แต่เรื่อง routing ก็ยังย้ายจากฝั่งเซิร์ฟเวอร์ไปอยู่ฝั่งไคลเอนต์ แล้วก็พยายามย้ายกลับไปฝั่งเซิร์ฟเวอร์อีกครั้งเพราะกระแส server-side rendering

ผมก็ยังสงสัยว่าอีก 3 ปีข้างหน้า ตามสถาบันสอนเขียนโค้ดหรือคอร์สต่าง ๆ จะยังสอน React สไตล์ SPA กันอยู่ไหม

[superwoou]

จุดเด่นที่สุดคงเป็นความลื่นไหลตอนเปลี่ยนหน้าไม่ใช่เหรอครับ (อย่างน้อยก็ในตอนนั้น)

[xguru]

ตอนท้ายของบทความต้นฉบับ ผู้เขียนปิดด้วยการโปรโมตคอร์สการสอนพัฒนาเว็บแบบฟูลสแต็ก The Road to Next ที่กำลังจะเปิด ^^;