🎞️ Videos → Type Safe Server to Client

แนะนำตัวออม (SaltyAom) ผู้พัฒนาเฟรมเวิร์ก Elysia0:00

ไมโครโฟนติดไหมครับ แบตหมดไหม แบตหมดนะครับ

Nope. Okay. Hello!

ง่วงกันไหมทุกคน ผมง่วงมากเลย

ตอนแรกนึกว่าแบบว่า เมื่อวานตื่นมา ผมไม่รู้ว่าแบบว่ากี่โมง ผมก็แบบเช็คเวลา อ้าว 6 โมง แล้วผมพูด session สุดท้าย โอ้โหง่วง ตอนนี้ง่วงมาก แต่เอาเป็นว่าไม่เป็นไร วันนี้เรามาพูดถึงเรื่อง TypeScript เนาะ TypeScript TypeScript TypeScript แต่ว่าก่อนอื่นแนะนำตัวนิดนึง ผมชื่อออมนะฮะ ถ้าเป็นชื่อบน GitHub หรือชื่อบนเน็ตใช้ชื่อว่า SaltyAom แล้วก็อันนี้เป็น QR code ไปตัวหน้าเว็บผมเนาะ ก็จะมีแบบว่า ลิงก์ไป GitHub เป็นลิงก์ไป Twitter เอาเป็นว่าเอาไว้ดูว่าแบบว่า เคยทำอะไรมาบ้าง ผลงาน เผื่อว่าแบบว่าใครอยากรู้ว่ามีอะไรบ้างเนาะ แล้วก็ผมทำ framework ชื่อ Elysia ฮะ แล้วก็วาดรูปได้นิดหน่อย นานๆ ทีวาดรูปนะฮะ ตัว framework เรามี mascot ด้วย แต่ว่าคือแบบว่า 2 เดือนวาดที กว่าจะเสร็จรูปหนึ่ง เพราะผมวาดแบบว่า ร่างเสร็จแล้ว 2 วัน แล้วก็ดองอีก 2 เดือน แล้วค่อยทำให้เสร็จ

tRPC ช่วยเชื่อม Type ข้ามหน้าบ้านและหลังบ้าน ทำให้เห็น Error ทันทีเมื่อโค้ดเปลี่ยน1:15

แต่หลักๆ ก็คือ มีใครรู้จักตัวนี้ไหมฮะ tRPC มีใครรู้จักไหม ยกมือให้ดูหน่อย โอ้ ก็โอเค ก็พอประมาณเนาะ เอาเป็นว่าอธิบายคร่าวๆ ก็คือ ปกติเวลาเราเขียน backend กับ frontend ปกติเวลาเราเขียน backend เนาะ มันจะแยกกับ frontend สมมติว่าเราอัปเดต endpoint หนึ่งใน backend เนาะ ตัว frontend อะ มันจะไม่รู้ว่าหลังบ้านถูกเปลี่ยนแล้ว ทำให้เวลาเรารัน code เนี่ย มันก็จะเกิด error ขึ้น แต่ทีนี้เหมือนถ้าหากว่าเราเขียนด้วยเครื่องมือตัวนี้ มันจะทำให้เราสามารถที่จะแบบว่า เวลาหลังบ้านถูกแก้ไขเงี้ย มันจะ highlight ให้เลย

ว่าบนหน้าบ้านอะว่าแบบ ฟังก์ชันไหนถูกเปลี่ยน แล้วก็ค่าถูกเปลี่ยนไปแล้ว เช่นสมมติว่า เราเอา table หนึ่งออกจากหลังบ้านเนาะ แล้ว API ค่าที่ส่งมาเนี่ย มันก็จะมีค่าที่หายไป ไอ้ตัวเหมือนไอ้ตัวเนี้ยเวลาเราทำอย่างงั้นอะ มันจะไปขึ้นบนหน้าบ้านด้วยว่า field นี้ถูกหายไปแล้ว ค่านี้ถูกหายไปแล้ว หรือค่านี้ถูกเติมขึ้นมาเนาะ เอาเป็นว่าอาจจะไม่ค่อย get ภาพเท่าไหร่ แต่เดี๋ยวเรามี demo ตอนท้ายสไลด์เนาะ

ทีนี้เนี่ย มันมีปัญหานิดหนึ่งก็คือตัว tRPC เนี่ย เหมือนฟีเจอร์มันก็คือ ทำให้เราสามารถ เชื่อมหลังบ้านกับหน้าบ้านได้ แบบเช็คตอน compile time เช็คตอนเราเขียน code ได้เลย แต่ทีนี้มันก็จะมีความปัญหานิดหนึ่งก็คือ เอาข้อดีก่อนแล้วกัน ข้อดีคือมันเชื่อมหน้าบ้านหลังบ้านได้ แบบแทบจะ 100% เลย code หลังบ้านเปลี่ยนแล้ว code หน้าบ้านก็จะ highlight ให้ด้วยว่า มีตรงไหนที่ถูกเปลี่ยนบ้าง มีโอกาส error ตอนไหนบ้าง ก่อนที่เราจะรัน code จริงๆ ซะอีก

ข้อจำกัดของ tRPC คือไม่ใช่มาตรฐาน REST API และเขียน API Docs ได้ยาก2:46

ข้อเสียคือ อย่างแรกคือมันเป็น JSON-RPC เนาะ คือปกติเวลาเราเขียน API เงี้ย เราก็จะใช้เป็น REST API

หรือว่าถ้าเมื่อก่อนก็จะเป็น SOAP เป็น XML something แต่ว่าเดี๋ยวนี้ก็จะใช้เป็น REST standard ก็คือ เหมือนว่าเป็น HTTP เนาะ ก็ส่งไปปุ๊บ ได้ค่ากลับมาเป็น JSON เป็น object เป็นอะไรก็แล้วแต่ ปัญหาที่ 2 ก็คือ tRPC เนี่ย มีปัญหาเรื่องการเขียน documentation ที่ค่อนข้างยาก ก็คือด้วยความที่มันไม่ได้เขียนเป็น REST standard เนาะ ทำให้แบบว่า มันไม่สามารถใช้กับพวก Swagger พวก OpenAPI ใช้ด้วยกันไม่ได้เลย ต้องเขียนเป็น format แยก และอย่างสุดท้ายก็คือด้วยความที่มันไม่ใช่ตัว REST API ซะทีเดียวเนาะ มันก็จะมฟีเจอร์บางอย่างที่หายไป เช่นแบบว่า ทำเป็น reverse proxy ไม่ได้ หรือว่าการส่งไฟล์กลับมาเนี่ย การทำ streaming เนี่ย ค่อนข้างยาก stream ไฟล์กลับมา stream วิดีโอกลับมา จะทำไม่ได้เลย ต้องไปเขียน API แยกทีหนึ่ง ถ้าเราอยากได้ฟีเจอร์พวกนั้นขึ้นมา

เฟรมเวิร์กยุคเก่าไม่ได้ออกแบบมาเพื่อ TypeScript ทำให้เสริมระบบ Type-safe ได้ยาก3:43

ทีนี้เนี่ย สมัยก่อนเราก็จะมี framework ประมาณนี้นะ ทุกคนน่าจะรู้จัก Express รู้จัก Fastify กันอยู่แล้ว รู้จัก Nest กันอยู่แล้ว ทีนี้เนี่ย framework พวกนี้เนี่ย คำถามก็คือ มันก็มีอยู่แล้ว แล้วทำไมเราถึงต้องไปใช้ของใหม่เนอะ? ปัญหาก็คือ ด้วยความที่ framework พวกนี้เนี่ย มันมีมาค่อนข้างที่จะนานละ มันแก้ปัญหาเมื่อประมาณ 10 ปีที่แล้ว ทำให้เวลาผ่านมา 10 ปีเงี้ย มันก็มีปัญหาใหม่ขึ้น

เช่น อาจจะต้องมีเรื่อง type safety ที่ดีขึ้น ซึ่งเครื่องมือพวกนี้เนี่ย ถูกเขียนก่อนที่จะมี TypeScript หรือว่า TypeScript ยังไม่ได้เฟื่องฟูขนาดนั้น ทำให้การเขียน code เนี่ย มันทำให้ type-safe ค่อนข้างยาก แล้วก็สมัยใหม่เนี่ย มันก็จะมีเครื่องมือที่มี standard เพิ่มขึ้น มี OpenAPI มี OpenTelemetry มีหลายๆ อย่างขึ้นมา ทำให้เครื่องมือสมัยก่อนไม่ค่อยตอบโจทย์ขนาดนั้นแล้ว แต่ว่าหลักๆ ก็คือปัญหาเครื่องมือพวกนั้นเนี่ย มันไม่สามารถ sync type ระหว่าง frontend กับ backend ได้ ซึ่งไอ้ฟีเจอร์เนี้ย เป็นฟีเจอร์ที่ค่อนข้างใหม่ เพิ่งมีประมาณเมื่อ 5 ปีแล้วเนอะ น่าจะ 5 ปีแล้วล่ะ

ที่ tRPC มีประมาณ 4-5 ปีละ

ค่อนข้างเก่าเหมือนกัน แต่ว่าก็ประมาณนั้น คือด้วยความที่มันใช้ tech ใหม่เนี่ย tech เก่า การที่จะ implement ของพวกนี้ขึ้นมาเนี่ย มันค่อนข้างที่จะต้องแก้ใหม่ทั้งหมดเลย สมมติเราอยากให้ Express หรือ Fastify ทำแบบ tRPC ได้เนี่ย มันต้องแก้ code ใหม่ทั้งหมดเลย เพื่อให้มันสามารถทำอย่างงั้นได้ ซึ่งมันไม่ค่อยคุ้มเท่าไหร่ แล้วก็มี breaking change ค่อนข้างเยอะ ทำให้มันมีเครื่องมือสมัยใหม่ขึ้นมาเนี่ย framework สมัยใหม่ที่สามารถแก้ปัญหาตรงนี้แทนได้ และทำได้ดีกว่า อาจจะเป็นเรื่อง performance เรื่อง standard ที่ดีกว่า

Elysia และ Hono คือทางเลือกใหม่ที่รองรับ REST API แบบ End-to-End Type Safety5:21

ทำ OpenAPI ง่ายกว่า ทำ OpenTelemetry ง่ายกว่า

ตัวที่ผมยกขึ้นมาตัวนี้ก็จะเป็น 3 ตัวนะ เรื่องทั้งหมดที่พูดมาคือ performance ดีกว่า เรื่อง standard ดีกว่า

และเรื่อง runtime รันได้หลาย runtime หรืออะไรประมาณนี้ แต่หลักๆ คือเรื่อง type safety คือสามารถเชื่อม frontend กับ backend ได้ โดยที่พอเราแก้ code แล้วมันเชื่อมกันเลย

ซึ่งใน 3 ตัวนี้เนี่ย จะมี 2 ตัวบน ก็คือ Elysia กับ Hono ที่สามารถทำเป็น REST API ได้ ส่วนตัว oRPC เนี่ย มันทำขึ้นมาเพื่อเป็นต่อยอดจาก tRPC อีกทีนึง ซึ่งสร้างขึ้นมาเพื่อแก้ปัญหาของตัว tRPC เช่น แบบว่า แทนที่จะใช้เป็น JSON-RPC เนี่ย เราก็ใช้เป็น REST standard ทำ API ได้ ทำอะไรประมาณนั้นได้ แต่มันไม่ได้ REST standard ซะทีเดียว เพราะว่ามันมีฟีเจอร์หลายๆ อย่างที่มันไม่ได้ REST compatible ขนาดนั้น มันจะออกเป็นแนว RPC มากกว่า เพราะฉะนั้นเราจะข้ามไปเป็นแค่ 2 ตัวบนเนาะ เพราะว่ามันสามารถ build ได้หลายอย่างมากกว่า ทีนี้เนี่ย คำถามก็คือ ระหว่าง 2 ตัวนี้เนี่ย เราเลือกตัวไหนดี? ถ้าถามผม ผมเป็นคนทำ Elysia ผมก็ต้องเลือกตัวเองอยู่แล้ว แต่เราจะมาดูตัว Hono ก่อนว่า Elysia ทำอะไรได้บ้างเนาะ เอาเป็นตัว Hono ก่อน ทำ end-to-end type safety ได้ คือเชื่อม client frontend ได้ type เชื่อมกันได้ปกติ ทีนี้มันก็จะมีปัญหาเล็กน้อยก็คือ REST API ทำได้ แต่ว่า API documentation เนี่ย เขียนค่อนข้างที่จะยาก

ถ้าเราเคยเขียน Hono เนี่ย เราต้องไปเขียนตัวอธิบาย API เอง ว่ามันต้องมี endpoint อะไรบ้าง มี field อะไรบ้าง รับค่าอะไรได้บ้าง แล้วก็ต้องส่งค่าอะไรกลับไปได้บ้างเนาะ ส่วนที่เหลือเนี่ย ด้วยความที่เป็น REST standard เหมือนตัว Express และ Fastify มันสามารถทำเป็น reverse proxy ทำ WebSocket ทำ Server-sent events หรือทุกๆ อย่างที่ API ทั่วไปทำได้เนาะ

แต่ว่ามีปัญหาใหญ่นิดนึงก็คือ

Elysia คำนวณ Type เร็วกว่าและไม่ติดข้อจำกัด 70 Endpoints แบบ Hono7:14

ถึงแม้ว่ามันจะสามารถทำ end-to-end type safety ได้เนี่ย แต่ว่าตัว type ที่เขาเขียนเนี่ย มันค่อนข้างที่จะช้า ซึ่งตรงนี้เนี่ย มันมี issue back อยู่ก็คือตัว maintainer เนี่ย มาเปิด issue เองว่า ถ้าหากว่ามี endpoint มากกว่า 70 endpoint มันจะไม่สามารถเชื่อมกันได้ละ คือด้วยความที่ TypeScript เนี่ย มันเหมือนกับว่ามันมี stack limit ว่า ถ้าหากว่าเราเขียน code มากเกินไปเนี่ย มันก็จะไม่สามารถเดา type ต่อได้ ซึ่งมันก็มีปัญหานี้ใน Hono มาประมาณ 2-3 ปีละ แต่เขาก็ยังไม่สามารถแก้ได้ ซึ่งมันพูดตรงๆ ว่ามันแก้ยากมาก จากประสบการณ์ตัวเองนะ ผมใช้เวลาประมาณ 2 ปี 3 ปีกว่าจะแก้ได้เหมือนกัน ค่อนข้างยาก

แต่ว่าเท่าที่เราลองทำมาแล้วเนี่ย ตัว Elysia จะไม่มีปัญหาเรื่อง type limit เราสามารถกำหนด route ได้ประมาณ 2,000-3,000 route และก็จะไม่มีปัญหาเรื่อง type limit และตัว Elysia สามารถคำนวณ type

เร็วกว่า Hono ประมาณ 2 เท่า ความสามารถในการคำนวณ type เนี่ย แอบค่อนข้างสำคัญนิดนึง เช่น เวลาที่เราพิมพ์ something แล้วมี autocomplete หรือมี type check ใช่ไหม ถ้าเราสังเกตเนี่ย มันจะมีเวลาประมาณแป๊บนึง ซึ่งใช้เวลาในการคำนวณว่าตัวนี้มันจะ error หรือเปล่า ไอ้เวลาตรงนี้ ก็คือเวลาในการคำนวณ type ที่ผมพูดถึง สมมติว่า Hono อาจจะใช้เวลาคำนวณพิมพ์ไปปุ๊บ autocomplete ขึ้นใน 200ms Elysia ก็อาจจะใช้ประมาณ 100 หรือ 90ms แทน ซึ่งทำให้ตรงนี้มันเป็น engineering ที่อยู่ข้างหลัง แต่ว่าค่อนข้างสำคัญ ก็คือถ้าเราพิมพ์ไปแล้วรู้สึกว่า autocomplete มันขึ้นช้า หรือว่า type check มันมาขึ้นทีหลังเกิน 200ms ไปแล้ว มันจะรู้สึกว่าช้าแล้ว ทำให้ตรงนี้แอบค่อนข้างสำคัญนิดนึง แต่ว่าเป็นเบื้องหลังครับ ตัว Elysia สามารถแก้ปัญหาที่เซิร์ฟเวอร์หลายอย่างมี

แต่ว่าเอาเป็นว่า เดี๋ยวเราจะมาเดโมให้ดูในภายหลังเนาะ

ลองใช้ฟังก์ชัน treaty เพื่อเรียกใช้หลังบ้านจากหน้าบ้านโดยตรงผ่าน Type9:08

เราจะใช้ตัว Elysia เป็นเซิร์ฟเวอร์ก่อนละกันเนาะ ฟีเจอร์ที่สำคัญที่พูดถึงวันนี้ก็คือ end-to-end type safety ก็คือการเชื่อมหลังบ้านหน้าบ้าน โค้ดตัวนี้เป็นตัว API ของ Elysia

เราสร้างเซิร์ฟเวอร์ขึ้นมา เรามี get endpoint อันหนึ่ง ส่งค่ากลับมาเป็นคำว่า hi เนาะ แล้วก็สร้างเซิร์ฟเวอร์ที่พอร์ต 3000 ทีนี้เนี่ย อันนี้คือเซิร์ฟเวอร์ที่ง่ายที่สุดในการเขียน Elysia ทีนี้ไอ้ตัว end-to-end type safety เราทำยังไงได้บ้าง เราก็แค่เริ่มมาคือเราประกาศ export app ออกไปเป็น type

ไปที่หน้าบ้าน อันนี้เป็นโค้ดหลังบ้านเนาะ เราไปที่โค้ดหน้าบ้านของเรา เรา import ตัว type มา และ import ฟังก์ชันหนึ่งที่ชื่อว่า treaty อารมณ์เป็นประมาณว่าเหมือนกับเป็น RPC นั่นแหละ พอเรา import มาแล้วเนี่ย เราก็เรียกฟังก์ชันนี้

แล้วก็ pass type เข้าไป และ pass API endpoint เข้ามา ทีนี้เวลาเราจะเรียกค่าเนี่ย เราก็สามารถเรียก api.get แล้วจะได้ค่าออกมาเลย แทนที่เราจะต้องเขียน fetch แทน อันนี้อาจจะยังไม่ค่อยเห็นภาพเท่าไหร่ว่ามันคืออะไร แต่ว่า สมมติเวลาเราแก้ที่หลังบ้านเนี่ย

สมมติอันนี้เราใช้เป็น .get เนาะ สมมติเราย้อนกลับไปตรงโค้ดเมื่อกี้ เราแก้จาก .get เป็น .post แทน ตรงนี้มันจะขึ้นเป็น error ทำให้เราไม่สามารถใช้อันนี้ได้ เวลาเรา build เราก็จะไม่ผ่าน และเราก็จะรู้เลยว่า API ตรงนี้มันไม่มีอยู่นะ

เพราะว่าโค้ดมันซิงกัน ทำให้เราไม่สามารถ build ได้ ทำให้เรารู้ว่า API ตัวนี้มันถูกแก้ไปแล้ว ทีนี้เนี่ย เรามาดูโค้ดนิดนึงก็คือ

ตรวจ Validation Data ขาเข้าอัตโนมัติ พร้อมแจ้งเตือน Error ทันทีใน IDE11:01

ถ้าเราจะส่งค่ากลับมาใช่ไหม ถ้าเราจะส่งค่าไปที่ตัว API server เราก็สามารถประกาศ method เป็น post เนาะ และก็บอกว่า เอ้ย ค่าที่เราอยากได้เนี่ย ให้เป็น object มี property เป็น name name เป็น string และก็มี file รับเป็น file format เป็น JPEG เนาะ ค่อนข้างชัดเจน อันนี้คือวิธีการแบบว่า พอเราประกาศตัวนี้แล้วเนี่ย Elysia จะเช็คว่า ค่าที่ส่งเข้ามาเนี่ย มันถูกต้องหรือเปล่า ถ้ามันไม่ถูกต้องเนี่ย มันก็จะถูกตีค่ากลับไป มันจะไม่รันตัวฟังก์ชัน ok เนาะ แต่ถ้าหากว่า ค่าทุกอย่างถูกต้องเนี่ย มันก็จะส่งเป็น ok กลับมา

ทีนี้ พอเราไปที่หน้าบ้านเนี่ย ก็จะเห็นว่า เอ้ย ตัวเนี้ย มันก็จะแบบมี autocomplete ขึ้นมาให้เลย 2 field ว่าเราสามารถใส่ไรได้บ้าง ถ้าตรงเนี้ย เราใส่เป็น number เนี่ย มันก็จะขึ้น highlight ว่า error ว่า เอ้ย ตรงเนี้ย มันไม่สามารถเป็นอย่างงี้ได้นะ หน้าตาจะเป็นประมาณแบบนี้ ซึ่งอันนี้เป็นโค้ดที่ไม่เหมือนเมื่อกี้เนาะ แต่ว่า หน้าตาจะเป็นประมาณแบบนี้ สมมติว่า เอ้ย เราเรียก endpoint something มา

แล้วเราใส่ไม่ถูกเนี่ย มันบอกว่า เอ้ย เราใส่เป็น username ใช่ไหม แต่ทีนี้ มันบอกว่า เอ้ย มันขาด property password อยู่ ทำให้เรารู้เลยว่า เอ้ย

ไอ้ตัวจากหน้าบ้านเนี่ย ไปหลังบ้านเนี่ย เอ้ย โค้ดมันไม่ถูกต้อง ทำให้แบบว่า เอ้ย เราก็สามารถแก้ตรงนี้ได้เลย แบบว่า แก้หลังบ้าน และมันก็จะขึ้น highlight ที่หน้าบ้านให้ด้วย ไอ้พลังตรงเนี้ย มันค่อนข้างที่จะเป็นอะไร ที่ค่อนข้างดีถ้าเราเคยใช้เนาะ มันจะสามารถทำให้เรารู้ว่า โค้ดมันเชื่อมกัน และเราจะแทบไม่มีทางที่จะแบบว่า ทำให้มันผิดได้เลย เพราะว่า มันจะฟ้องตลอดเลย ทุกจุดที่เราใช้เนาะ สมมติว่า เราแก้โค้ดหลังบ้านปุ๊บ มันก็จะ highlight หน้าบ้านให้ด้วย แบบบรรทัดเป๊ะๆ เลยว่า ตรงไหนมันไม่สามารถใช้ได้ ปึ๊บ ซึ่งถ้าเราดูโค้ดตรงนี้เนี่ย เราจะเห็นว่า โค้ดตรงเนี้ย มันเหมือน test case เป๊ะๆ เลย ก็คือเรามี test เรามี server และก็เรียกค่า และก็เช็คค่าว่า ถูกต้องหรือเปล่า ไอ้ตรงนี้เนี่ย นอกจากที่เราสามารถ เชื่อมหน้าบ้านกับหลังบ้านได้แล้วเนี่ย มันสามารถเอามาเขียนเป็น test case ได้ด้วย ทำให้เรามี autocomplete ทั้งค่าที่ถูกต้อง และก็ค่าที่ควรจะเป็น และก็ค่าตอนที่เช็คใน IDE ได้ด้วย

ทำให้เรารู้ว่า แบบว่า เอ้ย ก่อนที่จะรัน test case เนี่ย ตรงนี้มันอาจจะผิดได้นะ ซึ่งค่อนข้างที่จะสะดวก สะดวกกว่าเมื่อก่อนมาก ก็คือเรารู้เลยทันทีเนาะ ทำให้ตรงนี้ เราสามารถแชร์โค้ดจาก server ไปหน้าบ้าน และก็แชร์จาก server ไปตัว test case ได้ด้วย แต่ทีนี้เนี่ย เราสามารถทำได้มากกว่านั้น

ใช้ ORM อย่าง Prisma หรือ Drizzle เพื่อจัดการ Database แบบ Type-safe13:21

ก็คือเราสามารถทำให้ database ของเราเนี่ย มันสามารถ type-safe ได้เหมือนกัน ถ้า มีใครรู้จัก 3 ตัวนี้ไหม มีใครเคยใช้ไหม ยกมือให้ดูหน่อย โอ้ โห เยอะ เยอะมาก โอเค

งั้นผมไม่พูดมากแล้วกัน ตัวนี้ 3 ตัวนี้คือ ORM สำหรับเขียน TypeScript เนาะ ใครใช้ JavaScript หรือ TypeScript เนี่ย ก็จะสามารถใช้ตัว library พวกนี้ ในการคุยกับ database โดยตรงได้

ซึ่งความพิเศษของ library พวกนี้เนี่ย คือเราสามารถประกาศ schema และก็ไอ้ตัว library พวกนี้ มันจะ apply เข้าจัดการ database ให้ แบบจัดการเรื่อง migration file จัดการเรื่องอะไรพวกนี้มาให้ แต่เราเขียนโค้ดเป็น TypeScript มา และมันจะสามารถเช็คได้ว่า เอ้ย ค่าที่เราเขียนถูก ว่าค่าที่เราเขียนเนี่ย มันถูกต้องหรือเปล่านะ มันจะได้ type ออกมา ทำให้เราสามารถที่จะประกาศ สมมติเราประกาศ Prisma เนาะ Prisma เนี่ย ก็จะไปเชื่อมกับตัว database มาให้ และ Prisma เนี่ย เราก็สามารถเรียกใช้ค่า Prisma กลับบน server ได้ ทำให้โค้ดมันเชื่อมกัน แต่ทีนี้เนี่ย

มันจะมีปัญหาหน่อยก็คือ ต่อให้เรา code มัน type-safe แล้วเนี่ย ไอ้ค่าตอนที่เรา input เข้าไปเนี่ย ค่าประกาศ body เนี่ย Elysia มันไม่สามารถใช้ ตัว Prisma ตัว Drizzle เนี่ย เราไม่สามารถใช้ schema ของ database มาใช้ในการเช็คค่าได้เนาะ มันจะเช็คได้แค่ตอนท้ายอย่างเดียว แต่ไม่สามารถเช็คค่าจริงๆ ได้ ค่าที่ถูกส่งเข้ามาที่ server จริงๆ จะไม่ถูกเช็ค เพราะว่า มันเป็น schema ที่มันไม่เชื่อมกันเนาะ

แปลง Prisma Schema ให้เป็น TypeBox เพื่อตรวจสอบข้อมูลขาเข้าของ API14:56

ทีนี้เนี่ย สิ่งที่เจ๋งก็คือ เราสามารถแก้ปัญหานี้ได้ โดยการแปลเป็นภาษากลางก็คือ สมมติเรามี Prisma schema อันหนึ่ง เราสามารถแปลงเป็น TypeBox และเราสามารถใช้ TypeBox ต่อกับ Elysia ได้ ก็คือ เรามี schema เป็น database

แปลเป็นภาษากลาง และใช้ภาษากลางเนี่ย ให้ Elysia อีกทีหนึ่ง ทำให้เราสามารถเชื่อม type จากหน้าบ้านไปหลังบ้านได้ เวลาที่จะทำอย่างงี้เนี่ย ถ้าเป็น Prisma เนาะ เราเพิ่มโค้ดหน้าตาเป็นประมาณอย่างงี้ คือเราเพิ่ม generator ตัวหนึ่ง และทีนี้ ตอนที่เรา run generate กับ migrate เนี่ย มันจะ generate ตัว schema ของ TypeBox ซึ่งมันสามารถใช้กับ Elysia ได้ ทำให้หน้าตาโค้ดจริงๆ เนี่ย มันจะเป็นประมาณอย่างงี้ แทนที่เราจะต้องเขียน Prisma schema เอง เราสามารถเอา Prisma schema มาแปลเป็น TypeBox

และเราสามารถเอาค่าของตัว schema ตัวเนี้ย มาเชื่อมกับตัว Elysia ได้โดยตรง ทำให้เวลาเราส่งค่าเข้ามาเนี่ย เราไม่ต้องเขียนตัว Prisma กับตัว Elysia แยกกัน

ทำให้เราสามารถเชื่อมตัว database server จาก server ไป database และก็จาก server ไปตัว test case และก็ client ได้ด้วย ทีนี้เนี่ย สุดท้ายก็คือ

ลดความน่าเบื่อหน่ายในการเขียน API Docs เองด้วยการเจน OpenAPI16:10

สิ่งที่เราอยากได้จริงๆ มันไม่ได้มีแค่นี้ สิ่งที่เราไม่อยากทำกันเลยจริงๆ ก็คือ เราไม่อยากเขียน API เองเนาะ เราอยากให้ทุกอย่างมันสามารถเชื่อมเป็น API documentation ให้เราได้ ไม่มีใครชอบเขียนเอกสารเนาะ คิดว่าในนี้คงไม่มีใครชอบเขียนเอกสาร เราคงอยากให้เขียนโค้ดแล้วก็มีหน้าตาแบบ API documentation ให้เราเลยเนาะ ซึ่งตัว Elysia เนี่ย มันสามารถทำอย่างงั้นได้ ก็คือเราสามารถแปลงโค้ดเป็นตัวเอกสารได้

ซึ่งวิธีที่ง่ายที่สุดก็คือ เรา import plugin ชื่อ OpenAPI และก็กดใช้ แค่นี้เนี่ย เราก็จะได้ตัวหน้าตาโค้ด หน้าตา endpoint หน้าตาตัว API documentation เป็นประมาณอย่างงี้ มี endpoint มี body มีอะไรที่เราสามารถ interact ได้

ทีนี้เนี่ย สมมติเรามี endpoint ประมาณนี้เนาะ มี endpoint post และก็มี body เป็น object รับเป็น name string เนาะ ถ้าเราไปดูที่ตัว API documentation เนี่ย

มันก็จะขึ้นมาเป็นประมาณอย่างงี้มาให้ ก็คือจะขึ้นเป็น input มาให้ว่า เนี้ย endpoint เนี้ยสามารถรับค่านี้ได้นะ แต่ว่าสังเกตเห็นไหมว่า สิ่งเดียวที่เรามีเนี่ย มันคือมีแค่ body อย่างเดียว ไอ้สิ่งที่เราอยากได้จริงๆ เนี่ย นอกจาก body แล้วเนี่ย มันก็มีประโยชน์แล้วแหละ แต่ว่าเราสามารถมีได้มากกว่านั้นอีก ก็คือเราขาดตัว response หรือก็คือ

ค่าที่ API เนี่ยจะสามารถส่งค่ากลับมาได้ ก็คือเรามี body แล้วเนาะ เราจะเห็นว่า API endpoint เนี่ย มันอาจจะ 200 ส่งค่าเป็น name กลับมา หรืออาจจะส่งค่าเป็น something ที่ไม่ถูกต้องเนาะ เช่น ถ้าผมกลับไปดูตรงนี้ เห็นไหมว่าโค้ดตรงนี้เนี่ย มันสามารถ return code 200 ได้ก็คือตรงนี้ และก็ return code 418 ได้คือตรงนี้ อีกเคสหนึ่งก็คือ ถ้าหากว่าตัว body เนี่ย มันถูกส่งเข้ามาไม่ถูกต้อง มันก็จะส่งเป็น 422 ใช่ไหม

ไอ้ตอนนี้ที่เรามีคือเป็นแค่ประมาณอย่างงี้

การเขียน Response ใน Docs เองมักมีปัญหาไม่อัปเดตตามโค้ดจริง18:00

แต่ที่เราอยากได้คืออย่างงี้ใช่ไหม เพราะว่าแน่นอนว่าเราอยากได้อย่างงี้ ก็คือมีทุกอย่างออกมาให้เลยว่า endpoint เนี้ยสามารถส่งค่าอะไรกลับมาได้บ้าง สิ่งที่เราสามารถทำได้ก็คือ เราสามารถบอกได้ว่า เราอยากให้มี response 200

กับ 418 ใช่ไหม อันเนี้ยคือวิธีที่อาจจะใช้แก้ได้เนาะ

แต่ว่าปัญหาก็คือ สมมติ server เรามีอยู่ 200 endpoint

และเราต้องแก้มันทุกวัน สมมติเราเพิ่มหนึ่ง field เราก็ต้องมาแก้อันเนี้ย มันก็จะไม่ sync กันใช่ไหม เราต้องมานั่งสมมติเรา return ค่ากลับมา เพิ่ม field เดียวเนี่ย เราก็ต้องมานั่งแก้อันนี้ด้วย ซึ่งมันค่อนข้างน่ารำคาญเนาะ ซึ่งในความเป็นจริงแล้ว มันไม่มีใครมาอยากนั่งเขียนตรงนี้หรอก ว่าค่าที่ถูกส่งกลับมามันเป็นอะไรได้ใช่ไหม เพราะ endpoint อันหนึ่งเนี่ย วันหนึ่งเราแก้ไม่รู้เท่าไหร่ แล้วมันเยอะอะ คือเราไม่อยากมานั่งแก้เอง เราอยากแค่แก้โค้ดแล้วมันได้เอกสารออกมาเลย

ฟีเจอร์เฉพาะของ Elysia: อ่าน TypeScript Type มาเจนเป็น API Docs ให้ทำงานแทนคน18:59

สิ่งที่เราสามารถทำได้ก็คือ เราสามารถเอาตัว type เนี่ยมาแปลงเป็นตัว API document ได้ ซึ่งอันเนี้ย เป็น feature unique ของ Elysia ก็คือปกติแล้วเนี่ย เราต้องเขียนโค้ดสักอย่างขึ้นมาเพื่ออธิบายว่า มันสามารถทำอะไรได้บ้าง แต่สิ่งที่ Elysia สามารถทำได้เนี่ย ก็คือเราเพิ่ม เอาโค้ดให้ดูก่อน คือเราเพิ่มหนึ่งบรรทัดชื่อว่า reference จาก type ซึ่งตรงนี้

ทีนี้ เรากลับมาดูโค้ดเนาะ โค้ดเป็นประมาณอย่างงี้ เราไม่มี response ใช่ไหม ถ้าเรากลับไปดูที่ตัว API documentation เนี่ย มันจะมี field โผล่ขึ้นมาอัตโนมัติ โดยที่เราไม่ต้องเขียนเอง อันเนี้ย คือสิ่งที่เราอยากได้ และนี่คือสิ่งที่ Elysia สามารถทำได้ โดยการที่แบบว่า โค้ดตรงนี้เนี่ย ถ้าเราย้อนกลับไปดูเนาะ เราจะเห็นว่า function เนี้ย มันมี return type ออกมา ตัว TypeScript เนี้ย มันสามารถคำนวณออกมาได้ แต่ว่าเราไม่สามารถไปเตะต้องมันได้ ใช่ไหม สิ่งที่ Elysia ทำเนี่ย คือมันอ่านตัว TypeScript type ออกมา แล้วแปลงเป็นตัว API documentation ให้โดยอัตโนมัติ อันเนี้ย เป็นสิ่งที่ มีแค่ Elysia ที่ทำได้

ค่อนข้างภูมิใจมาก ก็คือมันเป็น unique feature เพราะว่า มันใช้ TypeScript ที่ค่อนข้างซับซ้อนมากๆ ในการทำ

ซึ่ง feature เนี้ย มันสามารถใช้กับตัว Prisma ใช้กับ Drizzle หรือใช้กับไลบรารีอะไรก็ได้ แทบจะประมาณ 99% สามารถใช้ได้ อาจจะต้องมี work around บางอย่าง ในเคสที่แบบว่า ประหลาดมากๆ นิดหนึ่ง

เอาเป็นว่าเรามาดูเดโมกันดีกว่าเนาะ

เดโม 1: Response ถูกเพิ่มลงใน API Docs อัตโนมัติโดยไม่ต้องเขียนอะไรเพิ่ม20:38

ปึ๊บ โอเค เรามาดูโค้ดตรงนี้นิดหนึ่ง

ก็คือ

เรามีโค้ดอย่างงี้ใช่ไหม ปึ๊บ และเราก็มี endpoint อันนี้ เรากลับไปดูตรงนี้ ปึ๊บ ปึ๊บ ปึ๊บ ปึ๊บ

ผมขอปิดอันนี้ นิดหนึ่ง

อ่ะ sidebar เนาะ โอเค คือตอนนี้เรามี endpoint ประมาณอย่างงี้เนาะ เรามี endpoint ชื่อ user อันนี้เป็น GET เนาะ อันนี้เป็น PUT เป็น PUT user จะเห็นว่า เรามีค่า name มีค่า bio ใช่ไหม เป็นค่าที่สามารถรับขึ้นมาได้ ถ้าเราย้อนกลับไปดูในโค้ดของเรา ปึ๊บ เป็น module user มันก็คือ endpoint นี้ใช่ไหม มันคือ endpoint นี้เนาะ แล้วจะเห็นว่า เอ้ย มันมี name มี bio ออกมา มีสอง field ใช่ไหม อ่ะ แต่ทีนี้เนี่ย เราจะเห็นว่า มันมีค่า something ที่มันถูกส่งค่ากลับมาจาก Prisma ก็คือค่าเป็นประมาณอย่างงี้ แต่มันไม่ขึ้นในตัว API endpoint ใช่ไหม ปกติเนี่ย เราก็ต้องมาเขียน response ตรงนี้เพิ่มเอง ว่าอยากให้มีอะไรบ้าง แต่ สิ่งที่เราสามารถทำได้ อย่างที่ผมบอกเมื่อกี้คือ เราเพิ่มโค้ดตรงนี้

ปึ๊บ จะเห็นว่า endpoint เดิมเนี่ย มี response ถูกเพิ่มขึ้นมา โดยอัตโนมัติ โดยที่เราไม่ต้องไปเพิ่มโค้ดอะไรเลย แล้ว endpoint ตรงนี้เนี่ย มันถูกเพิ่มในทุก endpoint ที่เรามี ไม่ว่าจะเป็นอะไรก็ตาม อันเนี้ย คือเป็นโค้ดที่ผมไม่ได้เขียนเลย แต่ว่าตัว Elysia เนี่ย มันสามารถไปอ่านโค้ดของเรา แล้วแปลงเป็นตัว documentation ขึ้นมาให้ได้ สมมติ อ่ะ ผมมีอันนี้ใช่ไหม endpoint นี้ getUser หน้าตาเป็นประมาณอย่างงี้เนาะ return ค่า 4 field โอเคไหม อ่ะ เราลองคลิก get ดู ปึ๊บ ได้เป็นประมาณอย่างงี้ อ่ะ array และก็ object 4 field ทีนี้ สมมติว่าผมกลับไปตัวที่โค้ด

เดโม 2: แค่แก้โค้ดเพิ่ม Field ที่หลังบ้าน ตัว API Docs ก็จะอัปเดตตามทันที22:44

ไปที่ตัวโค้ดเนาะ มันคือตัว endpoint นี้ สมมติผมเพิ่ม อยากให้มันเพิ่มค่าเข้ามา สมมติอยากให้เพิ่มเป็น include เป็น posts แล้วกัน

อ่ะ เซฟ ปึ๊บ อ่ะ ผมเซฟนะ

แล้วผมกลับไปที่ตัว API reference เนาะ เราจะเห็นว่า ตรงนี้เนี่ย มันมี field ถูกเพิ่มขึ้นมา อันนี้เป็น field เดิมที่เรามี และตรงนี้เนี่ย เป็น field ที่เราถูกเพิ่มเข้ามาเมื่อกี้ โดยที่เราไม่ได้แก้โค้ดอะไรเลย แต่มันจะไปขึ้นที่ตัว documentation ว่า เฮ้ย มันมีโค้ดเพิ่มขึ้นมาเนี่ย โดยที่เราไม่ต้องไปอธิบายให้ฟังเลยนะว่า โดยปกติแล้วเนี่ย ตรงนี้เราต้องมานั่งเขียนเอง

อธิบายเองว่ามันเป็นยังไงเนาะ ถ้าเราอยากรู้ว่าโค้ดมันเป็นยังไงเนี่ย คือปกติเราจะต้องเขียนหน้าตาเป็นประมาณนี้ ซึ่งเห็นไหมว่ามันแบบ ยาวมาก แต่โค้ดที่เราเขียนเนี่ย ไม่มีเลย มีแค่นี้ เราแค่ส่งค่ากลับมา แค่ส่งค่าจริงๆ กลับมา แล้ว Elysia เนี่ย จะแปลงตัว type เป็นพวกนี้มาให้โดยอัตโนมัติ อ่ะ เราลองเรียกตัว endpoint ดู ปึ๊บ ก็จะเห็นว่า เอ้ย มันก็มีค่าจริงๆ กลับมาให้ ก็หมายความว่าไอ้โค้ดตรงนี้เนี่ย ไม่ว่าเราจะส่งค่าอะไรกลับมาเนี่ย มันจะขึ้นเป็นตัว documentation ให้เราอัตโนมัติเลย ไม่ว่าเราจะทำอะไรก็ตาม โดยที่เราไม่ต้องไปแตะโค้ด ไม่ต้องไปเขียนอธิบายเลยว่า field นี้ มันสามารถส่งค่าอะไรกลับมาได้บ้าง รวมถึงตัว body รวมถึงอะไรพวกนี้ด้วย ทีนี้ ตัว end-to-end safety ที่อยากให้โชว์นิดหนึ่ง

เดโม 3: การดึง API ไปแสดงผลด้วย React แบบ End-to-end Type Safety24:15

อันนี้เป็น feature unique ของ Elysia เนาะ ซึ่งมันสามารถเชื่อมจาก database มาตัว server มาที่ตัว API documentation ได้ แต่นอกเหนือจากนี้เนี่ย เราสามารถไปที่

สมมติเรามีหน้าบ้าน อันนี้เป็นหน้าบ้านเนาะ ผมเรียกมาเป็นจาก ตัวนี้ โค้ดเป็น React ทั่วไปเลย public โป๊ะ จะเห็นว่า นี่ เรามี API ประมาณอย่างงี้เนาะ

แอปตรงนี้เนี่ย เราก็ import มาจากตัวหลังบ้านเมื่อกี้ จากโค้ดตัวเมื่อกี้เลย เรา import ตัว function เชื่อมมาเนาะ แล้วเราบอกว่า เราเรียก API user แล้วก็เอาข้อมูล get มา ทีนี้ เราลองดูโค้ดตรงนี้ ก็จะเห็นว่า อ่ะ เอาเป็นว่าตรงนี้มันมี สามารถ return ได้หลายอย่างเนาะ แต่เอาเป็นว่า หลักๆ คือเรามาดูตรงนี้ ปึ๊บ data อันนี้คือโค้ดที่เราสามารถส่งกลับมาได้ใช่ไหม จะเห็นว่า ตรงนี้เรามี post และก็มีตัว object 4 อันเมื่อกี้เนาะ สมมติผมบอกว่า ตอนนี้ผมใช้ name อยู่ใช่ไหม สมมติหลังบ้านเนี่ย อยากเอา field name ออก

เดโม 4: ทันทีที่แก้ไข Database ตัด Field ทิ้ง โค้ดที่เรียกใช้หน้าบ้านจะขึ้นแถบแจ้ง Error ให้เห็นทันที25:19

อันนี้ก็จะเห็นว่า เราเป็นปกติอยู่ เราสามารถจัดการทุกอย่างได้ ถ้าสมมติ หลังบ้านบอกว่า เอ้ย ไม่อยากได้ name ละ เรา return something เราไปแก้ที่ database อ่ะ ไปแก้ที่ Prisma เนาะ Prisma Prisma ปึ๊บ เราบอกว่า name เอ่อ เอา bio แล้วกัน เพราะว่า name เป็น unique ผมขี้เกียจแก้ เอาเป็น bio เนาะ ผม comment ออก ปึ๊บ

แล้วก็ไปซิงค์ตัว database

Yes, yes. โอเค ปึ๊บ. อันนี้ก็จะเชื่อม ทีนี้เมื่อกี้คือเราไปอัปเดต ตัว database หลังบ้านว่าเราเอา field bio ออกใช่ไหม? เดิมทีเรามี 4 field. มี id, name, bio, createAt. มี 4 field. แต่อันนี้ผมบอกว่าผมเอาออก ปึ๊บ. แล้วผมกลับไปดูที่ตัวหน้าบ้าน ตัวหน้าบ้านอยู่ที่ตรงนี้ ปึ๊บ. จะเห็นว่าเฮ้ย ตรงนี้มันมีไฮไลต์ว่า

ไอ้ property bio เนี่ยมันไม่มีแล้วนะ เพราะว่าเมื่อกี้เราไปอัปเดตโค้ดที่ database ใช่ไหม ว่าเอา field นี้ออก ตัวหน้าบ้านเนี่ย ก็จะขึ้นเหมือนกันว่าเอ้ย field นี้มันถูกเอาออกไปแล้ว มันไม่มีอยู่ เพราะฉะนั้นเราจะต้องมาอัปเดตตรงนี้. ทำให้โค้ดทุกอย่างเนี่ยมันเชื่อมตั้งแต่ database มายัน server มายันหลังบ้าน และก็ถ้าเราไปดูที่ตัว API endpoint เหมือนกันเนี่ย กลับไปที่ตรงนี้ ปึ๊บ รีโหลด. ก็จะเห็นว่า field ตรงนี้เนี่ยเหลือ property แค่ 3 อัน คือตัว bio เนี่ยถูกตัดออกไปแล้ว. อันนี้เนี่ยคือสิ่งที่ผมอธิบายว่า มันคือการเชื่อมโค้ดจากตัว database มา API

มาหน้าบ้าน หลังบ้าน ยัน test case ยันตัว API documentation โดยอัตโนมัติ. อันนี้คือเป็นฟีเจอร์ที่เราพยายามผลักดันอยู่ตอนนี้ ก็คือทุกอย่างมันเชื่อมกันโดยที่เราไม่ต้องจัดการอะไรเลย. ทุกอย่างมันเชื่อมหมด ทั้ง type ทั้ง error ทั้งอะไรทุกอย่าง ซึ่งเป็นฟีเจอร์ที่สมัยก่อน ไม่สามารถทำได้เนาะ แต่สมัยนี้ TypeScript มันพัฒนาขึ้นไปค่อนข้างเยอะมากๆ ละ จนเราสามารถทำอะไรพวกนี้ได้. ซึ่งมันเป็นฟีเจอร์ที่แบบว่าพวก Express, Fastify หรือ NestJS เนี่ยไม่สามารถพัฒนาขึ้นมาได้ เพราะว่ามันต้องเขียนใหม่เกือบทั้งหมดเลย

เพื่อให้สามารถทำแบบนี้ได้ ซึ่งตัว Elysia เนี่ย สามารถทำได้ และก็จะมี framework อีก 2-3 อัน ก็คือที่ผมบอกไปเมื่อกี้. แต่หลักๆ ก็คือเป็นประมาณนี้ครับ.

ประมวลผลสรุปและแจกโค้ดทดลอง พร้อมสถิติการเติบโตปัจจุบันของ Elysia27:53

ถ้าใครอยากลองเอา repo เอาโค้ดเมื่อกี้เนี่ยไปลองรันเอง

สามารถสแกน QR code ตรงนี้ได้นะ ถ้าใครอยากได้.

ใช่ครับ มันจะเชื่อมให้อัตโนมัติเลย.

สุดท้ายก็คือตัว Elysia เนี่ยตอนนี้เรามี weekly download อยู่ที่ 4 แสนเนาะ. ถ้าเดือนหนึ่งก็จะนับเป็น 1 ล้าน ล้านกว่าๆ และก็มีดาวอยู่ที่ 17,000 กว่าดวงบน GitHub เนาะ.

เพิ่ม description อธิบาย API เพิ่มได้ไหมครับ? ได้ครับ ได้ๆ.

ก็เอาเป็นว่าทั้งหมดของวันนี้ก็มีเท่านี้ครับ.