TypeSpec: API-केंद्रित विकास के लिए नई भाषा

 (typespec.io)
6 पॉइंट द्वारा GN⁺ 2024-05-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • TypeSpec API-केंद्रित विकास के लिए एक नई भाषा है, जिसे API डेवलपर्स, डिज़ाइनरों और मैनेजरों की ज़रूरतों को पूरा करने के लिए डिज़ाइन किया गया है
    • यह ऐसे वातावरण में विकसित किया गया है जहाँ लगातार उच्च गुणवत्ता वाले API और संबंधित अनुभव देना लगातार अधिक जटिल और महत्वपूर्ण होता जा रहा है
    • TypeSpec सिर्फ़ एक भाषा नहीं, बल्कि एक ऐसा प्लेटफ़ॉर्म है जो abstraction को संभव बनाता है, code reuse को बढ़ावा देता है, और तेज़ विकास के लिए आधुनिक टूलिंग का उपयोग करता है

TypeSpec के मुख्य फीचर्स

  • इंटरऑपरेबिलिटी
    • TypeSpec सिर्फ़ एक API description language नहीं है; यह एक high-level definition language है जो API को परिभाषित करके विभिन्न protocols, clients, servers और documentation को एक साथ emit कर सकता है
    • यह इंडस्ट्री-स्टैंडर्ड API definition भाषाओं के साथ interoperable है, जिससे अलग-अलग विकल्पों के बीच का अंतर कम होता है
  • उत्पादकता
    • TypeSpec उत्कृष्ट डेवलपर एक्सपीरियंस देता है जो डेटा और API definition प्रक्रिया को सरल व उत्पादक बनाता है
    • भाषा सरल है और कम इनपुट में जटिल डेटा और API structure define किया जा सकता है
  • API पैटर्न
    • TypeSpec सामान्य data types, API patterns और guidelines को टीम या ecosystem स्तर पर साझा किए जाने वाले reusable high-level components के रूप में encapsulate करके API quality improve करता है
  • परिचितता
    • TypeSpec ने TypeScript और C# से प्रेरणा लेकर इसे सीखना आसान बनाया है, इसलिए यह कई डेवलपर्स के लिए परिचित महसूस होता है
  • एक्सटेंसिबिलिटी
    • TypeSpec को custom decorator vocabularies और type templates के साथ extend करके business या application logic domain में API को model किया जा सकता है
  • इकोसिस्टम
    • TypeSpec से सामान्य types, language extensions, linters और emitters को पैकेज के रूप में bundle करके संगठन के भीतर या पूरे इकोसिस्टम में NPM पर distribute किया जा सकता है

समुदाय और सहयोग

  • Microsoft में उपयोग
    • Microsoft TypeSpec का उपयोग करके API विकास प्रक्रिया में बदलाव ला रहा है
    • कई Azure services ने TypeSpec अपना लिया है, और उनकी संख्या हर दिन बढ़ रही है
    • Microsoft Graph टीम TypeSpec की क्षमता का उपयोग करके productivity बढ़ा रही है और customization को सरल बना रही है
  • सहभागिता के लिए आमंत्रण
    • TypeSpec सिर्फ़ एक भाषा नहीं, बल्कि एक community है
    • सभी पृष्ठभूमि के डेवलपर्स को public beta में शामिल होकर TypeSpec की ताकत सीधे महसूस करने के लिए आमंत्रित किया जाता है

GN+ की राय

  • TypeSpec एक उच्च abstraction वाला API definition language लग रहा है, जो API development approach को काफी सुधार सकता है
    • यह "API First" approach को support करता है और विकास दक्षता व अंतिम product quality में सुधार में मदद कर सकता है
    • अलग-अलग protocols का समर्थन, extensibility और मजबूत ecosystem के कारण यह कई development scenarios में उपयोगी हो सकता है
  • लेकिन किसी नई भाषा को अपनाने में हमेशा learning cost आती है, इसलिए टीम में rollout से पहले पर्याप्त training होनी चाहिए
    • TypeScript और C# की syntax लेने का प्रयास सीखने की curve को कम करने की दिशा में एक सकारात्मक कदम है
  • Swagger, RAML, API Blueprint जैसे समान भूमिका वाले मौजूद API definition languages के साथ इसके differentiation points को और स्पष्ट करने की ज़रूरत है
    • यह कैसे पुराने language limits को resolve करता है और migration कितना आसान है, जैसे प्रश्न अभी भी बाकी हैं
  • Microsoft के अंदर पहले से उपयोग करके धीरे-धीरे सुधारने वाला dogfooding approach भरोसा देता है
    • लेकिन यह अभी ओपन सोर्स प्रोजेक्ट के रूप में नया है, इसलिए आने वाले कई वर्षों तक लगातार विकास और community support महत्त्वपूर्ण होगा
  • API डिजाइन में standardization और reusability बढ़ाने का दिशा सही है, पर कभी-कभी ऐसा लगता है कि एक साथ बहुत कुछ solve करने की कोशिश हो रही है
    • बेहतर होगा कि प्राथमिकता तय करके फीचर को चरणबद्ध तरीके से मजबूत किया जाए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-02
Hacker News की राय

  • API के लिए TypeScript types पहले से थे, इसलिए source से सीधे JSON schema बनाने वाला https://github.com/vega/ts-json-schema-generator बनाया था
    दोनों भाषाओं के feature sets थोड़े अलग हैं, इसलिए कुछ अजीब हिस्से भी हैं, लेकिन कई सालों से अच्छे से इस्तेमाल कर रहा हूं। अगर TypeScript नहीं है, या API surface छोटा है और types दोबारा लिखना ठीक है, तो TypeSpec भी देखने लायक है। हाथ से JSON schema लिखने से तो निश्चित ही बेहतर है

  • OpenAPI के YAML के बगल में रखो तो कुछ भी अच्छा दिखता है, इसलिए यह थोड़ा cheating जैसा लगता है। फिर भी OpenAPI अब भी सबसे अच्छे बदलावों में से एक है
    दूसरी तरफ, मैं काफी समय से उम्मीद कर रहा था कि TypeScript एक schema language के रूप में जगह बना ले। ठीक कहें तो इसका हैरान कर देने वाला बड़ा non-imperative, non-functional subset। पहली नजर में यह कुछ ऐसा लगता है: “TypeScript से JavaScript हटा दें, JSON के लिए सिर्फ types छोड़ दें, और OpenAPI व WSDL का व्यावहारिक successor बनने के लिए endpoint metadata description जोड़ दें”

    • “OpenAPI के YAML के बगल में रखो तो कुछ भी अच्छा दिखता है” — ठीक है, चुनौती स्वीकार
      https://github.com/bufbuild/protovalidate/blob/main/examples...
    • TypeScript type system बहुत advanced है, इसलिए सभी प्रमुख भाषाओं के लिए bindings बनाते हुए उन्हें हर भाषा के idiomatic style में बनाए रखना असंभव जैसा लगता है। API language का बहुत simple और intuitive होना बेहतर है

  • हाल में APIs के लिए TypeSpec इस्तेमाल कर रहा हूं, और GraphQL की तरह API describe करने वाला, लेकिन design-first approach देने वाला tool खोज रहा था
    OpenAPI editors सब बहुत sluggish थे, और API के अंदर data relationships साफ नहीं दिखते थे। TypeSpec वही tool निकला जिसकी तलाश थी, और यहां सच में बहुत मददगार रहा

  • Microsoft कहता है कि वह अपने products खुद इस्तेमाल करने वाली “dogfooding” की value में विश्वास करता है, लेकिन native Windows desktop development के messy ecosystem या mobile apps में Xamarin/MAUI adoption को देखें तो ऐसा नहीं लगता

    • Windows native app development के सारे विकल्पों को एक साथ dogfood कर रहा है
    • Dogfooding का मतलब यह नहीं कि हर नई technology आने पर सब कुछ scratch से दोबारा लिखा जाए
    • हो सकता है यह नई policy हो, या फिर सिर्फ इसी product पर लागू होकर marketing के लिए अच्छा case हो
      Microsoft Graph से email manage करके देखा था, अगर Outlook वही इस्तेमाल करता है तो मुझे काफी हैरानी होगी

  • Microsoft से आया है, इसलिए GraphQL के जवाब जैसा दिखता है। अगर वे internally dogfood कर रहे हैं, तो open-source consortium द्वारा जल्दी-जल्दी जोड़ी गई चीज़ से tools की quality कुछ हद तक बेहतर हो सकती है
    अभी पक्का नहीं है, लेकिन इसे ज्यादा attention मिलने की संभावना दिखती है

    • मैं team में काम करता हूं; TypeSpec को GraphQL जैसा मानना मुश्किल है, इसलिए सिर्फ TypeSpec से वह position बनना कठिन है
      GraphQL में concrete applications बनाने के लिए protocol, error handling, query semantics जैसी कई मजबूत assumptions होती हैं। इसके उलट TypeSpec का core API describe करने वाला एक assumption-free DSL जैसा है। Specific protocol bindings libraries के रूप में जोड़े जाते हैं, और GraphQL library भी काफी समय से विचाराधीन रही है
      संक्षेप में, अगर Microsoft GraphQL जैसे scenarios हल करने वाली assumptions का bundle बनाता है, तो उस context में API description language के रूप में TypeSpec इस्तेमाल हो सकता है। लेकिन उन assumptions को TypeSpec खुद के बराबर मानना सही नहीं है

  • मुख्य सवाल, यानी supported output languages, नहीं मिल पाया। क्या OpenAPI में export करके फिर उसके किसी भयानक generator में से एक इस्तेमाल करना ही विकल्प है?

    • आप अपना emitter बना सकते हैं, और docs में तरीका दिया है। हमारी team ने TypeSpec के लिए custom emitter बनाया और SDK व libraries का bundle output किया

  • TypeScript version के WSDL जैसा दिखता है
    https://en.wikipedia.org/wiki/Web_Services_Description_Langu...
    क्या यह WSDL से ज्यादा लंबे समय तक टिक पाएगा?

    • हम अब भी WSDL इस्तेमाल करते हैं, और सही कहें तो जिस platform पर मैं काम करता हूं वह इस्तेमाल करता है। नई technology के रूप में शायद popular न हो, लेकिन अब भी जिंदा है। आप चाहें तो आलोचना करें, पर YAML generate करने से generated XML बेहतर है
    • शायद आपको पहले से पता हो, लेकिन ज्यादा सही analogy WSDL+SOAP के करीब है
      WSDL और SOAP XML में define होते हैं, और SOAP XML को describe करता है। इन technologies की popularity XML की overall popularity के rise और fall के साथ चली। TypeSpec JSON और protobuf को describe करता है, इसलिए अगर उन formats की popularity ठंडी पड़ती है, तो TypeSpec भी popularity खो सकता है
    • WSDL की समस्या यह थी कि इसे कई बड़ी कंपनियों की committees ने design किया था। इसलिए इसमें consistency नहीं थी और यह bloated था। कई XML-related standards भी ऐसे ही थे
      आजकल बड़ी कंपनियां साथ काम करने के बजाय अपना solution market में फेंककर कब्जा जमाना पसंद करती हैं। नतीजतन, कभी-कभी एक team द्वारा single goal पर focus करके बनाया गया approach quality में बेहतर निकलता है। अलग-अलग agendas वाले 10 vendors को satisfy करने से बेहतर है

  • अच्छा होगा अगर TypeSpec file को TypeScript या किसी दूसरी language में सीधे import करके TypeScript types अपने-आप मिल जाएं
    Code generation झंझट भरा और error-prone है

    • मैं आम तौर पर code generation को prefer करता हूं। समझ नहीं आता कि यह दूसरे तरीकों से ज्यादा error-prone क्यों होगा
      उल्टा, errors abstraction की दो layers में छिपते नहीं, इसलिए debugging आसान हो सकती है। Generated code generator की कमी या bugs को workaround करने वाला build step जोड़ सकता है, जबकि non-generated तरीके में अक्सर वही सहना पड़ता है
      “झंझट भरा” वाला हिस्सा समझता हूं। Immediate feedback build फिर से चलाने से जाहिर तौर पर बेहतर है, इसलिए जहां बहुत iteration होती है वहां दूसरी तरफ के फायदे भी बड़े हो जाते हैं
    • यह TypeScript से भी बहुत मिलता-जुलता दिखता है। आखिर API description के लिए TypeScript इस्तेमाल क्यों नहीं करना चाहिए? TypeScript types मिलेंगे, और /openapi पर serve करने के लिए OpenAPI schema भी on the fly generate किया जा सकता है

  • क्या YAML को मनचाही tool chain के लिए transform किया जा सकता है?
    जैसे 25 साल पहले CORBA IDL करता था, वैसे कई भाषाओं के schema और stub generation कराने वाला कोई high-level IDL हो तो अच्छा लगेगा

    • कुछ दिन पहले मैंने अपने OpenAPI 3-आधारित code generator में TypeSpec को input specification के तौर पर support करना जोड़ा था
      OpenAPI document में convert करने वाली API उपलब्ध कराता है, इसलिए यह काफी आसान रहा (https://github.com/mnahkies/openapi-code-generator/pull/158)
      focus client SDK और server stub generation दोनों पर है, लेकिन अभी सिर्फ TypeScript support है। TypeScript templates की maturity से संतुष्ट हो जाऊं तो किसी दिन दूसरी भाषाएं भी जोड़ना चाहूंगा
    • OpenAPI और JSON Schema emitters YAML बना सकते हैं

  • dedicated language के लिए लोगों को मनाना मुश्किल है, और इसे बनाने वाली team पर भी काफी अतिरिक्त मेहनत पड़ती है
    लोग dedicated language सीखना नहीं चाहते। साथ ही compiler, documentation, language server, IDE integration, dependency management जैसे पूरे language ecosystem tools बनाने पड़ते हैं
    इसी तरह की कोशिशों में WaspLang और DarkLang हैं, लेकिन इन्हें production में या HN पर meaningful तरीके से इस्तेमाल होते अभी नहीं देखा। बेहतर है कि मौजूदा language इस्तेमाल करें और added value पर focus करें
    निजी तौर पर मैंने भी इसी तरह की value, यानी “source of truth -> everything” बनाने पर काम किया है और इस दर्द का कुछ हिस्सा झेला है
    https://github.com/hofstadter-io/hof
    idea है CUE + text/template = ऐसा generation tool जो सिर्फ API तक सीमित नहीं है

    • या तो इसे इस्तेमाल करें, या OpenAPI YAML को सीधे लिखें। YAML जानने वाले व्यक्ति के लिए भी basic OpenAPI definition तैयार करके इस्तेमाल करना इसमें हाथ से OpenAPI document लिखने की तुलना में कहीं ज्यादा सरल है। हाथ से लिखना सच में painful है
    • generative AI programming के उभरने के साथ नई language और ज्यादा disadvantage में आ जाती है। कोई नया framework objectively बेहतर हो, फिर भी अगर AI ने उस पर training नहीं ली है तो वास्तविक productivity कम हो सकती है
    • hof के लिए धन्यवाद। सोच रहा हूं कि इसे एक project में आजमाऊं। अभी project की स्थिति कैसी है? लगता है recent commits कम हो गए हैं, इसलिए जानना चाहता हूं कि क्या यह फिलहाल stable है और as-is इस्तेमाल किया जा सकता है