TypeSpec: Bahasa Baru untuk Pengembangan Berpusat pada API

 (typespec.io)
6 poin oleh GN⁺ 2024-05-02 | 1 komentar | Bagikan ke WhatsApp
  • TypeSpec adalah bahasa baru untuk pengembangan berpusat pada API, dirancang untuk memenuhi kebutuhan pengembang, perancang, dan manajer API
    • Dibuat karena semakin berkembangnya lingkungan yang membuatnya lebih kompleks dan penting untuk secara konsisten menghadirkan API berkualitas tinggi serta pengalaman terkait yang baik
    • TypeSpec bukan sekadar bahasa; ini adalah platform yang memungkinkan abstraksi, mendorong penggunaan kembali kode, dan memanfaatkan alat modern untuk pengembangan cepat

Fitur utama TypeSpec

  • Interoperabilitas
    • TypeSpec bukan bahasa deskripsi API yang sederhana, melainkan bahasa definisi tingkat tinggi untuk mendefinisikan API dan sekaligus mengeluarkan output untuk berbagai protokol, klien, server, serta dokumentasi
    • Dapat berinteroperasi dengan bahasa definisi API standar industri dan menutup kesenjangan antar beragam pilihan
  • Produktivitas
    • TypeSpec menghadirkan pengalaman pengembang yang menyenangkan dan produktif agar data dan proses definisi API lebih bernilai
    • Bahasanya ringkas dan memungkinkan definisi bentuk data dan API yang kompleks dengan masukan yang minimal
  • Pola API
    • TypeSpec meningkatkan kualitas API dengan mengenkapsulasi jenis data umum, pola API, dan pedoman sebagai komponen tingkat tinggi yang dapat digunakan kembali dan dibagikan di seluruh tim atau ekosistem
  • Keterkenalan
    • TypeSpec terinspirasi dari TypeScript dan C#, sehingga mudah dipelajari dan terasa familier bagi banyak pengembang
  • Ekstensibilitas
    • TypeSpec bisa diperluatan dengan kosakata dekorator dan template tipe yang dapat disesuaikan, memungkinkan pemodelan API dari domain logika bisnis atau logika aplikasi
  • Ekosistem
    • Dengan TypeSpec, tipe umum, ekstensi bahasa, linter, dan emitter bisa dikemas dalam sebuah paket dan didistribusikan ke NPM di tingkat organisasi atau lintas ekosistem

Komunitas dan kolaborasi

  • Digunakan di Microsoft
    • Microsoft sedang berinovasi dalam proses pengembangan API-nya dengan TypeSpec
    • Banyak layanan Azure mengadopsi TypeSpec, dan jumlahnya terus meningkat setiap hari
    • Tim Microsoft Graph memanfaatkan potensi TypeSpec untuk meningkatkan produktivitas sekaligus menyederhanakan penyesuaian
  • Undangan berpartisipasi
    • TypeSpec adalah lebih dari sekadar bahasa; ini juga komunitas
    • Mengundang pengembang dari segala latar belakang untuk ikut serta dalam beta publik agar bisa merasakan langsung kekuatan TypeSpec

Pendapat GN⁺

  • TypeSpec tampaknya merupakan bahasa definisi API dengan level abstraksi tinggi yang berpotensi secara revolusioner menyempurnakan cara pengembangan API dilakukan
    • Dengan mendukung pendekatan "API First", diperkirakan dapat membantu meningkatkan efisiensi pengembangan dan kualitas produk akhir
    • Dukungan terhadap berbagai protokol, ekstensibilitas, dan ekosistem yang kuat membuatnya berpotensi diterapkan pada beragam skenario pengembangan
  • Namun, selalu ada biaya pembelajaran saat memperkenalkan bahasa baru, sehingga saat adopsi di dalam tim perlu didahului pelatihan yang memadai
    • Upaya menurunkan kurva pembelajaran dengan mengadopsi sintaks TypeScript dan C# adalah langkah positif
  • Diperlukan kejelasan lebih lanjut mengenai poin pembeda dari bahasa definisi API yang berperan serupa (Swagger, RAML, API Blueprint, dan lain-lain)
    • Misalnya bagaimana mengatasi keterbatasan bahasa yang sudah ada, dan seberapa mudah proses migrasinya
  • Pendekatan dogfooding di mana digunakan dan disempurnakan lebih dulu di Microsoft menumbuhkan rasa kepercayaan
    • Tetapi karena proyek sumber terbuka ini baru saja dipublikasikan, perkembangan berkelanjutan dan dukungan komunitas dalam beberapa tahun ke depan akan menjadi faktor penting
  • Arah peningkatan standarisasi dan keterpakaian kembali desain API memang tepat, tetapi terasa seperti ingin menyelesaikan terlalu banyak hal sekaligus
    • Akan lebih baik jika penguatan fitur dilakukan secara bertahap dengan prioritas

Bacaan terkait

1 komentar

 
GN⁺ 2024-05-02
Opini Hacker News

  • Karena sudah ada tipe TypeScript untuk API, saya membuat https://github.com/vega/ts-json-schema-generator yang menghasilkan skema JSON langsung dari sumber
    Karena himpunan fitur kedua bahasa sedikit berbeda, ada beberapa bagian yang terasa aneh, tetapi sudah saya pakai dengan baik selama beberapa tahun. Kalau tidak memakai TypeScript, atau permukaan API-nya kecil sehingga menulis ulang tipe masih tidak masalah, TypeSpec juga layak dilihat. Jelas lebih baik daripada menulis skema JSON secara manual

  • Kalau diletakkan di samping YAML OpenAPI, apa pun akan terlihat bagus, jadi rasanya agak curang. Meski begitu, saya tetap menganggap OpenAPI sebagai salah satu perubahan terbaik
    Di sisi lain, saya cukup berharap TypeScript bisa menjadi bahasa skema. Tepatnya, subset non-imperatif dan non-fungsional yang ternyata sangat besar itu. Kesan pertama saya kira-kira: “Bagaimana kalau JavaScript dihapus dari TypeScript sehingga hanya tersisa tipe untuk JSON, lalu ditambahkan deskripsi metadata endpoint agar menjadi penerus praktis OpenAPI dan WSDL?”

    • “Apa pun terlihat bagus kalau diletakkan di samping YAML OpenAPI,” ya, saya akan coba menantangnya
      https://github.com/bufbuild/protovalidate/blob/main/examples...
    • Sistem tipe TypeScript sangat canggih, jadi rasanya mustahil membuat binding untuk semua bahasa utama sambil tetap terasa idiomatis di masing-masing bahasa. Bahasa API lebih baik dibuat sangat sederhana dan langsung

  • Belakangan ini saya memakai TypeSpec untuk API, dan sebelumnya sedang mencari alat yang bisa menjelaskan API seperti GraphQL tetapi dengan pendekatan design-first
    Semua editor OpenAPI terlalu lamban, dan relasi data di dalam API tidak terlihat jelas. TypeSpec persis alat yang saya cari, dan di sini sangat membantu

  • Microsoft bilang mereka percaya pada nilai “dogfooding”, yaitu memakai produk sendiri, tetapi melihat ekosistem pengembangan desktop Windows native yang berantakan atau adopsi Xamarin/MAUI di aplikasi mobile, rasanya tidak begitu

    • Windows melakukan dogfooding terhadap semua pilihan pengembangan aplikasi native secara bersamaan
    • Dogfooding bukan berarti setiap kali teknologi baru muncul, semuanya harus ditulis ulang dari awal
    • Bisa saja ini kebijakan baru, atau hanya berlaku untuk produk ini sehingga bagus untuk materi pemasaran
      Saya pernah mengelola email lewat Microsoft Graph, dan kalau Outlook memang memakainya, saya akan cukup terkejut

  • Karena ini dari Microsoft, terlihat seperti jawaban untuk GraphQL. Kalau mereka memakainya secara internal, kualitas tooling-nya mungkin lumayan lebih baik daripada sesuatu yang dibuat tergesa-gesa oleh konsorsium open-source
    Saya belum yakin, tetapi tampaknya ada kemungkinan ini mendapat perhatian lebih besar

    • Saya bekerja di timnya, dan sulit melihat TypeSpec sebagai sesuatu yang sama dengan GraphQL, jadi TypeSpec saja sulit menempati posisi seperti itu
      GraphQL punya banyak asumsi kuat seperti protokol, penanganan error, dan semantik query yang diperlukan untuk membangun aplikasi konkret. Sebaliknya, inti TypeSpec lebih dekat ke DSL tanpa asumsi untuk mendeskripsikan API. Binding protokol tertentu ditambahkan sebagai library, dan library GraphQL juga sudah lama menjadi hal yang kami pertimbangkan
      Ringkasnya, jika Microsoft membuat sekumpulan asumsi untuk menyelesaikan skenario yang mirip GraphQL, TypeSpec bisa dipakai sebagai bahasa deskripsi API dalam konteks itu. Namun tidak tepat menyamakan asumsi-asumsi tersebut dengan TypeSpec itu sendiri

  • Saya tidak menemukan pertanyaan inti, yaitu bahasa keluaran yang didukung. Apakah satu-satunya pilihan adalah mengekspor ke OpenAPI lalu memakai salah satu generator mengerikan di sana?

    • Anda bisa membuat emitter sendiri, dan caranya ada di dokumentasi. Tim kami membuat emitter kustom untuk TypeSpec dan menghasilkan sekumpulan SDK serta library

  • Terlihat seperti WSDL versi TypeScript
    https://en.wikipedia.org/wiki/Web_Services_Description_Langu...
    Apakah bisa bertahan lebih lama daripada WSDL?

    • Kami masih memakai WSDL, tepatnya platform tempat saya bekerja yang memakainya. Mungkin tidak populer untuk teknologi baru, tetapi masih hidup. Silakan mencela, tetapi XML yang dihasilkan lebih baik daripada menghasilkan YAML
    • Mungkin Anda sudah tahu, tetapi analogi yang lebih tepat adalah WSDL+SOAP
      WSDL dan SOAP didefinisikan dengan XML, dan SOAP mendeskripsikan XML. Popularitas teknologi-teknologi ini mengikuti naik turunnya popularitas XML secara umum. TypeSpec mendeskripsikan JSON dan protobuf, jadi kalau popularitas format-format itu mereda, TypeSpec juga kemungkinan akan kehilangan popularitas
    • Masalah WSDL adalah ia dirancang oleh komite beberapa perusahaan raksasa. Karena itu ia tidak konsisten dan membengkak. Banyak standar terkait XML juga begitu
      Sekarang perusahaan besar lebih suka melempar solusi mereka sendiri ke pasar untuk merebut pangsa, daripada bekerja bersama. Akibatnya kadang muncul pendekatan yang kualitasnya lebih baik karena dibuat oleh satu tim yang fokus pada satu tujuan. Itu lebih baik daripada berusaha memuaskan 10 vendor dengan agenda berbeda-beda

  • Akan bagus kalau file TypeSpec bisa langsung diimpor dari TypeScript atau bahasa lain dan otomatis mendapatkan tipe TypeScript
    Generasi kode itu merepotkan dan mudah menimbulkan error

    • Secara umum saya lebih suka generasi kode. Saya tidak mengerti mengapa itu lebih mudah menimbulkan error dibanding cara lain
      Justru debugging bisa lebih mudah karena error tidak tersembunyi di dalam dua lapis abstraksi. Kode yang dihasilkan juga bisa ditambahi tahap build untuk mengakali kekurangan atau bug pada generator, sedangkan dengan cara lain sering kali kita harus menerimanya apa adanya
      Saya paham bagian “merepotkan”. Umpan balik instan tentu lebih baik daripada menjalankan build ulang, jadi di area yang sering banyak diiterasi, keunggulan pihak sebaliknya juga besar
    • Ini juga terlihat sangat mirip dengan TypeScript. Dari awal, mengapa tidak memakai TypeScript untuk deskripsi API? Kita bisa mendapatkan tipe TypeScript, lalu menghasilkan skema OpenAPI secara langsung untuk disajikan di /openapi

  • Bisakah YAML dikonversi untuk toolchain yang diinginkan?
    Rasanya akan menyenangkan jika ada IDL tingkat tinggi yang menghasilkan skema dan stub untuk berbagai bahasa, seperti yang dilakukan CORBA IDL 25 tahun lalu

    • Beberapa hari lalu saya menambahkan dukungan TypeSpec sebagai spesifikasi input ke code generator berbasis OpenAPI 3 milik saya
      Cukup mudah karena menyediakan API untuk mengonversinya menjadi dokumen OpenAPI (https://github.com/mnahkies/openapi-code-generator/pull/158)
      Fokusnya adalah menghasilkan client SDK dan server stub, tetapi saat ini baru mendukung TypeScript. Kalau sudah puas dengan kelengkapan template TypeScript, suatu saat saya ingin menambahkan bahasa lain juga
    • Emitter OpenAPI dan JSON Schema bisa menghasilkan YAML

  • Bahasa khusus sulit meyakinkan orang, dan juga membutuhkan upaya tambahan yang besar dari tim yang membuatnya
    Orang tidak ingin mempelajari bahasa khusus. Selain itu, semua tooling ekosistem bahasa seperti compiler, dokumentasi, language server, integrasi IDE, dan manajemen dependensi harus dibuat
    Ada upaya serupa seperti WaspLang dan DarkLang, tetapi saya belum melihatnya dipakai secara berarti di lapangan atau di HN. Lebih baik memakai bahasa yang sudah ada dan berfokus pada nilai tambah
    Secara pribadi, saya juga pernah mengerjakan sesuatu dengan nilai serupa, yaitu “single source of truth -> semuanya”, dan mengalami sebagian rasa sakit ini
    https://github.com/hofstadter-io/hof
    Idenya adalah CUE + text/template = alat generasi yang tidak terbatas pada API

    • Pilihannya adalah memakai ini atau menulis OpenAPI YAML langsung. Bahkan bagi orang yang tahu YAML, untuk membuat dan menggunakan definisi OpenAPI dasar, pendekatan ini jauh lebih sederhana daripada menulis dokumen OpenAPI dengan tangan. Menulisnya langsung benar-benar menyakitkan
    • Dengan naiknya pemrograman AI generatif, bahasa baru menjadi makin kurang menguntungkan. Bahkan framework baru yang secara objektif lebih baik pun, jika belum dipelajari AI, produktivitas nyata bisa lebih rendah
    • Terima kasih untuk hof. Saya sedang mempertimbangkan memakainya di salah satu proyek. Bagaimana kondisi proyeknya saat ini? Sepertinya commit belakangan ini berkurang, jadi saya penasaran apakah sekarang sudah stabil dan bisa dipakai apa adanya