15 पॉइंट द्वारा tsboard 2024-12-30 | 12 टिप्पणियां | WhatsApp पर शेयर करें

लगभग 7 महीने पहले मैंने पहली बार TSBOARD प्रोजेक्ट का परिचय कराया था.

उस समय फ्रंटएंड और बैकएंड दोनों TypeScript में लिखे गए थे, और बैकएंड चलाने के लिए Bun runtime का इस्तेमाल किया गया था.

लेकिन कई कारणों से बैकएंड को फिर से नया बनाना पड़ा, और इसे मौजूदा TSBOARD प्रोजेक्ट से अलग GitHub repository में डालकर सार्वजनिक कर रहा हूँ. यह नया बैकएंड Go भाषा में लिखा गया है, और TSBOARD के आधिकारिक वर्जन में binary के रूप में साथ प्रदान किया जाएगा.


बैकएंड को फिर से क्यों बनाया?

  • Bun runtime वाकई शानदार performance दिखाता है. लेकिन all-in-one toolkit जैसी इसकी दूसरी पहचान के बावजूद package management अभी भी npm की बराबरी नहीं कर पाता.
  • इसी वजह से TSBOARD का इस्तेमाल करने के लिए Node.js और Bun, ऐसे 2 runtime की जरूरत पड़ती थी. यह झंझट भरा भी था और उपयोगकर्ता की नज़र से भी असुविधाजनक था.
  • अब यह ठीक हो चुका है, लेकिन शुरुआती दौर में virtual CPU पर काम न करने की समस्या इतनी गंभीर थी कि डेवलपर होने के बावजूद मैं खुद भी इसे दूसरे server पर तैनात नहीं कर पा रहा था.
  • (जैसा कि कुछ लोगों ने बताया) orchestration करने से इसे संभाला जा सकता है, लेकिन single-thread की जो मूलभूत सीमा JS runtime में होती ही है, उससे आगे बढ़कर मैं कई threads का उपयोग करना चाहता था.
  • मुझे और अधिक types की जरूरत थी. सिर्फ TypeScript से यह कमी पूरी नहीं हो रही थी.

Go भाषा को क्यों चुना?

  • नए बैकएंड के लिए 1) compile होना जरूरी था, 2) memory management अपने-आप हो जाए तो अच्छा हो, और 3) किसी अलग runtime जैसी चीज़ को install करने की जरूरत नहीं होनी चाहिए थी.
  • Rust, Kotlin, Python, PHP और Go भाषा के बीच काफी सोच-विचार के बाद, मैंने Go भाषा चुनी, जो इन 3 शर्तों को पूरा करती थी और मेरे लिए नई भी थी. (माफ करना PHP)
  • Go भाषा की सादगी मुझे सबसे ज्यादा पसंद आई, और TypeScript से इसकी समानताएँ भी चयन का एक बड़ा कारण थीं. सबसे बढ़कर, concurrency management और memory management के मामले में यह दूसरे विकल्पों की तुलना में बेहतर लगा.

Go भाषा, इस्तेमाल करके कैसी लगी?

  • यह महसूस हुआ कि दुनिया में कोई भी भाषा सिर्फ फायदों से भरी नहीं होती, और Go भाषा भी इसका अपवाद नहीं है. if err != nil { } ज़रूरी तो है, लेकिन सच में बहुत झंझट वाला है. कई बार try catch finally की याद आती है.
  • शायद go-mysql-driver की समस्या हो, लेकिन DB I/O जैसा bottleneck होने वाले वास्तविक development environment में यह उतना तेज़ नहीं चला. (यहाँ GeekNews पर डाली गई पोस्ट देखें: https://hi.news.hada.io/topic?id=18048)
  • implicit interface application अभी भी थोड़ा अजीब लगता है. क्या implements या extends जैसे keywords इस्तेमाल करना इतना बुरा था?
  • pointers देखकर अच्छा लगा. खासकर यह कि memory free होने के समय की चिंता नहीं करनी पड़ती!
  • तरह-तरह के types, simple लेकिन powerful structs, और slices बहुत पसंद आए. keywords कम हैं, इसलिए जल्दी सीखकर काम में लाया जा सकता है — यह सबसे अच्छी बात है.
  • go keyword से जादू की तरह lightweight threads इस्तेमाल कर पाना...! बहुत खुशी होती है!

बैकएंड को JS runtime आधारित सिस्टम से Go में बदलने का अनुभव...?

  • ऐसा काम एक बार करना ही काफी है.
  • DB I/O हिस्से की benchmarking करते हुए कई tests किए, लेकिन performance के नज़रिए से सच कहूँ तो JS runtime और Go binary के बीच बड़ा फर्क महसूस करना मुश्किल है. उदाहरण के लिए, JS में बहुत इस्तेमाल होने वाली image library sharp भी आखिरकार libvips library का उपयोग करती है, और DB I/O के बिना कोई web application होता भी नहीं है.
  • फिर भी, मैंने बहुत मेहनत की है, लेकिन मुझे लगता है कि यह बदलाव सही रहा, और आगे भी बैकएंड के लिए मैं सिर्फ Go भाषा ही इस्तेमाल करने वाला हूँ.
    • memory usage वास्तव में अर्थपूर्ण स्तर तक कम हो जाता है. बेशक Rust में बनाया जाए तो और optimization हो सकती है, लेकिन GC का इस्तेमाल कर पाने के बदले यह स्तर मेरे लिए पूरी तरह संतोषजनक है.
    • भाषा की सादगी सच में कमाल की है. याद रखने वाले keywords कम हैं, और अधिकतर usage patterns तय हैं, इसलिए सीखना आसान है. (हालाँकि इसे अच्छी तरह इस्तेमाल करना अलग बात है.) primitive types का विविध रूप से उपलब्ध होना मुझे बहुत पसंद आया.
    • सबसे संतोषजनक बात यह है कि compile होने के बाद सिर्फ binary हो तो वह चल जाती है. बैकएंड चलाने के लिए अलग से कुछ install करना और फिर उसी से code दोबारा चलाना अब मैं बिल्कुल नहीं चाहता.

इसका इस्तेमाल कैसे करें?

  • अफसोस की बात है कि Windows environment समर्थित नहीं है. Linux/Mac environment में binary चलानी होगी.
  • आपके server पर libvips library पहले से install होनी चाहिए. क्योंकि binary image processing के लिए उसी library की सुविधाओं का उपयोग करती है.
  • विस्तृत जानकारी README.md फ़ाइल में दी गई है.

अभी भी बहुत कुछ कम है, और मैं अब भी दूसरे डेवलपर्स की गहरी राय का इंतज़ार कर रहा हूँ. GeekNight इवेंट के समय अपनी झिझक याद करके खुद पर खीझ होती है. bug reports, improvement suggestions, या अलग तरह की राय — सबका स्वागत है.

इस साल दिसंबर कुछ ज़्यादा ही भारी लग रहा है, लेकिन फिर भी उम्मीद है कि नए साल में कुछ बेहतर भविष्य होगा. इतना लंबा लेख पढ़ने के लिए धन्यवाद. आखिर में TSBOARD v1.0.0 release note का लिंक नीचे साझा कर रहा हूँ.

https://tsboard.dev/board/free/47

12 टिप्पणियां

 
angkr 2025-02-03

मैंने यह Damoang पर देखा।
यह एक उम्मीद जगाने वाला CMS है। धन्यवाद।

 
tsboard 2025-02-04

मुझे भी यह देखकर हैरानी हुई कि Damoang में कुछ लोग अब भी मुझे याद रखते हैं. haha उम्मीदों पर खरा उतरने के लिए मैं और मेहनत करूंगा! 😊

 
dongho42 2025-01-03

जानकारीपूर्ण है!

 
tsboard 2025-02-04

देर से सही, लेकिन आपकी टिप्पणी के लिए धन्यवाद! 😃

 
jongyeol 2025-01-02

इम्प्लिसिट interface लागू करना अब भी थोड़ा अटपटा लगता है। क्या वे implements या extends जैसे कीवर्ड इस्तेमाल नहीं करना चाहते थे?

इसके फायदे और नुकसान दोनों हैं, लेकिन फायदे की बात करें तो बिना standard/external library code को बदले, किसी और के बनाए implementation को इस्तेमाल करते हुए उसके एक हिस्से को मेरे बनाए interface की तरह ट्रीट किया जा सकता है। यह मुझे कभी-कभी Java के FunctionalInterface जैसा, या जैसे duck typing को किसी compiled language पर लागू किया गया हो, वैसा लाभ लगता है। इसके उलट अगर implements/extends को अनिवार्य रूप से घोषित करना पड़े, तो मेरे बनाए interface से जोड़ने के लिए बीच में एक Adapter implement करना पड़ता।

नुकसान यह है कि जब interface में method जोड़े/हटाए/बदले जाते हैं, तो दूसरी static typing languages की तुलना में error दिखने की जगह अलग होती है, इसलिए यह थोड़ा असुविधाजनक है।

 
tsboard 2025-01-02

अच्छा, ऐसा है! मैंने तो इस फ़ायदे के बारे में सोचा ही नहीं था। शुक्र है, error message शायद gopls का था? या vscode के Go language extension ने उसे अच्छी तरह पकड़ लिया, इसलिए जो छूट गया था या गलत implement हुआ था, उसे मैं जल्दी ढूंढ सका। थोड़ा और अभ्यस्त हो जाऊं तो मैं भी किसी दिन इसे और बेहतर तरीके से इस्तेमाल कर पाऊंगा, ऐसा लगता है। haha टिप्पणी में समझाकर बताने के लिए धन्यवाद! नया साल आपके लिए बहुत शुभ रहे~!

 
ifmkl 2025-01-02

बहुत मेहनत की है आपने! मैं भी इसे test server पर डालकर देखूंगा! 2025 के नए साल में भी आपकी खूब तरक্কी हो!

 
tsboard 2025-01-02

धन्यवाद! कृपया इसे टेस्ट करके देखें, और अगर यह ठीक से काम न करे या आपका कोई सवाल हो, तो बेझिझक कभी भी बताइएगा! नए साल की हार्दिक शुभकामनाएँ~!

 
channprj 2025-01-01

समर्थन है~ 👍🏻

 
tsboard 2025-01-02

समर्थन के लिए धन्यवाद!!! नववर्ष की हार्दिक शुभकामनाएँ~!

 
zihado 2024-12-31

समर्थन करता हूँ!

 
tsboard 2025-01-02

धन्यवाद!!! नव वर्ष की बहुत-बहुत शुभकामनाएँ!!