TypeSpec: API Odaklı Geliştirme için Yeni Bir Dil

 (typespec.io)
6 puan yazan GN⁺ 2024-05-02 | 1 yorum | WhatsApp'ta paylaş
  • TypeSpec, API odaklı geliştirme için yeni bir dil olarak API geliştiricilerinin, tasarımcılarının ve yöneticilerin gereksinimlerini karşılamak üzere tasarlandı
    • Tutarlı biçimde yüksek kaliteli API'ler ve buna ilişkin deneyimler sunmanın giderek daha karmaşık ve önemli hale geldiği bir ortamda geliştirildi
    • TypeSpec yalnızca basit bir dilden ibaret değildir; soyutlamayı mümkün kılan, kod yeniden kullanımını teşvik eden ve hızlı geliştirme için modern araçları kullanan bir platformdur

TypeSpec'in Temel Özellikleri

  • Birlikte Çalışabilirlik
    • TypeSpec, basit bir API açıklama dili değil; API'leri tanımlayıp farklı protokoller, istemciler, sunucular ve belgeler gibi çıktıları aynı anda üretebilen yüksek seviyeli bir tanımlama dilidir
    • Endüstri standardı API tanım dilleriyle birlikte çalışarak farklı seçenekler arasındaki boşluğu kapatır
  • Üretkenlik
    • TypeSpec, veri ve API tanımlama sürecini daha keyifli ve üretken kılan üstün bir geliştirici deneyimi sağlar
    • Dil, karmaşık veri ve API biçimlerini minimal girdiyle tanımlayabilecek kadar özlüdür
  • API Kalıpları
    • TypeSpec, genel veri türlerini, API kalıplarını ve yönergeleri; ekip veya ekosistem genelinde paylaşılabilen yüksek seviyeli, yeniden kullanılabilir bileşenlere sararak API kalitesini artırır
  • Tanıdıklık
    • TypeSpec, TypeScript ve C#'den esinlenerek öğrenmesi kolay ve birçok geliştirici için tanıdık bir yapı sunar
  • Genişletilebilirlik
    • TypeSpec, özel dekoratör sözlüğü ve tip şablonlarıyla genişletilebilir; bu sayede iş veya uygulama mantığı alanında API'leri modelleyebilirsiniz
  • Ekosistem
    • TypeSpec ile ortak türler, dil uzantıları, linter'lar ve emitter'lar paketlenip, kurum içi veya ekosistem genelinde NPM'de dağıtılabilir

Topluluk ve İş Birliği

  • Microsoft'ta Kullanım
    • Microsoft, API geliştirme sürecini dönüştürmek için TypeSpec kullanıyor
    • Pek çok Azure servisi TypeSpec'i benimsemiş durumda ve bu sayı her geçen gün artıyor
    • Microsoft Graph ekibi, TypeSpec'in potansiyelini kullanarak verimliliği artırıyor ve özelleştirmeyi basitleştiriyor
  • Katılım Çağrısı
    • TypeSpec yalnızca bir dil değil; aynı zamanda bir topluluktur
    • Farklı geçmişten tüm geliştiriciler, TypeSpec'in gücünü doğrudan deneyimleyebilsin diye herkesi açık betaya katılmaya davet ediyor

GN⁺'nin Görüşü

  • TypeSpec, yüksek soyutlama seviyesine sahip bir API tanımlama dili olarak, API geliştirme biçimlerini önemli ölçüde iyileştirebilecek görünüyor
    • API First yaklaşımını destekleyerek geliştirme verimliliğine ve nihai ürün kalitesinin artmasına katkı sağlayacağı öngörülüyor
    • Geniş protokol desteği, genişletilebilirlik ve güçlü bir ekosistemle birlikte çok farklı geliştirme senaryolarına uygulanabilirliği bekleniyor
  • Ancak yeni bir dilin devreye alınmasında her zaman öğrenme maliyeti oluşur; bu nedenle ekip içi benimsemede yeterli eğitim öncesinde verilmelidir
    • TypeScript ve C# sözdizimlerini ödünç alarak öğrenme eğrisini düşürmeye çalışması olumlu
  • Benzer rolü üstlenen mevcut API tanım dilleri (Swagger, RAML, API Blueprint vb.) ile ayrıştırıcı noktaların daha net açıklanması gerekiyor gibi görünüyor
    • Mevcut dillerin sınırlamalarını nasıl aşacağı, geçişin kolay olması gibi konular
  • Microsoft içinde önce kullanıp geliştirerek ilerleme yaklaşımı güven verici
    • Ancak proje henüz yeni açılmış bir açık kaynak olduğu için, önümüzdeki yıllarda sürekli gelişim ve topluluk desteği kritik bir rol oynayacak gibi görünüyor
  • API tasarımını standartlaştırma ve yeniden kullanılabilirliği artırma yönündeki yaklaşım doğru olsa da, çok fazla şeyi bir anda çözmeye çalıştığı izlenimi de var
    • Özellikle fonksiyonlar kademeli ve öncelikli şekilde geliştirilse daha iyi olur

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-02
Hacker News yorumları

  • API’ler için zaten TypeScript tipleri vardı; bu yüzden kaynaktan doğrudan JSON şeması üreten https://github.com/vega/ts-json-schema-generator’ı yaptım.
    İki dilin özellik kümeleri biraz farklı olduğu için tuhaf yerleri var, ama birkaç yıldır sorunsuz kullanıyorum. TypeScript’in olmadığı ya da API yüzey alanının küçük olup tipleri yeniden yazmanın sorun olmayacağı durumlarda TypeSpec’e de bakmaya değer. Elle JSON şeması yazmaktan kesinlikle daha iyi.

  • OpenAPI’nin YAML’ının yanına koyunca her şey iyi görünüyor; bu yüzden biraz hile gibi geliyor. Yine de OpenAPI’nin hâlâ en iyi değişimlerden biri olduğunu düşünüyorum.
    Öte yandan TypeScript’in bir şema dili olarak yerleşmesini epey umuyordum. Daha doğrusu, şaşırtıcı derecede büyük olan deklaratif/işlevsel olmayan alt kümesini kastediyorum. İlk izlenimim, “TypeScript’ten JavaScript’i çıkarıp JSON için yalnızca tipleri bıraksak, üstüne de OpenAPI ve WSDL’in fiilî halefi olacak şekilde endpoint meta verisi açıklamalarını eklesek nasıl olurdu” fikrine yakın göründüğü yönünde.

    • “OpenAPI’nin YAML’ının yanına koyunca her şey iyi görünür” demek; meydan okumayı kabul ediyorum.
      https://github.com/bufbuild/protovalidate/blob/main/examples...
    • TypeScript tip sistemi çok ileri düzey; tüm büyük dillere karşılık gelen binding’ler üretirken her birini o dile özgü tutmanın imkânsız olacağını düşünüyorum. API dili çok basit ve sezgisel olunca daha iyi.

  • Son zamanlarda bir API’de TypeSpec kullanıyorum; GraphQL gibi API’yi açıklarken aynı zamanda tasarım öncelikli yaklaşabileceğim bir araç arıyordum.
    OpenAPI editörlerinin hepsi çok hantaldı ve API içindeki veri ilişkileri iyi görünmüyordu. TypeSpec tam aradığım araçtı ve burada gerçekten yardımcı oldu.

  • Microsoft kendi ürünlerini bizzat kullanma, yani “dogfooding” değerine inandığını söylüyor; ama yerel Windows masaüstü geliştirmedeki dağınık ekosisteme ya da mobil uygulamalarda Xamarin/MAUI benimsenmesine bakınca öyle görünmüyor.

    • Windows, yerel uygulama geliştirme seçeneklerinin hepsini aynı anda dogfood ediyor.
    • Dogfooding, her yeni teknoloji çıktığında her şeyi sıfırdan yeniden yazmak demek değildir.
    • Yeni bir politika olabilir ya da yalnızca bu ürüne özgü, pazarlaması kolay bir durum olabilir.
      Microsoft Graph ile e-posta yönetmeyi denedim; Outlook bunu kullanıyorsa epey şaşırırım.

  • Microsoft’tan çıktığına göre GraphQL’e bir yanıt gibi görünüyor. İçeride dogfood ediliyorsa, açık kaynak bir konsorsiyumun aceleyle bir araya getirdiği bir şeyden araç kalitesi bir ölçüde daha iyi olabilir.
    Henüz emin değilim ama daha fazla ilgi görme ihtimali var gibi.

    • Ekipte çalışıyorum; TypeSpec’i GraphQL ile aynı görmek zor ve bu yüzden TypeSpec tek başına böyle bir konuma gelmekte zorlanır.
      GraphQL’in belirli bir uygulama kurmak için gereken protokol, hata işleme, sorgu semantiği gibi güçlü varsayımları var. Buna karşılık TypeSpec’in özü, API’yi açıklayan varsayımsız bir DSL’e daha yakın. Belirli protokol binding’leri kütüphane olarak ekleniyor; GraphQL kütüphanesi de uzun süredir değerlendirdiğimiz konulardan biri.
      Özetle Microsoft, GraphQL’e benzer senaryoyu çözen bir varsayımlar paketi oluşturursa, o bağlamda API açıklama dili olarak TypeSpec kullanılabilir. Ama bu varsayımları TypeSpec’in kendisiyle özdeşleştirmek doğru değil.

  • Asıl soru olan desteklenen çıktı dillerini bulamadım. OpenAPI’ye dışa aktarıp oradaki berbat üreticilerden birini kullanmaktan başka çare yok mu?

    • Kendi emitter’ınızı yazabilirsiniz; belgelerde nasıl yapılacağı anlatılıyor. Bizim ekip TypeSpec için özel bir emitter yazıp SDK ve kütüphane paketleri üretti.

  • TypeScript sürümü bir WSDL gibi görünüyor.
    https://en.wikipedia.org/wiki/Web_Services_Description_Langu...
    WSDL’den daha uzun yaşayabilir mi?

    • Hâlâ WSDL kullanıyoruz; daha doğrusu çalıştığım platform kullanıyor. Yeni teknolojiler için popüler olmayabilir ama hâlâ hayatta. İsterseniz kötüleyin, ama YAML üretmektense üretilmiş XML daha iyi.
    • Zaten biliyor olabilirsiniz ama daha doğru benzetme WSDL+SOAP’a yakın.
      WSDL ve SOAP XML ile tanımlanır, SOAP da XML’i açıklar. Bu teknolojilerin popülerliği, XML’in genel popülerliğinin yükseliş ve düşüşünü izledi. TypeSpec JSON ve protobuf’u açıkladığı için, bu formatların popülerliği soğursa TypeSpec’in de popülerliğini kaybetmesi olası.
    • WSDL’in sorunu, birden fazla dev şirket komitesi tarafından tasarlanmış olmasıydı. Bu yüzden tutarsız ve şişkindi. XML ile ilgili birçok standart da öyleydi.
      Günümüzde büyük şirketler birlikte çalışmak yerine kendi çözümlerini pazara atıp pay kapmayı tercih ediyor. Sonuç olarak tek bir ekip tek bir hedefe odaklanarak yaptığı için bazen daha kaliteli yaklaşımlar çıkıyor. Farklı gündemleri olan 10 tedarikçiyi memnun etmeye çalışmaktan daha iyi.

  • TypeSpec dosyasını TypeScript’ten ya da başka bir dilden doğrudan import edip TypeScript tiplerini otomatik alabilsek iyi olurdu.
    Kod üretimi zahmetli ve hataya açık.

    • Genelde kod üretimini tercih ederim. Neden diğer yöntemlerden daha hataya açık olsun, bilmiyorum.
      Aksine hatalar iki katmanlı soyutlamanın içinde saklanmadığı için hata ayıklaması daha kolay olabilir. Üretilen kod, üreticinin eksiklerini ya da hatalarını aşmak için bir build adımı eklemenize de izin verebilir; diğer yöntemlerde ise çoğu zaman olduğu gibi kabullenmek gerekir.
      “Zahmetli” kısmını anlıyorum. Anlık geri bildirim, build’i yeniden çalıştırmaktan elbette daha iyi; dolayısıyla çok sık yineleme yapılan alanlarda karşı tarafın avantajı da büyüyor.
    • TypeScript’e de çok benziyor. En başta API açıklaması için TypeScript kullanmamak için ne sebep var? TypeScript tiplerini alır, /openapi üzerinden sunulacak OpenAPI şemasını da anında üretirsiniz.

  • YAML’i istediğimiz araç zinciri için dönüştürebilir mi?
    25 yıl önce CORBA IDL’nin yaptığı gibi, birden çok dil için şema ve stub üretebilen üst seviye bir IDL olsa güzel olurdu

    • Birkaç gün önce OpenAPI 3 tabanlı kod üretecime TypeSpec’i giriş spesifikasyonu olarak destekleyecek şekilde ekledim
      OpenAPI belgesine dönüştüren bir API sağladığı için oldukça kolay oldu (https://github.com/mnahkies/openapi-code-generator/pull/158)
      Hem istemci SDK’sı hem de sunucu stub’ı üretmeye odaklanıyorum, ama şimdilik yalnızca TypeScript destekleniyor. TypeScript şablonlarının olgunluğundan memnun kalırsam bir gün başka dilleri de eklemek isterim
    • OpenAPI ve JSON Schema emitter’ları YAML üretebiliyor

  • Özel amaçlı bir dili kabul ettirmek zor; ayrıca bunu yapan ekibe de ciddi ek iş yükü bindiriyor
    İnsanlar özel amaçlı bir dil öğrenmek istemiyor. Ayrıca derleyici, dokümantasyon, language server, IDE entegrasyonu, bağımlılık yönetimi gibi dil ekosistemi araçlarının tamamını da yapmak gerekiyor
    Benzer girişimler olarak WaspLang ve DarkLang var, ancak bunların gerçek sahada ya da HN’de anlamlı biçimde kullanıldığını henüz görmedim. Mevcut dili kullanıp katma değere odaklanmak daha iyi
    Ben de kişisel olarak benzer bir değer, yani “tek doğruluk kaynağı -> her şey” üretme işi üzerinde çalıştım ve bu sancıların bir kısmını yaşadım
    https://github.com/hofstadter-io/hof
    Fikir şu: CUE + text/template = API ile sınırlı olmayan bir üretim aracı

    • Ya bunu kullanacaksınız ya da OpenAPI YAML’ını doğrudan yazacaksınız. YAML bilen biri için bile temel OpenAPI tanımını oluşturup kullanmak, OpenAPI belgesini elle yazmaktan çok daha basit. Elle yazmak gerçekten acı verici
    • Üretken yapay zeka ile programlama öne çıktıkça yeni diller daha büyük bir dezavantaja sahip oluyor. Nesnel olarak daha iyi yeni bir framework olsa bile, yapay zeka onu öğrenmemişse gerçek üretkenlik daha düşük olabilir
    • hof için teşekkürler. Bir projede kullanmayı düşünüyorum. Projenin şu anki durumu nasıl? Son commit’ler azalmış gibi göründüğü için, şu anda stabil mi ve olduğu gibi kullanmaya uygun mu merak ediyorum