TypeSpec: Ngôn ngữ mới cho phát triển tập trung vào API

 (typespec.io)
6 điểm bởi GN⁺ 2024-05-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • TypeSpec là ngôn ngữ mới cho phát triển API, được thiết kế để đáp ứng nhu cầu của các nhà phát triển, nhà thiết kế và nhà quản lý API
    • Được xây dựng trong bối cảnh việc cung cấp API chất lượng cao và trải nghiệm liên quan một cách nhất quán ngày càng phức tạp hơn nhưng cũng ngày càng quan trọng
    • TypeSpec không chỉ là một ngôn ngữ; nó là một nền tảng cho phép trừu tượng hóa, khuyến khích tái sử dụng mã và tận dụng các công cụ hiện đại cho phát triển nhanh

Đặc điểm nổi bật của TypeSpec

  • Khả năng tương tác
    • TypeSpec không phải là ngôn ngữ mô tả API đơn thuần mà là ngôn ngữ định nghĩa cấp cao có thể đồng thời xuất ra API, nhiều giao thức, client, server và tài liệu
    • Tương thích với các ngôn ngữ định nghĩa API chuẩn của ngành, giúp thu hẹp khoảng cách giữa các lựa chọn
  • Năng suất
    • TypeSpec mang đến trải nghiệm nhà phát triển giúp quá trình định nghĩa dữ liệu và API trở nên thú vị và hiệu quả hơn
    • Ngôn ngữ ngắn gọn và có thể định nghĩa dữ liệu và cấu trúc API phức tạp với ít dữ liệu đầu vào nhất
  • Mẫu API
    • TypeSpec nâng cao chất lượng API bằng cách đóng gói các loại dữ liệu phổ biến, mẫu API và hướng dẫn thành các thành phần có thể tái sử dụng ở cấp cao, dùng chung cho cả nhóm hoặc toàn hệ sinh thái
  • Tính quen thuộc
    • TypeSpec lấy cảm hứng từ TypeScript và C#, nên dễ học và dễ gây quen thuộc cho nhiều nhà phát triển
  • Khả năng mở rộng
    • TypeSpec có thể mở rộng bằng từ vựng decorator tùy chỉnh và mẫu kiểu, giúp mô hình hóa API trong miền logic nghiệp vụ hoặc logic ứng dụng
  • Hệ sinh thái
    • Khi sử dụng TypeSpec, bạn có thể đóng gói các kiểu dùng chung, phần mở rộng ngôn ngữ, linter và emitter rồi phát hành lên NPM trên toàn tổ chức hoặc toàn hệ sinh thái

Cộng đồng và hợp tác

  • Đang được Microsoft sử dụng
    • Microsoft đang đổi mới quy trình phát triển API bằng TypeSpec
    • Nhiều dịch vụ Azure đã áp dụng TypeSpec và số lượng này đang tăng lên mỗi ngày
    • Nhóm Microsoft Graph đang tận dụng tiềm năng của TypeSpec để nâng cao năng suất và đơn giản hóa tùy chỉnh
  • Mời tham gia
    • TypeSpec không chỉ là một ngôn ngữ; nó là cộng đồng
    • Mọi nhà phát triển từ mọi nền tảng đều được mời tham gia bản beta công khai để trực tiếp trải nghiệm sức mạnh của TypeSpec

Ý kiến của GN⁺

  • TypeSpec là ngôn ngữ định nghĩa API có mức trừu tượng cao, dường như có thể cải thiện theo hướng đột phá cách phát triển API
    • Hỗ trợ tiếp cận "API First" nên có thể giúp nâng cao hiệu quả phát triển và chất lượng sản phẩm đầu ra
    • Với việc hỗ trợ nhiều giao thức, tính mở rộng và hệ sinh thái mạnh mẽ, sản phẩm dự kiến sẽ phù hợp cho nhiều kịch bản phát triển
  • Tuy nhiên, việc áp dụng ngôn ngữ mới luôn phát sinh chi phí học tập, nên cần có đào tạo đầy đủ trước khi triển khai trong team
    • Việc mượn cú pháp TypeScript và C# để hạ thấp độ dốc học tập là điểm tích cực
  • Cần làm rõ hơn điểm khác biệt với các ngôn ngữ định nghĩa API cùng vai trò trước đây như Swagger, RAML, API Blueprint, v.v.
    • cách nó vượt qua các hạn chế của ngôn ngữ hiện có, mức độ dễ dàng khi di chuyển (migration), v.v.
  • Cách Microsoft trước tiên dùng nội bộ rồi liên tục cải tiến theo hướng dogfooding tạo cảm giác tin cậy
    • Tuy nhiên, vì đây mới là dự án mã nguồn mở công bố chưa lâu, nên trong vài năm tới sự phát triển liên tục và hỗ trợ cộng đồng sẽ là yếu tố then chốt
  • Mục tiêu chuẩn hóa thiết kế API và nâng cao tính tái sử dụng là đúng đắn, nhưng cũng có cảm giác rằng quá nhiều vấn đề đang được giải quyết cùng lúc
    • Nên tăng cường và mở rộng các tính năng theo từng giai đoạn

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-02
Ý kiến trên Hacker News

  • Đã có sẵn kiểu TypeScript cho API, nên tôi đã tạo https://github.com/vega/ts-json-schema-generator để sinh JSON schema trực tiếp từ mã nguồn
    Bộ tính năng của hai ngôn ngữ hơi khác nhau nên có vài chỗ kỳ quặc, nhưng tôi đã dùng ổn trong nhiều năm. Nếu không có TypeScript, hoặc bề mặt API đủ nhỏ để viết lại kiểu cũng không sao, thì TypeSpec cũng đáng để xem thử. Dù sao nó chắc chắn vẫn tốt hơn tự tay viết JSON schema

  • Đặt cạnh YAML của OpenAPI thì cái gì trông cũng đẹp hơn, nên cảm giác hơi gian lận. Dù vậy, tôi vẫn cho rằng OpenAPI là một trong những thay đổi tốt nhất
    Mặt khác, từ lâu tôi đã khá mong TypeScript trở thành một ngôn ngữ schema. Chính xác hơn là một tập con phi mệnh lệnh, phi hàm, lớn đến mức đáng ngạc nhiên. Ấn tượng đầu tiên của tôi là nó giống với ý tưởng: “Nếu bỏ JavaScript khỏi TypeScript, chỉ giữ lại các kiểu cho JSON, rồi thêm mô tả metadata endpoint để nó trở thành người kế nhiệm trên thực tế của OpenAPI và WSDL thì sao?”

    • “Đặt cạnh YAML của OpenAPI thì cái gì trông cũng đẹp hơn”, vậy để tôi thử thách điều đó
      https://github.com/bufbuild/protovalidate/blob/main/examples...
    • Hệ thống kiểu của TypeScript rất cao cấp, nên có lẽ không thể tạo binding tương ứng cho mọi ngôn ngữ lớn mà vẫn giữ được cảm giác tự nhiên của từng ngôn ngữ. Một ngôn ngữ API đơn giản và trực quan sẽ tốt hơn nhiều

  • Gần đây tôi đang dùng TypeSpec cho API, vì tôi tìm một công cụ có thể mô tả API như GraphQL nhưng vẫn cho phép tiếp cận theo hướng thiết kế trước
    Các trình biên tập OpenAPI đều quá cồng kềnh, và quan hệ dữ liệu trong API không hiện ra rõ ràng. TypeSpec đúng là công cụ tôi tìm kiếm và thực sự hữu ích ở điểm đó

  • Microsoft nói họ tin vào giá trị của việc “dogfooding” chính sản phẩm của mình, nhưng nhìn vào hệ sinh thái hỗn loạn của phát triển desktop Windows native hay việc chấp nhận Xamarin/MAUI cho ứng dụng di động thì tôi không thấy vậy

    • Windows đang dogfooding tất cả các lựa chọn phát triển ứng dụng native cùng một lúc
    • Dogfooding không có nghĩa là cứ mỗi khi có công nghệ mới là phải viết lại mọi thứ từ đầu
    • Cũng có thể đây là chính sách mới, hoặc chỉ áp dụng cho sản phẩm này nên thuận tiện cho marketing
      Tôi từng thử quản lý email bằng Microsoft Graph; nếu Outlook thực sự dùng nó thì tôi sẽ khá ngạc nhiên

  • Vì là thứ do Microsoft làm nên nó giống như một câu trả lời dành cho GraphQL. Nếu họ thật sự dogfood nó nội bộ, thì chất lượng công cụ có thể sẽ ổn hơn hàng do một consortium mã nguồn mở chắp vá làm ra
    Tôi vẫn chưa chắc, nhưng có vẻ nó có thể thu hút được nhiều sự chú ý hơn

    • Tôi làm trong nhóm này, và khó có thể xem TypeSpec là GraphQL, nên chỉ riêng TypeSpec sẽ khó đạt được vị thế đó
      GraphQL mang theo rất nhiều giả định mạnh về giao thức, xử lý lỗi, ngữ nghĩa truy vấn và những thứ cần thiết để xây dựng ứng dụng cụ thể. Trong khi đó, cốt lõi của TypeSpec gần hơn với một DSL mô tả API không kèm giả định. Các binding giao thức cụ thể được thêm vào dưới dạng thư viện, và thư viện GraphQL cũng là thứ chúng tôi đã cân nhắc từ lâu
      Tóm lại, nếu Microsoft tạo ra một gói giả định để giải quyết các kịch bản tương tự GraphQL, thì trong bối cảnh đó họ có thể dùng TypeSpec làm ngôn ngữ mô tả API. Nhưng không đúng khi đồng nhất các giả định đó với chính TypeSpec

  • Tôi không tìm thấy câu hỏi cốt lõi là các ngôn ngữ đầu ra được hỗ trợ. Chẳng lẽ chỉ còn cách xuất sang OpenAPI rồi dùng một trong các bộ sinh mã khủng khiếp bên đó?

    • Bạn có thể tự tạo emitter, và tài liệu có hướng dẫn cách làm. Nhóm chúng tôi đã làm emitter tùy chỉnh cho TypeSpec để xuất ra một bộ SDK và thư viện

  • Trông giống WSDL phiên bản TypeScript
    https://en.wikipedia.org/wiki/Web_Services_Description_Langu...
    Liệu nó có sống lâu hơn WSDL không?

    • Tôi vẫn đang dùng WSDL, chính xác hơn là nền tảng nơi tôi làm việc vẫn dùng. Có thể nó không còn thịnh hành với công nghệ mới, nhưng nó vẫn sống. Cứ chê cũng được, nhưng XML được sinh ra vẫn còn tốt hơn việc sinh YAML
    • Có thể bạn đã biết rồi, nhưng phép so sánh chính xác hơn là WSDL+SOAP
      WSDL và SOAP được định nghĩa bằng XML, còn SOAP mô tả XML. Mức độ phổ biến của các công nghệ này lên xuống theo độ phổ biến chung của XML. TypeSpec mô tả JSON và protobuf, nên nếu các định dạng đó mất nhiệt thì TypeSpec cũng rất có thể sẽ mất sức hút
    • Vấn đề của WSDL là nó do nhiều ủy ban của các tập đoàn lớn cùng thiết kế. Vì vậy nó thiếu nhất quán và phình to. Nhiều tiêu chuẩn liên quan đến XML cũng vậy
      Ngày nay, các tập đoàn lớn thường thích tung giải pháp riêng ra thị trường để chiếm thị phần hơn là cùng hợp tác. Kết quả là đôi khi ta có được cách tiếp cận chất lượng hơn vì một nhóm tập trung vào một mục tiêu duy nhất. Vẫn tốt hơn là cố làm hài lòng 10 nhà cung cấp với các chương trình nghị sự khác nhau

  • Sẽ hay nếu có thể chỉ cần import file TypeSpec vào TypeScript hay ngôn ngữ khác để tự động có kiểu TypeScript
    Sinh mã thì phiền và dễ lỗi

    • Tôi nhìn chung lại thích sinh mã hơn. Tôi không hiểu vì sao nó lại dễ lỗi hơn các cách khác
      Thậm chí còn có thể dễ debug hơn, vì lỗi không bị giấu dưới hai tầng trừu tượng. Với mã được sinh ra, bạn còn có thể thêm bước build để обход những thiếu sót hay lỗi của bộ sinh; còn với cách khác thì nhiều khi đành phải chấp nhận nguyên trạng
      Tôi hiểu ý “phiền”. Phản hồi tức thì rõ ràng tốt hơn phải chạy lại build, nên ở những phần phải chỉnh sửa lặp lại nhiều thì lợi thế của phía ngược lại cũng lớn hơn
    • Nó cũng trông rất giống TypeScript. Ngay từ đầu, tại sao không dùng TypeScript để mô tả API? Vừa có được kiểu TypeScript, vừa có thể sinh ngay OpenAPI schema để phục vụ ở /openapi chẳng phải tốt hơn sao?

  • Có thể chuyển đổi sang chuỗi công cụ cần YAML không?
    Sẽ rất đáng mừng nếu có một IDL cấp cao có thể tạo schema và stub cho nhiều ngôn ngữ, giống như CORBA IDL đã làm cách đây 25 năm

    • Vài ngày trước tôi đã bổ sung hỗ trợ dùng TypeSpec làm đặc tả đầu vào cho bộ sinh mã dựa trên OpenAPI 3 của mình
      Việc này khá suôn sẻ nhờ có API chuyển đổi sang tài liệu OpenAPI (https://github.com/mnahkies/openapi-code-generator/pull/158)
      Tôi đang tập trung vào việc tạo cả SDK phía client lẫn stub phía server, nhưng hiện vẫn chỉ hỗ trợ TypeScript. Khi đã hài lòng với độ hoàn thiện của template TypeScript, tôi muốn một ngày nào đó sẽ bổ sung thêm các ngôn ngữ khác
    • Bộ phát OpenAPI và JSON Schema có thể tạo YAML

  • Khó thuyết phục mọi người dùng một ngôn ngữ chuyên dụng, và đội ngũ làm ra nó cũng phải bỏ thêm khá nhiều công sức
    Mọi người không muốn học một ngôn ngữ chuyên dụng. Ngoài ra còn phải xây toàn bộ công cụ hệ sinh thái ngôn ngữ như compiler, tài liệu, language server, tích hợp IDE, quản lý phụ thuộc
    Có những nỗ lực tương tự như WaspLang và DarkLang, nhưng tôi vẫn chưa thấy chúng được dùng một cách đáng kể ngoài thực tế hay trên HN. Dùng ngôn ngữ hiện có và tập trung vào giá trị gia tăng có vẻ tốt hơn
    Cá nhân tôi cũng từng làm thứ có giá trị tương tự, tức là xây “nguồn chân lý duy nhất -> mọi thứ”, và đã trải qua phần nào nỗi đau này
    https://github.com/hofstadter-io/hof
    Ý tưởng là CUE + text/template = công cụ sinh mã không chỉ giới hạn cho API

    • Hoặc dùng cái này, hoặc tự viết OpenAPI YAML trực tiếp. Ngay cả với người đã biết YAML, cách này cũng đơn giản hơn nhiều để dựng định nghĩa OpenAPI cơ bản và sử dụng, so với việc tự tay viết tài liệu OpenAPI. Tự viết thực sự rất đau khổ
    • Khi lập trình bằng AI tạo sinh đang nổi lên, ngôn ngữ mới lại càng bất lợi hơn. Dù một framework mới có khách quan là tốt hơn, nếu AI chưa được huấn luyện về nó thì năng suất thực tế vẫn có thể thấp hơn
    • Cảm ơn hof. Tôi đang nghĩ đến việc thử nó cho một dự án. Tình trạng dự án hiện giờ thế nào? Có vẻ các commit gần đây đã ít đi, nên tôi muốn biết hiện tại nó có ổn định và dùng nguyên trạng được không