การนำเสนอเว็บแอปพลิเคชันที่พัฒนาด้วย Rust และ TypeScript เมื่อเร็วๆ นี้ได้จุดประกายการอภิปรายอย่างกว้างขวางในหมู่นักพัฒนาเกี่ยวกับวิธีการที่ดีที่สุดในการรักษาความปลอดภัยของประเภทข้อมูลข้ามภาษาโปรแกรมมิ่งที่แตกต่างกัน โปรเจ็กต์ต้นฉบับใช้ข้อกำหนด OpenAPI ในการสร้างไคลเอนต์ที่มีความปลอดภัยของประเภทข้อมูล แต่สมาชิกในชุมชนได้แบ่งปันแนวทางทางเลือกต่างๆ และได้ตั้งคำถามสำคัญเกี่ยวกับสถาปัตยกรรม
เครื่องมือหลากหลายเกิดขึ้นสำหรับการสร้างประเภทข้อมูลข้ามภาษา
ชุมชนนักพัฒนาได้ระบุเครื่องมือหลายตัวนอกเหนือจาก OpenAPI สำหรับการสร้างคำจำกัดความ TypeScript จากโค้ด Rust crate ts-rs ได้รับความนิยมสำหรับการสร้างคำจำกัดความ TypeScript โดยอัตโนมัติที่สามารถคัดลอกไปยังเว็บแอปพลิเคชันได้โดยตรง ตัวเลือกอื่นคือ typeshare จาก 1Password ซึ่งมีฟังก์ชันการทำงานที่คล้ายกันแม้จะมีข้อผิดพลาดบางอย่าง เครื่องมือเหล่านี้มีเป้าหมายเพื่อแก้ไขความท้าทายพื้นฐานในการรักษาคำจำกัดความประเภทข้อมูลให้ซิงโครไนซ์ระหว่างโค้ดเบสแบ็กเอนด์และฟรอนต์เอนด์โดยไม่ต้องบำรุงรักษาด้วยตนเอง
หมายเหตุ: crate คือแพ็กเกจหรือไลบรารี Rust ที่สามารถแบ่งปันและนำกลับมาใช้ใหม่ในโปรเจ็กต์ต่างๆ ได้
เครื่องมือสร้าง Type ยอดนิยม
| เครื่องมือ | ภาษา | คำอธิบาย |
|---|---|---|
| ts-rs | Rust → TypeScript | สร้าง TypeScript definitions โดยอัตโนมัติ |
| typeshare | Rust → TypeScript | โซลูชันสำหรับแชร์ type ของ 1Password |
| FastAPI + Pydantic | Python → TypeScript | สร้าง OpenAPI specs สำหรับการสร้าง type |
| poem-openapi | Rust | การกำหนด OpenAPI service แบบ ergonomic |
| utoipa-axum | Rust | การรวม OpenAPI สำหรับ Axum framework |
การรวม WebAssembly นำเสนอความเป็นไปได้ใหม่
นักพัฒนาหลายคนแสดงความสนใจใน WebAssembly ( WASM ) เป็นแนวทางทางเลือกสำหรับการรวม Rust และ TypeScript แม้ว่าบางคนจะสังเกตว่าฟีเจอร์การนำเข้า Rust โดยตรงของ Parcel ถูกลบออกใน version 2 แต่คนอื่นๆ ชี้ให้เห็นว่าการรวมเอาต์พุต wasm-pack เข้ากับโปรเจ็กต์ Vite ยังคงเป็นเรื่องง่าย แนวทาง WASM ช่วยให้โค้ด Rust ทำงานได้โดยตรงในเบราว์เซอร์ ซึ่งอาจขจัดความจำเป็นในการใช้บริการแบ็กเอนด์แยกต่างหากในบางกรณี
ตัวเลือกสถาปัตยกรรมทำให้เกิดคำถามเรื่องประสิทธิภาพ
การตั้งค่าเซิร์ฟเวอร์คู่ที่ใช้กันทั่วไปในแอปพลิเคชันเหล่านี้ได้สร้างการอภิปรายเกี่ยวกับโอเวอร์เฮดและความซับซ้อน ในระหว่างการพัฒนา โปรเจ็กต์มักจะรันเซิร์ฟเวอร์แยกต่างหากสำหรับฟรอนต์เอนด์และ API แต่การปรับใช้ในการผลิตแตกต่างกันอย่างมาก นักพัฒนาบางคนแพ็กเกจบริการทั้งสองเข้าไปในคอนเทนเนอร์เดียวกันด้วยการพร็อกซีภายใน ในขณะที่คนอื่นๆ เปิดใช้งานการให้บริการไฟล์สแตติกบนปลายทาง API หรือปรับใช้เป็นบริการที่เป็นอิสระโดยสมบูรณ์
ผมชอบที่จะไม่ถูกเรียกตอนกลางคืน ดังนั้นผมจึงชอบแบ็กเอนด์ rust มากกว่า ผมมีประสบการณ์กับแบ็กเอนด์ TS , Python และ Rust และแบ็กเอนด์ Rust ไม่ค่อยล้มเหลวสำหรับผม
การเลือกเฟรมเวิร์กมีอิทธิพลต่อประสบการณ์นักพัฒนา
การเลือกระหว่างเว็บเฟรมเวิร์กได้กลายเป็นจุดอภิปราย โดยเฉพาะเรื่อง Poem เทียบกับ Axum สำหรับแบ็กเอนด์ Rust แม้ว่า Axum จะได้รับความนิยมอย่างกว้างขวาง แต่การรวม OpenAPI ของ Poem ผ่าน poem-openapi ให้ความสามารถในการกำหนด API ที่เป็นมิตรกับผู้ใช้มากกว่า สำหรับนักพัฒนาที่ชอบ Axum crate utoipa-axum มีฟังก์ชัน OpenAPI ที่คล้ายกัน แม้ว่าจะมีรูปแบบไวยากรณ์และเวิร์กโฟลว์ที่แตกต่างกัน
คอมโพเนนต์สถาปัตยกรรมโปรเจกต์
- Backend: Rust พร้อม web framework Poem
- Frontend: TypeScript พร้อม SvelteKit
- Build System: Vite สำหรับการพัฒนาและการผลิต
- Type Safety: การสร้าง OpenAPI spec และการสร้าง client
- Development: Zellij terminal multiplexer พร้อม custom layout
ความปลอดภัยของประเภทข้อมูลข้ามภาษาขยายไปเกิน Rust
การสนทนาได้ขยายไปรวมถึงการรวมภาษาอื่นๆ โดยนักพัฒนา Python และ TypeScript แบ่งปันโซลูชันของตนเอง FastAPI กับ Pydantic ได้กลายเป็นตัวเลือกยอดนิยมสำหรับแบ็กเอนด์ Python โดยสร้างข้อกำหนด OpenAPI โดยอัตโนมัติที่สามารถแปลงเป็นประเภท TypeScript ได้ แนวทางนี้ขจัดการตรวจสอบประเภทด้วยตนเองโดยการสร้างประเภทฟรอนต์เอนด์โดยตรงจากคำจำกัดความแบ็กเอนด์
การอภิปรายที่กำลังดำเนินอยู่เน้นให้เห็นว่าความปลอดภัยของประเภทข้อมูลข้ามภาษาโปรแกรมมิ่งที่แตกต่างกันยังคงเป็นพื้นที่ของนวัตกรรมที่มีการเคลื่อนไหวอยู่ โดยมีเครื่องมือและแนวทางใหม่ๆ เกิดขึ้นอย่างต่อเนื่องขณะที่นักพัฒนาแสวงหาวิธีที่มีประสิทธิภาพมากขึ้นในการสร้างเว็บแอปพลิเคชันที่เชื่อถือได้
อ้างอิง: Rust + TypeScript Web Application