Pbkit - Deno से बना Protobuf टूलकिट (compiler, package manager, VSCode extension, Chrome extension)
(pbkit.dev)Santa TOEIC को सर्विस देने वाली Riiid में gRPC/Protobuf का बहुत सक्रिय रूप से उपयोग किया जाता है.
मेरे Riiid में शामिल होने के कुछ समय बाद ही हमें बताया गया कि आगे backend टीम frontend (mobile/web) को देने वाले सभी API को gRPC पर एकीकृत किया जाएगा.
वेब frontend में gRPC/Protobuf स्टैक इस्तेमाल करने के लिए पहले protoc में JS/TS plugin जोड़कर इस्तेमाल करने या Protobuf.js का उपयोग करने जैसे तरीके थे.
protoc का आधिकारिक JS plugin बहुत पुराने स्टाइल का कोड जनरेट करने की समस्या रखता था, और ecosystem plugins भी हमारी सभी आवश्यकताओं को पूरा नहीं कर पा रहे थे. Native binary (protoc) dependency साथ लेकर चलने की असुविधा भी थी. (आजकल M1 डिवाइस पर protoc इंस्टॉल करना कठिन होने की समस्या भी है.)
हमने अब तक Protobuf.js का उपयोग करके कई प्रोडक्ट बनाए थे, लेकिन जब कंपनी में बनने वाले सभी प्रोडक्ट्स के लिए platform के बीच संचार करने वाले सभी interfaces में Protobuf का उपयोग होने लगा, तब हमें पता चला कि Protobuf.js हमारे ज़रूरी स्तर तक mature नहीं है.
अगर message name एक जैसा हो तो उसे किसी दूसरे namespace के message के रूप में गलत पहचान लेना, या global namespace में enum के बाद message declaration आने पर message type code generation न होना, या generated TypeScript type definitions का generated JS के व्यवहार से अलग होना—ऐसी कई समस्याओं का सामना करना पड़ा.
इसी प्रक्रिया में, किसी खास प्रोडक्ट के लिए ज़रूरी protobuf schema ही चुनकर build करने वाली प्रणाली बनाने के लिए हमने pollapo नाम का protobuf package manager बनाया.
(उस समय दूसरे protobuf dependency managers मौजूद थे, लेकिन उनमें bugs थे या nested dependencies का समर्थन नहीं था. साथ ही, buf द्वारा दिया जाने वाला package management feature उस समय केवल development में होने पर एक blog post तक सीमित था, और हमारे pollapo बनाने व internal migration पूरा करने तक भी वह तैयार नहीं हुआ था.)
pollapo का उपयोग करके हमने प्रति प्रोडक्ट build होने वाले schema की संख्या काफी कम कर दी, और समान message name जैसी वजहों से होने वाले bugs भी कम हुए, लेकिन फिर भी bugs और build समस्याएँ बनी रहीं. इन्हें हल करने के लिए हमने protobuf to typescript compiler खुद बनाया.
Santa TOEIC ने अब protobuf.js को पूरी तरह हटाकर pbkit से बदलना पूरा कर लिया है.
Santa TOEIC सहित Riiid में विकसित किए जाने वाले apps WebView का सक्रिय रूप से उपयोग करते हैं.
WebView डिवाइस/यूज़र जानकारी या वर्तमान में दिखाए जा रहे content की जानकारी पाने के लिए native के साथ संचार करता है, और इस समय का interface भी Protobuf service schema से परिभाषित किया जाता है.
pbkit में service code generation के समय network layer को gRPC की जगह किसी दूसरे protocol से बदलने के लिए interface दिया जाता है.
pbkit compiler का उपयोग करने वाले web frontend engineers को mobile native के साथ संचार करते समय यह जानने की ज़रूरत नहीं होती कि request gRPC से जा रही है या mobile engineers के साथ तय किए गए App Bridge protocol से.
और क्योंकि हमने Chrome extension भी खुद विकसित किया है, इसलिए mobile के साथ होने वाले संचार की सामग्री को भी Chrome DevTools के pbkit tab में network tab की तरह आसानी से देखा जा सकता है.
क्योंकि हमने protobuf schema compiler खुद बनाया, इसलिए लगा कि code editor में Go to Definition जैसी सुविधाएँ भी जल्दी बनाई जा सकती हैं, और इसी वजह से हमने VSCode extension भी बनाया.
अब तक के VSCode-विशेष protobuf extensions केवल syntax highlighting जैसी सुविधाएँ देते थे, लेकिन pbkit vscode extension में ठीक से काम करने वाला Go to Definition feature शामिल है.
आगे हम swift/kotlin/python जैसी अन्य भाषाओं का समर्थन, server use case support, document generation tools, linting/formatting tools आदि विकसित करने की योजना रखते हैं.
हम ऐसे tools को साथ में विकसित करने वाले engineers भी ढूँढ़ रहे हैं: https://riiid.com/ko/career/dx-software-engineer
कृपया इसमें रुचि दिखाएँ.
pbkit repository: https://github.com/pbkit/pbkit
VSCode extension: https://marketplace.visualstudio.com/items?itemName=pbkit.vscode-pbkit
Chrome extension: https://chrome.google.com/webstore/detail/pbkit-devtools/fjacmiijeihblfhobghceofniolonhca
9 टिप्पणियां
हमारी कंपनी में कुछ साल पहले हमने gRPC के साथ तुलना करने के बाद Thrift चुना था। Thrift का JS generator भी अधूरा था, इसलिए हमने उसे खुद संशोधित किया, लेकिन तब समझ आया कि यह करने लायक काम नहीं था। इसलिए लगा कि शायद gRPC चुनना चाहिए था, लेकिन लगता है उधर की स्थिति भी बहुत अच्छी नहीं है।
इसके बाद हमने GraphQL चुना, और मैं उससे संतुष्ट हूँ। कभी-कभी communication overhead की चिंता होती है, लेकिन binary-based protocol का इस्तेमाल मुझसे नहीं हो पाता।
हम इसे Danggeun Market में अच्छी तरह इस्तेमाल कर रहे हैं!! ( _ _ )
हम इसे internal API mesh के लिए अच्छे से उपयोग करने की कोशिश कर रहे हैं haha
वाह, कमाल है!
वैसे, अगर आपकी कंपनी में यह पहले से production में इस्तेमाल होने लायक है, तो अब v0.0.44 जैसे pre-alpha लगने वाले version का इस्तेमाल बंद कर देना चाहिए।
लगता है कुछ लोग सिर्फ version number देखकर इसे इस्तेमाल नहीं करेंगे, हुह
वाह, आपने compiler खुद बनाया है। बहुत बढ़िया! (मैं सोच रहा था कि golang code कैसे generate होता है, लेकिन लगता है कि अभी सिर्फ deno और node.js ही support हैं।) मैं आमतौर पर protoc या buf के साथ ts-proto जोड़कर इस्तेमाल करता हूँ, तो यह जानने की जिज्ञासा है कि ts-proto की तुलना में generate होने वाले ts code में क्या अंतर है।
लगता है जैसे यह थोड़ा घुमा-फिराकर जा रहा है https://github.com/trpc/trpc
मैं इससे सहमत हूँ कि gRPC/Protobuf स्टैक का उपयोग करना आदर्श नहीं है। (मैंने इसे अपनी इच्छा से नहीं, बल्कि कंपनी की परिस्थितियों के कारण इस्तेमाल किया था)
लेकिन trpc, zod का उपयोग करके interface परिभाषित करता है, इसलिए जब सभी platforms पर TypeScript का उपयोग किया जाता हो तो यह आदर्श लगता है।
हमारे environment में, जहाँ हम server को kotlin में लिखते हैं, इसका उपयोग करना मुश्किल लगता है, और mobile native (swift, kotlin) के साथ communication के मामलों में भी यह उपयुक्त नहीं दिखता।
gRPC से जुड़ी पोस्ट्स का हमेशा स्वागत है :)
वाह, कोड के साथ VS/Chrome extension तक... कमाल है!! समर्थन करता हूँ।
परिचय इतना बढ़िया लिखा है कि लगता है सिर्फ Repo पर सीधे आने वालों की तुलना में, GeekNews के ज़रिए आने वाले लोगों को ज़्यादा जानकारी मिलेगी ^^;
जो लोग अभी Protobuf इस्तेमाल कर रहे हैं, अगर वे कमेंट छोड़ें तो काफ़ी मदद मिलेगी।