TypeSpec: ภาษาใหม่สำหรับการพัฒนาแบบเน้น API

 (typespec.io)
6 คะแนน โดย GN⁺ 2024-05-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • TypeSpec เป็นภาษาใหม่สำหรับการพัฒนาแบบเน้น API ซึ่งออกแบบมาเพื่อรองรับความต้องการของนักพัฒนา API, นักออกแบบ และผู้จัดการ API
    • พัฒนาขึ้นในบริบทที่การมอบ API และประสบการณ์ที่เกี่ยวข้องที่มีคุณภาพสูงอย่างสม่ำเสมอยิ่งซับซ้อนมากขึ้นและมีความสำคัญมากขึ้น
    • TypeSpec ไม่ได้เป็นเพียงภาษา แต่เป็นแพลตฟอร์มที่ทำให้เกิดการนามธรรม ส่งเสริมการนำโค้ดกลับมาใช้ใหม่ และใช้เครื่องมือที่ทันสมัยเพื่อการพัฒนาที่รวดเร็ว

คุณสมบัติหลักของ TypeSpec

  • ความเข้ากันได้
    • TypeSpec ไม่ได้เป็นแค่ภาษาอธิบาย API แบบง่าย ๆ แต่เป็นภาษาระดับสูงสำหรับการกำหนด API ที่สามารถสร้างผลลัพธ์ได้พร้อมกัน ทั้งโปรโตคอล, ไคลเอนต์, เซิร์ฟเวอร์ และเอกสาร
    • เข้ากันได้กับภาษาคำจำกัดความ API มาตรฐานของอุตสาหกรรม ช่วยลดช่องว่างระหว่างทางเลือกต่าง ๆ
  • ผลิตภาพ
    • TypeSpec มอบประสบการณ์นักพัฒนาที่ดีเยี่ยม ช่วยให้กระบวนการนิยามข้อมูลและ API มีความราบรื่นและมีประสิทธิภาพมากขึ้น
    • ภาษาออกแบบให้กระชับ ทำให้สามารถนิยามข้อมูลที่ซับซ้อนและรูปแบบ API ด้วยการป้อนข้อมูลน้อยที่สุดได้
  • รูปแบบ API
    • TypeSpec ช่วยยกระดับคุณภาพ API โดยบรรจุชนิดข้อมูลทั่วไป รูปแบบ API และแนวทางที่เป็นมาตรฐานเป็นองค์ประกอบที่นำกลับมาใช้ใหม่ได้ระดับสูง เพื่อแชร์ทั้งในทีมและระบบนิเวศทั้งหมด
  • ความคุ้นเคย
    • TypeSpec ได้รับแรงบันดาลใจจาก TypeScript และ C# จึงเรียนรู้ได้ง่ายและคุ้นเคยกับนักพัฒนาจำนวนมาก
  • ความยืดหยุ่น
    • TypeSpec สามารถขยายด้วยคำศัพท์ decorator และ type template ที่กำหนดเอง เพื่อจำลอง API ในโดเมนตรรกะทางธุรกิจหรือแอปพลิเคชันได้
  • ระบบนิเวศ
    • ด้วย TypeSpec คุณสามารถรวบรวม common types, การขยายภาษา, linter และ emitter เป็นแพ็กเกจ แล้วเผยแพร่บน NPM ให้ใช้ภายในองค์กรหรือระบบนิเวศทั้งหมด

ชุมชนและความร่วมมือ

  • การใช้งานของ Microsoft
    • Microsoft กำลังใช้ TypeSpec เพื่อสร้างการเปลี่ยนแปลงกระบวนการพัฒนา API
    • หลายบริการของ Azure ได้รับการนำ TypeSpec มาใช้งาน และจำนวนการใช้งานเพิ่มขึ้นทุกวัน
    • ทีม Microsoft Graph ใช้ศักยภาพของ TypeSpec เพื่อเพิ่มประสิทธิภาพการทำงานและทำให้การปรับแต่งง่ายขึ้น
  • คำเชิญให้เข้าร่วม
    • TypeSpec ไม่ได้เป็นแค่ภาษา แต่มันคือชุมชน
    • เชิญนักพัฒนาทุกระดับเข้าร่วม public beta เพื่อสัมผัสพลังของ TypeSpec ด้วยตัวเอง

ความคิดเห็นของ GN⁺

  • TypeSpec เป็นภาษานิยาม API ที่มีระดับนามธรรมสูง จึงมีแนวโน้มที่จะพัฒนาวิธีการพัฒนา API อย่างก้าวกระโดด
    • การรองรับแนวทาง "API First" จะช่วยเพิ่มประสิทธิภาพการพัฒนาและยกระดับคุณภาพของผลิตภัณฑ์สุดท้าย
    • ด้วยการรองรับโปรโตคอลหลากหลาย ความยืดหยุ่น และระบบนิเวศที่แข็งแกร่ง คาดว่าจะนำไปใช้ได้ในสถานการณ์การพัฒนาที่หลากหลาย
  • อย่างไรก็ตาม การนำภาษาใหม่มาใช้ย่อมมีต้นทุนด้านการเรียนรู้ จึงควรมีการอบรมให้เพียงพอก่อนการนำ TypeSpec มาใช้ในทีม
    • การยืมไวยากรณ์จาก TypeScript และ C# เพื่อลดความชันของเส้นการเรียนรู้ถือเป็นความพยายามที่ดี
  • ควรชี้ความแตกต่างจากภาษาเดิมที่มีบทบาทใกล้เคียงกัน เช่น Swagger, RAML, API Blueprint ให้ชัดเจนมากขึ้น
    • เช่น วิธีที่ช่วยข้ามข้อจำกัดของภาษาที่มีอยู่เดิม และความง่ายในการย้ายระบบ
  • แนวทาง dogfooding ที่ Microsoft นำมาใช้ภายในก่อนเป็นการใช้งานจริงนอกโลก ทำให้เกิดความเชื่อมั่น
    • อย่างไรก็ตาม โครงการโอเพ่นซอร์สยังเผยแพร่สู่สาธารณะไม่นาน จึงคาดว่าการพัฒนาอย่างต่อเนื่องและการสนับสนุนจากชุมชนในอีกหลายปีข้างหน้าจะเป็นกุญแจสำคัญ
  • การเน้นมาตรฐานการออกแบบ API และการเพิ่มความสามารถในการนำกลับมาใช้ใหม่เป็นทิศทางที่ถูกต้อง แม้จะรู้สึกว่าพยายามแก้ไขหลายประเด็นพร้อมกันเกินไป
    • ควรกำหนดลำดับความสำคัญและค่อย ๆ เสริมความสามารถเพิ่มเติมเป็นลำดับขั้น

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

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

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

  • มี TypeScript types สำหรับ API อยู่แล้ว เลยทำ https://github.com/vega/ts-json-schema-generator ที่สร้าง JSON schema จากซอร์สได้โดยตรง
    ชุดความสามารถของสองภาษานี้ต่างกันเล็กน้อยจึงมีบางจุดที่แปลก ๆ แต่ก็ใช้งานได้ดีมาหลายปีแล้ว ถ้าอยู่ในสถานการณ์ที่ไม่มี TypeScript หรือ API มีขอบเขตเล็กจนเขียน type ใหม่ก็ไม่เป็นไร TypeSpec ก็น่าลองดูเช่นกัน ยังไงก็ดีกว่าการเขียน JSON schema ด้วยมือแน่นอน

  • พอวางอะไรไว้ข้าง YAML ของ OpenAPI อะไรก็ดูดีไปหมด เลยรู้สึกเหมือนโกงนิดหน่อย แต่ถึงอย่างนั้น OpenAPI ก็ยังถือเป็นหนึ่งในความเปลี่ยนแปลงที่ดีที่สุด
    อีกด้านหนึ่ง ผมคาดหวังมานานพอสมควรว่า TypeScript จะตั้งตัวเป็น schema language ได้ พูดให้ชัดคือส่วนย่อยที่ไม่ใช่เชิงคำสั่งและไม่ใช่เชิงฟังก์ชัน ซึ่งมีขนาดใหญ่น่าประหลาดใจ ความประทับใจแรกคือมันดูใกล้เคียงกับแนวคิดว่า “ถ้าเอา JavaScript ออกจาก TypeScript เหลือไว้แต่ type สำหรับ JSON แล้วเพิ่มคำอธิบาย metadata ของ endpoint เพื่อให้เป็นผู้สืบทอดเชิงปฏิบัติของ OpenAPI และ WSDL จะเป็นอย่างไร”

    • “พอวางอะไรไว้ข้าง YAML ของ OpenAPI อะไรก็ดูดี” งั้นขอลองท้าทายดู
      https://github.com/bufbuild/protovalidate/blob/main/examples...
    • Type system ของ TypeScript ขั้นสูงมาก จึงดูเป็นไปไม่ได้ที่จะทำ binding รองรับภาษาหลักทั้งหมดพร้อมกับยังคงความเป็นธรรมชาติของแต่ละภาษาไว้ได้ ภาษา API ควรเรียบง่ายและตรงไปตรงมามากกว่า

  • ช่วงหลังใช้ TypeSpec กับ API อยู่ และกำลังหาเครื่องมือที่อธิบาย API ได้เหมือน GraphQL แต่ยังใช้แนวทาง design-first
    ตัวแก้ไข OpenAPI ทั้งหมดอืดเกินไป และไม่แสดงความสัมพันธ์ของข้อมูลใน API ได้ดี TypeSpec เป็นเครื่องมือที่ตามหาอยู่พอดี และช่วยได้มากจริง ๆ ในจุดนี้

  • Microsoft บอกว่าเชื่อในคุณค่าของ “dogfooding” คือใช้ผลิตภัณฑ์ของตัวเองจริง แต่ถ้าดู ecosystem ที่ยุ่งเหยิงของการพัฒนาเดสก์ท็อป Windows แบบ native หรือการนำ Xamarin/MAUI ไปใช้ในแอปมือถือ ก็ดูไม่เป็นอย่างนั้น

    • Windows กำลัง dogfood ตัวเลือกการพัฒนา native app ทั้งหมดพร้อมกัน
    • dogfooding ไม่ได้แปลว่าต้องเขียนทุกอย่างใหม่ตั้งแต่ต้นทุกครั้งที่มีเทคโนโลยีใหม่ออกมา
    • อาจเป็นนโยบายใหม่ หรืออาจเป็นกรณีที่ใช้กับผลิตภัณฑ์นี้เท่านั้นและเหมาะกับการทำการตลาด
      เคยจัดการอีเมลด้วย Microsoft Graph ถ้า Outlook ใช้มันจริงก็คงค่อนข้างแปลกใจ

  • เพราะมาจาก Microsoft เลยดูเหมือนเป็นคำตอบต่อ GraphQL ถ้ามีการ dogfood ภายในจริง คุณภาพของเครื่องมือก็อาจพอใช้ได้มากกว่าสิ่งที่คอนซอร์เซียมโอเพนซอร์สรีบปั้นขึ้นมา
    ยังไม่มั่นใจนัก แต่ดูมีโอกาสที่จะได้รับความสนใจมากขึ้น

    • ทำงานอยู่ในทีมนี้ และคงมองว่า TypeSpec เหมือนกับ GraphQL ได้ยาก ดังนั้น TypeSpec ล้วน ๆ คงไปอยู่ในตำแหน่งนั้นได้ยาก
      GraphQL มีสมมติฐานที่แข็งแรงหลายอย่าง เช่น protocol, error handling และ semantics ของ query ที่จำเป็นต่อการสร้างแอปพลิเคชันเฉพาะ ในทางกลับกัน แกนหลักของ TypeSpec ใกล้เคียงกับ DSL ที่ไม่มีสมมติฐานกำกับ สำหรับอธิบาย API มากกว่า การ binding กับ protocol เฉพาะจะเพิ่มผ่านไลบรารี และไลบรารี GraphQL ก็เป็นสิ่งที่พิจารณามานานแล้ว
      สรุปคือ ถ้า Microsoft สร้างชุดสมมติฐานเพื่อแก้ scenario ที่คล้ายกับ GraphQL ในบริบทนั้นก็สามารถใช้ TypeSpec เป็นภาษาอธิบาย API ได้ แต่ไม่ถูกต้องที่จะถือว่าสมมติฐานเหล่านั้นเป็นสิ่งเดียวกับตัว TypeSpec เอง

  • หาเรื่องสำคัญอย่าง ภาษาที่รองรับสำหรับ output ไม่เจอ แบบนี้มีทางเดียวคือต้อง export เป็น OpenAPI แล้วใช้ generator แย่ ๆ ตัวใดตัวหนึ่งของฝั่งนั้นหรือ?

    • คุณสร้าง emitter เองได้ และในเอกสารก็มีวิธีบอกไว้ ทีมของเราสร้าง emitter แบบกำหนดเองสำหรับ TypeSpec เพื่อ output ชุด SDK และไลบรารี

  • ดูเหมือน WSDL เวอร์ชัน TypeScript
    https://en.wikipedia.org/wiki/Web_Services_Description_Langu...
    จะอยู่ได้นานกว่า WSDL ไหม?

    • ทุกวันนี้ยังใช้ WSDL อยู่ และพูดให้ชัดคือแพลตฟอร์มที่ผมทำงานด้วยใช้อยู่ ถึงจะไม่เป็นที่นิยมสำหรับเทคโนโลยีใหม่ ๆ แต่ก็ยังไม่ตาย จะด่าก็ได้ แต่ XML ที่ generate ออกมายังดีกว่าการ generate YAML
    • คุณอาจรู้อยู่แล้ว แต่การเปรียบเทียบที่แม่นกว่าคือใกล้กับ WSDL+SOAP
      WSDL และ SOAP ถูกนิยามด้วย XML และ SOAP ก็อธิบาย XML ความนิยมของเทคโนโลยีเหล่านี้ขึ้นลงตามความนิยมของ XML โดยรวม TypeSpec อธิบาย JSON และ protobuf ดังนั้นถ้าความนิยมของ format เหล่านั้นลดลง TypeSpec ก็มีโอกาสเสียความนิยมไปด้วย
    • ปัญหาของ WSDL อยู่ที่มันถูกออกแบบโดยคณะกรรมการของบริษัทใหญ่หลายแห่ง จึงไม่สอดคล้องกันและบวมเกินไป มาตรฐานที่เกี่ยวกับ XML หลายอย่างก็เป็นแบบเดียวกัน
      ทุกวันนี้บริษัทใหญ่ ๆ มักชอบโยนโซลูชันของตัวเองเข้าสู่ตลาดเพื่อยึดส่วนแบ่ง มากกว่าทำงานร่วมกัน ผลลัพธ์คือบางครั้งได้แนวทางที่คุณภาพดีกว่า เพราะทีมเดียวโฟกัสกับเป้าหมายเดียว ดีกว่าต้องพยายามทำให้ vendor 10 รายที่ต่างมี agenda ของตัวเองพอใจ

  • อยากให้สามารถ import ไฟล์ TypeSpec จาก TypeScript หรือภาษาอื่น ๆ ได้ตรง ๆ แล้วได้ TypeScript types โดยอัตโนมัติ
    code generation ยุ่งยากและเกิดข้อผิดพลาดง่าย

    • โดยทั่วไปผมชอบ code generation มากกว่า ไม่รู้ว่าทำไมมันถึงเกิดข้อผิดพลาดง่ายกว่าวิธีอื่น
      ตรงกันข้าม มันอาจ debug ได้ง่ายกว่า เพราะ error ไม่ได้ซ่อนอยู่ใน abstraction สองชั้น โค้ดที่ generate แล้วสามารถเพิ่มขั้นตอน build เพื่อเลี่ยงข้อจำกัดหรือ bug ของ generator ได้ด้วย แต่ถ้าเป็นวิธีที่ไม่ generate ก็มักต้องรับสภาพตามนั้น
      ส่วนที่ว่า “ยุ่งยาก” นั้นเข้าใจได้ feedback ทันทีดีกว่าการรัน build ใหม่อยู่แล้ว ดังนั้นในพื้นที่ที่ต้องแก้ซ้ำบ่อย ๆ ข้อดีของอีกฝั่งก็มีมากเช่นกัน
    • ดูคล้าย TypeScript มากอยู่แล้ว แล้วทำไมถึงไม่ใช้ TypeScript สำหรับ คำอธิบาย API ตั้งแต่แรก? จะได้ TypeScript types และยัง generate OpenAPI schema สำหรับให้บริการที่ /openapi แบบทันทีได้ด้วย

  • จะสามารถแปลง YAML ให้เหมาะกับ toolchain ที่ต้องการได้ไหม?
    ถ้ามี IDL ระดับสูงที่ช่วยสร้างสคีมาและสตับสำหรับหลายภาษาได้ เหมือนที่ CORBA IDL เคยทำเมื่อ 25 ปีก่อน ก็น่าจะน่ายินดี

    • เมื่อไม่กี่วันก่อน ผมเพิ่มการรองรับ TypeSpec เป็นสเปกอินพุตในตัวสร้างโค้ดที่ใช้ OpenAPI 3 ของผม
      มันมี API สำหรับแปลงเป็นเอกสาร OpenAPI ให้ เลยทำได้ค่อนข้างง่าย (https://github.com/mnahkies/openapi-code-generator/pull/158)
      ผมโฟกัสทั้งการสร้าง client SDK และ server stub แต่ตอนนี้ยังรองรับเฉพาะ TypeScript เท่านั้น ถ้าพอใจกับความสมบูรณ์ของเทมเพลต TypeScript แล้ว สักวันก็อยากเพิ่มภาษาอื่นด้วย
    • ตัว emitter สำหรับ OpenAPI และ JSON Schema สามารถสร้าง YAML ได้

  • ภาษาเฉพาะทางโน้มน้าวให้คนใช้ได้ยาก และยังเพิ่มภาระให้ทีมที่สร้างมันค่อนข้างมาก
    คนไม่อยากเรียนภาษาเฉพาะทาง อีกทั้งยังต้องสร้าง เครื่องมือระบบนิเวศของภาษา ทั้งหมดเอง เช่น คอมไพเลอร์ เอกสาร language server การผสานรวมกับ IDE และการจัดการ dependency
    มีความพยายามคล้าย ๆ กันอย่าง WaspLang และ DarkLang แต่ยังไม่เห็นว่ามีการใช้อย่างมีนัยสำคัญในงานจริงหรือบน HN เลย ใช้ภาษาที่มีอยู่แล้วแล้วไปโฟกัสที่มูลค่าเพิ่มน่าจะดีกว่า
    ส่วนตัวผมก็เคยลองทำงานที่มีคุณค่าใกล้เคียงกัน คือ “แหล่งความจริงเดียว -> ทุกอย่าง” และก็เจอความเจ็บปวดแบบนี้มาบ้าง
    https://github.com/hofstadter-io/hof
    แนวคิดคือ CUE + text/template = เครื่องมือสร้างที่ไม่ได้จำกัดอยู่แค่ API

    • ทางเลือกคือใช้สิ่งนี้ หรือไม่ก็เขียน OpenAPI YAML โดยตรงอย่างใดอย่างหนึ่ง แม้สำหรับคนที่รู้จัก YAML การตั้งค่านิยาม OpenAPI พื้นฐานแล้วใช้งานด้วยวิธีนี้ก็ยังง่ายกว่าการเขียนเอกสาร OpenAPI ด้วยมือมาก การเขียนเองนี่ทรมานจริง ๆ
    • เมื่อการเขียนโปรแกรมด้วย generative AI เริ่มมาแรง ภาษาใหม่ ก็ยิ่งเสียเปรียบมากขึ้น ต่อให้เป็นเฟรมเวิร์กใหม่ที่ดีกว่าอย่างเป็นกลาง แต่ถ้า AI ไม่ได้เรียนรู้มันมา ประสิทธิภาพการผลิตจริงก็อาจต่ำกว่าได้
    • ขอบคุณสำหรับ hof กำลังคิดว่าจะลองใช้กับโปรเจกต์หนึ่ง ตอนนี้สถานะโปรเจกต์เป็นอย่างไรบ้าง? เห็นเหมือนคอมมิตช่วงหลังลดลง เลยอยากรู้ว่าปัจจุบันเสถียรและใช้ตามสภาพได้เลยไหม