[{"content":"रात के 3 बजे हैं। PagerDuty चीख रहा है। कुछ कस्टमर्स के लिए चेकआउट फेल हो रहा है पर कुछ के लिए नहीं। आप एक बॉक्स में SSH करते हैं, लॉग्स को tail करते हैं, और आपका स्वागत होता है INFO: processing request लाइनों की एक दीवार से — जिसमें न कोई ऑर्डर आईडी है, न यूज़र आईडी, न इस बात का कोई निशान कि कौन सी डाउनस्ट्रीम सर्विस अटक गई। अब आप डीबग नहीं कर रहे — आप पुरातत्व (archaeology) कर रहे हैं।\nमैं उस रात के उस पार जितनी बार रहा हूँ, उतना मानने में मुझे थोड़ी हिचक होती है। और सच कहूँ तो, 5 मिनट के फिक्स और 3 घंटे के आउटेज के बीच का फर्क लगभग कभी भी खुद बग नहीं होता। फर्क इस बात का होता है कि आपके लॉग्स ने आपको कुछ उपयोगी बताया या नहीं। तो चलिए बात करते हैं कि अच्छी लॉगिंग असल में कैसी दिखती है — किताबी \u0026ldquo;सब कुछ लॉग करो\u0026rdquo; वाली सलाह नहीं, बल्कि वो चीज़ें जो तब आपको बचाती हैं जब प्रोडक्शन में आग लगी हो।\nजब आपको लॉगिंग की सबसे ज़्यादा ज़रूरत होती है, तब ज़्यादातर लॉगिंग बेकार क्यों होती है यह रही असहज सच्चाई: ज़्यादातर टीमें गलत मात्रा में लॉग नहीं करतीं, वे गलत चीज़ों को गलत तरीके से लॉग करती हैं। एक स्पष्ट रणनीति के बिना, लॉग्स शोरगुल वाले, बिना स्ट्रक्चर के, महँगे और किसी इंसिडेंट के दौरान लगभग बेकार बन जाते हैं [1]। आप user clicked button के गीगाबाइट्स स्टोर करने के लिए एक ख़ज़ाना खर्च कर देते हैं और फिर वो एक लाइन नहीं ढूँढ पाते जो बताती है कि पेमेंट क्यों फेल हुआ।\nएक लॉग लाइन का अस्तित्व ठीक एक वजह से होता है: ताकि भविष्य का आप, इंसिडेंट के बीचों-बीच, बिना उसे दोबारा प्रोड्यूस किए यह पुनर्निर्माण कर सके कि क्या हुआ था। यही कसौटी है। अगर कोई लॉग आपको \u0026ldquo;सिस्टम क्या कर रहा था, किसके लिए, और क्या गलत हुआ\u0026rdquo; का जवाब देने में मदद नहीं करता, तो वह शोर है। लॉग्स को इतना संदर्भ देना चाहिए कि किसी इवेंट को बिना इश्यू दोबारा प्रोड्यूस किए समझा जा सके — टाइमस्टैम्प, स्पष्ट एरर मैसेज, और सिस्टम्स के आर-पार ट्रेस करने के लिए यूनीक आइडेंटिफ़ायर [1]।\nउस एक वाक्य को अपने दिमाग में रखिए और नीचे के ज़्यादातर फैसले अपने आप साफ़ हो जाएँगे।\nलॉग लेवल: इन्हें सजावट की तरह इस्तेमाल करना बंद करें लगभग हर कोई लॉग लेवल को थोड़ा-बहुत गलत करता है। वे logger.info और logger.debug को बस अंदाज़े से इधर-उधर छिड़क देते हैं, और फिर प्रोडक्शन में या तो सब कुछ खामोश रहता है या फिर एक फायरहोस। लॉग लेवल एक सीवियरिटी कॉन्ट्रैक्ट हैं, न कि कोई स्टाइल चॉइस। कॉन्ट्रैक्ट सही करें और आप तुरंत शोर में से सिग्नल छाँट सकते हैं।\nमानक पदानुक्रम, सबसे कम से सबसे ज़्यादा प्राथमिकता तक [4]:\nलेवल कब इस्तेमाल करें क्या इसे किसी को पेज करना चाहिए? TRACE अल्ट्रा-फाइन-ग्रेन्ड फ्लो, प्रति-लूप इटरेशन। प्रोड में शायद ही कभी ऑन। नहीं DEBUG वेरिएबल स्टेट्स, API पेलोड्स, एग्ज़िक्यूशन ब्रांचेस — डेवलपर डायग्नोस्टिक्स [2] नहीं INFO सामान्य रनटाइम इवेंट्स: स्टार्टअप, शटडाउन, यूज़र ऐक्शन्स, स्टेट चेंजेस नहीं WARN कुछ गड़बड़ है पर सिस्टम संभल गया या ग्रेसफुली डीग्रेड हुआ शायद (ट्रेंड) ERROR कोई ऑपरेशन फेल हुआ, पर ऐप चलता रहता है [3] अक्सर FATAL अपूरणीय — ऐप बाहर निकलने वाला है (बूट पर मिसिंग कॉन्फ़िग, OOM) [3] हाँ कुछ राय जिन पर मैं अड़ा रहूँगा:\nINFO आपका प्रोडक्शन डिफ़ॉल्ट है। थ्रेशोल्ड को INFO पर सेट करें और आप INFO, WARN, ERROR, FATAL कैप्चर करते हैं जबकि DEBUG का शोर छोड़ देते हैं [5]। लगभग हर सर्विस के लिए यही सही बेसलाइन है। DEBUG अस्थायी डीबगिंग के लिए है, फिर इसे बंद कर दें। विस्तृत DEBUG लॉग्स लिखने से असली I/O ओवरहेड जुड़ता है जो हाई-थ्रूपुट सिस्टम्स को धीमा करता है और लेटेंसी बढ़ाता है [1]। इसे \u0026ldquo;बस यूँ ही, ज़रूरत पड़ी तो\u0026rdquo; के लिए ऑन मत रहने दें। WARN सबसे ज़्यादा दुरुपयोग किया जाने वाला लेवल है। एक रिट्राई जो सफल हुई वह WARN है। एक फेल हुई रिक्वेस्ट जिसे यूज़र ने सचमुच देखा वह ERROR है। अगर आप \u0026ldquo;हमने इसे संभाल लिया\u0026rdquo; और \u0026ldquo;कस्टमर को 500 मिला\u0026rdquo; के बीच फर्क नहीं बता सकते, तो आपके अलर्ट्स झूठ बोल रहे हैं। रनटाइम पर किसी एक सर्विस के लिए DEBUG ऑन कर पाने की क्षमता — बिना रीडिप्लॉय के — सोने के मोल बराबर है। प्रोड में DEBUG का यही वैध इस्तेमाल है: दस मिनट के लिए ऑन करें, अजीब केस कैप्चर करें, फिर बंद कर दें। इसे सही करें और आपका ऑन-कॉल डैशबोर्ड बन जाता है \u0026ldquo;मुझे पिछले 15 मिनट के सारे ERROR और FATAL दिखाओ\u0026rdquo; — एक ऐसी क्वेरी जिसका सचमुच कोई मतलब है।\nअसल में क्या लॉग करें (और क्या कभी न करें) हर लॉग लाइन में जो फ़ील्ड्स होने चाहिए अगर आप इस लेख से एक चीज़ लेते हैं, तो यह लें: स्ट्रिंग्स लॉग करना बंद करें, स्ट्रक्चर्ड की-वैल्यू रिकॉर्ड्स लॉग करना शुरू करें। स्ट्रक्चर्ड लॉगिंग फ्री टेक्स्ट के बजाय मशीन-रीडेबल की-वैल्यू पेयर (आमतौर पर JSON) निकालती है, ताकि हर फ़ील्ड को फ़िल्टरिंग और सर्विसेस के आर-पार कोरिलेशन के लिए स्वतंत्र रूप से क्वेरी किया जा सके [12]। क्वेरी टाइम पर फर्क ज़मीन-आसमान का है — grep बनाम एक असली WHERE order_id = '...'।\nहर प्रोडक्शन लॉग लाइन में, कम से कम, ये होने चाहिए [12]:\ntimestamp — ISO 8601, UTC में। हमेशा UTC। किसी इंसिडेंट के दौरान टाइमज़ोन बग्स अपने आप में एक खास नर्क हैं। level — ऊपर वाली सीवियरिटी service — किस सर्विस ने इसे निकाला event — एक छोटा, सुसंगत नाम जैसे payment.captured या order.rejected trace_id और request_id — कोरिलेशन का गोंद (इस पर आगे और बात) domain fields — user_id, order_id, tenant_id — जो भी आपको किसके और किसके हिसाब से स्लाइस करने दे यहाँ वही फेलियर दो तरीकों से लॉग किया गया है। बिना स्ट्रक्चर के:\nERROR Payment failed for user after timeout स्ट्रक्चर्ड:\n{ \u0026#34;timestamp\u0026#34;: \u0026#34;2026-06-20T15:42:11.204Z\u0026#34;, \u0026#34;level\u0026#34;: \u0026#34;ERROR\u0026#34;, \u0026#34;service\u0026#34;: \u0026#34;payments-api\u0026#34;, \u0026#34;event\u0026#34;: \u0026#34;payment.capture_failed\u0026#34;, \u0026#34;trace_id\u0026#34;: \u0026#34;4bf92f3577b34da6a3ce929d0e0e4736\u0026#34;, \u0026#34;request_id\u0026#34;: \u0026#34;req_8821aa\u0026#34;, \u0026#34;user_id\u0026#34;: \u0026#34;usr_4471\u0026#34;, \u0026#34;order_id\u0026#34;: \u0026#34;ord_99812\u0026#34;, \u0026#34;gateway\u0026#34;: \u0026#34;stripe\u0026#34;, \u0026#34;error_code\u0026#34;: \u0026#34;gateway_timeout\u0026#34;, \u0026#34;duration_ms\u0026#34;: 30021 } पहला आपको बताता है कि कुछ टूट गया। दूसरा आपको बताता है कि payments-api ने एक खास ऑर्डर के लिए Stripe से बात करते हुए 30 सेकंड बाद टाइमआउट किया, और आपको तुरंत हर वह दूसरी रिक्वेस्ट ढूँढने देता है जो उसी गेटवे टाइमआउट से टकराई। इनमें से एक ही 3am के इंसिडेंट में टिकता है।\nफ़ील्ड नामों पर एक और बात: एक कन्वेंशन चुनें और उसे कभी न तोड़ें। अगर यह एक सर्विस में user_id है, तो इसे दूसरी में userId या user मत बनाइए [4]। मैंने उन सर्विसेस के लॉग्स को जोड़ने में असली समय बर्बाद किया है जो केसिंग पर असहमत थीं। snake_case पर टिके रहें, इसे एक शेयर्ड लॉगिंग लाइब्रेरी में लिखें, और इंसानों के याद रखने पर निर्भर रहना बंद करें।\nएरर्स को स्ट्रक्चर्ड डेटा के रूप में लॉग करें, स्टैक-ट्रेस सूप के रूप में नहीं एक कच्चे स्टैक ट्रेस को एक विशाल स्ट्रिंग फ़ील्ड के रूप में मत उड़ेलिए। स्ट्रक्चर्ड एरर जानकारी लॉग करें — एरर टाइप, मैसेज, कोड, और स्टैक को उसके अपने फ़ील्ड के रूप में [12]। एक स्ट्रिंगिफ़ाइड स्टैक ट्रेस खोजा नहीं जा सकता और आपकी स्टोरेज को फुला देता है। स्ट्रक्चर्ड एरर फ़ील्ड्स आपको रेगेक्स की कसरत किए बिना \u0026ldquo;पिछले एक घंटे में कितने gateway_timeout एरर्स\u0026rdquo; पूछने देते हैं।\nक्या कभी लॉग न करें यहीं लापरवाही एक ब्रीच या कंप्लायंस जुर्माने में बदल जाती है। सीक्रेट्स या PII कभी लॉग न करें। यूज़रनेम, पासवर्ड, सिक्योरिटी क्वेश्चन, API कीज़, एक्सेस टोकन, प्राइवेट कीज़, और सेशन आईडी कभी किसी लॉग में नहीं आने चाहिए [13][16]। यही व्यक्तिगत रूप से पहचान योग्य जानकारी के लिए भी — नाम, पते, सरकारी आईडी, पूरी पेमेंट डिटेल्स [17]।\nऔर यह रहा वह हिस्सा जो लोग गलत करते हैं: रिडैक्ट करना याद रखने के लिए डेवलपर्स पर निर्भर मत रहिए। कोई न कोई हमेशा भूल जाता है। सही तरीका है ऑटोमेटेड फ़िल्टर्स जो लिखे जाने से पहले सीक्रेट्स को हटा दें, साथ ही एक allowlist — स्पष्ट रूप से उन गैर-संवेदनशील फ़ील्ड्स को परिभाषित करें जिन्हें शामिल करने की अनुमति है, बजाय हर संवेदनशील फ़ील्ड को ब्लॉकलिस्ट करने की कोशिश के [16][17]। Allowlists फेल होने पर सुरक्षित रहती हैं; blocklists फेल होने पर खुली रहती हैं।\nOWASP Logging Cheat Sheet यहाँ का प्रामाणिक संदर्भ है, और अगर आप कुछ भी रेगुलेटेड संभाल रहे हैं तो यह पढ़ने लायक है [15]।\nसर्विसेस के आर-पार कोरिलेशन: वह हिस्सा जो असल में मायने रखता है यहीं डिस्ट्रिब्यूटेड सिस्टम में लॉगिंग वाकई मुश्किल हो जाती है। एक मोनोलिथ में, एक रिक्वेस्ट = एक थ्रेड = एक सतत लॉग स्ट्रीम। माइक्रोसर्विसेस में, एक अकेला यूज़र ऐक्शन छह सर्विसेस, दो क्यू, और एक बैकग्राउंड जॉब को छू सकता है — और हर एक अपनी ही स्ट्रीम में लॉग करता है। उन्हें जोड़ने वाले एक धागे के बिना, आपके पास एक के बजाय छह अलग-अलग खून के मामले होते हैं।\nवह धागा है एक कोरिलेशन आईडी (या ट्रेस आईडी): एक यूनीक आइडेंटिफ़ायर जो किसी रिक्वेस्ट से जुड़ा होता है और हर सर्विस सीमा के आर-पार उसके साथ यात्रा करता है [9]। जब कोई रिक्वेस्ट आपके सिस्टम में प्रवेश करती है, तो उसे एक आईडी मिलती है। हर सर्विस उस आईडी को आने वाली रिक्वेस्ट से निकालती है और किसी भी डाउनस्ट्रीम कॉल के हेडर्स में उसे आगे पास करती है [10]। फिर हर लॉग लाइन उसे शामिल करती है। अब आप एक ही क्वेरी से उस एक रिक्वेस्ट के लिए हर सर्विस के आर-पार के हर लॉग को खींच सकते हैं।\nअपना खुद का हेडर मत बनाइए — W3C Trace Context इस्तेमाल करें आप अपना खुद का X-Correlation-ID हेडर बना सकते हैं, और बहुत सी टीमें बनाती हैं। पर अब एक स्टैंडर्ड है, और इसे अपनाना सार्थक है। W3C Trace Context स्पेक एक traceparent हेडर परिभाषित करता है जिसे सब कुछ समझता है [13]। इसका फ़ॉर्मैट बेहद सरल है:\ntraceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 │ │ │ │ version trace-id (32 hex) parent span-id flags ट्रेस आईडी पूरी रिक्वेस्ट यात्रा की पहचान करती है; स्पैन आईडी उसके भीतर एक ऑपरेशन की पहचान करती है [14]। इसे इस्तेमाल करें और कोई भी कंप्लायंट टूल — Jaeger, Zipkin, Sentry, Datadog — बिना कस्टम गोंद के आपके ट्रेस को सिल सकता है [10]।\nलॉग्स बनाम ट्रेसेस — ये चचेरे भाई हैं, जुड़वाँ नहीं लोग इन्हें घालमेल कर देते हैं, तो मुझे फर्क के बारे में सीधा-सीधा कहने दीजिए:\nएक trace सर्विसेस के आर-पार किसी रिक्वेस्ट की स्ट्रक्चर्ड टाइमलाइन है, जो नेस्टेड spans से बनी होती है, हर स्पैन एक ऑपरेशन होता है जिसका एक स्टार्ट, एंड और ड्यूरेशन होता है। एक log संदर्भ के साथ एक पॉइंट-इन-टाइम इवेंट है। जादू तब होता है जब आप अपनी लॉग लाइनों में trace_id डालते हैं। तब आप अपने ट्रेस व्यू में एक धीमे स्पैन से सीधे उस स्पैन के दौरान निकले ठीक उन्हीं लॉग्स पर कूद सकते हैं। यही आधुनिक डिस्ट्रिब्यूटेड ट्रेसिंग का पूरा खेल है [8]।\nOpenTelemetry वह टूल है जिसे मैं यहाँ चुनूँगा। इसके SDK डिफ़ॉल्ट प्रोपगेशन फ़ॉर्मैट के रूप में W3C Trace Context इस्तेमाल करते हैं, तो अगर आप OTel से इंस्ट्रूमेंट करते हैं तो आपको क्रॉस-सर्विस कोरिलेशन लगभग मुफ़्त में मिल जाता है [13]। हर HTTP क्लाइंट से हाथ से हेडर पिरोने की ज़रूरत नहीं।\nएक व्यावहारिक टिप: थ्रेड-लोकल कॉन्टेक्स्ट ज़्यादातर फ्रेमवर्क्स में आप कोरिलेशन आईडी को हर फंक्शन सिग्नेचर के ज़रिए हाथ से पास नहीं करना चाहेंगे — वह दुखदायी है। एक कॉन्टेक्स्ट मैकेनिज़्म इस्तेमाल करें: Java/SLF4J दुनिया में MDC (Mapped Diagnostic Context), Go में context.Context, Node में async local storage। जब रिक्वेस्ट आती है तब आप ट्रेस आईडी एक बार सेट करते हैं, और लॉगिंग फ्रेमवर्क उस रिक्वेस्ट के बाकी हिस्से के लिए हर लाइन पर इसे अपने आप ठप्पा लगा देता है [10]। इसे मिडलवेयर में सेट करें, फिर भूल जाइए।\nकैनोनिकल लॉग लाइन: मेरा पसंदीदा कम आँका गया पैटर्न इसने मेरे लॉगिंग के बारे में सोचने का तरीका बदल दिया, और यह Stripe के इंजीनियरिंग ब्लॉग से आता है। विचार: अपने सामान्य बिखरे हुए लॉग्स के साथ-साथ, हर रिक्वेस्ट के अंत में एक मोटी, स्ट्रक्चर्ड लॉग लाइन निकालें जिसमें सारी ज़रूरी टेलीमेट्री एक ही जगह हो [20]।\nतो किसी रिक्वेस्ट के अंत में आप एक अकेली लाइन निकालते हैं जिसमें होता है: रूट, यूज़र आईडी, रिस्पॉन्स स्टेटस, कुल ड्यूरेशन, कौन सी डाउनस्ट्रीम सर्विसेस को कॉल किया गया और हर एक ने कितना समय लिया, ऑथ मेथड, ट्रेस आईडी — उस रिक्वेस्ट के बारे में जो भी मायने रखता है, सब एक साथ।\nयह इतना अच्छा क्यों है? क्योंकि किसी इंसिडेंट के दौरान, आप पाँच अलग-अलग लॉग स्टेटमेंट्स को जोड़ने के बजाय एक लाइन पर एक क्वेरी लिखते हैं [20]। कम्युनिटी ने इसी विचार को wide events नाम से दोबारा खोजा है — हर रिक्वेस्ट के लिए एक व्यापक इवेंट जिसमें हर ऐट्रिब्यूट जुड़ा हो [20]। वही अवधारणा, और ऑब्ज़र्वेबिलिटी इसी दिशा में जा रही है।\nStripe से चतुर इम्प्लीमेंटेशन डिटेल: वे एमिशन को एक ensure ब्लॉक (मूलतः एक finally) में लपेटते हैं ताकि कैनोनिकल लाइन तब भी लिखी जाए जब रिक्वेस्ट बीच में ही एक्सेप्शन फेंक दे [20]। यह रही इसकी आकृति:\ndef handle_request(req): ctx = {\u0026#34;request_id\u0026#34;: req.id, \u0026#34;route\u0026#34;: req.route, \u0026#34;user_id\u0026#34;: req.user_id} try: result = process(req) ctx[\u0026#34;status\u0026#34;] = result.status return result finally: ctx[\u0026#34;duration_ms\u0026#34;] = elapsed_ms() logger.info(\u0026#34;canonical_line\u0026#34;, **ctx) # always runs सामान्य लॉगिंग और प्रति रिक्वेस्ट एक कैनोनिकल लाइन, दोनों करें। सामान्य लॉग्स आपको पल-पल का ब्योरा देते हैं; कैनोनिकल लाइन आपको स्कोरकार्ड देती है।\nलॉग्स को किफ़ायती रखना: बिना अंधे हुए सैम्पलिंग लॉग्स जल्दी महँगे हो जाते हैं, और भोली प्रतिक्रिया — \u0026ldquo;बस कम लॉग करो\u0026rdquo; — आमतौर पर मतलब है कि आप वही चीज़ बंद कर देते हैं जिसकी आपको ज़रूरत थी। समझदारी भरा कदम है सैम्पलिंग: स्ट्रीम का केवल एक हिस्सा रखें, पर इस बारे में सोच-समझकर रहें कि कौन सा हिस्सा [18]।\nहाई-वॉल्यूम सिस्टम्स के लिए जो रणनीति मैं सुझाऊँगा [18][19]:\nएरर्स और वॉर्निंग्स को कभी सैम्पल न करें। वे दुर्लभ और बहुमूल्य हैं। उनका 100% रखें। उबाऊ चीज़ों को आक्रामक रूप से सैम्पल करें — हेल्थ चेक्स, सफल ऑथ, रूटीन 200s। 100 में से 1 रखना भी आपको साफ़ ट्रैफ़िक पैटर्न दिखाता है [18]। सैम्पल रेट को हमेशा लॉग में ही रिकॉर्ड करें, ताकि आपका विश्लेषण इसे वापस गुणा कर सके और वॉल्यूम्स के बारे में आपसे झूठ न बोले [18]। अपनी स्टोरेज को टियर करें — हाल के लॉग्स के लिए हॉट/सर्चेबल, पुराने के लिए सस्ता कोल्ड आर्काइव। स्ट्रक्चर्ड लॉग्स इसे आसान बनाते हैं क्योंकि हर लाइन में रूट करने के लिए क्वेरी करने योग्य मेटाडेटा होता है [12]। Datadog, Better Stack और दूसरों के पास इसे ट्यून करने पर अच्छे गहन-विश्लेषण हैं, पर सिद्धांत हर जगह टिकता है: शोर को सैम्पल करें, सिग्नल को कभी सैम्पल न करें, और अपना रेट हमेशा जानें।\nसाथ ही — उबाऊ पर लोगों को काटता है — अपने लॉग्स को रोटेट और आर्काइव करें। असीमित लॉग फ़ाइलें डिस्क भर देती हैं और ठीक उसी सर्विस को गिरा देती हैं जिसे आप ऑब्ज़र्व करने की कोशिश कर रहे थे [1]। रोटेशन सेट करें, रिटेंशन सेट करें, आगे बढ़ें।\nएक झटपट गट-चेक लिस्ट अपनी लॉगिंग को \u0026ldquo;हो गई\u0026rdquo; कहने से पहले, इससे गुज़रिए:\nक्या लॉग्स सुसंगत फ़ील्ड नामों के साथ स्ट्रक्चर्ड JSON हैं? [12] क्या हर लाइन में एक trace_id है जो सर्विसेस के आर-पार प्रोपगेट होता है? [13] क्या INFO आपका प्रोड डिफ़ॉल्ट है, जिसमें DEBUG रनटाइम पर फ्लिप किया जा सके? [5] क्या ERROR और FATAL का मतलब कुछ ऐसा है जिसकी एक ऑन-कॉल इंसान को परवाह करनी चाहिए? [3] क्या सीक्रेट्स और PII एक ऑटोमेटेड allowlist द्वारा हटाए जाते हैं, न कि डेवलपर की याददाश्त द्वारा? [16] क्या आप प्रति रिक्वेस्ट एक कैनोनिकल/वाइड लाइन निकालते हैं? [20] क्या एरर्स और वॉर्निंग्स सैम्पलिंग से मुक्त हैं? [18] क्या टाइमस्टैम्प UTC और ISO 8601 हैं? [12] अगर आप इन पर टिक लगा सकते हैं, तो आपका अगला 3am पेज काफ़ी छोटा होने वाला है।\nलक्ष्य कभी \u0026ldquo;सब कुछ लॉग करो\u0026rdquo; नहीं था। यह सुनिश्चित करना था कि जब कुछ टूटे — और यह टूटेगा — तो जवाब पहले से ही एक ऐसी क्वेरी में बैठा हो जिसे आप पंद्रह सेकंड में, आधी नींद में, पेजर के अब भी भनभनाते हुए लिख सकें।\nस्रोत Logging Best Practices: 12 Tips for Developers and SREs — Parseable Logging Levels Explained — SigNoz Log Debug vs. Info vs. Warn vs. Error and Fatal — Edge Delta Log Levels: Different Types and How to Use Them — Last9 Log Levels Explained and How to Use Them — Better Stack Logging Best Practices: 12 Dos and Don\u0026rsquo;ts — Better Stack Logging Best Practices: The 13 You Should Know — DataSet Pattern: Distributed tracing — microservices.io Understanding and Implementing Correlation ID in Microservices — Anil Goyal Distributed Tracing Logs: How They Work \u0026amp; Best Practices — groundcover Structured Logging in Production: Best Practices for Scalable Systems — OpenObserve Structured Logging: Best Practices \u0026amp; JSON Examples — Uptrace OpenTelemetry Context Propagation: W3C TraceContext — Uptrace Traceparent: How OpenTelemetry Connects Your Microservices — Last9 Logging Cheat Sheet — OWASP Best Logging Practices for Safeguarding Sensitive Data — Better Stack How to Keep Sensitive Data Out of Your Logs: 9 Best Practices — Skyflow Log Sampling: Techniques, Challenges \u0026amp; Best Practices — groundcover How to Reduce Logging Costs with Log Sampling — Better Stack Fast and flexible observability with canonical log lines — Stripe How to optimize high-volume log data without compromising visibility — Datadog ","permalink":"https://cloudmato.com/hi/posts/logging-best-practices-production-troubleshooting/","title":"प्रोडक्शन ट्रबलशूटिंग के लिए लॉगिंग की बेस्ट प्रैक्टिसेस"},{"content":"आप Windows 11 खोलते हैं, Start menu पर राइट-क्लिक करते हैं, और देखते हैं: Command Prompt, PowerShell, Windows Terminal। तीन चीज़ें। आप बस एक झटपट command चलाना चाहते थे। अब आप अपने जीवन के फैसलों पर सवाल उठा रहे हैं।\nयह उलझन वास्तविक है, और सच में, Microsoft ने इसे आसान नहीं बनाया। लेकिन PowerShell के अस्तित्व का एक वास्तविक अच्छा कारण है — और एक बार जब आप इसे समझ लेते हैं, तो पूरी तस्वीर स्पष्ट होने लगती है।\nCMD कभी सच में Shell नहीं था — यह एक अस्थायी समाधान था शुरुआत से शुरू करते हैं। cmd.exe — Command Prompt — दिसंबर 1987 में Windows NT के लॉन्च से मौजूद है [1]। इससे पहले, MS-DOS में COMMAND.COM काम संभालता था। तो हाँ, Windows में लगभग 40 साल से command-line interface है।\nलेकिन यहाँ वह बात है जो लोग चूक जाते हैं: CMD को power users या administrators के लिए डिज़ाइन नहीं किया गया था। इसे पुराने DOS batch files को चलाए रखने और आपको बुनियादी काम करने देने के लिए बनाया गया था — एक फ़ाइल कॉपी करना, IP address जाँचना, एक program चलाना। बस इतना ही। इसकी जड़ें 1980s के एक single-user, single-tasking operating system में थीं, और वह बोझ कभी दूर नहीं हुआ।\nWindows command-line का विकास इस कहानी को अच्छी तरह बताता है — CMD हमेशा पीछे भागता रहा, कभी भी आधुनिक Windows systems की जटिलता के लिए सच में डिज़ाइन नहीं किया गया था [2]।\nकुछ वास्तविक CMD सीमाएँ जो लोगों को पागल कर देती थीं:\nअधिकतम command line string लंबाई: 8,191 characters। लंबे file paths पास करने की कोशिश में उस सीमा को छूने पर cryptic failures मिलती थीं [3]। Objects के लिए कोई native support नहीं — सब कुछ plain text है, इसलिए आपको string gymnastics से output parse करना पड़ता था। .bat files में scripting capabilities वास्तव में भयानक हैं — conditional logic, loops, error handling — सब दर्दनाक। Registry, services, WMI, या Active Directory जैसे Windows internals तक शून्य built-in पहुँच। उल्लेखनीय tab completion नहीं। Syntax highlighting नहीं। कोई modern UX नहीं। जब आप एक PC manage कर रहे हों, तो ये सीमाएँ परेशान करने वाली हैं। जब आप एक enterprise में सैकड़ों या हज़ारों Windows machines के लिए ज़िम्मेदार sysadmin हों? CMD के पास जो चाहिए वह पास भी नहीं आता [4]। बुनियादी bulk administration करने के लिए भी आपको VBScript से script करना होता या custom tools लिखने होते। यह एक गड़बड़ी थी।\nएक आदमी इससे थक गया — और उसने एक Manifesto लिखा यहीं से कहानी दिलचस्प होती है।\n1999 में, Jeffrey Snover नाम के एक developer Microsoft में शामिल हुए। उनके पास Unix background था और वे जानते थे कि एक असली shell क्या कर सकती है। उन्होंने Windows system administration को देखा और, उनके अपने स्वीकारोक्ति के अनुसार, भयभीत हो गए। Unix में bash, grep, awk, sed था — scale पर systems manage करने के लिए composable tools का पूरा ecosystem। Windows में\u0026hellip; .bat files थीं।\nSnover ने इस समस्या के बारे में कुछ साल सोचा। फिर, 8 अगस्त, 2002 को, उन्होंने वह लिखा जो Monad Manifesto के नाम से जाना जाता है — एक 17-page document जो एक नए प्रकार के Windows shell के लिए उनके vision को रखता है [5]। उन्होंने project का नाम Monad रखा।\nManifesto आश्चर्यजनक रूप से पठनीय है। Snover का मूल तर्क यह था: Unix shells शक्तिशाली हैं क्योंकि वे text की pipelines के माध्यम से simple tools को compose करती हैं। लेकिन text नाज़ुक होता है — आपको इसे parse करना, split करना, columns गिनना होता है, और प्रार्थना करनी होती है कि output format कभी न बदले। क्या होगा अगर इसकी जगह आप objects pipe करें? Named properties के साथ structured data, raw strings नहीं?\nवह विचार — pipeline में objects, text नहीं — वह एकमात्र सबसे बड़ी चीज़ है जो PowerShell को CMD (और सच में bash से भी) अलग करती है।\nMonad का नाम बदला गया और PowerShell 1.0 को आधिकारिक रूप से नवंबर 2006 में जारी किया गया [6]। Manifesto से ship होने तक चार साल लगे।\nPowerShell वास्तव में क्या अलग करता है ठीक है, पर्याप्त इतिहास — चलिए बात करते हैं क्यों यह व्यावहारिक रूप से महत्वपूर्ण है।\nObjects, Text नहीं जब आप PowerShell में Get-Process चलाते हैं, तो आपको एक string नहीं मिलती। आपको System.Diagnostics.Process .NET objects का एक collection मिलता है — हर एक में Name, Id, CPU, WorkingSet जैसी properties होती हैं [7]। उनके types होते हैं। आप उन्हें filter कर सकते हैं, sort कर सकते हैं, compare कर सकते हैं, string parsing को कभी छुए बिना।\nतुलना करें:\n# PowerShell — reads like English, rock solid Get-Process | Where-Object WorkingSet -gt 100MB | Sort-Object CPU -Descending REM CMD — parsing text by character position, good luck tasklist /NH | sort /R /+65 CMD version output में character positions गिनता है। Windows version बदलें, column width बदले — यह चुपचाप टूट जाता है। PowerShell version? यह चाहे जो हो, ठीक काम करेगा।\nयह .NET पर बना है — जिसका मतलब है यह लगभग कुछ भी कर सकता है PowerShell cmdlets .NET Framework (और बाद में .NET Core) पर बने हैं। इसका मतलब है आप अपने shell से सीधे .NET APIs call कर सकते हैं। Active Directory, Windows registry, Event Logs, COM objects, REST APIs, या WMI के साथ interact करना चाहते हैं? PowerShell में इन सभी के लिए native cmdlets हैं [4]।\nCMD शाब्दिक रूप से external tools के बिना इनमें से कुछ भी नहीं कर सकता।\nScale पर Remote Management Invoke-Command आपको एक साथ 500 remote Windows machines पर PowerShell script चलाने देता है। यह अतिशयोक्ति नहीं है — enterprise sysadmins वास्तव में इसी के लिए इसका उपयोग करते हैं। CMD का कोई equivalent नहीं है। शून्य।\nऔर फिर Microsoft ने उलझन पैदा की यहीं से चीज़ें बिगड़ती हैं।\nPowerShell 1.0 से 5.1 तक — जिसे Windows PowerShell कहा जाता था — Windows-only था, पुराने .NET Framework पर बना था। फिर अगस्त 2016 में, Microsoft ने कुछ ऐसा किया जिसकी किसी को उम्मीद नहीं थी: उन्होंने PowerShell को open-source किया और Linux और macOS के लिए जारी किया [8]। उन्होंने इसे .NET Core पर फिर से बनाया और नई चीज़ को PowerShell Core 6.0, अंततः बस PowerShell 7 कहा।\nतो अब हैं — और मैं मज़ाक नहीं कर रहा — दो अलग PowerShells:\nविशेषता Windows PowerShell 5.1 PowerShell 7.x Executable powershell.exe pwsh.exe आधारित .NET Framework .NET Core / .NET 5+ Platform केवल Windows Windows, Linux, macOS स्थिति केवल Maintenance सक्रिय विकास Pre-installed हाँ (Windows) नहीं, अलग install Windows PowerShell 5.1 को अब नई features नहीं मिल रही हैं — Microsoft केवल security bugs के लिए इसे patch करता है [9]। PowerShell 7 में सभी नई चीज़ें होती हैं। लेकिन Windows अभी भी 5.1 pre-installed के साथ आता है, और PowerShell 7 एक अलग download है।\nतो अगर आप Windows के साथ आने वाला \u0026ldquo;PowerShell\u0026rdquo; खोलते हैं — वह पुराना वाला है। और कुछ modules जो 5.1 में काम करते हैं वे अभी 7 में काम नहीं करते। और इसके विपरीत भी। सच में, यहीं यह पेचीदा हो जाता है।\nऔर फिर Windows Terminal आया मई 2019 में Microsoft Build पर, उन्होंने Windows Terminal की घोषणा की — एक बिल्कुल नया tabbed terminal application [10]। यह मई 2020 में stable हुआ।\nलेकिन यहाँ बात यह है: Windows Terminal एक shell नहीं है। यह बस एक host app है — एक सुंदर wrapper जो CMD, PowerShell 5.1, PowerShell 7, WSL (Windows Subsystem for Linux), या SSH sessions चला सकता है — सभी tabs में, GPU-accelerated text rendering, themes, custom fonts, और split panes के साथ।\nइसे इस तरह सोचें:\nCMD = एक shell (engine, interpreter) PowerShell = एक shell (अधिक शक्तिशाली engine) Windows Terminal = वह window जो उन shells को अंदर चलाती है समस्या यह है कि जब आप Windows 11 पर Windows Terminal खोलते हैं, तो यह PowerShell पर default होता है। इसलिए बहुत से लोग सोचते हैं कि Windows Terminal ही PowerShell है। ऐसा नहीं है। यह बस PowerShell को default के रूप में धारण किए हुए है।\nवह mental model जो Microsoft ने उम्मीद की कि लोग खुद समझेंगे:\nWindows Terminal (the window) ├── PowerShell 7 tab ← आधुनिक shell ├── Windows PowerShell 5.1 tab ← पुरानी shell ├── Command Prompt tab ← प्राचीन shell └── Ubuntu (WSL) tab ← Windows पर Linux shell तो CMD को ठीक क्यों नहीं किया? उचित सवाल। Microsoft ने कुछ बिल्कुल नया बनाने की बजाय CMD को upgrade क्यों नहीं किया?\nजवाब है backwards compatibility — वह चीज़ जो हर Windows निर्णय को सताती है। CMD का उपयोग शाब्दिक रूप से लाखों batch scripts द्वारा enterprises, अस्पतालों, बैंकों, सरकारी systems में किया जाता है। cmd.exe को छूएं, और कुछ महत्वपूर्ण टूट जाता है। CMD engine जानबूझकर maintenance mode में है क्योंकि \u0026ldquo;हर बार जब कोई बदलाव किया जाता है, तो कुछ महत्वपूर्ण टूट जाता है\u0026rdquo; [11]।\nएक strategic architectural कारण भी था: 2002 के आसपास, Microsoft COM (Component Object Model) programming से .NET Framework में जा रहा था। .NET पर एक नई shell बनाना पूरी तरह समझ में आता था। DOS-era interpreter पर .NET को retrofit करना एक nightmare होता।\nइसलिए उन्होंने PowerShell को एक parallel track के रूप में बनाया — नए users इसे पाते हैं, पुराने systems CMD चलाते रहते हैं, अंततः CMD fade out होता है। सिद्धांत में। व्यवहार में, CMD 20 साल बाद भी वहाँ है, सबको उलझाते हुए।\nक्या आपको वास्तव में PowerShell सीखनी चाहिए? अगर आप Windows पर एक developer या sysadmin हैं, तो जवाब है हाँ, और विशेष रूप से PowerShell 7 — वह cross-platform वाला जिसे आप अलग से install करते हैं (pwsh.exe)। यह सक्रिय रूप से maintained है, Linux और Mac पर काम करता है, और यही वह है जिसमें Microsoft आगे निवेश कर रहा है [12]।\nअगर आप बस झटपट एक बार के commands चला रहे हैं — एक file ढूंढना, network config जाँचना — CMD अभी भी उसके लिए ठीक काम करता है। कोई आपको नहीं रोक रहा।\nअसली जाल यह सोचना है कि ये tools परस्पर बदले जा सकते हैं। वे नहीं हैं। PowerShell loops, functions, error handling, classes, और remote execution के साथ एक proper scripting language है। CMD glorified batch files के साथ एक command runner है। 2026 में automation के लिए CMD का उपयोग करना raw CGI में एक web app लिखने जैसा है — तकनीकी रूप से संभव, व्यावहारिक रूप से दर्दनाक।\nयहाँ एक मोटा guide है:\nCMD का उपयोग करें जब: आप legacy .bat scripts चला रहे हैं, एक झटपट ipconfig या ping कर रहे हैं, या locked-down enterprise environment में काम कर रहे हैं Windows PowerShell 5.1 का उपयोग करें जब: आपको ऐसे modules चाहिए जो अभी PS7 पर नहीं हैं, या आप ऐसी machine पर हैं जहाँ PS7 install करना option नहीं है PowerShell 7 का उपयोग करें जब: बाकी सब के लिए — automation, scripting, DevOps, cloud management, कुछ भी गंभीर Windows Terminal का उपयोग करें जब: आप उपरोक्त सभी को themes के साथ एक अच्छी tabbed window में चाहते हैं \u0026ldquo;Microsoft ने यह क्यों किया?\u0026rdquo; का असली जवाब Microsoft ने इसे जानबूझकर उलझाऊ नहीं बनाया। उन्होंने एक वास्तविक रूप से अच्छा engineering निर्णय लिया (PowerShell administration के लिए CMD से वैध रूप से बेहतर है), लेकिन फिर वर्षों के naming decisions, backwards compatibility constraints, एक open-source pivot, दो parallel product lines, और एक नया terminal host app — सभी को बिना end users को mental model स्पष्ट रूप से समझाए — परत दर परत जोड़ते गए।\nCMD बना रहा क्योंकि उसे रहना था। PowerShell बनाया गया क्योंकि CMD scale नहीं हो सकता था। Windows Terminal आया क्योंकि पुराना console host शर्मनाक रूप से पुराना था। और PowerShell 7, 5.1 के साथ-साथ मौजूद है क्योंकि cross-platform एक बड़ा architectural बदलाव था जिसे version bump handle नहीं कर सकता था।\nइनमें से कोई भी अतार्किक नहीं है — यह बस दशकों के accumulated decisions हैं जिन्हें किसी ने regular लोगों के लिए एक simple picture में map करने की परवाह नहीं की। जो Microsoft के लिए बहुत, बहुत on-brand है।\nसमाप्त\nस्रोत Cmd.exe — विकिपीडिया Windows Command-Line: Windows Command-Line का विकास — Microsoft DevBlogs Command prompt line string सीमा — Microsoft Learn 2.1. CMD.exe की सीमाएँ — O\u0026rsquo;Reilly Professional Windows PowerShell Monad Manifesto — Microsoft Learn Monad Manifesto – Windows PowerShell की उत्पत्ति — PowerShell Team Blog PowerShell Object Pipelines बनाम CMD Text Parsing — Windows News AI PowerShell अब open-source और cross-platform है — .NET Blog Windows PowerShell 5.1 से PowerShell 7 में Migration — Microsoft Learn Windows Terminal का परिचय — Windows Command Line Blog CMD maintenance mode में है — The Register Windows PowerShell का कोई भविष्य नहीं — PowerShell Core में बदलें — 4sysops ","permalink":"https://cloudmato.com/hi/posts/why-powershell-when-cmd-exists/","title":"PowerShell क्यों है जब CMD पहले से था"},{"content":"Module Federation एक ऐसी अवधारणा है जिसे हर कोई तब उठाता है जब किसी मीटिंग में \u0026ldquo;micro frontends\u0026rdquo; का जिक्र होता है। बढ़िया लगता है — runtime पर code share करो, टीमों को independently deploy करो। फिर टीम का कोई कहता है \u0026ldquo;हम webpack पर नहीं, Vite पर हैं\u0026rdquo; और पूरी बातचीत अजीब हो जाती है। तो जब आप Module Federation को Vite project में लाने की कोशिश करते हैं तो वास्तव में क्या होता है? कुछ हिस्से बेहतरीन तरीके से काम करते हैं। कुछ\u0026hellip; वास्तव में नहीं करते, कम से कम अभी तक तो नहीं।\nठीक है, तो Module Federation क्या है फिर से? जल्दी से याद दिला देते हैं क्योंकि यह Vite की कहानी समझने के लिए जरूरी है। Module Federation एक JavaScript application को दूसरे application से runtime पर code load करने देता है, build time पर नहीं। एक app (\u0026ldquo;remote\u0026rdquo;) कुछ modules expose करती है — एक component, एक utility, एक पूरा page — और उन्हें एक छोटी entry file में bundle करती है, जिसे आमतौर पर remoteEntry.js कहते हैं। दूसरी app (\u0026ldquo;host\u0026rdquo;) उस entry file को dynamically import करती है और exposed code को normal import की तरह उपयोग करती है।\nयह मूल रूप से एक webpack 5 feature था, webpack के chunk-loading runtime में गहराई से बना हुआ। Webpack इसे first-class concept मानता है — इसका पूरा module graph, code-splitting, और async chunk loader इसी को ध्यान में रखकर बनाया गया था।\nVite, दूसरी ओर, इस idea के आधार पर कभी नहीं बना था। Vite का dev server browser को native ES modules directly serve करता है, और इसके production builds Rollup से होकर जाते हैं। इनमें से किसी में भी \u0026ldquo;runtime पर एक remote module graph load करो और उसे अपने साथ merge करो\u0026rdquo; का कोई concept नहीं है। इसलिए Vite में Module Federation built-in नहीं है — एकदम सीधी बात। यहाँ आप जो भी करते हैं वह community (या community-turned-official) plugins द्वारा जोड़ा गया है।\nVite में यह built-in नहीं है — कौन इस कमी को पूरा करता है दो main players हैं, और honestly, इनके बीच चुनाव ही आपका पहला असली निर्णय है।\nपुराना और अधिक battle-tested वाला है @originjs/vite-plugin-federation [1]। यह एक virtual module (virtual:__federation__) के आसपास बना अपना runtime ship करता है, और इसे explicitly webpack के Module Federation से आने वाले लोगों को familiar feel कराने के लिए design किया गया था — exposes, remotes, और shared का वही mental model।\nनया वाला है @module-federation/vite [2], जिसे Module Federation 2.0 के पीछे की वही टीम maintain करती है। खुद का runtime बनाने की बजाय, यह Vite को directly @module-federation/runtime से जोड़ता है, वही runtime जो webpack और Rspack implementations को power करता है। यह इसलिए मायने रखता है क्योंकि Module Federation 2.0 को specifically किसी भी particular bundler से runtime को decouple करने के लिए rebuild किया गया था — लक्ष्य यह था कि Rspack से बना एक remote और Vite से बना एक host एक ही protocol का उपयोग करके एक दूसरे से बात कर सकें [3]।\nअब एक तीसरा नाम भी floating around है: एक standalone vite-plugin-federation package जो 1.0 release के साथ खुद को \u0026ldquo;production era\u0026rdquo; option के रूप में position कर रहा है, manifest-first approach (mf-manifest.json, mf-stats.json, mf-debug.json) और built-in governance features जैसे circuit breakers और SRI verification के साथ [4]। यह जानना worth है कि यह exist करता है, लेकिन इस नई चीज के साथ \u0026ldquo;चलो देखते हैं यह wild में कैसे टिकता है\u0026rdquo; का healthy dose रखना उचित होगा।\nयहाँ बताता हूँ मैं इस choice को कैसे frame करूँगा:\n@originjs/vite-plugin-federation @module-federation/vite Runtime अपना, webpack-MF-inspired @module-federation/runtime (webpack/Rspack के साथ shared) परिपक्वता पुराना, widely used, GitHub issues already triaged नया, कम battle scars, actively developed Cross-bundler interop ज्यादातर Vite-to-Vite Rspack/webpack remotes के साथ interoperate करने के लिए designed [3] TypeScript type sharing Limited MF 2.0 features जैसे dynamic type hints के आसपास built [3] सबसे उपयुक्त Existing OriginJS-style setups, simple host/remote pairs नए projects, खासकर जो पहले से wider Module Federation ecosystem को touch कर रहे हों अगर आप आज fresh start कर रहे हैं और कोई भी chance है कि आप आगे bundlers mix करेंगे, तो @module-federation/vite की तरफ lean करें। अगर आप बस सबसे simple possible \u0026ldquo;host imports a button from a remote\u0026rdquo; setup चाहते हैं और बड़े ecosystem की परवाह नहीं है, तो @originjs/vite-plugin-federation अभी भी ठीक काम करता है और इसके बारे में अधिक Stack Overflow answers लिखे गए हैं।\nएक basic host + remote सेट करना (वो हिस्सा जो वास्तव में काम करता है) यह वो हिस्सा है जो genuinely बस काम करता है, और honestly पहली बार देखने पर यह कुछ magical लगता है। यहाँ एक minimal remote app है जो एक component expose करती है:\n// remote/vite.config.ts import { defineConfig } from \u0026#39;vite\u0026#39; import react from \u0026#39;@vitejs/plugin-react\u0026#39; import federation from \u0026#39;@originjs/vite-plugin-federation\u0026#39; export default defineConfig({ plugins: [ react(), federation({ name: \u0026#39;remote_app\u0026#39;, filename: \u0026#39;remoteEntry.js\u0026#39;, exposes: { \u0026#39;./Button\u0026#39;: \u0026#39;./src/components/Button.tsx\u0026#39;, }, shared: [\u0026#39;react\u0026#39;, \u0026#39;react-dom\u0026#39;], }), ], build: { target: \u0026#39;esnext\u0026#39;, minify: false, cssCodeSplit: false, }, }) और host जो इसे consume करता है:\n// host/vite.config.ts import { defineConfig } from \u0026#39;vite\u0026#39; import react from \u0026#39;@vitejs/plugin-react\u0026#39; import federation from \u0026#39;@originjs/vite-plugin-federation\u0026#39; export default defineConfig({ plugins: [ react(), federation({ name: \u0026#39;host_app\u0026#39;, remotes: { remote_app: \u0026#39;http://localhost:5001/assets/remoteEntry.js\u0026#39;, }, shared: [\u0026#39;react\u0026#39;, \u0026#39;react-dom\u0026#39;], }), ], build: { target: \u0026#39;esnext\u0026#39; }, }) फिर host में, आप इसे किसी भी lazy component की तरह consume करते हैं:\nconst RemoteButton = React.lazy(() =\u0026gt; import(\u0026#39;remote_app/Button\u0026#39;) ) आप पहले remote build करते हैं (vite build), dist folder को कहीं serve करते हैं, और फिर host run करते हैं। यही पूरा magic trick है — host network पर remoteEntry.js fetch करता है, पता लगाता है कि क्या exposed है, और code को on demand pull करता है। कोई iframe नहीं, कोई अलग React root अजीब तरीके से mount नहीं — यह बस\u0026hellip; वहाँ है, एक component के रूप में।\nVite में Module Federation के साथ आप क्या कर सकते हैं एक बार wired up हो जाने पर, webpack-era promise का आश्चर्यजनक रूप से बड़ा हिस्सा सच साबित होता है। यहाँ है जो व्यावहारिक रूप से काम करता है:\nSeparately built और deployed apps में runtime पर components, hooks, और utilities expose और consume करना — core use case, और यह काम करता है। React, Vue, या एक design-system package जैसी singleton dependencies share करना ताकि host और remotes अपनी-अपनी copy ship न करें [7]। singleton: true के साथ shared config एक shared instance पर resolve होता है। Remotes को तभी lazy-load करना जब जरूरत हो, जो admin panel या checkout flow जैसी चीजों के लिए बढ़िया है जिन्हें ज्यादातर users कभी touch नहीं करते। Frameworks mix करना — एक Vue host technically एक React remote load कर सकता है (या vice versa) इसे एक wrapper component में mount करके, क्योंकि federation बस एक module देता है, framework contract नहीं। Manifests generate करना (mf-manifest.json और similar) जो describe करते हैं कि प्रत्येक remote क्या expose करता है, जो CI pipelines के लिए genuinely useful है जो deploy करने से पहले compatibility verify करना चाहती हैं [4]। Remotes के लिए TypeScript type hints use करना, एक Module Federation 2.0 feature जो remote modules के लिए .d.ts files generate और download करता है ताकि आपका editor बस any पर guess न करे [3]। Runtime plugins — loading lifecycle में hooks (before request, after resolve, on error) जो आपको application code touch किए बिना logging, retries, या fallback URLs add करने देते हैं [3]। Independent deploys — एक बार दोनों apps federation contract पर agree कर लें, आप सच में host को redeploy किए बिना remote ship कर सकते हैं, जो इस exercise का पूरा point है। आखिरी वाला असली payoff है। अगर आपके org में multiple teams एक monorepo में एक-दूसरे के रास्ते में आ रही हैं, तो \u0026ldquo;checkout\u0026rdquo; मंगलवार को और \u0026ldquo;profile\u0026rdquo; गुरुवार को release coordinate किए बिना deploy करने में सक्षम होना एक real win है — जब यह काम करता है।\nयह कहाँ टूटता है: dev mode ही असली समस्या है यहाँ यह tricky हो जाता है, और honestly, यही वो चीज है जो पहली बार में लगभग हर किसी को trip करती है।\nकेवल host side को proper Vite dev server experience मिलती है। Remote को पहले build किया जाना होता है — host उन्हें import करने से पहले उसके remoteEntry.js और exposed chunks को static files के रूप में exist करना होता है [5]। \u0026ldquo;दोनों apps full HMR के साथ vite dev run कर रहे हैं एक-दूसरे से live बात कर रहे हैं\u0026rdquo; का कोई equivalent नहीं है।\nदिन-प्रतिदिन इसका क्या मतलब है:\nआप remote के exposed component में कुछ बदलते हैं। Vite का dev server (सिर्फ remote के लिए चल रहा है, अपनी सुविधा के लिए) host की कोई मदद नहीं करता। आपको remote पर फिर से vite build run करना होगा। Host को फिर new remoteEntry.js pick up करने के लिए hard refresh की जरूरत है। यह \u0026ldquo;fast feedback loop\u0026rdquo; नहीं है, यह है \u0026ldquo;हर बार shared code touch करने पर context switch\u0026rdquo;। कुछ teams इसके आसपास remote का vite build --watch एक terminal में run करके काम करती हैं और बस refresh के साथ जीती हैं — यह elegant नहीं है, लेकिन host team के लिए workable है। Remote team जो actively अपना UI develop कर रही है, वे typically बस अपना app standalone (federation के बिना) normal Vite dev का उपयोग करके run करती हैं, और केवल कभी-कभी federated integration test करती हैं।\nकुछ और चीजें जो काम नहीं करतीं, या केवल आधी काम करती हैं:\nbuild.rollupOptions.output.manualChunks effectively off-limits है। Federation plugin खुद chunk graph manage करता है, और custom chunk grouping उस bootstrap order को break कर सकती है जिस पर federation runtime निर्भर करता है [2]। Vite/Rollup remotes को webpack hosts के साथ mix करना (या vice versa) fragile है। कोई guarantee नहीं है कि Rollup और webpack CommonJS dependencies के लिए same chunk shape produce करेंगे, जो silently shared resolution को break कर सकता है [1]। baseUrl / custom base paths में real bugs रहे हैं। अगर आपका remote एक subpath से serve होता है (enterprise setups में reverse proxy के पीछे common), तो ऐसे issues रहे हैं जहाँ Vite 5+ के तहत federation plugin remoteEntry.js को correctly resolve नहीं करता [6]। Non-ESM output formats second-class हैं। Plugin docs frankly कहते हैं कि ESM well-tested path है; UMD/CJS-style remotes में \u0026ldquo;complete test cases की कमी है\u0026rdquo; [1]। CSS की वह गड़बड़ी जिसके बारे में कोई नहीं बताता यह मुझे पहली बार hard bit किया, और यह basically हर किसी को eventually bite करता है। Dev mode में, आपके remote की styles ठीक load होती हैं क्योंकि Vite उन्हें अपने dev server के माध्यम से inject करता है। Production में, Vite default रूप से CSS code-splitting करता है — प्रत्येक chunk को अपनी CSS file मिलती है, जो एक \u0026lt;link\u0026gt; tag के माध्यम से load होती है जो page को जाननी चाहिए।\nसमस्या? जब एक host dynamically एक remote का component import करता है, तो कुछ भी host के HTML को remote की CSS file load करने के लिए नहीं बताता। इसलिए आपको एक perfectly functional, completely unstyled component मिलता है। एक developer ने इसे बिल्कुल सही describe किया: production में यह \u0026ldquo;एक unstyled wireframe जैसा दिखा\u0026rdquo; जबकि locally बढ़िया काम कर रहा था [10]।\nलोग जो fixes पर land करते हैं:\nRemote पर build.cssCodeSplit: false set करें ताकि उसके सभी CSS एक single file में bundle हो जाएं जिसे आप reliably reference कर सकते हैं। CSS को directly JS bundle में inline करने के लिए vite-plugin-css-injected-by-js जैसा plugin use करें — ugly है, लेकिन यह guarantee करता है कि styles component के साथ travel करें [10]। कुछ teams और आगे जाती हैं और CSS Modules या :host/Shadow DOM-style scoping use करती हैं यह सुनिश्चित करने के लिए कि remote की styles accidentally host की global styles में leak नहीं हो सकती (या clobbered नहीं हो सकती) — एक अलग लेकिन related headache, क्योंकि Vite के अपने CSS Modules composes handling में खुद duplication quirks रहे हैं। इनमें से कोई भी exotic नहीं है, लेकिन यह exactly वो तरह की चीज है जो आपकी machine पर perfectly काम करती है और deployed build खुलते ही QA पर fail हो जाती है।\nShared dependencies और singleton का जाल Module Federation अपनी असली value shared config में earn करता है — या वहाँ quietly आपका दिन बर्बाद करता है। Idea simple है: हर remote अपनी React की copy ship करने की बजाय, आप इसे shared mark करते हैं, और ideally singleton: true, ताकि पूरे federated app के लिए exactly एक React instance हो [7]।\nव्यावहारिक रूप में, version mismatches federated setups में single most common production bug हैं [8]। अगर host React 18.2 expect करता है और एक remote React 18.3 के खिलाफ build हुआ था, तो आप वैसे भी दो React instances के साथ end up कर सकते हैं — और React के hooks rules इसे absolutely forgive नहीं करते। Classic symptom है \u0026ldquo;Invalid hook call\u0026rdquo; errors जो तब तक कोई sense नहीं बनाते जब तक आपको एहसास नहीं होता कि memory में दो Reacts हैं।\nयहाँ जानने लायक कुछ चीजें:\nsingleton: true runtime को बताता है कि एक version pick करे और सभी को उसे use करने के लिए force करे — भले ही यह technically सभी के requiredVersion के साथ compatible न हो [7]। यह एक \u0026ldquo;best effort, don\u0026rsquo;t crash\u0026rdquo; setting है, correctness की guarantee नहीं। strictVersion: true उसे flip करता है — version silently pick करने की बजाय, यह incompatibility होने पर throw करता है। Production में discover करने से बेहतर है CI में problems catch करने के लिए। Version strings के बारे में real bugs रहे हैं जिनमें build metadata या pre-release suffixes हैं (जैसे 18.2.0-release.99) जो semver ranges के खिलाफ correctly resolve नहीं होते, जो silently पूरे shared-singleton mechanism को defeat कर सकते हैं [9]। Multiple remotes एक shared lib के slightly different versions pull कर रहे हैं इसके opposite problem भी cause कर चुके हैं — dependencies multiple times fetch और bundle हो रहे हैं बजाय deduplicated होने के, खासकर more complex routing setups में react-router-dom के साथ [15]। मेरा honest take: shared config जरूरी है लेकिन पर्याप्त नहीं। आपको अभी भी teams में real dependency-version discipline चाहिए — ideally एक shared package.json या कम से कम एक documented \u0026ldquo;ये pinned versions हैं जिन्हें हर कोई target करता है\u0026rdquo; doc। Module Federation duplication reduce करता है; यह alignment enforce नहीं करता।\nक्या यह झंझट करने लायक है? जानने योग्य विकल्प यह वो question है जो मैं एक भी line of federation config लिखने से पहले पूछूँगा: क्या आपको वास्तव में इसकी जरूरत है, या आपको independent deploys चाहिए और एक simpler tool काम करेगा?\nकुछ alternatives जो 2026 की conversations में बहुत आते हैं:\nImport Maps. एक real web standard (Chrome में 2021 से) जो browser को खुद एक JSON map के माध्यम से versioned URLs पर module specifiers resolve करने देता है — कोई bundler-specific runtime required नहीं [11]। अगर आपके \u0026ldquo;micro frontends\u0026rdquo; वास्तव में बस कुछ independently versioned ES modules हैं, तो import maps बहुत कम tooling के साथ आपको ज्यादातर रास्ते तक पहुँचा सकते हैं। Native Federation. Angular Architects team द्वारा specifically Vite/esbuild-style toolchains के लिए बनाया गया, यह Module Federation concept को implement करता है import maps और native ESM का उपयोग करके बजाय custom runtime के [12]। Framework-agnostic, और notably webpack-derived approach से lighter weight। Rspack के माध्यम से Module Federation 2.0। अगर आपकी team bundlers switch करने के लिए open है (सिर्फ plugin add करने के लिए नहीं), तो Rspack का native Module Federation support Vite ecosystem में किसी भी चीज से ज्यादा mature है, और यह वही MF 2.0 protocol बोलता है जो @module-federation/vite use करता है — यानी specific remotes के लिए gradual Vite-to-Rspack migration realistic है [13][3]। Runtime federation के बिना shared packages के साथ एक monorepo। कभी-कभी actual requirement है \u0026ldquo;इस Button component को duplicate करना बंद करो,\u0026rdquo; और एक published internal npm package बिना किसी runtime complexity के उसे solve करता है। Boring, लेकिन boring एक feature है। अगर आपका main goal \u0026ldquo;independently deployable\u0026rdquo; है बजाय \u0026ldquo;must work exactly like our old webpack setup\u0026rdquo; के, तो मैं genuinely पहले import maps या Native Federation consider करूँगा। Vite federation plugins उससे कठिन problem solve कर रहे हैं जितनी उन्हें करनी चाहिए बहुत सारे cases में, purely क्योंकि teams webpack के साथ API parity चाहती हैं।\nइसे अपनाने से पहले मेरी ईमानदार checklist अगर आप यह शुरू करने वाले हैं, तो पहली federation() config लिखने से पहले यह stuff nail down करें:\nप्रश्न यह क्यों मायने रखता है क्या remotes को host के release cycle से independently deploy होना है? अगर नहीं, तो शायद आपको federation की जरूरत नहीं — एक monorepo package simpler हो सकता है क्या आपकी team development के दौरान \u0026ldquo;rebuild remote, refresh host\u0026rdquo; tolerate कर सकती है? यही दोनों major plugins के साथ dev-mode reality है अभी [5] क्या आप target: 'esnext' पर हैं और manualChunks से बच रहे हैं? दोनों plugins इसकी require/expect करते हैं; इसके खिलाफ लड़ने से obscure build failures होती हैं [2] क्या teams में shared dependency versions के लिए आपका कोई plan है? singleton: true help करता है लेकिन version discipline की जगह नहीं लेता [8][9] क्या remotes को non-root base के साथ subpath/CDN से serve किया जाएगा? remoteEntry.js resolution bugs का known source [6] क्या आपने production builds test किए हैं, सिर्फ dev नहीं, CSS के लिए? Styles जो dev में काम करती हैं वो prod में silently गायब हो जाती हैं बहुत लोगों के लिए [10] क्या Native Federation या import maps आपकी actual requirement cover कर सकते हैं? कभी-कभी simpler standard 20% complexity के साथ 80% काम करता है [11][12] चीजें जहाँ खड़ी हैं उनका honest summary: Module Federation Vite के साथ काम करता है, और core \u0026ldquo;runtime पर एक remote component load करो, एक singleton dependency share करो\u0026rdquo; use case के लिए, यह अच्छी तरह काम करता है। Rough edges तब दिखते हैं जब आप production की तरफ push करते हैं — CSS, dev-mode parity, version drift, और non-root deployments। इनमें से कोई भी dealbreaker नहीं है, लेकिन इनमें से हर एक एक debugging session खाएगा अगर आपको पहले से पता नहीं है कि वे आ रहे हैं। Module Federation 2.0 का bundler-agnostic runtime की तरफ push [3] सबसे promising sign है कि Vite story में सुधार होता रहेगा — लेकिन \u0026ldquo;improving\u0026rdquo; और \u0026ldquo;solved\u0026rdquo; अभी भी दो अलग-अलग words हैं।\nस्रोत originjs/vite-plugin-federation on GitHub @module-federation/vite on npm Module Federation 2.0 Reaches Stable Release with Wider Support outside of Webpack - InfoQ vite-plugin-federation 1.0: Bringing Module Federation Into the Production Era for Vite - DEV Community Support dev server remote entry file · Issue #525 · originjs/vite-plugin-federation Module Federation + base url · Issue #580 · originjs/vite-plugin-federation Shared configuration - Module Federation docs Getting Out of Version-Mismatch-Hell with Module Federation - ANGULARarchitects Module Federation Fails to Share Singleton Dependencies with Version Postfixes · Issue #4078 · module-federation/core How I Finally Got My Vite + Module Federation Styles to Load in Production You Might Not Need Module Federation: Orchestrate your Microfrontends at Runtime with Import Maps - Mercedes-Benz.io Announcing Native Federation 1.0 - ANGULARarchitects Module Federation 2.0: webpack vs Rspack vs Vite 2026 - PkgPulse Guides module-federation/vite on GitHub Bug Report: Multiple Instances of React and React-Router-DOM in Host and Remote · Issue #650 · originjs/vite-plugin-federation ","permalink":"https://cloudmato.com/hi/posts/module-federation-vite-guide/","title":"Vite के साथ Module Federation: क्या काम करता है, क्या नहीं"},{"content":"हर कुछ हफ्तों में कोई न कोई AI लैब एक नया मॉडल लॉन्च करती है और तुरंत दावा करती है कि यह धरती पर सबसे स्मार्ट चीज़ है। फिर एक हफ्ते बाद कोई दूसरी लैब वही करती है। अगर आपने कभी यह समझने की कोशिश की है कि वास्तव में कौन बेहतर है, तो आप शायद MMLU, GPQA, और SWE-bench जैसे नामों वाले चार्ट्स की एक दीवार को घूरते रहे होंगे और आपका दिमाग चकरा गया होगा। मैंने हाल ही में इस रैबिट होल में गोता लगाया, और यहां इसका छोटा वर्शन है: कोई एक स्कोरबोर्ड नहीं है। लोग \u0026ldquo;बेहतर\u0026rdquo; को मापने के कम से कम चार पूरी तरह से अलग तरीकों का इस्तेमाल करते हैं, और एक बार जब आपको पता चल जाए कि हर एक वास्तव में क्या करता है, तो पूरा AI लीडरबोर्ड सर्कस बहुत ज्यादा समझ में आने लगता है।\n\u0026ldquo;कौन सा LLM सबसे बेहतर है?\u0026rdquo; का कोई एक जवाब क्यों नहीं है यहां वह बात है जो कोई आपको शुरुआत में नहीं बताता: \u0026ldquo;सबसे बेहतर\u0026rdquo; पूरी तरह इस पर निर्भर करता है कि आप इसे किसके लिए इस्तेमाल कर रहे हैं।\nजो मॉडल कविता लिखने में शानदार है, वह Python के बग ठीक करने में औसत हो सकता है। जो मॉडल मैथ कॉम्पिटिशन में कमाल करता है, वह आपको एक भद्दा, ओवर-फॉर्मेटेड ईमेल दे सकता है। और जो मॉडल हर चार्ट में टॉप करता है, वह प्रति रिक्वेस्ट 10 गुना ज्यादा खर्च कर सकता है और उस मॉडल से काफी धीमा जवाब दे सकता है जो \u0026ldquo;सिर्फ\u0026rdquo; कुछ पॉइंट्स पीछे है।\nतो जब लोग पूछते हैं \u0026ldquo;क्या GPT, Claude से बेहतर है\u0026rdquo; या \u0026ldquo;क्या Gemini, Llama से बेहतर है,\u0026rdquo; तो ईमानदार जवाब यह है: किस चीज़ में बेहतर, कैसे मापा गया, और किस बजट पर तुलना की गई? यह कोई बहाना नहीं है — यही असल में पूरी वजह है कि AI बेंचमार्किंग इंडस्ट्री मौजूद है। मोटे तौर पर, लोग मॉडल की क्वालिटी मापने के तरीकों को चार श्रेणियों में बांटते हैं:\nस्टैंडर्डाइज्ड टेस्ट — मॉडल को सवालों का एक तय सेट दिया जाता है जिनके सही जवाब पहले से पता हैं, जैसे स्कूल का एग्ज़ाम। ह्यूमन प्रेफरेंस एरीना — असली लोगों को दो अनाम (anonymous) जवाब दिखाए जाते हैं और उन्हें वोट करने दिया जाता है कि कौन सा बेहतर है। LLM-as-a-judge — एक AI मॉडल का इस्तेमाल दूसरे मॉडल के ओपन-एंडेड जवाबों को ग्रेड करने के लिए किया जाता है। रियल-वर्ल्ड टास्क बेंचमार्क — मॉडल को किसी असली काम के करीब की स्थिति में डाल दिया जाता है (इस बग को ठीक करो, इस मल्टी-स्टेप टास्क को पूरा करो) और देखा जाता है कि वह वहां तक पहुंच पाता है या नहीं। आइए हर एक को बारी-बारी से देखते हैं, क्योंकि इन सबका \u0026ldquo;स्मार्ट\u0026rdquo; होने का मतलब बिल्कुल अलग-अलग है।\nतरीका 1: स्टैंडर्डाइज्ड टेस्ट अप्रोच यह सबसे पुराना और सबसे जाना-पहचाना तरीका है — मॉडल को सवालों का एक बड़ा ढेर दो, जवाबों को आंसर-की से चेक करो, और एक प्रतिशत (percentage) रिपोर्ट करो। यह बेसिकली AI के लिए SAT है।\nनॉलेज और रीजनिंग टेस्ट इसमें सबसे पुराना और सबसे बड़ा नाम है MMLU (Massive Multitask Language Understanding), जो लॉ से एनाटॉमी से एब्स्ट्रैक्ट एल्जेब्रा तक 57 विषयों में फैले मल्टीपल-चॉइस सवालों का एक सेट है। सालों तक यही वह नंबर था जिसे हर कोई कोट करता था। दिक्कत? फ्रंटियर मॉडल अब इस पर 90%+ स्कोर करते हैं, यानी यह बेसिकली सैचुरेट हो गया है और अब अच्छे मॉडलों को बेहतरीन मॉडलों से अलग नहीं बता सकता [2]।\nइसलिए लैब्स ज्यादा मुश्किल वर्जन की तरफ बढ़ गईं:\nMMLU-Pro — वही आइडिया, लेकिन 4 के बजाय 10 आंसर ऑप्शन के साथ (अच्छा स्कोर अंदाज़े से पाना बहुत मुश्किल) और सवाल इस तरह डिज़ाइन किए गए हैं कि उनके लिए असली रीजनिंग चाहिए, सिर्फ याद रखने (recall) से काम नहीं चलेगा। GPQA Diamond — बायोलॉजी, केमिस्ट्री और फिज़िक्स में PhD-लेवल के सवाल, इतनी सावधानी से लिखे गए हैं कि गैर-एक्सपर्ट PhD होल्डर्स भी इन पर सिर्फ लगभग 34% स्कोर करते हैं। यह कम ह्यूमन बेसलाइन ही इसे एक उपयोगी मापदंड बनाती है — अगर कोई मॉडल 80%+ पार कर ले, तो वह वाकई कुछ मुश्किल कर रहा है [2]। Humanity\u0026rsquo;s Last Exam (HLE) — डोमेन एक्सपर्ट्स द्वारा लिखे गए 2,500 सवाल, जो \u0026ldquo;मानव ज्ञान की सीमा पर\u0026rdquo; हैं, और STEM से लेकर ह्यूमैनिटीज़ तक सब कुछ कवर करते हैं। इंसान एक्सपर्ट्स इस पर औसतन लगभग 90% स्कोर करते हैं, जबकि बिना एक्सटर्नल टूल्स वाले फ्रंटियर मॉडल लगभग 37-47% पर ही टिकते हैं [7]। यह खास तौर पर इसलिए बनाया गया क्योंकि बाकी सब कुछ बहुत आसान हो गया था। कोडिंग और मैथ टेस्ट कोड के लिए, HumanEval पहले सबसे पॉपुलर था — 164 छोटी Python प्रॉब्लम्स, जिनमें से हर एक को यूनिट टेस्ट के खिलाफ चेक किया जाता है। यह अब टॉप मॉडलों के लिए 93% से ऊपर है, जिसका मतलब फिर से यही है कि यह बेसिकली सैचुरेट हो गया है [2]। असली एक्शन अब SWE-bench Verified की तरफ शिफ्ट हो गया है, जो मॉडलों को पॉपुलर ओपन-सोर्स रिपॉज़िटरी से असली GitHub इश्यूज़ के सामने खड़ा करता है और चेक करता है कि उनका पैच वाकई टेस्ट सूट को पास कराता है या नहीं। टॉप मॉडल अब \u0026ldquo;Verified\u0026rdquo; सेट पर 80-89% रेंज में पहुंच रहे हैं, जबकि उससे कहीं ज्यादा मुश्किल \u0026ldquo;Pro\u0026rdquo; वैरिएंट — मल्टी-फाइल, मल्टी-लैंग्वेज, असली आर्किटेक्चरल कॉम्प्लेक्सिटी — स्कोर को 55-65% रेंज में ही रोक देता है [6]।\nमैथ के मामले में, AIME (American Invitational Mathematics Examination) के सवाल \u0026ldquo;रीजनिंग\u0026rdquo; मॉडलों के लिए स्टैंडर्ड टॉर्चर टेस्ट बन गए हैं। यहां फर्क बहुत बड़ा है: जनरल-पर्पस मॉडल अक्सर 7-35% रेंज में स्कोर करते हैं, जबकि डेडिकेटेड रीजनिंग मॉडल वही सवालों पर 90-100% तक पहुंच जाते हैं [16]। यह एक बेंचमार्क शायद सबसे साफ सबूत है कि \u0026ldquo;रीजनिंग मोड\u0026rdquo; (वह मॉडल जो जवाब देने से पहले स्टेप-बाय-स्टेप सोचता है) सच में एक अलग क्षमता है, सिर्फ मार्केटिंग नहीं।\nयहां एक क्विक चीट शीट है कि ये टेस्ट वास्तव में क्या मापते हैं:\nबेंचमार्क यह क्या टेस्ट करता है कैसे ग्रेड होता है 2026 में स्टेटस MMLU सामान्य ज्ञान, 57 विषय मल्टीपल-चॉइस, ऑटो-स्कोर्ड सैचुरेटेड (90%+) [2] MMLU-Pro ज्यादा मुश्किल नॉलेज + रीजनिंग 10-ऑप्शन मल्टीपल-चॉइस एक्टिव, फर्क करने वाला GPQA Diamond PhD-लेवल साइंस रीजनिंग एक्सपर्ट-लिखित मल्टीपल-चॉइस एक्टिव, ह्यूमन बेसलाइन ~34% [2] HumanEval बेसिक Python कोड जेनरेशन यूनिट टेस्ट, pass@1 सैचुरेटेड (93%+) [2] SWE-bench Verified असली GitHub बग फिक्स, एंड-टू-एंड ऑटोमेटेड टेस्ट सूट पास/फेल एक्टिव, ~80-89% टॉप मॉडल [6] AIME कॉम्पिटिशन-लेवल मैथ सटीक न्यूमेरिक जवाब नॉन-रीजनिंग मॉडलों के लिए एक्टिव [16] Humanity\u0026rsquo;s Last Exam सभी क्षेत्रों के एक्सपर्ट सवाल सटीक/शॉर्ट आंसर मैच एक्टिव, बिना टूल्स के ~37-47% [7] ARC-AGI-2 नए विज़ुअल पैटर्न पज़ल सटीक ग्रिड मैच ज्यादातर अनसुलझा जो पैटर्न आपको दिखेगा: जैसे ही कोई बेंचमार्क \u0026ldquo;सॉल्व\u0026rdquo; हो जाता है (सब 90%+ स्कोर करने लगते हैं), वह बेकार हो जाता है, और फील्ड एक नया, ज्यादा मुश्किल बेंचमार्क बना लेती है। पिछले दो सालों में कम से कम चार बड़े बेंचमार्क के साथ ऐसा हो चुका है। यह बेसिकली टेस्ट बनाने वालों और मॉडल बनाने वालों के बीच एक आर्म्स रेस है।\nतरीका 2: टेस्ट छोड़ो, सीधे इंसानों से पूछो स्टैंडर्डाइज्ड टेस्ट यह मापने में बहुत अच्छे हैं कि \u0026ldquo;क्या मॉडल ने टेक्स्टबुक वाला सही जवाब दिया,\u0026rdquo; लेकिन यह मापने में बेकार हैं कि \u0026ldquo;क्या मॉडल ने मदद करने वाला, अच्छी तरह लिखा गया, पढ़ने में सुखद जवाब दिया।\u0026rdquo; इसके लिए, AI वर्ल्ड ने कुछ ऐसा बनाया जो एग्ज़ाम से कहीं ज्यादा डेटिंग ऐप जैसा दिखता है।\nसबसे मशहूर उदाहरण है LMArena (पहले Chatbot Arena के नाम से जाना जाता था, जिसे LMSYS ग्रुप चलाता है, और 2026 की शुरुआत में फिर से सिर्फ \u0026ldquo;Arena\u0026rdquo; के नाम से रीब्रांड किया गया) [1]। यह इस तरह काम करता है:\nआप एक प्रॉम्प्ट टाइप करते हैं — जो भी आप चाहें। रैंडमली चुने गए दो अलग-अलग मॉडल, दोनों आपके प्रॉम्प्ट का जवाब देते हैं। उनके नाम छिपे रहते हैं। आपको सिर्फ \u0026ldquo;Model A\u0026rdquo; और \u0026ldquo;Model B\u0026rdquo; साथ-साथ दिखते हैं। आप उसके लिए वोट करते हैं जिसने आपको बेहतर जवाब दिया लगता है। इसे लाखों वोटों से मल्टीप्लाई करें — इस प्लेटफॉर्म पर अब तक 60 लाख से ज्यादा वोट जमा हो चुके हैं — और आपको हर मॉडल के लिए एक Elo-स्टाइल रेटिंग मिलती है, वही स्टैटिस्टिकल सिस्टम जो शतरंज खिलाड़ियों को रैंक करने के लिए इस्तेमाल होता है [1]। किसी मॉडल की रेटिंग तब बढ़ती है जब वह ज्यादा रेटिंग वाले विरोधी को हराता है, और तब घटती है जब वह कम रेटिंग वाले से हार जाता है, इसलिए यह गणित खुद-ब-खुद \u0026ldquo;शेड्यूल की मजबूती\u0026rdquo; का हिसाब रख लेता है।\n","permalink":"https://cloudmato.com/hi/posts/how-to-test-and-benchmark-llm-models/","title":"LLM का टेस्ट कैसे करें: बेंचमार्क, एरीना, और असली एवल्स"},{"content":" उपयोग की शर्तें cloudmato.com का उपयोग करके, आप निम्नलिखित शर्तों से सहमत होते हैं। यदि आप सहमत नहीं हैं, तो कृपया इस साइट का उपयोग न करें।\nकंटेंट के बारे में cloudmato.com सॉफ्टवेयर डेवलपमेंट, वेब तकनीक, और संबंधित विषयों पर लेख प्रकाशित करता है। लेख सार्वजनिक रूप से उपलब्ध स्रोतों से शोध करके लिखे जाते हैं, और जहाँ ज़रूरी हो वहाँ स्रोतों के लिंक इनलाइन दिए जाते हैं।\nकंटेंट केवल सूचना के उद्देश्य से प्रदान किया जाता है और यह पेशेवर, कानूनी, वित्तीय, या सुरक्षा संबंधी सलाह नहीं है। महत्वपूर्ण जानकारी (विशेष रूप से सुरक्षा, अनुपालन, या प्रोडक्शन सिस्टम से जुड़ी) पर कार्य करने से पहले हमेशा आधिकारिक दस्तावेज़ों से सत्यापित करें।\nसटीकता हम सटीकता का प्रयास करते हैं और स्रोतों का हवाला देते हैं, लेकिन तकनीक तेज़ी से बदलती है और लेख पुराने हो सकते हैं। यदि आपको कोई त्रुटि मिलती है, तो कृपया हमें बताएं और हम उसे ठीक करेंगे।\nकंटेंट का उपयोग आप इस साइट के लेखों को लिंक करने के लिए स्वतंत्र हैं। अनुमति के बिना पूरे लेख को कहीं और पुनः प्रकाशित करने की अनुमति नहीं है। एट्रिब्यूशन और लिंक के साथ छोटे अंश ठीक हैं। लेखों में दिए गए कोड स्निपेट उदाहरण के रूप में प्रदान किए जाते हैं और आप इन्हें अपने प्रोजेक्ट्स में स्वतंत्र रूप से उपयोग कर सकते हैं। थर्ड-पार्टी लिंक और विज्ञापन यह साइट Google AdSense सहित थर्ड पार्टियों द्वारा परोसे गए विज्ञापन दिखा सकती है, और बाहरी वेबसाइटों से लिंक कर सकती है। हम थर्ड-पार्टी साइट्स या विज्ञापनदाताओं के कंटेंट, सटीकता, या प्रैक्टिसेज़ को नियंत्रित नहीं करते और उनके लिए ज़िम्मेदार नहीं हैं। विज्ञापन और कुकीज़ के बारे में विवरण के लिए हमारी प्राइवेसी पॉलिसी देखें।\nकोई वारंटी नहीं यह साइट और इसका कंटेंट \u0026ldquo;जैसा है\u0026rdquo; के आधार पर, किसी भी प्रकार की स्पष्ट या अंतर्निहित वारंटी के बिना प्रदान किया जाता है। हम यह गारंटी नहीं देते कि साइट त्रुटि-मुक्त, सुरक्षित, या निरंतर उपलब्ध रहेगी।\nदायित्व की सीमा कानून द्वारा अनुमत अधिकतम सीमा तक, cloudmato.com और इसके लेखक इस साइट या इसके कंटेंट के उपयोग, या उपयोग करने में असमर्थता से उत्पन्न होने वाले किसी भी नुकसान के लिए उत्तरदायी नहीं हैं।\nइन शर्तों में बदलाव हम समय-समय पर इन शर्तों को अपडेट कर सकते हैं। बदलावों के बाद साइट का उपयोग जारी रखने का मतलब है कि आप अपडेटेड शर्तों को स्वीकार करते हैं।\nसंपर्क इन शर्तों से जुड़े सवाल? cloudmato@gmail.com पर ईमेल करें।\nअंतिम अपडेट: जून 2026।\n","permalink":"https://cloudmato.com/hi/pages/terms/","title":"उपयोग की शर्तें"},{"content":" प्राइवेसी पॉलिसी यह पॉलिसी बताती है कि cloudmato.com कौन-सा डेटा इकट्ठा करता है, उसका उपयोग कैसे होता है, और आपके पास कौन-से विकल्प हैं। यह साइट के सभी भाषा संस्करणों पर लागू होती है।\nयह साइट कौन चलाता है cloudmato.com एक स्वतंत्र ब्लॉग है। इस पॉलिसी से जुड़े सवालों के लिए cloudmato@gmail.com पर संपर्क करें।\nकुकीज़ और समान तकनीकें यह साइट, और इसके द्वारा उपयोग की जाने वाली थर्ड-पार्टी सेवाएं, आपके ब्राउज़र में कुकीज़ या समान तकनीकों (जैसे लोकल स्टोरेज) का उपयोग कर सकती हैं ताकि:\nआपकी पसंद याद रखी जा सके (जैसे लाइट/डार्क थीम) साइट के उपयोग को मापा जा सके (एनालिटिक्स) विज्ञापन दिखाए और मापे जा सकें Google AdSense और विज्ञापन cloudmato.com विज्ञापन दिखाने के लिए Google AdSense का उपयोग करता है या कर सकता है। Google और इसके पार्टनर्स इस साइट या इंटरनेट की अन्य साइट्स पर आपकी पिछली विज़िट के आधार पर विज्ञापन दिखाने के लिए कुकीज़ और समान तकनीकों का उपयोग कर सकते हैं।\nGoogle की विज्ञापन कुकीज़ Google और उसके पार्टनर्स को आपकी इस साइट और/या इंटरनेट की अन्य साइट्स पर विज़िट के आधार पर विज्ञापन दिखाने में सक्षम बनाती हैं। आप Google के Ads Settings पर जाकर पर्सनलाइज़्ड विज्ञापन से ऑप्ट-आउट कर सकते हैं। आप www.aboutads.info पर जाकर थर्ड-पार्टी वेंडर की पर्सनलाइज़्ड विज्ञापन कुकीज़ से भी ऑप्ट-आउट कर सकते हैं। Google अपनी सेवाओं का उपयोग करने वाली साइट्स/ऐप्स से जानकारी का उपयोग कैसे करता है, इसके बारे में अधिक जानकारी के लिए देखें: How Google uses information from sites or apps that use our services। एनालिटिक्स यह साइट विज़िटर्स के उपयोग को समझने के लिए वेब एनालिटिक्स टूल्स (जैसे Google Analytics या समान सेवाएं) का उपयोग कर सकती है — उदाहरण के लिए, कौन-से पेज लोकप्रिय हैं और विज़िटर कहाँ से आए। ये टूल्स कुकीज़ का उपयोग कर सकते हैं और आपका IP एड्रेस, ब्राउज़र टाइप, डिवाइस टाइप, और देखे गए पेज जैसी जानकारी इकट्ठा कर सकते हैं। यह डेटा एग्रीगेटेड होता है और आपकी व्यक्तिगत पहचान के लिए उपयोग नहीं किया जाता।\nहम क्या नहीं करते हम व्यक्तिगत डेटा नहीं बेचते। इस साइट को पढ़ने के लिए अकाउंट, लॉगिन, या व्यक्तिगत जानकारी की आवश्यकता नहीं है। हमें भेजे गए कमेंट या ईमेल का उपयोग केवल आपको जवाब देने के लिए किया जाता है और कानूनी आवश्यकता के अलावा थर्ड पार्टीज़ के साथ साझा नहीं किया जाता। थर्ड-पार्टी लिंक इस साइट के लेख उद्धरण और अधिक जानकारी के लिए बाहरी स्रोतों से लिंक करते हैं। हम बाहरी साइट्स की प्राइवेसी प्रैक्टिसेज़ या कंटेंट के लिए ज़िम्मेदार नहीं हैं। हम सलाह देते हैं कि आप किसी भी साइट पर जाने से पहले उसकी प्राइवेसी पॉलिसी देखें।\nबच्चों की प्राइवेसी यह साइट 13 वर्ष से कम उम्र के बच्चों के लिए नहीं है, और हम जानबूझकर बच्चों से व्यक्तिगत जानकारी इकट्ठा नहीं करते।\nइस पॉलिसी में बदलाव हम समय-समय पर इस पॉलिसी को अपडेट कर सकते हैं। नीचे दी गई तारीख सबसे हाल के संशोधन को दर्शाती है।\nसंपर्क इस पॉलिसी से जुड़े सवाल? cloudmato@gmail.com पर ईमेल करें।\nअंतिम अपडेट: जून 2026।\n","permalink":"https://cloudmato.com/hi/pages/privacy/","title":"प्राइवेसी पॉलिसी"},{"content":" संपर्क करें cloudmato.com एक छोटी टीम द्वारा चलाया जाता है जो इस साइट पर हर लेख पर शोध करती है और लिखती है। हम आपसे सुनना चाहेंगे।\nसंपर्क में रहें ईमेल: cloudmato@gmail.com\nयदि आप यह करना चाहते हैं तो संपर्क करें:\nभविष्य के लेख के लिए कोई विषय सुझाएं किसी त्रुटि, पुरानी जानकारी, या टूटे हुए लिंक की रिपोर्ट करें साइट पर कवर किए गए किसी विषय के बारे में सवाल पूछें हम हर ईमेल पढ़ते हैं और कुछ दिनों के भीतर जवाब देने की कोशिश करते हैं।\nकोई त्रुटि मिली? यदि किसी लेख में कुछ गलत या पुराना है, तो कृपया लेख का URL और समस्या का संक्षिप्त विवरण शामिल करें — हम इसकी समीक्षा करेंगे और सुधार करेंगे।\n","permalink":"https://cloudmato.com/hi/pages/contact/","title":"संपर्क करें"},{"content":"पिछले हफ़्ते किसी ने मुझसे ठीक यही सवाल पूछा, और यह एक अच्छा सवाल है क्योंकि अगर आप ध्यान से देखें तो दोनों सेटअप एक जैसे लगते हैं। कई सारी मशीनें, बीच में कुछ साझा स्टोरेज, और नोड्स में बँटा हुआ काम। तो फिर एक को \u0026ldquo;बिग डेटा\u0026rdquo; और दूसरे को \u0026ldquo;माइक्रोसर्विसेज़\u0026rdquo; क्यों कहा जाता है? क्या ये एक ही क्लस्टर के लिए बस दो अलग शब्द हैं? सच कहूँ तो, नहीं। ये दोनों एक ही चीज़ को लेकर विपरीत मान्यताओं पर बने हैं: डेटा कहाँ रहता है और कौन किसके पास जाता है।\nपहले मैं समझाता हूँ कि Hadoop असल में है क्या, फिर हम दोनों को साथ-साथ रखकर देखेंगे।\nHadoop असल में क्या है? Apache Hadoop एक ऐसा फ़्रेमवर्क है जो इतने बड़े डेटासेट को स्टोर और प्रोसेस करने के लिए बनाया गया है जो एक मशीन पर नहीं समा सकते — हम टेराबाइट से लेकर पेटाबाइट तक की बात कर रहे हैं। इसे Apache Software Foundation ने बनाया और यह सस्ती कमोडिटी मशीनों के क्लस्टर पर एक क्लासिक मास्टर-स्लेव डिज़ाइन का पालन करता है [1]। पूरी बात यह है: एक बड़ा महँगा सर्वर खरीदने के बजाय, आप 50 साधारण सर्वर खरीदते हैं और उन्हें मिलकर काम करवाते हैं।\nइसमें तीन परतें हैं, और इसे समझने के लिए आपको वाकई तीनों की ज़रूरत है:\nHDFS (Hadoop Distributed File System) — स्टोरेज परत। यह आपकी बड़ी फ़ाइलों को लेती है, उन्हें ब्लॉक-आकार के टुकड़ों में काटती है, और उन ब्लॉक्स को क्लस्टर की सभी मशीनों की डिस्क पर बिखेर देती है [1]। YARN (Yet Another Resource Negotiator) — रिसोर्स मैनेजर। यह तय करता है कि कौन-सी मशीन कौन-सा काम चलाएगी, और रिसोर्स मैनेजमेंट तथा जॉब शेड्यूलिंग को अलग-अलग डेमॉन में बाँट देता है [1]। MapReduce — मूल प्रोसेसिंग मॉडल। आप एक \u0026ldquo;map\u0026rdquo; स्टेप और एक \u0026ldquo;reduce\u0026rdquo; स्टेप लिखते हैं, और फ़्रेमवर्क उन्हें पूरे क्लस्टर में समानांतर रूप से चलाता है [1]। HDFS आपके डेटा को कैसे फैलाता है जब आप 1 TB की फ़ाइल HDFS में डालते हैं, तो वह एक डिस्क पर नहीं बैठती। HDFS उसे ब्लॉक्स में तोड़ता है (डिफ़ॉल्ट रूप से 128 MB प्रत्येक) और उन ब्लॉक्स को स्लेव नोड्स में स्टोर करता है। NameNode नामक एक मास्टर डेमॉन मेटाडेटा रखता है — फ़ाइल नाम, कौन-से ब्लॉक किस फ़ाइल के हैं, और सबसे अहम, कौन-सी मशीन किस ब्लॉक को रखती है। असली ब्लॉक्स DataNodes पर रहते हैं, जो हर मशीन पर चलने वाले स्लेव डेमॉन हैं [1]।\nहर ब्लॉक की कई कॉपी भी बनती हैं (आमतौर पर अलग-अलग मशीनों पर 3 कॉपी), ताकि अगर कोई डिस्क खराब हो जाए — और सस्ते हार्डवेयर के साथ, डिस्क लगातार खराब होती रहती हैं — तो आपका डेटा बचा रहे। यही वह बात है जिसे लोग नज़रअंदाज़ कर देते हैं: Hadoop यह मानकर चलता है कि विफलता सामान्य है, अपवाद नहीं।\nMapReduce इसे कैसे प्रोसेस करता है यहाँ चालाकी वाली बात है। एक सामान्य Hadoop सेटअप में, कंप्यूट नोड्स और स्टोरेज नोड्स एक ही मशीनें होती हैं। MapReduce फ़्रेमवर्क और HDFS नोड्स के एक ही सेट पर चलते हैं। इससे फ़्रेमवर्क हर टास्क को उसी नोड पर शेड्यूल कर सकता है जहाँ डेटा पहले से भौतिक रूप से मौजूद है, जिससे आपको पूरे क्लस्टर में बहुत ऊँची कुल बैंडविड्थ मिलती है [2]।\nवह आख़िरी वाक्य ही पूरा खेल है। चलिए इसे ज़ोर देकर कहता हूँ।\nवह एक विचार जो Hadoop को परिभाषित करता है: कोड को ले जाओ, डेटा को नहीं पहले दिन से Hadoop में एक डिज़ाइन लक्ष्य गहराई से बसा है: कंप्यूटेशन को डेटा के पास ले जाओ, बजाय इसके कि डेटा को कंप्यूटेशन के पास ले जाओ [3]। इसे डेटा लोकैलिटी कहते हैं, और यह कोई \u0026ldquo;अच्छा-तो-है\u0026rdquo; किस्म का ऑप्टिमाइज़ेशन नहीं है — यही वह कारण है जिसके लिए Hadoop अस्तित्व में है।\nज़रा सोचिए। आपका कोड — map फ़ंक्शन — शायद कुछ किलोबाइट का है। जिस डेटा ब्लॉक को इसे प्रोसेस करना है वह 128 MB का है। अगर आप डेटा को वहाँ भेजते हैं जहाँ कोड है, तो आप हर ब्लॉक के लिए नेटवर्क पर 128 MB धकेल रहे हैं, और आपके पास हज़ारों ब्लॉक्स हैं। नेटवर्क पिघल जाएगा। इसके बजाय, Hadoop छोटे-से कोड को उस मशीन पर भेजता है जो पहले से ब्लॉक रखती है, और उसे वहीं चलाता है, लोकल डिस्क से पढ़ते हुए [3]।\nHadoop यह भी रैंक करता है कि किसी टास्क की प्लेसमेंट कितनी अच्छी है:\nData-local — टास्क ठीक उसी नोड पर चलता है जो ब्लॉक रखता है। सबसे बढ़िया स्थिति। Rack-local — ठीक वही नोड नहीं मिल पाता, तो उसे उसी सर्वर रैक की किसी दूसरी मशीन पर चलाओ (रैक के भीतर नेटवर्क तेज़ होता है) [4]। Off-rack — सबसे खराब स्थिति, डेटा रैक पार करता है। Hadoop इससे बचने की पूरी कोशिश करता है। यह इतना मायने क्यों रखता है? क्योंकि स्टोरेज की दुनिया में एक चीज़ है जिसे डेटा ग्रैविटी कहते हैं — बड़े, सक्रिय डेटासेट एप्लिकेशन को अपनी ओर खींचते हैं चाहे वे कहीं भी रहें, क्योंकि डेटा को हिलाना बहुत धीमा और बहुत महँगा हो जाता है [5]। स्टोरेज खुद रुकावट नहीं है; डेटा मूवमेंट रुकावट है। भौतिकी ऐसी सीमाएँ लगाती है जिनके आसपास आप इंजीनियरिंग नहीं कर सकते — आप डेटा को उतनी तेज़ी से नहीं भेज सकते जितनी तेज़ी से उसे बना सकते हैं [5]। डेटा ग्रैविटी के प्रति Hadoop का जवाब था इससे लड़ना बंद कर देना। कंप्यूट को डेटा के पास ले आओ। यानी मूल रूप से, ग्रैविटी के आगे आत्मसमर्पण कर दो।\nअब Kubernetes पर माइक्रोसर्विसेज़ वाला सेटअप उस दूसरी चीज़ की कल्पना कीजिए जिसका सवाल में ज़िक्र था: एक Kubernetes क्लस्टर में चलती 10 माइक्रोसर्विसेज़, जो सभी किसी साझा स्टोरेज से बात कर रही हैं (मान लीजिए कोई नेटवर्क फ़ाइल सिस्टम, या कोई क्लाउड ऑब्जेक्ट स्टोर, या कोई मैनेज्ड डेटाबेस)।\nKubernetes को मूल रूप से स्टेटलेस एप्लिकेशन के लिए डिज़ाइन किया गया था — ऐसी सर्विसेज़ जिन्हें बंद होने पर कुछ भी याद रखने की ज़रूरत नहीं होती। यही स्टेटलेसनेस ही वह जादू है जो काम करता है: डिक्लेरेटिव डिप्लॉयमेंट, हाई अवेलेबिलिटी, ऑटोस्केलिंग, और किसी सर्विस को आसानी से रोकने, फिर से चालू करने और क्लोन करने की क्षमता [6]। आपकी शॉपिंग-कार्ट सर्विस, आपकी auth सर्विस, आपकी पेमेंट सर्विस — हर एक एक छोटा डिब्बा है जो एक रिक्वेस्ट संभालता है और उसे भूल जाता है।\nऔर यहाँ वास्तुशिल्प सिद्धांत Hadoop के सिद्धांत के बिल्कुल विपरीत है। एक Kubernetes माइक्रोसर्विसेज़ सेटअप में, आप जानबूझकर स्टोरेज को कंप्यूट से अलग करते हैं। स्टोरेज परत उस कंप्यूट परत से पूरी तरह अलग होती है जिसे Kubernetes मैनेज करता है [6]। स्टेटलेस ऐप-सर्वर कंप्यूट अक्सर ऐसी डेटा सर्विसेज़ से जुड़ता है जो क्लस्टर के बाहर ही चलती हैं [6]।\nएक और नियम है जो खुद माइक्रोसर्विसेज़ की दुनिया से आता है: सर्विसेज़ को डेटा स्टोर साझा नहीं करना चाहिए। हर सर्विस से अपेक्षा होती है कि वह अपने डेटासेट का मालिक खुद हो, ठीक इसलिए ताकि सर्विसेज़ के बीच छिपी निर्भरताओं और आकस्मिक कपलिंग से बचा जा सके [6]। तो \u0026ldquo;साझा स्टोरेज वाली 10 माइक्रोसर्विसेज़\u0026rdquo; वाक्यांश पहले से ही थोड़ा संदिग्ध है — सच्ची माइक्रोसर्विसेज़ वास्तुकला साझा स्टोरेज से दूर धकेलती है, इस ओर कि हर सर्विस अपने हिस्से की मालिक हो। (इस तनाव के बारे में आप Microsoft की AKS माइक्रोसर्विसेज़ रेफ़रेंस आर्किटेक्चर में और पढ़ सकते हैं।)\nजब आप Kubernetes में स्टोरेज जोड़ते हैं, तो आप आमतौर पर क्लस्टर को NFS, GlusterFS, या Amazon EFS, Azure Files, और Google Cloud Filestore जैसी क्लाउड फ़ाइल सिस्टम पर उजागर पारंपरिक इन्फ़्रास्ट्रक्चर से जोड़ते हैं [6]। कंप्यूट और स्टोरेज अलग-अलग मशीनों पर होते हैं, जो नेटवर्क से जुड़े होते हैं। डेटा डिज़ाइन के हिसाब से ही दूरस्थ होता है।\nआमने-सामने: असली फ़र्क़ तो चलिए अमूर्त बातें छोड़ते हैं। यहाँ है जहाँ ये सचमुच अलग होते हैं।\nआयाम Hadoop K8s पर 10 माइक्रोसर्विसेज़ + साझा स्टोरेज मुख्य काम विशाल डेटासेट को थोक में प्रोसेस करना कई स्वतंत्र रिक्वेस्ट संभालना डेटा कहाँ रहता है उन्हीं नोड्स पर जो कंप्यूट करते हैं (HDFS) दूरस्थ/साझा स्टोरेज पर, कंप्यूट से अलग मार्गदर्शक सिद्धांत कोड को डेटा के पास ले जाओ [3] कंप्यूट को स्टोरेज से अलग करो [6] स्टेट स्टोरेज-केंद्रित, डेटा ही सिस्टम है कंप्यूट स्टेटलेस, स्टेट बाहर धकेला गया [6] काम की इकाई map/reduce टास्क में बँटा एक बैच जॉब प्रति सर्विस एक रिक्वेस्ट/रिस्पॉन्स नेटवर्क पर क्या जाता है ज़्यादातर छोटा कोड; डेटा लोकल रहता है डेटा खुद, हर ऑपरेशन पर कपलिंग कसकर एक साथ रखा कंप्यूट + स्टोरेज ढीली कपलिंग, हर सर्विस स्वतंत्र स्केलिंग लक्ष्य विशाल डेटा पर थ्रूपुट रिक्वेस्ट की कंकरेंसी और अवेलेबिलिटी विफलता मॉडल मानता है डिस्क खराब होती हैं; ब्लॉक रेप्लिकेट करता है मानता है पॉड्स मरते हैं; स्टेटलेस पॉड्स फिर शेड्यूल करता है मुख्य बात: Hadoop कंप्यूट और स्टोरेज को जानबूझकर एक साथ रखता है; Kubernetes माइक्रोसर्विसेज़ उन्हें जानबूझकर अलग करती हैं। ये एक ही विचार के दो स्वाद नहीं हैं। ये दो अलग सवालों के जवाब हैं।\nHadoop पूछता है: \u0026ldquo;मेरे पास डेटा का एक पहाड़ शांत बैठा है। मैं नेटवर्क का दम घोंटे बिना इस सब पर कंप्यूटेशन कैसे चलाऊँ?\u0026rdquo;\nKubernetes माइक्रोसर्विसेज़ पूछती हैं: \u0026ldquo;मेरे पास छोटी, स्वतंत्र रिक्वेस्ट की बाढ़ है। मैं इन्हें भरोसेमंद ढंग से कैसे परोसूँ, हर हिस्से को अलग से कैसे स्केल करूँ, और क्रैश से कैसे बचूँ?\u0026rdquo;\nएक परिदृश्य जो बात को साफ़ कर देगा मान लीजिए आप एक ई-कॉमर्स साइट चलाते हैं।\nKubernetes पर माइक्रोसर्विसेज़ आपकी चलती-फिरती दुकान हैं: एक यूज़र \u0026ldquo;add to cart\u0026rdquo; पर क्लिक करता है, कार्ट सर्विस इसे संभालती है, इन्वेंट्री सर्विस स्टॉक जाँचती है, पेमेंट सर्विस कार्ड से पैसे काटती है। दस छोटी सर्विसेज़, हर एक ट्रैफ़िक के हिसाब से स्केल करती हुई, हर एक आदर्श रूप से अपने डेटा की मालिक। रिक्वेस्ट छोटी हैं, हर एक जिस डेटा को छूती है वह छोटा है, और लेटेंसी ही सब कुछ है। यहाँ नेटवर्क पर किसी साझा डेटाबेस को कुछ KB भेजना बिल्कुल ठीक है।\nअब, रात 2 बजे, आप पिछले पाँच साल के हर ऑर्डर का विश्लेषण करना चाहते हैं ताकि खरीदारी के पैटर्न मिल सकें। वह 8 TB ऐतिहासिक लॉग है। आप 8 TB को नेटवर्क पर किसी माइक्रोसर्विस के ज़रिए नहीं खींचने वाले — आपका नेटवर्क और आपका बटुआ, दोनों डेटा ग्रैविटी से मर जाएँगे [5]। यह Hadoop-आकार का काम है: डेटा को HDFS पर पार्क करो, विश्लेषण कोड को वहाँ भेजो जहाँ ब्लॉक्स रहते हैं, उसे समानांतर में पीसो, और एक सारांश लिख दो। डेटा कभी नहीं हिलता; कोड हिलता है।\nएक ही कंपनी, दो बिल्कुल अलग समस्याएँ, दो बिल्कुल अलग वास्तुकलाएँ। ये प्रतिस्पर्धी नहीं हैं — सच कहूँ तो, ये अक्सर एक ही इमारत में साथ-साथ रहती हैं।\n\u0026ldquo;पर मेरी माइक्रोसर्विसेज़ भी तो डेटा प्रोसेस करती हैं!\u0026rdquo; बेशक करती हैं। यहीं बात पेचीदा हो जाती है, और यहीं तुलना धुँधली लगने लगती है। एक माइक्रोसर्विस ज़रूर एक फ़ाइल पढ़ सकती है, उसे रूपांतरित कर सकती है, और वापस लिख सकती है। तो फिर असली रेखा क्या है?\nयह तीन बातों पर निर्भर करता है:\nमात्रा और लोकैलिटी। एक माइक्रोसर्विस एक पंक्ति, एक दस्तावेज़, एक छोटा ब्लॉब लाती है — यह दूरस्थ डेटा को कंप्यूट के पास खींचती है। Hadoop इतने बड़े पैमाने पर ऐसा करने से इनकार करता है क्योंकि डेटा हिलाने के लिए बहुत बड़ा है, इसलिए वह कंप्यूट को डेटा के पास भेजता है [3]। अगर आपके काम की रुकावट यह है कि \u0026ldquo;मैं तो सारा डेटा पढ़ भी नहीं पाता इतनी तेज़ी से,\u0026rdquo; तो आप Hadoop के इलाके में हैं।\nकाम की महीनता। माइक्रोसर्विसेज़ रिक्वेस्ट के हिसाब से सोचती हैं — छोटी, अलग-थलग, कम-लेटेंसी वाली। Hadoop जॉब्स के हिसाब से सोचता है — पूरे डेटासेट पर लंबे समय तक चलने वाले बैच पास, जहाँ आप खुशी-खुशी मिनटों या घंटों इंतज़ार करते हैं [7]। MapReduce की बैच प्रकृति असल में रियल-टाइम काम के लिए लेटेंसी की समस्याएँ पैदा करती है, और यही ठीक वह कारण है जिससे यह लाइव रिक्वेस्ट परोसने के लिए ग़लत औज़ार है [7]।\nकपलिंग का दर्शन। माइक्रोसर्विसेज़ ढीली कपलिंग और स्वतंत्र स्टोरेज स्वामित्व चाहती हैं ताकि टीमें एक-दूसरे के रास्ते में आए बिना तेज़ी से आगे बढ़ सकें [6]। Hadoop कंप्यूट और स्टोरेज की कसकर एक-साथ स्थिति चाहता है ताकि वह नेटवर्क की लड़ाई जीत सके। ये लक्ष्य सचमुच एक-दूसरे का खंडन करते हैं।\nतो थोड़ा-बहुत डेटा प्रोसेसिंग करती माइक्रोसर्विस फिर भी एक माइक्रोसर्विस ही है। यह तब \u0026ldquo;बिग डेटा सिस्टम\u0026rdquo; बनती है जब डेटा ही वह अचल गुरुत्वाकर्षण केंद्र हो और कंप्यूट को उसके चारों ओर चक्कर लगाने पड़ें।\nजानने लायक एक पेच: बिग डेटा भी \u0026ldquo;शुद्ध\u0026rdquo; Hadoop से दूर हट गया अगर मैं आपको यह आभास दूँ कि Hadoop अब भी बिग डेटा के लिए डिफ़ॉल्ट है, तो मैं आपके साथ अन्याय करूँगा। अब ऐसा नहीं है। Hadoop ने डिस्ट्रिब्यूटेड कंप्यूटिंग का बीड़ा उठाया, पर नई परियोजनाओं के लिए इसका इस्तेमाल घट रहा है [7]। MapReduce हर स्टेप के बीच मध्यवर्ती नतीजों को डिस्क पर लिखता है, जो धीमा है, इसलिए Apache Spark आया और उसी किस्म की डिस्ट्रिब्यूटेड प्रोसेसिंग ज़्यादातर मेमोरी में करने लगा, जिससे पुनरावृत्त (iterative) और इंटरैक्टिव काम नाटकीय रूप से तेज़ हो गया [7]।\nऔर व्यापक इकोसिस्टम बहुत बड़ा है — Hadoop सिर्फ़ MapReduce नहीं है। इसने ऐसे औज़ार उगाए जैसे:\nHive — एक डेटा-वेयरहाउस परत जो आपको HiveQL नामक SQL-जैसी भाषा से HDFS डेटा पर क्वेरी करने देती है [8]। HBase — एक डिस्ट्रिब्यूटेड डेटाबेस जो अरबों पंक्तियों और लाखों कॉलम वाली टेबलों में संरचित डेटा स्टोर करता है, सीधे HDFS पर बैठा हुआ [8]। Pig — एक उच्च-स्तरीय प्लेटफ़ॉर्म जो बड़े डेटासेट को लोड, फ़िल्टर और रूपांतरित करने के लिए PigLatin का उपयोग करता है [8]। दिलचस्प बात यह है कि आधुनिक क्लाउड-डेटा दुनिया ने Hadoop के मूल सबक को आंशिक रूप से भुला दिया है। BigQuery और Snowflake जैसे औज़ार जानबूझकर स्टोरेज को कंप्यूट से फिर अलग करते हैं — वही डिकपलिंग जो Kubernetes माइक्रोसर्विसेज़ इस्तेमाल करती हैं — क्योंकि क्लाउड में, ऑब्जेक्ट स्टोरेज और कंप्यूट के बीच नेटवर्क बैंडविड्थ इतनी तेज़ और सस्ती हो गई कि डेटा लोकैलिटी 2008 की तुलना में कम मायने रखती है। तो एक मज़ेदार तरीके से, पेंडुलम \u0026ldquo;सब कुछ एक साथ रखो\u0026rdquo; (Hadoop) से झूलकर \u0026ldquo;सब कुछ अलग करो\u0026rdquo; (क्लाउड डेटा वेयरहाउस और माइक्रोसर्विसेज़ दोनों) की ओर चला गया। जैसे-जैसे AI वर्कलोड फिर से डेटा की मात्रा को विस्फोटित करता है, यह स्थिति टिकेगी या नहीं, यह एक खुला सवाल है — कुछ लोग तर्क देते हैं कि डेटा ग्रैविटी ज़ोर-शोर से वापस आ रही है और असल में कभी गई ही नहीं थी [5]।\nतो, क्या ये एक ही चीज़ हैं या नहीं? नहीं। और मैं इसे सबसे साफ़ तरीके से यूँ कह सकता हूँ।\nमाइक्रोसर्विसेज़ चलाता एक Kubernetes क्लस्टर एक रिक्वेस्ट-परोसने वाली मशीन है। इसकी प्रवृत्ति है कंप्यूट को स्टेटलेस और हल्का रखना, और डेटा को बाहर वहाँ धकेलना जहाँ उसे साझा किया जा सके या स्वतंत्र रूप से उसका मालिक हुआ जा सके। नेटवर्क डेटा को कंप्यूट के पास ले जाता है, और यह स्वीकार्य है क्योंकि हर रिक्वेस्ट बहुत थोड़ा डेटा छूती है [6]।\nHadoop एक डेटा-पीसने वाली मशीन है। इसकी प्रवृत्ति है डेटा को उन्हीं डिस्क पर कील ठोककर रखना जो कंप्यूट करती हैं, क्योंकि पेटाबाइट हिलाना भौतिकी के खिलाफ़ हारने वाली लड़ाई है। नेटवर्क कोड को डेटा के पास ले जाता है [3]।\nअगर आपको सिर्फ़ एक पंक्ति याद रहे: माइक्रोसर्विसेज़ डेटा को कोड के पास ले जाती हैं; Hadoop कोड को डेटा के पास ले जाता है। बाकी सब कुछ — डेमॉन, रेप्लिकेशन, YARN शेड्यूलिंग, StatefulSets — उसी एक फ़ैसले से बहता है।\nये सतही तरीकों से ओवरलैप करते हैं (क्लस्टर, डिस्ट्रिब्यूशन, फ़ॉल्ट टॉलरेंस), यही वजह है कि यह सवाल पूछना इतना स्वाभाविक है। पर ये वास्तुकलाएँ किसी भी डिस्ट्रिब्यूटेड सिस्टम की सबसे महँगी चीज़ को लेकर विपरीत दाँव पर बनी हैं: तार के पार बाइट हिलाना।\nसमाप्त\nस्रोत Apache Hadoop Architecture - HDFS, YARN \u0026amp; MapReduce (TechVidvan) Apache Hadoop 3.3.5 – MapReduce Tutorial (Official Docs) Data Locality in Hadoop: The Most Comprehensive Guide (DataFlair) Introduction to Data Locality in Hadoop MapReduce (TechVidvan) What Is Data Gravity in Cloud Architecture? (simplyblock) Kubernetes Assimilation and the Need of Persistent Storage (Lightbits) Hadoop vs. Spark: Which One Should You Choose? (Back4App) Exploring the Hadoop Ecosystem: Hive, Pig, HBase, and More (Medium) ","permalink":"https://cloudmato.com/hi/posts/what-is-hadoop-vs-microservices-kubernetes/","title":"Hadoop क्या है, और यह K8s पर 10 माइक्रोसर्विसेज़ क्यों नहीं है"},{"content":"हर कोई ChatGPT और Claude के बारे में ऐसे बात करता है जैसे ये किसी दिन अचानक प्रकट हो गए हों। आप कुछ टाइप करते हैं, आपको जवाब मिलता है, जादू। पर क्या आपने कभी रुककर यह पूछा है कि इनमें से एक चीज़ को बनाने में असल में क्या लगता है? चैट इंटरफ़ेस नहीं — मॉडल खुद। वह चीज़ जिसमें महीनों लगे, करोड़ों डॉलर लगे, और एक छोटे शहर को बिजली देने जितनी बिजली खर्च हुई।\nमैं काफ़ी समय से इसके बारे में उत्सुक रहा हूँ, कुछ हद तक इसलिए क्योंकि ये आँकड़े वाकई तब तक यकीन करने लायक नहीं लगते जब तक आप उनके साथ बैठ न जाएँ। तो मैंने उसमें खोजबीन की जो असल में ज्ञात है — लीक हुई आर्किटेक्चर डिटेल्स, हार्डवेयर घोषणाएँ, डेटा सेंटर निर्माण। इसमें से कुछ सार्वजनिक है, कुछ अच्छी तरह से प्रमाणित अटकलें हैं, और कुछ को लैब्स जानबूझकर अस्पष्ट रखती हैं। चलिए मैं आपको बताता हूँ कि हम असल में क्या जानते हैं।\nसंक्षिप्त संस्करण: यह एक नहीं, तीन बड़े चरण हैं जब लोग कहते हैं कि एक मॉडल को \u0026ldquo;ट्रेन\u0026rdquo; किया गया, तो वे आम तौर पर एक विशाल गणना की कल्पना करते हैं। यह ग़लत है। आधुनिक फ्रंटियर मॉडल एक बहु-चरणीय पाइपलाइन से गुज़रते हैं जिसे OpenAI ने 2022 में InstructGPT के साथ कमोबेश औपचारिक रूप दिया था [1]। तीन चरण ये हैं:\nप्रीट्रेनिंग — मॉडल को खरबों शब्द खिलाएँ और उसे अगला टोकन पूर्वानुमान करना सिखाएँ। यह महँगा हिस्सा है, वही जो महीनों तक GPU क्लस्टर खा जाता है। सुपरवाइज़्ड फाइन-ट्यूनिंग (SFT) — उसे अच्छे प्रश्न-और-उत्तर व्यवहार के क्यूरेट किए गए उदाहरण दिखाएँ ताकि वह केवल ऑटोकंप्लीट करने के बजाय असल में मददगार बनना सीखे। मानव प्रतिक्रिया से सुदृढ़ीकरण सीखना (RLHF) — इंसान मॉडल की प्रतिक्रियाओं को रैंक करते हैं, एक अलग \u0026ldquo;रिवॉर्ड मॉडल\u0026rdquo; उन प्राथमिकताओं को सीखता है, और मुख्य मॉडल को उन जवाबों की ओर धकेला जाता है जो लोग पसंद करते हैं [1]। वह आख़िरी चरण ही वह गुप्त मसाला है जो एक कच्चे टेक्स्ट प्रिडिक्टर को ऐसी चीज़ में बदल देता है जो ऐसा महसूस कराती है कि वह आपसे बात कर रही है। Anthropic यहाँ अपना ख़ुद का मोड़ जोड़ता है जिसे Constitutional AI कहते हैं, जहाँ मॉडल पूरी तरह मानव लेबल पर निर्भर रहने के बजाय लिखित सिद्धांतों के एक सेट के विरुद्ध ख़ुद की आलोचना करता है।\nईमानदारी से कहूँ, यहीं पर ज़्यादातर व्याख्याएँ रुक जाती हैं और यहीं यह दिलचस्प हो जाता है। तो चलिए हर हिस्से में और गहराई से जाते हैं।\nकुछ भी ट्रेन होने से पहले: डेटा की समस्या आप बिना डेटा के एक फ्रंटियर मॉडल ट्रेन नहीं कर सकते, और यहाँ का पैमाना ही पहली चीज़ है जो आपके दिमाग़ को चकरा देती है। GPT-3 को लगभग 300 अरब टोकन पर ट्रेन किया गया था। जब तक आप Meta के Llama 3 तक पहुँचते हैं, यह संख्या 15 खरब टोकन से ऊपर है [2]। GPT-4 कथित तौर पर लगभग 13 खरब के आसपास था [3]। एक टोकन मोटे तौर पर एक उप-शब्द टुकड़ा होता है — \u0026ldquo;running\u0026rdquo; एक टोकन हो सकता है, या टोकनाइज़र के आधार पर यह \u0026ldquo;run\u0026rdquo; और \u0026ldquo;ning\u0026rdquo; में बँट सकता है।\nयह सारा टेक्स्ट आता कहाँ से है? रीढ़ की हड्डी है Common Crawl, वेब पेजों का एक खुला संग्रह जो हर महीने ताज़ा स्नैपशॉट जारी करता है, जिसे पेटाबाइट में मापा जाता है [2]। पर यहाँ वह बात है जो कोई नहीं बताता: कच्चा वेब डेटा कचरा है, और ज़्यादातर काम उसे साफ़ करने का होता है। टीमें विस्तृत फ़िल्टरिंग पाइपलाइन बनाती हैं जो ये करती हैं:\nभाषा पहचान — उन भाषाओं को रखें जो आप असल में चाहते हैं बॉयलरप्लेट हटाना — नेविगेशन मेन्यू, कुकी बैनर, विज्ञापन हटाएँ गुणवत्ता स्कोरिंग — निम्न-गुणवत्ता या स्पैमी पेज फेंक दें डीडुप्लिकेशन — दोहराई गई सामग्री हटाएँ ताकि मॉडल ज़रूरत से ज़्यादा रटे नहीं सुरक्षा फ़िल्टरिंग — वाकई घटिया चीज़ें हटा दें [2] वह डीडुप्लिकेशन कदम चुपके से सबसे बड़ी अड़चनों में से एक है। खरब-टोकन पैमाने पर आप हर दस्तावेज़ की तुलना हर दूसरे दस्तावेज़ से नहीं कर सकते — यह कंप्यूटेशनल रूप से पागलपन है। तो टीमें MinHash LSH और Jaccard समानता जैसी तरकीबों का उपयोग करती हैं ताकि निकट-डुप्लिकेट्स को बिल्कुल सटीक के बजाय अनुमानित रूप से ढूँढ सकें [4]। फिर सब कुछ UTF-8 बाइट्स में बदला जाता है और Byte Pair Encoding के माध्यम से चलाया जाता है ताकि वे टोकन ID बन सकें जिन्हें मॉडल असल में देखता है [2]।\nयह चरण ग्लैमरहीन है और इसमें गंभीर इंजीनियरिंग लगती है, पर इसे छोड़ दें तो आपका अरब-डॉलर का ट्रेनिंग रन क्लिकबेट और कमेंट-सेक्शन की गंदगी से सीखेगा। कचरा अंदर, कचरा बाहर — सिवाय इसके कि उस कचरे को प्रोसेस करने में $10 करोड़ लगते हैं।\nप्रीट्रेनिंग: जहाँ GPU काम पर लग जाते हैं अब महँगा हिस्सा। प्रीट्रेनिंग में, मॉडल को टेक्स्ट का एक टुकड़ा दिखाया जाता है और बार-बार, अरबों बार पूछा जाता है: अगला टोकन क्या है? वह अनुमान लगाता है, ग़लत होता है, त्रुटि को वापस नेटवर्क के ज़रिए धकेला जाता है, वज़न थोड़ा सा खिसकते हैं। इसे खरबों टोकन में दोहराएँ और यह चीज़ धीरे-धीरे व्याकरण, तथ्य, तर्क के पैटर्न, कोडिंग — सब कुछ सीख लेती है, और यह सब एक बेवकूफ़ाना सरल लक्ष्य से उभरता है।\nपेंच यह है कि \u0026ldquo;खरबों टोकन में अरबों बार\u0026rdquo; के लिए स्पष्ट रूप से बेतुकी मात्रा में कंप्यूट की माँग होती है। चलिए हार्डवेयर की बात करते हैं, क्योंकि यही वह हिस्सा है जो यूज़र ने असल में पूछा था।\nGPT-4 किस पर चला व्यापक रूप से उद्धृत लीक हुई डिटेल्स के अनुसार (OpenAI ने इनकी आधिकारिक पुष्टि कभी नहीं की), GPT-4 को लगभग 25,000 NVIDIA A100 GPU पर करीब 90–100 दिनों में ट्रेन किया गया था [3][5]। मॉडल खुद कथित तौर पर लगभग 1.8 खरब पैरामीटर का है जो एक Mixture-of-Experts डिज़ाइन का उपयोग करता है — लगभग 111B पैरामीटर वाले 16 एक्सपर्ट, जहाँ पूरे नेटवर्क के बजाय प्रति टोकन केवल कुछ ही सक्रिय होते हैं [5]। कच्चा कंप्यूट लगभग 2 × 10²⁵ FLOPs तक पहुँचा, और अकेले ट्रेनिंग रन की अनुमानित लागत $6.3 करोड़ थी [3]।\nGPT-5 कथित तौर पर किस पर चलता है आगे बढ़ें और हार्डवेयर पीढ़ी NVIDIA के Hopper चिप्स में पलट जाती है। रिपोर्ट्स GPT-5 की ट्रेनिंग को लगभग 50,000 H100 GPU पर आँकती हैं, जो कुल मिलाकर लगभग 14.4 करोड़ GPU-घंटे है, जिसकी अनुमानित लागत $60 करोड़ से ऊपर है [6]। NVIDIA ने ख़ुद कहा है कि GPT-5 को H100 और H200 GPU पर ट्रेन किया गया [7]। H200 वह अपग्रेड है जिसने OpenAI को ज़्यादा साँस लेने की जगह दी: 4.8 TB/s बैंडविड्थ पर 141 GB मेमोरी, बनाम H100 की 80 GB [8]।\nAnthropic किस पर चलता है यहीं पर यह वाकई अलग हो जाता है। Anthropic भारी रूप से Amazon पर निर्भर है — NVIDIA पर नहीं — Project Rainier के ज़रिए, जो पृथ्वी पर सबसे बड़े AI कंप्यूट क्लस्टरों में से एक है, जो AWS के कस्टम Trainium2 सिलिकॉन पर बना है। Rainier 2025 में लगभग पाँच लाख Trainium2 चिप्स के साथ ऑनलाइन आया, और AWS का कहना है कि उस साल के अंत तक Claude के 10 लाख से ज़्यादा Trainium2 चिप्स पर चलने की उम्मीद थी [9]। यह उस कंप्यूट से पाँच गुना से ज़्यादा है जो Anthropic ने अपने पिछले मॉडलों के लिए इस्तेमाल किया था [9]।\nआर्किटेक्चर इन चिप्स को UltraServers के साथ जोड़ता है — 16 Trainium2 चिप्स वाले चार सर्वर प्रत्येक — जो आंतरिक रूप से हाई-स्पीड NeuronLinks पर और क्लस्टरों के बीच Elastic Fabric Adapter नेटवर्किंग के ज़रिए जुड़े हैं [9]। और वे रुक नहीं रहे: Anthropic ने AWS पर $100 अरब से ज़्यादा खर्च करने और Trainium2, Trainium3, और उससे आगे में 5 गीगावाट तक की क्षमता सुरक्षित करने की प्रतिबद्धता जताई [10]। उन्होंने और अधिक कस्टम चिप्स के लिए Google और Broadcom के साथ एक अलग सौदा भी किया है [11]। जब आप सुनते हैं \u0026ldquo;कंप्यूट नया तेल है,\u0026rdquo; तो व्यवहार में यह ऐसा ही दिखता है।\nGPU पीढ़ियाँ, आमने-सामने चिप आर्किटेक्चर मेमोरी बैंडविड्थ उल्लेखनीय A100 Ampere 40/80 GB ~2 TB/s GPT-4 ट्रेन किया (कथित तौर पर) [5] H100 Hopper 80 GB 3.35 TB/s 2023–24 का वर्कहॉर्स [8] H200 Hopper 141 GB 4.89 TB/s मेमोरी अपग्रेड, वही डाई [8] B200 Blackwell 180 GB 8 TB/s ~4x H100 ट्रेनिंग थ्रूपुट, FP4 [12] Trainium2 AWS कस्टम — NeuronLink फ़ैब्रिक Anthropic का Project Rainier [9] H100 से Blackwell के B200 तक की छलाँग बहुत मायने रखती है। B200 प्रति GPU 1.8 TB/s पर NVLink 5.0 लाता है (H100 का दोगुना) और नए FP4 प्रिसिज़न टेंसर कोर लाता है जो ट्रांसफ़ॉर्मर मॉडलों पर लगभग 4 गुना ट्रेनिंग थ्रूपुट देते हैं [12]। जब आप दसियों हज़ार चिप्स में GPU-घंटे के हिसाब से भुगतान कर रहे हों, तो 4x तेज़ी एक नाइस-टू-हैव नहीं है — यह तीन महीने के रन और तीन हफ़्ते के रन के बीच का फ़र्क़ है।\n1,00,000 GPU को आपस में जोड़ना अपने आप में एक दुःस्वप्न है यहाँ एक बात है जिसने मुझे चौंका दिया: GPU ख़रीदना लगभग आसान हिस्सा है। उनमें से 1,00,000 को एक कंप्यूटर की तरह काम करवाना वहाँ है जहाँ असली इंजीनियरिंग का दर्द रहता है।\nएक अकेले 1,00,000 H100 क्लस्टर को लगभग 150 मेगावाट डेटा सेंटर क्षमता की ज़रूरत होती है और यह एक साल में लगभग 1.59 टेरावाट-घंटे बिजली जला देता है — मानक दरों पर अकेले बिजली की लागत में लगभग $12.4 करोड़ [13]। सर्वर खुद लगभग $4 अरब के पड़ते हैं [13]। यह तब है जब आपने अभी कुछ ट्रेन भी नहीं किया है।\nफिर नेटवर्किंग है। हर GPU को मॉडल का अपना हिस्सा लगातार हर दूसरे GPU के साथ साझा करना होता है, इसलिए इंटरकनेक्ट — InfiniBand या हाई-स्पीड Ethernet — अड़चन बन जाता है। xAI का Colossus सुपरकंप्यूटर यहाँ का चरम उदाहरण है। उन्होंने इसे 122 दिनों में 1,00,000 H100 के साथ बनाया, फिर और 92 दिनों में इसे दोगुना करके 2,00,000 GPU कर दिया [14]। उनका बिल्डिंग ब्लॉक 64 H100 का एक Supermicro लिक्विड-कूल्ड रैक है, जिसे 8 रैक (512 GPU) के समूहों में मिनी-क्लस्टर के रूप में व्यवस्थित किया गया है [15]। असामान्य रूप से, उन्होंने InfiniBand को पूरी तरह छोड़ दिया और NVIDIA के Spectrum-X Ethernet फ़ैब्रिक का उपयोग किया [14]। 2025 के अंत तक Colossus में कथित तौर पर 1,50,000 H100, 50,000 H200, और 30,000 GB200 थे [14]।\nऔर इस पैमाने पर, विफलताएँ कोई किनारे का मामला नहीं हैं — वे लगातार होती हैं। दसियों हज़ार GPU के महीनों तक पूरी रफ़्तार से चलने के साथ, अलग-अलग चिप्स, केबल, और नोड नियमित रूप से मर जाते हैं। यही वजह है कि लैब्स चेकपॉइंटिंग पर इतना भरोसा करती हैं: समय-समय पर पूरे मॉडल की स्थिति सहेजना ताकि जब (अगर नहीं) कुछ विफल हो, तो आप शून्य से नहीं बल्कि आख़िरी चेकपॉइंट से फिर शुरू करें [13]। चेकपॉइंट न करने की वजह से $60 करोड़ के रन का एक हफ़्ता गँवा दें और, ख़ैर, आपकी तिमाही ख़राब जाने वाली है।\nतो शुरू से अंत तक असल में कितना समय लगता है? यह वह सवाल है जो मुझे लगता है कि ज़्यादातर लोग ग़लत समझते हैं, क्योंकि वे मान लेते हैं कि \u0026ldquo;ट्रेनिंग समय\u0026rdquo; का मतलब \u0026ldquo;पूरी समय-सीमा\u0026rdquo; है। ऐसा नहीं है। चलिए मैं इसे उन चरणों में बाँटता हूँ जो असल में कैलेंडर समय खाते हैं।\nखुद प्रीट्रेनिंग रन मुख्य कंप्यूट रन — GPU-पिघलाने वाला हिस्सा — एक फ्रंटियर मॉडल के लिए 2 से 4 महीने के क्रम का है। GPT-4 का कथित तौर पर 25,000 A100 पर लगभग 100 दिन था [5]। यही वह संख्या है जो आप आम तौर पर उद्धृत देखते हैं। पर यह असली समय-सीमा का सबसे छोटा हिस्सा भी है।\nइसके आसपास सब कुछ GPT-4 लीक के अनुसार, असली ट्रेनिंग में लगभग 3 महीने लगे, और रिलीज़ से पहले उस पर लगभग 6 अतिरिक्त महीने की सुरक्षा परीक्षण परत चढ़ाई गई [16]। तो कंप्यूट पूरी तस्वीर का अधिकतम एक तिहाई है।\nयहाँ एक फ्रंटियर मॉडल के लिए सार्वजनिक रूप से ज्ञात बातों के आधार पर एक मोटा शुरू-से-अंत तक का विभाजन है:\nचरण मोटे तौर पर कितना लंबा क्या हो रहा है डेटा संग्रह और क्यूरेशन महीने (अक्सर ओवरलैपिंग) खरबों टोकन को क्रॉल, फ़िल्टर, डीडुप, टोकनाइज़ करना [2] आर्किटेक्चर और छोटे-पैमाने के प्रयोग हफ़्तों से महीनों प्रतिबद्ध होने से पहले छोटे पैमाने पर डिज़ाइन परखना मुख्य प्रीट्रेनिंग रन 2–4 महीने बड़ा GPU क्लस्टर काम [5] SFT + RLHF हफ़्तों से कुछ महीनों तक मददगारी और प्राथमिकताएँ सिखाना [1] सुरक्षा परीक्षण और रेड टीमिंग महीने (GPT-4 के लिए ~6) रिलीज़ से पहले नुकसान के लिए तनाव-परीक्षण [16] कुल, विचार से लॉन्च तक अक्सर ~9–18 महीने — वह सुरक्षा चरण कोई रबर स्टैम्प नहीं है। उदाहरण के लिए, Anthropic की रेड टीमिंग में विषय-विशेषज्ञों और LLM विशेषज्ञों को खतरनाक क्षमताओं के लिए मॉडल की जाँच में प्रति डोमेन 100+ घंटे बिताने पड़ते हैं [17]। Claude 3 भेजने से पहले, उनकी Trust \u0026amp; Safety टीम ने टेक्स्ट और इमेज दोनों जोखिमों के लिए रेड-टीम किया और बाहरी परीक्षकों को लाया [17]। Anthropic और OpenAI दोनों के मॉडल अमेरिकी और ब्रिटिश AI Safety Institutes के साथ डिप्लॉयमेंट-पूर्व परीक्षण से भी गुज़रे हैं [17]। तो जब एक लैब कहती है कि एक मॉडल \u0026ldquo;ट्रेनिंग पूरी कर चुका,\u0026rdquo; तो अक्सर आधे साल की कुरेदना, ठोकना-पीटना, और पैच करना अभी बाक़ी होता है।\nऔर ईमानदारी से, लॉन्च के बाद भी यह वाकई कभी ख़त्म नहीं होता। निरंतर फाइन-ट्यूनिंग पास होते हैं, विज़न घटक (GPT-4 की इमेज क्षमताओं को कथित तौर पर टेक्स्ट प्रीट्रेनिंग के बाद और 2 खरब टोकन पर ट्रेन किया गया था) [5], और मूल्यांकन तथा पुनरावृत्ति का अंतहीन चक्र।\nआख़िर इस सब की लागत इतनी ज़्यादा क्यों है? चलिए डॉलर को एक जगह रखता हूँ, क्योंकि पैमाना ही पूरी कहानी है:\nGPT-4 ट्रेनिंग रन: ~$6.3 करोड़ [3] GPT-5 ट्रेनिंग रन: अनुमानित $60 करोड़+ [6] एक अकेला 1 लाख-GPU क्लस्टर: हार्डवेयर में ~$4 अरब, बिजली में ~$12.4 करोड़/वर्ष [13] Anthropic की AWS प्रतिबद्धता: एक दशक में $100 अरब+ [10] कारण लगभग शर्मनाक हद तक सरल है। यह है कंप्यूट। आप ग्रह पर सबसे ज़्यादा माँग वाली चिप्स में से दसियों हज़ार किराए पर ले रहे हैं (या ख़रीद रहे हैं), उन्हें महीनों तक पूरी रफ़्तार पर चला रहे हैं, ऐसे डेटा सेंटरों में जो एक शहर जितनी बिजली खींचते हैं। उन GPU-घंटों में से हर एक की लागत पैसा है, हर वॉट की लागत पैसा है, और हर विफल रन जिसे फिर से शुरू करना पड़ता है उसकी लागत पैसा है। इसे पूरी पाइपलाइन में जोड़ें और करोड़ों डॉलर पागलपन जैसा लगना बंद कर देते हैं और अनिवार्य लगने लगते हैं।\nएक शांत लागत भी है जिसे ज़्यादातर कवरेज नज़रअंदाज़ कर देती है: लोग। क्यूरेशन पाइपलाइन बनाने वाले डेटा इंजीनियर, बड़े रन को डी-रिस्क करने के लिए छोटे-पैमाने के प्रयोग चलाने वाले शोधकर्ता, RLHF के लिए हज़ारों प्रतिक्रियाओं को रैंक करने वाले मानव एनोटेटर, उस चीज़ को तोड़ने की कोशिश में सौ-घंटे के दौर बिताने वाले रेड टीमर। चिप्स को सुर्खियाँ मिलती हैं, पर एक फ्रंटियर मॉडल जितना हार्डवेयर का कारनामा है उतना ही लॉजिस्टिक्स और मानव-समन्वय का भी।\nइसका क्या मतलब है अगर आप एक खरब-डॉलर की लैब नहीं हैं आप शायद अपने गैरेज में 1.8-खरब-पैरामीटर मॉडल प्रीट्रेन नहीं करने वाले, और बात कुछ हद तक यही है। शुरू से एक फ्रंटियर मॉडल बनाने की बाधा अब अरबों डॉलर और गीगावाट बिजली में मापी जाती है — यही कारण है कि पृथ्वी पर केवल मुट्ठी भर संगठन ही ऐसा करते हैं।\nपर यहाँ अधिक उपयोगी निष्कर्ष है। लगभग हर दिलचस्प चीज़ जो आप बना सकते हैं, उस काम के ऊपर बैठती है — एक API के ज़रिए, एक छोटे ओपन मॉडल को फाइन-ट्यून करके, रिट्रीवल और प्रॉम्प्टिंग के ज़रिए। खरब-टोकन प्रीट्रेनिंग रन वह हिस्सा है जिसे आप किराए पर लेते हैं, वह हिस्सा नहीं जिसे आप दोबारा करते हैं। लैब्स ने $60 करोड़ खर्च किए ताकि आप प्रति दस लाख टोकन कुछ डॉलर खर्च कर सकें।\nजो मुझे वाकई अजीब लगता है वह यह है कि इसमें से कितना अभी भी आधा-गुप्त है। OpenAI ने GPT-4 के आर्किटेक्चर की कभी आधिकारिक पुष्टि नहीं की — जो हम \u0026ldquo;जानते\u0026rdquo; हैं उसका ज़्यादातर हिस्सा लीक और अच्छी तरह से प्रमाणित विश्लेषण से आता है [5]। Anthropic सुरक्षा विधियों के बारे में बहुत कुछ प्रकाशित करता है पर सटीक मॉडल आकारों पर चुप रहता है। तो अगर आपने यह पूरी चीज़ एक सटीक, पुष्ट स्पेसिफिकेशन शीट की चाहत में पढ़ी, तो मुझे ईमानदार रहना होगा: उन इमारतों के बाहर किसी के पास वह नहीं है। हमारे पास जो है वह है लीक, हार्डवेयर घोषणाएँ, और लैब्स द्वारा हमें यह बताना कि वे इस समस्या पर कितना पैसा और सिलिकॉन झोंक रहे हैं — और वह भी आपके सिर को चकरा देने के लिए काफ़ी है।\nस्रोत Pretraining: Breaking Down the Modern LLM Training Pipeline — MLOps Community Curating Trillion-Token Datasets — NVIDIA Technical Blog GPT-4 architecture, datasets, costs and more leaked — The Decoder Data Deduplication at Trillion Scale — Zilliz Blog GPT-4 Architecture, Infrastructure, Training Dataset, Costs — SemiAnalysis How Many GPUs to Train GPT-5 — CometAPI OpenAI\u0026rsquo;s GPT-5 was trained on NVIDIA H100 and H200 GPUs — NVIDIA Data Center NVIDIA H200 GPU: Specs, VRAM, Price — RunPod AWS activates Project Rainier — About Amazon Amazon announces additional $5B Anthropic investment — About Amazon Anthropic expands partnership with Google and Broadcom — Anthropic NVIDIA B200 vs H100 — Clarifai 100,000 H100 Clusters: Power, Network, Reliability — SemiAnalysis xAI Colossus supercomputer with 100K H100 GPUs comes online — Tom\u0026rsquo;s Hardware Inside the 100K GPU xAI Colossus Cluster — ServeTheHome GPT-4 Details Revealed — Patrick McGuinness Frontier Threats Red Teaming for AI Safety — Anthropic ","permalink":"https://cloudmato.com/hi/posts/how-openai-anthropic-train-models/","title":"OpenAI और Anthropic अपने मॉडल असल में कैसे ट्रेन करते हैं"},{"content":"हर कोई HTTP/3 के बारे में ऐसे बात करता है जैसे यह एक मुफ़्त स्पीड अपग्रेड हो जिसे आप चालू करके भूल जाते हैं। ज़्यादातर ऐसा है ही — पर उस वाक्य में \u0026ldquo;ज़्यादातर\u0026rdquo; शब्द बहुत कुछ कह रहा है। HTTP/3 अब दुनिया भर में लगभग 35% वेब रिक्वेस्ट्स के लिए इस्तेमाल होता है [1], तो यह अब कोई रिसर्च का खिलौना नहीं रहा। बात यह है कि लगभग कोई नहीं समझाता कि यह क्यों तेज़ है, यह असल में HTTP/2 से कहाँ हार जाता है, और — वह सवाल जो कोई नहीं पूछता — कि आपकी अपनी साइट को इससे फ़ायदा भी होता है या नहीं। चलिए मैं इसे ऐसे समझाता हूँ जैसे चाय पर किसी दोस्त को समझाऊँ।\nअसल में बदला सिर्फ़ एक चीज़ यहीं पर लोग ग़लती करते हैं। वे सोचते हैं कि HTTP/3 रिक्वेस्ट लिखने का एक नया तरीका है, नए हेडर, नए मेथड, सब कुछ नया। ऐसा नहीं है।\nHTTP सेमांटिक्स — मेथड, स्टेटस कोड, हेडर — HTTP/2 और HTTP/1.1 के बिल्कुल समान हैं [2]। एक GET अब भी GET ही है। एक 404 अब भी 404 ही है। जो बदला वह है ट्रांसपोर्ट: वे बाइट्स इंटरनेट पर कैसे धकेले जाते हैं। HTTP/1.1 और HTTP/2 दोनों TCP पर चलते हैं। HTTP/3 TCP को बाहर फेंक देता है और QUIC नामक एक बिल्कुल नए प्रोटोकॉल पर चलता है, जो खुद UDP पर चलता है [3]।\nतो फ़र्क कैसे में है, क्या में नहीं [4]। वह एक अदला-बदली — TCP बाहर, QUIC अंदर — ही पूरी कहानी है। HTTP/3 की हर अच्छी और हर परेशान करने वाली चीज़ इसी से निकलती है।\nयह समझने के लिए कि किसी ने इतनी मेहनत क्यों की, आपको वह समस्या समझनी होगी जिससे TCP कभी छुटकारा नहीं पा सका।\nहेड-ऑफ़-लाइन ब्लॉकिंग: वह बग जो कभी मरा ही नहीं यही पूरी कहानी का खलनायक है, तो चलिए इसे ठीक से समझते हैं।\nहम यहाँ तक पहुँचे कैसे पुराने HTTP/1.1 में, आपका ब्राउज़र एक कनेक्शन खोलता और एक बार में एक रिक्वेस्ट भेजता। रिक्वेस्ट, रिस्पॉन्स का इंतज़ार, फिर अगली रिक्वेस्ट। अगर आपको समानांतरता (parallelism) चाहिए थी, तो ब्राउज़र प्रति डोमेन 6 अलग-अलग TCP कनेक्शन खोलता और उन्हें संभालता। बेकार था, पर काम चल जाता था।\nHTTP/2 ने इसे मल्टिप्लेक्सिंग से ठीक किया: एक ही TCP कनेक्शन साझा करती कई स्वतंत्र \u0026ldquo;स्ट्रीम्स\u0026rdquo;। आपकी CSS, आपकी JS, आपकी इमेजेज़ सब एक ही पाइप पर एक साथ, गुथे हुए बहती हैं। काग़ज़ पर शानदार। और एक साफ़ नेटवर्क पर, वाकई बेहतरीन।\nपर यहाँ एक पेच है जिसका ज़िक्र कोई नहीं करता। HTTP/2 स्ट्रीम्स को HTTP लेयर पर मल्टिप्लेक्स करता है, जबकि नीचे TCP अब भी एक सख़्ती से क्रमबद्ध बाइट स्ट्रीम पहुँचाने पर अड़ा रहता है। TCP को न तो पता है न परवाह कि आपके पास 100 स्वतंत्र स्ट्रीम्स हैं। उसे तो बाइट्स का एक ही क्रम दिखता है जो अवश्य क्रम में आना चाहिए।\nतो क्या होता है जब एक अकेला पैकेट खो जाता है?\nअटकाव अगर एक पैकेट गिर जाए, तो TCP उसके बाद आने वाली हर चीज़ को रोक देता है — पूरी तरह असंबंधित स्ट्रीम्स के बाइट्स समेत — जब तक वह खोया पैकेट दोबारा भेजकर आ नहीं जाता [5]। आपकी image1.jpg शायद वहाँ पूरी डाउनलोड होकर, रेंडर के लिए तैयार बैठी हो, पर अपनी किसी नेटवर्क दिक़्क़त से नहीं बल्कि इसलिए ब्लॉक हो क्योंकि styles.css का एक पैकेट खो गया [5]।\nHTTP/2 ने असल में हेड-ऑफ़-लाइन ब्लॉकिंग को हल नहीं किया। उसने बस इसे एक लेयर नीचे धकेल दिया, एप्लिकेशन लेयर से ट्रांसपोर्ट लेयर में [5]। एक परफ़ेक्ट नेटवर्क पर आप कभी नोटिस ही नहीं करेंगे। पर 2% पैकेट लॉस वाले एक डगमगाते मोबाइल कनेक्शन पर? वह एक अटकाव हर चीज़ पर लहर की तरह फैल जाता है।\nयही वह हिस्सा है जिसने मुझे सचमुच चौंकाया जब मैंने पहली बार गहराई से देखा। हमने सालों HTTP/2 मल्टिप्लेक्सिंग का जश्न मनाया, और गंदा राज़ यह था कि TCP एक अकेले गिरे पैकेट से उस सब को बेकार कर सकता था।\nQUIC इसे कैसे ख़त्म करता है QUIC हर स्ट्रीम को सचमुच स्वतंत्र बनाता है। हर QUIC स्ट्रीम अपना ख़ुद का पैकेट क्रम रखती है। तो जब स्ट्रीम #5 एक पैकेट खोती है, तो सिर्फ़ स्ट्रीम #5 अटकती है — स्ट्रीम #1 से #4 और #6 आगे तक तुरंत डिलीवर होती रहती हैं [5]। QUIC अब भी टाइमआउट के बाद खोए पैकेट को दोबारा भेजता है, बिल्कुल TCP की तरह, पर वह बाक़ी सबको साथ में नीचे नहीं खींचता [3]।\nयही सबसे बड़ी जीत है। एक साफ़ नेटवर्क पर इससे बमुश्किल फ़र्क पड़ता है। एक लॉसी नेटवर्क पर बहुत फ़र्क पड़ता है।\nबाक़ी जीतें (वे भी असली हैं) सुर्खियाँ हेड-ऑफ़-लाइन ब्लॉकिंग को मिलती हैं, पर QUIC कुछ और जानने लायक अपग्रेड भी साथ बंडल करता है।\nतेज़ हैंडशेक TCP पर HTTP/2 के साथ, एक सुरक्षित कनेक्शन खोलने का मतलब है एक TCP हैंडशेक और फिर उसके ऊपर एक अलग TLS हैंडशेक। QUIC ट्रांसपोर्ट हैंडशेक और क्रिप्टोग्राफ़िक हैंडशेक को एक ही ऑपरेशन में मोड़ देता है — कनेक्शन एक ही फ़्लाइट में स्थापित और एन्क्रिप्टेड [3]।\nलोग जो आँकड़े उछालते हैं: HTTP/3 1-RTT कनेक्शन सेटअप और 0-RTT रिज़म्पशन देता है, जबकि HTTP/2 को एक सुरक्षित कनेक्शन के लिए लगभग 3 RTT चाहिए [3]। सीधे शब्दों में, HTTP/3 कनेक्शन HTTP/2 से ~50% तक तेज़ी से सेट कर सकता है [4]। अगर आपके यूज़र आपके सर्वर से दूर हैं — हाई लेटेंसी — तो वे बचे हुए राउंड ट्रिप असली, महसूस होने वाला समय हैं।\nएन्क्रिप्शन अब वैकल्पिक नहीं रहा HTTP/1.1 और HTTP/2 में, TLS एक अलग लेयर के रूप में ऊपर बैठता है जिसे आप जोड़ते हैं। QUIC में, TLS 1.3 एक अभिन्न घटक के रूप में अंदर ही बना हुआ है [3]। बिना एन्क्रिप्शन वाला HTTP/3 जैसी कोई चीज़ है ही नहीं। सच कहूँ तो, मुझे लगता है यह अच्छी बात है — यह \u0026ldquo;उफ़, प्लेनटेक्स्ट\u0026rdquo; जैसी ग़लत कॉन्फ़िगरेशन्स की एक पूरी श्रेणी ही हटा देता है।\nकनेक्शन माइग्रेशन (कम आँका गया फ़ीचर) यह मेरा पसंदीदा फ़ीचर है और इसके बारे में लगभग कोई बात नहीं करता।\nTCP एक कनेक्शन को क्लासिक 4-ट्यूपल से पहचानता है: सोर्स IP, सोर्स पोर्ट, डेस्टिनेशन IP, डेस्टिनेशन पोर्ट। इनमें से कोई भी बदलिए — मान लीजिए आपका फ़ोन Wi-Fi से 5G पर कूदता है — तो IP बदल जाता है, इसलिए TCP कनेक्शन मर जाता है और उसे शुरू से दोबारा बनाना पड़ता है।\nQUIC 4-ट्यूपल पर निर्भर रहने के बजाय एक कनेक्शन की पहचान के लिए एक कनेक्शन ID इस्तेमाल करता है [6]। तो जब आपका फ़ोन नेटवर्क बदलता है, QUIC बस वही कनेक्शन ID बनाए रखता है और चलता रहता है [6]। आपका वीडियो चलता रहता है, आपका डाउनलोड डाउनलोड होता रहता है। यह देखते हुए कि इंटरनेट का कितना बड़ा हिस्सा अब इधर-उधर घूमते नेटवर्क बदलते मोबाइल यूज़र्स हैं, यह सचमुच एक बड़ी बात है।\nएक झटपट तुलना HTTP/1.1 HTTP/2 HTTP/3 ट्रांसपोर्ट TCP TCP QUIC (UDP पर) मल्टिप्लेक्सिंग नहीं (6 कनेक्शन) हाँ हाँ हेड-ऑफ़-लाइन ब्लॉकिंग हाँ (ऐप लेयर) हाँ (ट्रांसपोर्ट लेयर) काफ़ी हद तक हल [5] एन्क्रिप्शन TLS वैकल्पिक, ऊपर से जुड़ा TLS वैकल्पिक, ऊपर से जुड़ा TLS 1.3 अनिवार्य, अंदर निर्मित [3] सुरक्षित तक हैंडशेक कई RTT ~3 RTT [3] 1-RTT / 0-RTT रिज़म [3] नेटवर्क बदलने पर टिकता है नहीं नहीं हाँ (कनेक्शन माइग्रेशन) [6] तो क्या HTTP/3 बस\u0026hellip; बेहतर है? हमेशा नहीं। यहीं पर मार्केटिंग पेज चुप हो जाते हैं और मैं साफ़-साफ़ कहूँगा। HTTP/3 हमेशा HTTP/2 से तेज़ नहीं होता [7], और इसके उलट दिखावा करना आपको निराशा की ओर ले जाता है।\nCPU की क़ीमत असली है TCP को दशकों का कर्नेल-स्तर का ऑप्टिमाइज़ेशन मिला है। QUIC UDP पर यूज़रस्पेस में चलता है, जो बिल्कुल वही चीज़ है जो इसे अपडेट और डिप्लॉय करना आसान बनाती है — पर इसकी एक परफ़ॉर्मेंस क़ीमत है [8]।\nक्योंकि QUIC यूज़रस्पेस में रहता है, इसे लगातार सिस्टम कॉल्स के ज़रिए ACK पढ़ने पड़ते हैं, और QUIC पैकेट छोटे होते हैं (~1KB), तो उन सभी पैकेट-वार ACK को प्रोसेस करना CPU का एक बड़ा हिस्सा खा जाता है [8]। नतीजा: तेज़, कम-लॉस वाले नेटवर्क पर भरपूर बैंडविड्थ के साथ, एक HTTP/3 ट्रांसफ़र उसी ट्रांसफ़र की तुलना में HTTP/2 पर ज़्यादा CPU समय जला सकता है [8]। हाई-बैंडविड्थ परिदृश्यों में जहाँ CPU अड़चन बन जाता है, HTTP/3 HTTP/1.1 से भी कम थ्रूपुट दिखा सकता है [8]।\nइसे फिर से पढ़िए। एक मोटे, साफ़ पाइप पर, \u0026ldquo;नया, तेज़\u0026rdquo; प्रोटोकॉल धीमा हो सकता है क्योंकि वह CPU-बाउंड है। एक CPU-बाउंड सर्विस के लिए, HTTP/3 असल में आपकी प्रभावी क्षमता घटा सकता है [8]।\nUDP कभी-कभी पहुँचता ही नहीं QUIC UDP पर चलता है, और कुछ नेटवर्क UDP को संदिग्ध मानते हैं। कुछ फ़ायरवॉल और डिवाइस अनजान UDP प्रोटोकॉल्स को ब्लॉक कर देते हैं, तो QUIC सर्वर से बिना किसी रिस्पॉन्स के टाइमआउट हो जाता है [9]। कुछ कैरियर सेटअप्स पर QUIC के फ़ेल होने की असली रिपोर्ट्स हैं — जैसे कुछ 5G होम इंटरनेट पर UDP का ब्लॉक होना [9]। ब्राउज़र इसे चुपचाप TCP पर HTTP/2 में फ़ॉलबैक करके संभाल लेते हैं, तो यूज़र्स का आमतौर पर कुछ नहीं बिगड़ता — पर इसका मतलब है कि आपके सर्वर पर पहुँचने वाले हर किसी के लिए HTTP/3 एक पक्की जीत नहीं है।\nकुछ इन्फ़्रास्ट्रक्चर के पेच भी हैं। कुछ NAT डिवाइस कनेक्शन माइग्रेशन को ठीक से नहीं संभालते, जिससे मोबाइल हैंडऑफ़ के दौरान IP बदलने पर ड्रॉप होते हैं [6]। और एनीकास्ट और ECMP रूटिंग इस्तेमाल करने वाले नेटवर्क के लिए, एक ही QUIC कनेक्शन के पैकेट NAT रीबाइंड या माइग्रेशन के बाद अलग-अलग बैकएंड सर्वर पर रूट हो सकते हैं [6]। इनमें से कोई भी डील-ब्रेकर नहीं है, पर ये उस तरह की चीज़ें हैं जो अपना ख़ुद का एज चलाने पर आपकी एक दोपहर डिबगिंग में बर्बाद करवा देती हैं।\n0-RTT वाला फुटगन वह प्यारा 0-RTT रिज़म्पशन याद है? उसका एक तेज़ धार वाला किनारा है। 0-RTT अर्ली डेटा को रीप्ले किया जा सकता है [10]।\nयह तंत्र पिछले सेशन से एक प्री-शेयर्ड की का इस्तेमाल करता है, और क्योंकि अर्ली डेटा सर्वर के यह पुष्टि करने से पहले भेजा जाता है कि वह एक ताज़ा, जीवित क्लाइंट से बात कर रहा है, एक हमलावर उस एन्क्रिप्टेड 0-RTT डेटा की एक कॉपी पकड़कर उसे सेकंडों या मिनटों बाद सर्वर को दोबारा भेज सकता है [10]। सर्वर को एक दोहराई गई रिक्वेस्ट दिखती है जबकि असल में सिर्फ़ एक ही की गई थी [10]। यह चुपचाप उस आइडेम्पोटेन्सी मान्यता को तोड़ देता है जिस पर वेब बना है।\nसमाधान कोई अनोखी चीज़ नहीं है: 0-RTT पर नॉन-आइडेम्पोटेंट रिक्वेस्ट्स (जैसे POST) की अनुमति न दें। Cloudflare जैसे कुछ CDN पहले से ही नॉन-आइडेम्पोटेंट 0-RTT रिक्वेस्ट्स को डिफ़ॉल्ट रूप से ब्लॉक करते हैं, पर nginx जैसी अन्य इम्प्लीमेंटेशन्स शायद आपको बॉक्स से बाहर सुरक्षा न दें [10]। तो अगर आप ख़ुद हाथ से HTTP/3 तैयार कर रहे हैं, तो इसे सही करना आपके ज़िम्मे है। सच कहूँ तो, यहीं पर यह पेचीदा हो जाता है और यहीं बहुत से लोग चीज़ें ग़लत कॉन्फ़िगर कर बैठेंगे [10]।\nअसल में इसे इस्तेमाल किसे करना चाहिए? अब असली सवाल। चलिए इसे इस आधार पर तोड़ता हूँ कि आप कौन हैं, क्योंकि जवाब सचमुच अलग होता है।\nआप एक CDN के पीछे एक सामान्य वेबसाइट चलाते हैं बस इसे चालू कर दीजिए। यह आसान मामला है। अगर आप Cloudflare, Fastly, Cloudron, या इन जैसी किसी पर हैं, तो CDN एज पर HTTP/3 संभाल लेता है — कोई रीकम्पाइलिंग नहीं, कोई कर्नेल पैच नहीं। Cloudflare पर आप शाब्दिक रूप से डैशबोर्ड में इसे टॉगल करते हैं और एज Alt-Svc हेडर के ज़रिए कम्पैटिबल क्लाइंट्स को HTTP/3 का विज्ञापन देना शुरू कर देता है [11]।\nवैसे, वह Alt-Svc हेडर ही वह तरीका है जिससे पूरी चीज़ बूटस्ट्रैप होती है। क्लाइंट पहले HTTP/2 पर कनेक्ट होता है, इस तरह का एक रिस्पॉन्स हेडर देखता है, और जान जाता है कि अगली बार वह HTTP/3 आज़मा सकता है [11]:\nalt-svc: h3=\u0026#34;:443\u0026#34;; ma=86400 CDN आपके लिए CPU ओवरहेड और UDP-फ़ॉलबैक की झंझटें सोख लेता है। मूलतः कोई नुक़सान नहीं है। कर दीजिए।\nआप अपना ख़ुद का nginx / ओरिजिन सर्वर चलाते हैं करने लायक है, पर आँखें खुली रखकर कीजिए। आपको एक ऐसा nginx बिल्ड चाहिए होगा जो QUIC सपोर्ट करे — जिसका ऐतिहासिक रूप से मतलब था QUIC पैच के साथ सोर्स से बिल्ड करना या एक सपोर्टेड फ़ोर्क इस्तेमाल करना [11]। एक न्यूनतम कॉन्फ़िग quic पैरामीटर के साथ एक दूसरी listen लाइन जोड़ती है और सपोर्ट का विज्ञापन देती है:\nlisten 443 quic reuseport; listen 443 ssl; # फ़ॉलबैक के लिए TCP रखें ssl_protocols TLSv1.3; add_header alt-svc \u0026#39;h3=\u0026#34;:443\u0026#34;; ma=86400\u0026#39;; सामान्य TCP listen 443 ssl लाइन भी रखें — वह उन क्लाइंट्स और नेटवर्कों के लिए आपका फ़ॉलबैक है जो QUIC नहीं कर सकते [9]। और अर्ली डेटा चालू करने से पहले 0-RTT के बारे में अच्छे से सोचें [10]। अगर आप एक साफ़ डेटासेंटर नेटवर्क पर एक CPU-भारी, हाई-बैंडविड्थ API सर्व करते हैं, तो इसका बेंचमार्क लें — आप पा सकते हैं कि HTTP/2 असल में आपके लिए सस्ता है [8]।\nआपके यूज़र मोबाइल पर, दूर, या ख़राब नेटवर्क पर हैं यहीं HTTP/3 सबसे ज़्यादा चमकता है। हाई लेटेंसी का मतलब है कि तेज़ हैंडशेक असल में महसूस होने वाला समय बचाता है [3]। लॉसी कनेक्शन का मतलब है कि प्रति-स्ट्रीम स्वतंत्रता आपके पेज को चलता रखती है जबकि एक स्ट्रीम रिकवर होती है [5]। और Wi-Fi और सेल्युलर के बीच स्विच करने वाले मोबाइल यूज़र्स को कनेक्शन माइग्रेशन से सीधा फ़ायदा होता है [6]। अगर आपका ऑडियंस \u0026ldquo;पैची नेटवर्क वाली जगहों में फ़ोन पर लोग\u0026rdquo; है — असल दुनिया का बड़ा हिस्सा — तो HTTP/3 एक साफ़ जीत है।\nआप एक साफ़ नेटवर्क पर एक CPU-बाउंड, हाई-थ्रूपुट बैकएंड चलाते हैं रुकिए। प्रतिबद्ध होने से पहले बेंचमार्क लीजिए। यही एकमात्र समूह है जिसे शायद फ़ायदा न हो। अगर आपके सर्वर CPU-कंस्ट्रेंड हैं और आपका नेटवर्क तेज़ और भरोसेमंद है, तो यूज़रस्पेस QUIC ओवरहेड आपके थ्रूपुट को खा सकता है [8]। अपने असली ट्रैफ़िक से मापिए, किसी के ब्लॉग बेंचमार्क से नहीं (इस वाले समेत)।\nअपनाव असल में कहाँ है बस ताकि आप जानें कि यह कल्पना नहीं है: 2025 के अंत तक HTTP/3 वैश्विक रिक्वेस्ट्स के लगभग 35% पर बैठता है [1]। वृद्धि धीमी हुई है — HTTP/2 और HTTP/3 दोनों ने 2024 की तुलना में 2025 में सिर्फ़ प्रतिशत के अंश ही हासिल किए [1] — और अपनाव क्षेत्र के हिसाब से काफ़ी अलग है, जहाँ 15 देश अपनी एक-तिहाई से ज़्यादा रिक्वेस्ट्स HTTP/3 पर धकेल रहे हैं [1]। सभी बड़े ब्राउज़र इसे सपोर्ट करते हैं, और बड़े CDN इसे चालू करने के लिए तैयार रखते हैं। यह अब मेनस्ट्रीम है, अत्याधुनिक प्रयोग नहीं।\nईमानदार सारांश? HTTP/3 उन परिस्थितियों के लिए एक असली सुधार है जिनके लिए इसे डिज़ाइन किया गया था — लॉसी नेटवर्क, मोबाइल यूज़र्स, हाई लेटेंसी, ढेर सारी छोटी रिक्वेस्ट्स। यह \u0026ldquo;सब कुछ तेज़ कर दो\u0026rdquo; वाला कोई जादुई स्विच नहीं है, और एक साफ़-सुथरे नेटवर्क पर एक CPU-बाउंड सर्विस पर यह चुपचाप आपको महँगा पड़ सकता है। इसे CDN पर चालू कर दीजिए जहाँ यह मुफ़्त और सुरक्षित है। अपने ख़ुद के ओरिजिन पर इसके बारे में सोच-समझकर कीजिए। और चाहे जो हो, POST रिक्वेस्ट्स के लिए 0-RTT चालू करके चलते मत बन जाइए।\nस्रोत HTTP/3 Is at 35% Adoption — DEV Community What is QUIC and HTTP/3? — GeeksforGeeks What is HTTP/3? — Cloudflare HTTP/3 vs HTTP/2 Performance — DebugBear TCP head of line blocking — HTTP/3 explained Connection Migration — quic-go docs TIL: HTTP/3 Is Not Always Faster Than HTTP/2 — Ian Duncan LiteQUIC: Reducing CPU Overhead of QUIC — OpenReview How to Troubleshoot QUIC Protocol Issues Over UDP — OneUptime 0-RTT Replay: The High-Speed Flaw in HTTP/3 — InstaTunnel The End-to-End Playbook: Enabling HTTP/2 and HTTP/3 on Nginx + Cloudflare — DCHost ","permalink":"https://cloudmato.com/hi/posts/understanding-http3-vs-http2-http1/","title":"HTTP/3 को समझना: क्या यह वाकई HTTP/2 से बेहतर है?"},{"content":"क्या आपने कभी किसी React app में कोई button क्लिक किया है और बस\u0026hellip; भरोसा कर लिया है कि UI सही तरीके से update हो जाएगा? हाँ, मैंने भी, सालों तक। मैंने कभी रुककर यह नहीं सोचा कि setState और स्क्रीन पर pixels बदलने के बीच क्या होता है — जब तक मैं एक ऐसे component को debug नहीं करने लगा जो एक ही क्लिक पर पाँच बार re-render हो रहा था। वह rabbit hole मुझे सीधे Fiber, lanes, और इस आश्चर्यजनक रूप से लंबी history में ले गया कि React यह कैसे तय करता है कि आपके app को असल में कब re-render करना है।\nयह article उसी rabbit hole को organized तरीके से पेश करता है। हम देखेंगे कि React असल में अंदर से कैसे काम करता है, React Fiber क्या है और यह क्यों मौजूद है, और फिर यह समझेंगे कि batching — जो यह control करता है कि आपका component कितनी बार re-render होता है — हर release के साथ कैसे बदलती गई है।\nजब आप setState कॉल करते हैं, तो असल में क्या होता है? यहाँ वह बात है जो शायद ही कोई साफ़-साफ़ बताता है: setState (या useState से मिला state setter) कॉल करने से स्क्रीन पर तुरंत कुछ नहीं बदलता। यह बस React को बताता है, \u0026ldquo;अरे, कुछ बदल गया है, शायद तुम्हें इसे फिर से देखना चाहिए।\u0026rdquo;\nइसके बाद एक multi-step प्रोसेस शुरू होता है:\nTrigger — कुछ होता है (एक event, network response, या timer) जो किसी state setter को कॉल करता है। Render — React आपके component functions को फिर से कॉल करता है ताकि यह पता चल सके कि नया UI कैसा दिखना चाहिए। इससे React elements का एक tree बनता है (जिसे अक्सर ढीले-ढाले तौर पर \u0026ldquo;virtual DOM\u0026rdquo; कहा जाता है)। Reconciliation — React नए tree की तुलना पिछले वाले से करता है और यह पता लगाता है कि कम से कम कौन-कौन से बदलाव करने ज़रूरी हैं। Commit — React उन बदलावों को असली DOM पर लागू करता है, effects चलाता है, और browser परिणाम को paint करता है। \u0026ldquo;virtual DOM\u0026rdquo; शब्द बहुत इस्तेमाल होता है, और सच कहें तो अब यह नाम थोड़ा भ्रामक हो गया है। आज React असल में अंदर जो maintain करता है वह Fiber nodes का एक tree है — जो DOM के एक साधारण snapshot से कहीं ज़्यादा rich structure है। हम इस पर थोड़ी देर में आएंगे, क्योंकि यही असल में इस पूरे article का दिल है।\nReconciliation: React की Diffing Trick Fiber की बात आने से पहले, यह समझना ज़रूरी है कि React DOM को इतनी efficiently update क्यों कर पाता है। दो arbitrary trees की node-by-node तुलना करना, computer science के नज़रिए से, एक costly समस्या है — naive tree diffing लगभग n nodes के लिए O(n³) है। यह उस UI library के लिए बहुत slow है जिसे हर keystroke पर चलना पड़ता है।\nइसलिए React कुछ simplifying assumptions के साथ एक heuristic-based algorithm इस्तेमाल करता है [5]:\nअलग-अलग element types अलग-अलग trees बनाते हैं। अगर कोई \u0026lt;div\u0026gt; \u0026lt;span\u0026gt; बन जाता है, तो React उनके children को diff करने की ज़हमत नहीं करता — यह सिर्फ़ पुराने को तोड़कर नया scratch से बना देता है। एक ही element type, एक ही position? React underlying DOM node को रखता है और सिर्फ़ बदले हुए attributes/props को update करता है। Lists को keys की ज़रूरत होती है। जब आप .map() से कोई list render करते हैं, तो React renders के बीच items को match करने के लिए key prop इस्तेमाल करता है। stable keys के बिना (या उससे भी बदतर, जब list reorder हो सकती है तब array index को key के तौर पर इस्तेमाल करने पर), React confuse हो सकता है कि कौन-सा item कौन-सा है — जिससे ऐसे अजीब bugs आते हैं जैसे reorder के बाद form inputs में गलत value रह जाना। React के reconciliation process का यही वह हिस्सा है जिसे ज़्यादातर tutorials cover करते हैं [5]। लेकिन reconciliation अपने आप यह नहीं बताता कि एक बड़े update पर React, browser को freeze किए बिना यह सब काम कैसे कर लेता है। यहीं पर Fiber आता है — और यह उससे कहीं बड़ी बात है जितना ज़्यादातर लोग समझते हैं।\nFiber की एंट्री: वह Rewrite जिसने सब कुछ बदल दिया React 16 से पहले, React वह इस्तेमाल करता था जिसे अब \u0026ldquo;stack reconciler\u0026rdquo; कहा जाता है। यह काम तो करता था, लेकिन इसमें एक बुनियादी समस्या थी: यह recursive और synchronous था। एक बार जब React किसी tree को render करना शुरू कर देता, तो वह खत्म होने तक रुक नहीं सकता था — JavaScript call stack तब तक बढ़ता रहता जब तक पूरा tree process न हो जाए [3][4]।\nछोटे apps के लिए यह ठीक है। आपको कभी फ़र्क महसूस नहीं होगा। लेकिन बड़े component trees के लिए — जैसे हज़ारों rows वाला कोई data grid, या एक complex dashboard — वह synchronous render इतना समय ले सकता था कि main thread दसों milliseconds के लिए block हो जाए। Animations अटकने लगते, scrolling में jank आता, और किसी input में टाइप करना सुस्त लगता, क्योंकि जब तक React अपना काम पूरा नहीं कर लेता, browser कुछ और process ही नहीं कर पाता।\nसितंबर 2017 में, React 16 इस core algorithm के पूरे rewrite के साथ आया, जिसे Fiber कहा गया [2]। Meta की engineering team ने इसे एक \u0026ldquo;API-compatible rewrite\u0026rdquo; बताया — यानी आपके component code को बदलने की ज़रूरत नहीं थी, लेकिन इसके नीचे जो कुछ हो रहा था, वह सब बदल गया [2]।\nअसल में Fiber क्या है? इसे describe करने का सबसे साफ़ तरीका जो मैंने देखा है (React core contributor Andrew Clark के अपने notes से) यह है कि fiber एक \u0026ldquo;virtual stack frame\u0026rdquo; है [3]। JavaScript call stack पर निर्भर रहने के बजाय — जो बिना रुके top से bottom तक execute होता है — React अपना खुद का data structure बनाता है जो एक stack जैसा बर्ताव करता है, लेकिन जिसे React पूरी तरह control करता है।\nहर fiber एक plain JavaScript object होता है जो work की एक unit को represent करता है — मूल रूप से एक component — और इसमें होता है:\ntype और key — यह बताते हैं कि यह किस तरह का component या DOM element है child, sibling, और return pointers — जो tree का एक linked-list representation बनाते हैं (एक typical nested-array tree के बजाय) pendingProps और memoizedProps — आ रहे नए props बनाम पिछली बार के props, यह जांचने के लिए कि असल में कुछ बदला है या नहीं alternate — इस fiber के \u0026ldquo;दूसरे version\u0026rdquo; की तरफ़ इशारा करने वाला pointer (इस पर थोड़ी देर में और बात करेंगे) सच कहूं तो वह alternate pointer ही सबसे clever हिस्सा है। React एक साथ memory में दो trees रखता है: current tree (जो अभी असल में स्क्रीन पर है) और workInProgress tree (जिसे React अगले update के लिए अभी बना रहा है) [4]। जब work-in-progress tree पूरा हो जाता है, तो React सिर्फ़ एक pointer swap कर देता है — work-in-progress, current tree बन जाता है। इसे कभी-कभी \u0026ldquo;double buffering\u0026rdquo; कहा जाता है, और यह वही trick है जो video games आधे-बने frames को दिखाने से बचने के लिए इस्तेमाल करते हैं।\nक्योंकि हर fiber खुद work की एक छोटी unit है, React tree को node-by-node process कर सकता है, और हर node खत्म करने के बाद, रुककर पूछ सकता है: \u0026ldquo;क्या मेरे पास आगे जारी रखने का समय है, या मुझे control browser को वापस दे देना चाहिए?\u0026rdquo; [3][4]। यही एक क्षमता — pause करना, yield करना, और resume करना — बाकी सब कुछ (concurrent rendering, transitions, automatic batching) संभव बनाती है।\nRender Phase बनाम Commit Phase React इस सारे काम को दो phases में बांटता है, जिनके नियम बहुत अलग हैं:\nRender phase — React workInProgress tree पर चलता है, आपके components को कॉल करता है, और पता लगाता है कि क्या बदला है। यह phase pure है (कोई DOM mutations नहीं, कोई side effects नहीं) और interruptible है — अगर कोई ज़्यादा urgent update आता है, तो React इसे pause कर सकता है, इसके काम को छोड़ सकता है, या इसे फिर से शुरू कर सकता है [3][4]। Commit phase — React तैयार हो चुके काम को लेकर असल DOM को mutate करता है, layout effects चलाता है, और refs को update करता है। यह phase synchronous है और इसे interrupt नहीं किया जा सकता — एक बार शुरू होने के बाद, यह पूरा होकर ही खत्म होता है, ताकि यूज़र को कभी आधा-अधूरा updated UI न दिखे [1][4]। Scheduler: हर Update को Priority देना एक बार जब Fiber ने interruptible rendering को संभव बना दिया, तो React को यह तय करने का एक तरीका चाहिए था कि क्या interrupt होगा और क्या priority पाएगा। यही काम scheduler का है — एक अलग package जिसे React अपने core के साथ ship करता है [14]।\nScheduler priority levels को define करता है, हर एक के साथ एक internal timeout होता है जो यह तय करता है कि किसी काम को कब तक टाला जा सकता है, इससे पहले कि React उसे जबरन पूरा करवाए [14]:\nPriority Timeout उदाहरण use case Immediate -1ms (अभी) Synchronous, critical updates User-blocking 250ms टाइप करना, क्लिक करना, drag करना Normal 5,000ms Data fetch के results, non-urgent updates Low 10,000ms Analytics, background sync Idle लगभग कभी नहीं Offscreen content, hidden tabs React 18 में, यह priority system lanes के साथ और भी granular हो गया — एक bitmask-based model जिसमें updates को assign करने के लिए 31 तक अलग-अलग priority \u0026ldquo;lanes\u0026rdquo; हो सकते हैं [9]। practical असर यह है: अगर आप किसी बड़े, low-priority update को render कर रहे हैं (मान लीजिए, किसी विशाल list को filter करना) और यूज़र किसी button पर क्लिक करता है, तो React उस low-priority render को pause कर सकता है, क्लिक को तुरंत handle कर सकता है, और बाद में filtering का काम वापस शुरू कर सकता है [9]। Fiber से पहले, यह architecturally संभव ही नहीं था — एक बार जब React rendering शुरू कर देता, तो वह रुक नहीं सकता था।\nयही useTransition और useDeferredValue की foundation भी है, जिनके बारे में हम जल्द ही बात करेंगे। ये असल में developer के लिए वे levers हैं जिनसे कहा जा सकता है, \u0026ldquo;कृपया इस particular update को low priority के तौर पर treat करो\u0026rdquo; [10]।\nBatching: वह खामोश Optimization जिसे बनने में 10 साल लगे ठीक है, यहीं से चीज़ें असल में दिलचस्प होती हैं — और यहीं ज़्यादातर articles या तो बात को बहुत आसान बना देते हैं या history को पूरी तरह छोड़ देते हैं। Batching React की वह strategy है जिसमें कई state updates को साथ में group किया जाता है, ताकि वे कई बार के बजाय एक ही re-render trigger करें। सुनने में यह आसान लगता है। लेकिन इसका implementation लगभग हर major React release में चुपचाप evolve होता रहा है।\nReact 18 से पहले: Batching सिर्फ़ Event Handlers के अंदर काम करती थी सालों तक, React की batching उसके synthetic event system से जुड़ी रहती थी। अगर आप किसी React event handler (onClick, onChange, आदि) के अंदर कई state setters कॉल करते थे, तो React उन्हें एक ही re-render में batch कर देता था। लेकिन उस context से बाहर निकलते ही — किसी setTimeout, Promise.then(), या raw addEventListener में — batching पूरी तरह काम करना बंद कर देती थी [1][7]।\n// React 17 and earlier function handleClick() { setTimeout(() =\u0026gt; { setCount(c =\u0026gt; c + 1); // triggers a re-render setFlag(f =\u0026gt; !f); // triggers ANOTHER re-render }, 1000); } यह conceptually एक logical update के लिए दो पूरे render-and-commit cycles हैं। दो setState calls के लिए यह कोई बड़ी बात नहीं है, लेकिन मैंने ऐसे real apps देखे हैं जहां एक ही async callback छह या सात state updates fire कर देता था — और हर एक, एक moderately heavy component tree को re-render कर देता था। यह जुड़ता चला जाता है।\nइस limitation की वजह से unstable_batchedUpdates का अस्तित्व था। यह react-dom से export होने वाला एक undocumented API था (इसीलिए वह डरावना unstable_ prefix था) जो किसी callback को manually React के batching context में wrap कर देता था [6]:\nimport { unstable_batchedUpdates } from \u0026#39;react-dom\u0026#39;; setTimeout(() =\u0026gt; { unstable_batchedUpdates(() =\u0026gt; { setCount(c =\u0026gt; c + 1); setFlag(f =\u0026gt; !f); }); // now only ONE re-render }, 1000); अगर आपने कभी Redux, MobX, या Zustand इस्तेमाल किया है, तो आपको इसका फायदा बिना जाने ही मिला है — इन libraries ने अपने store update notifications को खास तौर पर unstable_batchedUpdates में wrap किया था, ताकि \u0026ldquo;external state से कई renders\u0026rdquo; वाली समस्या से बचा जा सके [6]। यह एक ऐसा workaround था जो ecosystem के आधे हिस्से में बेक हो गया था, क्योंकि framework खुद इसे consistently नहीं कर पाता था।\nReact 18: हर जगह Automatic Batching React 18 (मार्च 2022 में release हुआ) ने आखिरकार इसे जड़ से ठीक कर दिया [1]। नए createRoot API के साथ, हर state update अपने-आप, by default batch हो जाता है, चाहे वह कहीं से भी आए — timeouts, promises, native event listeners, जो भी हो [1][8]।\n// React 18+ with createRoot function handleClick() { setTimeout(() =\u0026gt; { setCount(c =\u0026gt; c + 1); setFlag(f =\u0026gt; !f); // Only ONE re-render, automatically }, 1000); } कुछ ज़रूरी details जिनमें लोग अक्सर उलझ जाते हैं:\nआपको createRoot के ज़रिए opt in करना होता है। अगर आपका app अभी भी legacy ReactDOM.render() कॉल करता है, तो आपको automatic batching नहीं मिलती — React backward compatibility के लिए पुराना behavior बनाए रखता है [1]। unstable_batchedUpdates एक no-op बन जाता है। क्योंकि अब सब कुछ automatically batch हो जाता है, वह पुराना API अब\u0026hellip; कुछ खास नहीं करता [6][7]। आप अब भी इससे बाहर निकल सकते हैं react-dom के flushSync का इस्तेमाल करके, उन कुछ rare cases के लिए जहां आपको असल में अगली line of code चलने से पहले DOM को synchronously updated चाहिए (उदाहरण के लिए, state change के ठीक बाद layout measure करना): import { flushSync } from \u0026#39;react-dom\u0026#39;; function handleClick() { flushSync(() =\u0026gt; { setCount(c =\u0026gt; c + 1); }); // DOM has already updated here setFlag(f =\u0026gt; !f); // this one batches normally } सच कहूं तो — React लिखते हुए इन सालों में, मैंने शायद सिर्फ़ दो बार flushSync का इस्तेमाल किया है, दोनों बार state-driven layout change के ठीक बाद DOM nodes को measure करने के लिए। यह एक असली escape hatch है, लेकिन अगर आप इसे बार-बार इस्तेमाल कर रहे हैं, तो आम तौर पर इसका मतलब है कि आपके architecture में कुछ और सोचने की ज़रूरत है।\nReact 18 के Concurrent Features: Transitions और Deferred Values Automatic batching renders की संख्या कम करती है। लेकिन React 18 ने renders की priority control करने के लिए भी tools introduce किए — जो एक related लेकिन अलग optimization है [1]।\nstartTransition / useTransition — इससे आप किसी state update को \u0026ldquo;non-urgent\u0026rdquo; मार्क कर सकते हैं। React इसे background में render करेगा और अगर कोई ज़्यादा urgent चीज़ (जैसे कोई keystroke) आती है, तो इसे interrupt कर सकता है [1][10]। useDeferredValue — एक value लेता है और आपको उसका एक ऐसा version देता है जो urgent renders के दौरान \u0026ldquo;पीछे रह जाता है\u0026rdquo;, जो debouncing जैसा ही है, लेकिन किसी arbitrary timer के बिना [1]। const [query, setQuery] = useState(\u0026#39;\u0026#39;); const [isPending, startTransition] = useTransition(); function handleChange(e) { setQuery(e.target.value); // urgent: keep the input snappy startTransition(() =\u0026gt; { setSearchResults(filterHugeList(e.target.value)); // low priority }); } Batching से इसका फ़र्क subtle लेकिन ज़रूरी है: batching का मतलब है updates को जोड़कर कम renders में बदलना, जबकि transitions का मतलब है किसी render को deprioritize करना ताकि वह ज़्यादा urgent renders को block न करे [9][10]। दोनों आखिर में इसलिए मौजूद हैं क्योंकि सबसे पहले Fiber ने rendering को interruptible बनाया — उस बुनियादी rewrite के बिना, इनमें से कोई भी संभव नहीं होता।\nReact 19 और 19.2: Actions, Compiler, और SSR Batching React 19 (दिसंबर 2024) ने batching में React 18 जैसा बड़ा बदलाव नहीं किया, लेकिन यह उसी foundation पर आगे बनता रहा [11]:\nActions API (useActionState, useFormStatus, useOptimistic) — इनसे आप async functions को सीधे \u0026lt;form action={...}\u0026gt; को pass कर सकते हैं। अंदर ही अंदर, React pending state को automatically manage करता है, उससे बनने वाले updates को batch करता है, और सफल होने पर form को reset कर देता है — और इसके लिए आपको manually loading flags track करने की ज़रूरत नहीं पड़ती [11]। const [error, submitAction, isPending] = useActionState( async (previousState, formData) =\u0026gt; { const error = await updateName(formData.get(\u0026#39;name\u0026#39;)); if (error) return error; return null; }, null, ); React Compiler — यह overall rendering performance के लिए एक बड़ी बात है, भले ही यह strictly \u0026ldquo;batching\u0026rdquo; न हो। यह अक्टूबर 2025 में version 1.0 तक पहुंचा [13]। यह compiler build time पर चलता है और automatically memoization डाल देता है — वही optimization जो आप पहले useMemo, useCallback, और React.memo से hand-write करते थे — जिससे components, जब उनके inputs असल में नहीं बदले हों, तो re-render होने को skip कर देते हैं [13]। यह Meta में production में चल रहा है, और React team ने Vite, Next.js, और Expo के साथ partner किया है ताकि नए projects इसे by default चालू कर सकें [13]। सच कहूं तो, यह उस सब चीज़ का स्वाभाविक अंत लगता है जो Fiber ने शुरू की थी: पहले rendering को interruptible और schedulable बनाओ, फिर इसे efficiently batch करो, और आखिर में — बस ज़रूरत से ज़्यादा काम को पूरी तरह skip कर दो।\nReact 19.2 (अक्टूबर 2025) ने batching को server rendering में भी बढ़ा दिया। Streaming SSR के दौरान, Suspense boundary reveals अब एक छोटी window के लिए batch हो जाते हैं, ताकि कई boundaries जो आसपास resolve होते हैं उन्हें एक-एक करके भेजने के बजाय client को साथ में भेजा जा सके — जो client के behave करने के तरीके से भी बेहतर मेल खाता है [12]। इस release में नया \u0026lt;Activity /\u0026gt; component (UI को hide/restore करते हुए state को preserve रखने के लिए), useEffectEvent, और \u0026ldquo;Performance Tracks\u0026rdquo; भी आए — एक Chrome DevTools integration जो scheduler के priority decisions को सीधे Performance panel में visualize करता है [12]।\nसब कुछ एक साथ: एक नज़र में पूरा Evolution Version साल Rendering/Batching के लिए क्या बदला ≤ React 15 — Stack reconciler — synchronous, non-interruptible recursion [3][4] React 16 2017 Fiber rewrite — interruptible render phase, double-buffered tree, priority-aware scheduling [2][3] React 16–17 2017–2020 Batching सिर्फ़ React event handlers के अंदर; manual workaround के तौर पर unstable_batchedUpdates [6][7] React 18 2022 हर जगह automatic batching (createRoot के ज़रिए), flushSync opt-out, lanes-based concurrent rendering, useTransition/useDeferredValue [1][9] React 19 2024 Actions API async updates के आसपास pending/optimistic state को auto-manage करता है [11] React 19.2 2025 SSR में Suspense boundary reveals batch होते हैं; \u0026lt;Activity /\u0026gt;, scheduler priorities को visualize करने के लिए Performance Tracks [12] React Compiler 1.0 2025 Build-time automatic memoization — manual useMemo/useCallback के बिना re-renders skip करता है [13] आपके लिए यह सब क्यों मायने रखता है अगर आप सिर्फ़ forms और dashboards बना रहे हैं, तो आप सोच सकते हैं, \u0026ldquo;ठीक है, लेकिन मुझे कभी flushSync या unstable_batchedUpdates की ज़रूरत नहीं पड़ी, तो यह क्यों मायने रखता है?\u0026rdquo;\nबात सही है। लेकिन practice में यह असल में यहां लोगों को परेशान करता है:\n\u0026ldquo;यह दो बार render क्यों हुआ?\u0026rdquo; को debug करना हर React developer के लिए एक rite of passage है, और इसका जवाब लगभग हमेशा batching behavior में ही छुपा होता है — development में Strict Mode द्वारा effects को double-invoke करना, या किसी batched context के बाहर होने वाला update। ReactDOM.render() से createRoot पर migrate करना सिर्फ़ एक version bump नहीं है — यह चुपचाप बदल देता है कि आपका app updates को कैसे batch करता है। अगर आपके app ने कहीं synchronous re-renders पर भरोसा किया था (चाहे जानबूझकर या नहीं), तो automatic batching उन assumptions को सामने ला सकती है। lanes और priorities के बारे में जानने के बाद Performance debugging कहीं ज़्यादा समझ में आती है। जब आप React DevTools का profiler खोलते हैं — या अब, Chrome DevTools के Performance Tracks [12] — और देखते हैं कि renders interrupt या defer हो रहे हैं, तो यह कोई bug नहीं है। यह scheduler ठीक वही कर रहा है जिसके लिए उसे design किया गया है। useTransition और useDeferredValue तभी समझ में आते हैं जब आपको पता हो कि React का render phase interruptible है। Fiber के बिना, इनमें से कोई भी hook मौजूद नहीं हो सकता था — \u0026ldquo;interrupt\u0026rdquo; करने के लिए कुछ होता ही नहीं। इस पूरे arc को पीछे मुड़कर देखने पर मुझे जो बात सबसे ज़्यादा चौंकाती है, वह यह है कि इसमें से ज़्यादातर हिस्सा design से ही invisible है। आप ऐसा कोई code नहीं लिखते जो कहे \u0026ldquo;use Fiber\u0026rdquo;। आप explicitly \u0026ldquo;lanes\u0026rdquo; को invoke नहीं करते। इस दशक-भर लंबे rewrite का पूरा मकसद यही था कि React, developers से scheduling के बारे में सोचने को कहे बिना ही तेज़ महसूस हो — और ज़्यादातर मामलों में, यह कामयाब रहा। जो चीज़ें पहले careful manual batching की मांग करती थीं (unstable_batchedUpdates, debounced inputs, manual shouldComponentUpdate checks), वे अब हर release के साथ बढ़ते-बढ़ते बस\u0026hellip; अपने-आप काम करने लगी हैं।\nशायद React Compiler के और mature होने के साथ, अगला \u0026ldquo;दशक-भर लंबा arc\u0026rdquo; manual memoization को हटाने के बारे में होगा, उसी तरह जैसे React 18 ने manual batching को हटाया था। देखते हैं।\nस्रोत React v18.0 – React Blog React 16: हमारी frontend UI library के rewrite की एक झलक – Meta Engineering React Fiber Architecture – acdlite/react-fiber-architecture (GitHub) Inside Fiber: React के नए reconciliation algorithm का in-depth overview – AG Grid Blog ReactJS Reconciliation – GeeksforGeeks क्या आप React में unstable_batchedUpdates के बारे में जानते हैं? – DEV Community React 18 में automatic batching जुड़ी – Saeloun Blog React 18 में Automatic Batching क्या है – GeeksforGeeks React 18 में Concurrent Rendering और Lane Prioritization – Jim\u0026rsquo;s Blog useTransition – React Reference Documentation React 19 – React Blog React 19.2 – React Blog React Compiler v1.0 – React Blog packages/scheduler/src/forks/Scheduler.js – facebook/react (GitHub) ","permalink":"https://cloudmato.com/hi/posts/how-react-works-fiber-and-batch-rendering-explained/","title":"React असल में कैसे काम करता है: Fiber और Batch Rendering की पूरी समझ"},{"content":"क्या आपने कभी किसी प्रोजेक्ट का CSS खोला है और पाया है कि font sizes px, em, rem, %, और vw में सेट हैं — सब एक ही फ़ाइल में, कभी-कभी एक ही element पर? हाँ, मेरे साथ भी ऐसा हुआ है। Font size, CSS की सबसे boring property लगती है, जब तक आपको यह पता नहीं चलता कि इसे express करने के कम से कम आठ अलग-अलग तरीके हैं, और गलत तरीका चुनने से आपके यूज़र्स के एक हिस्से के लिए accessibility चुपचाप टूट जाती है, बिना एक भी error दिखाए।\nइस article की ज़रूरत आखिर क्यों है मैं सोचता था कि font-size: 16px; ही पूरी कहानी है। एक नंबर चुनो, उस पर px लगाओ, हो गया। मुझे यह समझने में एक support ticket लगा, जो एक ऐसे यूज़र से आया था जिसने अपने browser का default font size बढ़ाकर 24px कर दिया था — और पाया कि मेरी \u0026ldquo;responsive\u0026rdquo; साइट ने इसे पूरी तरह नज़रअंदाज़ कर दिया — तब मुझे पता चला कि मैं कितना गलत था।\nआप font-size के लिए जो unit चुनते हैं, वह सिर्फ़ एक styling decision नहीं है। यह एक accessibility decision है। कुछ units वह सम्मान करते हैं जो browser और यूज़र ने configure किया है। कुछ को इससे कोई फ़र्क ही नहीं पड़ता। कुछ स्क्रीन साइज़ में बहुत अच्छे से scale होते हैं। कुछ को सही तरीके से काम करने के लिए तीन media queries चाहिए। आइए इन सबको उस क्रम में देखते हैं, जिस क्रम में मैं असल में इन्हें इस्तेमाल करता हूँ।\nAbsolute units: px और वो size keywords जिन्हें कोई इस्तेमाल नहीं करता Pixels — वही जिससे हर कोई शुरुआत करता है font-size: 16px एक absolute length है। एक CSS pixel एक fixed reference unit है — यह parent element, viewport, या (यह सबसे ज़रूरी हिस्सा है) यूज़र की browser settings के आधार पर नहीं बदलता [1]।\nh1 { font-size: 32px; } p { font-size: 16px; } यह predictable है, और यही वजह है कि यह लुभावना लगता है। जो आप design करते हैं, वही आपको मिलता है — आपके monitor पर, default zoom पर। समस्या तब सामने आती है जब किसी के पास आपका exact setup नहीं होता: कम दृष्टि वाला कोई यूज़र जिसने अपनी browser settings में \u0026ldquo;default font size\u0026rdquo; 16px से 24px कर दिया है, उसे\u0026hellip; कुछ नहीं मिलता। 16px, 16px ही रहता है, क्योंकि px उस preference को सुनता ही नहीं [1]।\nKeyword units — medium, x-large, और इनके दोस्त यह CSS का एक ऐसा कोना है जिसे ज़्यादातर developers ने कभी छुआ ही नहीं। Spec असल में absolute-size keywords define करता है: xx-small, x-small, small, medium, large, x-large, xx-large, और (हाल ही में) xxx-large। ये एक internal table से map होते हैं जिसे browser maintain करता है, और जो यूज़र के default font size (medium) के आसपास index होती है [2]।\nइसके अलावा relative-size keywords भी हैं — smaller और larger — जो parent element के computed size से, आम तौर पर 1.2 से 1.5 के बीच के factor से, ऊपर या नीचे scale होते हैं [2]।\nsmall { font-size: smaller; } .fine-print { font-size: x-small; } सच कहूं तो, मैंने इन्हें असली codebases में लगभग कभी इस्तेमाल होते नहीं देखा। ये early web की एक निशानी हैं, rem के आने से पहले के समय की, जब \u0026ldquo;इसे यूज़र की preferences के हिसाब से size करो\u0026rdquo; कहने का कोई साफ़ तरीका नहीं था। इनका वजूद जानना फायदेमंद है, मुख्यतः इसलिए कि जब आप 2009 के किसी legacy stylesheet में इन्हें देखें, तो आप इन्हें पहचान सकें।\nवो relative units जो असल में किसी चीज़ का जवाब देते हैं यहीं से यह दिलचस्प होता है — और यहीं असली misconceptions छिपे हैं।\nem — parent के font size के हिसाब से em का मतलब है \u0026ldquo;इस element के computed value के font-size के हिसाब से, जिसका मतलब आम तौर पर parent के font-size से होता है\u0026rdquo; [3]। तो किसी child पर font-size: 1.5em का मतलब है \u0026ldquo;मेरे parent का font-size जो भी resolve हुआ है, उसका 1.5 गुना।\u0026rdquo;\nसुनने में हानिरहित लगता है। यहीं यह tricky हो जाता है: अगर हर nested level em इस्तेमाल करता है, तो sizes एक के ऊपर एक जुड़ती (compound) चली जाती हैं।\nhtml { font-size: 16px; } /* root = 16px */ section { font-size: 1.25em; } /* 1.25 × 16px = 20px */ article { font-size: 1.25em; } /* 1.25 × 20px = 25px ← compounding! */ p { font-size: 1.25em; } /* 1.25 × 25px = 31.25px */ वह \u0026lt;p\u0026gt; अब 31px से ज़्यादा पर render हो रहा है, जबकि आप शायद 20px के आसपास कुछ चाहते थे। यह कोई जानबूझकर नहीं करता — यह सिर्फ़ इस वजह से होता है कि nesting कैसे काम करती है, और यही वह सबसे common वजह है जिसकी वजह से लोग font-size के लिए em को पूरी तरह छोड़ देते हैं।\nइसके बावजूद, em बेकार नहीं है — यह उन चीज़ों के लिए वाकई बढ़िया है जिन्हें अपने ही element के font size के साथ scale होना चाहिए, जैसे किसी button पर padding, line-height, या letter-spacing। अगर button का text बड़ा हो जाता है, तो आप शायद चाहेंगे कि padding भी proportionally बढ़े। बस em-based font sizes को पाँच levels की nesting में chain मत कीजिए और फिर sanity की उम्मीद मत रखिए।\nrem — root के हिसाब से, और एक default recommendation के सबसे करीब rem का मतलब है \u0026ldquo;root em\u0026rdquo;। यह हमेशा \u0026lt;html\u0026gt; element के font-size के हिसाब से होता है, चाहे element कितनी भी गहराई में nested हो [3]। पिछले example को फिर से लिखते हैं:\nhtml { font-size: 16px; } /* 1rem = 16px, always */ section { font-size: 1.25rem; } /* 20px */ article { font-size: 1.25rem; } /* 20px — no compounding */ p { font-size: 1.25rem; } /* 20px */ हर 1.25rem का मतलब 20px है, चाहे वह DOM में कहीं भी हो। यही predictability वह वजह है जिसकी वजह से rem, font sizes, spacing, और ज़्यादातर layout dimensions के लिए de-facto recommendation बन गया है [4]।\nलेकिन rem के अहम होने की असली वजह predictability से आगे जाती है — यह यूज़र का सम्मान करने की बात है। अगर कोई अपने browser का default font size 16px के बजाय 20px कर देता है, तो आपकी साइट पर हर rem-based value automatically, proportionally scale हो जाती है, बिना कोई extra code लिखे [5]। px के साथ, उस यूज़र की preference को बस\u0026hellip; नज़रअंदाज़ कर दिया जाता है।\nPercentages — em का शांत कज़िन font-size: 80%, em जैसा ही काम करता है — यह parent के computed font-size के हिसाब से होता है, और nested elements में उसी तरह compound होता है [3]। आपको यह सबसे ज़्यादा html { font-size: 62.5%; } जैसी tricks में दिखेगा (ताकि mental math आसान हो जाए और 1rem = 10px हो जाए), या उन पुराने stylesheets में जो rem को solid browser support मिलने से पहले के हैं।\nsmaller और larger — भुला दिए गए relative keywords पहले भी इसका ज़िक्र हुआ है, लेकिन यहाँ दोहराना ज़रूरी है: smaller और larger relative-size keywords हैं जो context के आधार पर, लगभग 1.2× से 1.5× तक, parent के computed size से font size को ऊपर या नीचे करते हैं [2]। \u0026lt;small\u0026gt; या \u0026lt;sup\u0026gt;-जैसे elements के लिए कभी-कभी उपयोगी हैं, लेकिन आज के component-based CSS में दुर्लभ हैं, जहाँ आप शायद design token का इस्तेमाल करेंगे।\nViewport units — स्क्रीन के हिसाब से ही text को size करना vw (viewport width), vh (viewport height), vmin, और vmax, चीज़ों को browser के viewport dimensions के हिसाब से size करते हैं। 1vw = viewport की width का 1%। तो:\nh1 { font-size: 5vw; } 1000px-wide viewport पर, यह 50px का heading है। 1920px के viewport पर, यह 96px है। यह स्क्रीन साइज़ के साथ continuously scale होता है — किसी breakpoints की ज़रूरत नहीं।\nसुनने में बढ़िया लगता है, है ना? यहाँ पेंच यह है: सिर्फ़ viewport units, font-size के लिए खतरनाक हैं। किसी छोटी phone स्क्रीन पर, 5vw आपके body text को इतना छोटा कर सकता है कि वह पढ़ा ही न जा सके। किसी ultrawide monitor पर, यह किसी paragraph को 80px के text में फुला सकता है। और एक छिपी हुई समस्या भी है — सिर्फ़ vw में size किया गया text, कुछ setups में यूज़र की font-size zoom preference का सही जवाब नहीं देता, क्योंकि text-only zoom लगाने पर viewport dimensions बदलते नहीं हैं [6]।\nतो सिर्फ़ viewport units, body text के लिए लगभग कभी सही चुनाव नहीं हैं। ये अगली चीज़ के लिए एक building block हैं।\nclamp() — वह function जो viewport units को असल में इस्तेमाल लायक बनाता है clamp(min, preferred, max), बिना किसी शक के, वह unit/function combo है जिसकी तरफ़ मैं अब किसी भी नए प्रोजेक्ट में सबसे पहले जाता हूँ। यह तीन values लेता है — एक minimum, एक preferred (अक्सर viewport-based) value, और एक maximum — और जो भी value आपको floor और ceiling के बीच रखे, उसे चुन लेता है [7]।\nh1 { font-size: clamp(2rem, 1.5rem + 3vw, 4rem); } इसे इस तरह पढ़ें: \u0026ldquo;2rem (32px) से नीचे कभी मत जाओ। 4rem (64px) से ऊपर कभी मत जाओ। बीच में, viewport width के आधार पर fluidly scale करो।\u0026rdquo; एक लाइन उस चीज़ की जगह ले लेती है जिसके लिए पहले चार या पाँच media queries लगती थीं [8]।\nकुछ practical नोट्स जो मैंने कई projects में clamp() इस्तेमाल करते हुए सीखे हैं:\nmin/max के लिए rem को preferred value के लिए vw के साथ combine करें। इससे आपकी floor और ceiling, यूज़र की font-size preference से जुड़ी रहती हैं, जबकि बीच का हिस्सा fluidly scale होता रहता है [8]। clamp() एक tool है, कोई जादुई fix नहीं — अगर आपका minimum बहुत छोटा है, तो low-vision यूज़र्स अब भी इसे पढ़ नहीं पाएंगे, और अगर आपका maximum बहुत छोटा है, तो यह उन यूज़र्स की मदद नहीं करता जो किसी वजह से zoom in करते हैं [7]। min() और max() अलग-अलग भी मौजूद हैं, उन मामलों के लिए जब आपको सिर्फ़ एक bound की परवाह हो। font-size: min(8vw, 3rem), किसी heading को 3rem पर cap कर देता है लेकिन छोटी स्क्रीन्स पर इसे छोटा होने देता है। ch, ex, और वो units जिन्हें text की ही परवाह है दो अजीब-से units जिनके बारे में जानना ज़रूरी है:\nch current font में \u0026ldquo;0\u0026rdquo; character की width पर आधारित है। इसका इस्तेमाल असल में font-size के लिए नहीं होता, लेकिन यह इसका perfect साथी है — max-width: 66ch, किसी paragraph को लगभग हर line में 50–75 characters पर रखता है, जिसे readability के लिए सबसे ज़्यादा माना जाने वाला sweet spot कहा जाता है [9]। ex font की x-height पर आधारित है (मोटे तौर पर lowercase \u0026ldquo;x\u0026rdquo; की height)। इस पर भरोसा करने लायक consistency से support मिलना दुर्लभ है, लेकिन कभी-कभी आपको यह typography-heavy designs में दिखेगा। article p { font-size: clamp(1rem, 0.95rem + 0.3vw, 1.125rem); line-height: 1.6; max-width: 66ch; } यह combo — fluid font size, generous line-height, और ch-based max-width — अब किसी भी long-form text block के लिए मूल रूप से मेरी पहली पसंद है। Line-height लगभग 1.5–1.6 आमतौर पर recommended baseline है, और 75 characters से लंबी lines के लिए इसे ज़्यादा (1.6–1.7) रखा जाता है [9]।\nContainer query units — स्क्रीन के बजाय component के box के हिसाब से size करना यह वाला नया है, और मैं मानता हूँ कि मैंने इसे पिछले साल या उसके आसपास ही इस्तेमाल करना शुरू किया। Container query units (cqw, cqh, cqi, cqb, cqmin, cqmax) बिल्कुल viewport units जैसे काम करते हैं, सिवाय इसके कि ये पूरे browser viewport के बजाय, आपके द्वारा चुने गए एक containing element के हिसाब से होते हैं [10]।\n.card { container-type: inline-size; } .card h2 { font-size: clamp(1rem, 4cqi, 1.5rem); } यह क्यों ज़रूरी है? क्योंकि वही \u0026lt;h2\u0026gt;, एक full-width hero section में या एक narrow sidebar widget में हो सकता है। Viewport units इस फ़र्क को नहीं समझ सकते — उन्हें सिर्फ़ browser window के बारे में पता होता है। Container query units उस heading को उसकी असली उपलब्ध जगह के हिसाब से size करने देते हैं, जो component-driven design systems के लिए बहुत बड़ी बात है [11]।\ncqw = query container की width का 1% cqi = container के inline size का 1% (writing-mode aware — आम तौर पर cqw के बजाय इसे prefer करें) [10] cqb = block size का 1% cqmin / cqmax = inline और block sizes में से जो छोटा/बड़ा हो viewport units की तरह ही, इन्हें भी clamp() में wrap करें ताकि किसी tiny sidebar में squeeze किया गया component, 4px के text में न बदल जाए [10]। CSS containment spec के ज़रिए evergreen browsers में browser support पहले से ही ठीक है, लेकिन फिर भी मैं उस पर test करने की सलाह दूँगा जो आपके analytics के मुताबिक आपके यूज़र्स असल में इस्तेमाल कर रहे हैं।\nrem बनाम px की लड़ाई — मेरी असली राय मैंने इस पर बहुत सारे opinions पढ़े हैं, और आख़िर में मैं यहाँ पहुँचा हूँ।\nBrowser zoom और \u0026ldquo;default font size\u0026rdquo; setting दो अलग-अलग चीज़ें हैं, और लोग अक्सर इन्हें मिला देते हैं [6]:\nMechanism यह क्या करता है px पर असर rem पर असर Browser zoom (Ctrl/Cmd + / -) पूरे page को proportionally scale करता है — layout, images, सब कुछ समान रूप से बड़ा होता है समान रूप से बड़ा होता है \u0026ldquo;Default font size\u0026rdquo; preference 1rem (और medium keyword) किस value में resolve होगा, उसे बदलता है कोई असर नहीं Proportionally scale होता है तो अगर कोई यूज़र पूरे page को 150% zoom करता है, तो 16px वाला element और 1rem वाला element दोनों 50% बड़े हो जाते हैं — यहाँ कोई फ़र्क नहीं है [6]। लेकिन अगर कोई यूज़र अपनी browser settings में जाकर default font size 16px से 24px कर देता है (एक ऐसी setting जिस पर कई low-vision यूज़र्स permanently, बिना कुछ zoom किए, निर्भर रहते हैं), तो rem-based sizes उस बदलाव के साथ scale होते हैं, जबकि px-based sizes बिल्कुल नहीं बदलते [4][5]।\nअसल में, यही पूरी दलील है। ऐसा नहीं है कि px \u0026ldquo;गलत\u0026rdquo; है — बात यह है कि px चुपचाप आपके text को एक खास accessibility preference से बाहर कर देता है, और ज़्यादातर developers को इस बात का अंदाज़ा ही नहीं होता कि यह preference मौजूद है, क्योंकि उन्हें इसका इस्तेमाल करने की कभी ज़रूरत ही नहीं पड़ी।\nमेरा practical नियम, जो उन ज़्यादातर accessibility-focused writers की राय से मिलता है जिन पर मैं भरोसा करता हूँ:\nfont sizes, padding, margins, और text से जुड़ी हर चीज़ के लिए rem इस्तेमाल करें — यह यूज़र की preferences का सम्मान करता है [4][5]। उन चीज़ों के लिए px इस्तेमाल करें जिन्हें text scaling से बेपरवाह visually crisp रहना चाहिए — 1px borders, box-shadow offsets, outline widths। अगर किसी ने अपना font size बढ़ा दिया और कोई 1px border अचानक 1.5px बन जाए, तो वह बस टूटा हुआ दिखेगा। html { font-size: 16px; } को hardcode करने के बजाय html { font-size: 100%; } सेट करें (या इसे बिल्कुल छुएं ही नहीं) — बाद वाला असल में यूज़र के browser default को override कर देता है, जो पूरी बात का मतलब ही खत्म कर देता है। 16px वाला gotcha जिसका डिज़ाइन से कोई लेना-देना नहीं यह एक मज़ेदार वाला है जिसने मुझे एक mobile-first प्रोजेक्ट में परेशान किया। हमारे पास एक स्लीक, compact login form था — input fields को 14px में styled किया गया था क्योंकि डिज़ाइन में tight, minimal लुक चाहिए था। Desktop पर, बिल्कुल सही। iPhones पर, जब भी कोई input field पर tap करता, Safari पूरे पेज को zoomed-in view में खींच लेता, जैसे वह \u0026ldquo;मदद\u0026rdquo; करने की कोशिश कर रहा हो।\nपता चला कि यह iOS Safari का एक जानबूझकर किया गया accessibility behavior है: अगर किसी input field का computed font-size 16px से कम है, तो Safari मान लेता है कि टाइप करते समय इसे आराम से पढ़ना मुश्किल होगा, और जब वह field focus में आती है तो viewport को auto-zoom कर देता है [12][13]। यह बरसों से ऐसा ही है, और यह iOS-specific है — Android browsers ऐसा नहीं करते [12]।\nFix लगभग शर्मनाक रूप से simple था:\ninput, textarea, select { font-size: 16px; /* या 1rem, यह मानते हुए कि root 16px है */ } बस इतना ही। जैसे ही हर form field 16px या उससे बड़ा रेंडर होने लगा, auto-zoom पूरी तरह बंद हो गया। पेंच यह है कि यह threshold computed, rendered size को चेक करता है — तो अगर आप किसी वजह से किसी form पर transform: scale() लगा रहे हैं, तो इससे भी यह तय होता है कि zoom चालू होगा या नहीं [13]। यह उन चीज़ों में से एक है जिसका आपकी visual design preferences से कोई लेना-देना नहीं है, और सब कुछ एक platform quirk से जुड़ा है — और यह ठीक वैसा bug है जो किसी real device पर टेस्ट करने तक नज़र ही नहीं आता।\nBrowser से आगे — दूसरे platforms इसे कैसे देखते हैं अगर आप सिर्फ़ web के लिए नहीं बनाते, तो font-size units दूसरी जगहों पर थोड़े अलग दिखते हैं, लेकिन असली tension — fixed बनाम user-scalable — हर जगह एक जैसा है:\nAndroid में dp (density-independent pixels) और sp (scale-independent pixels) हैं। ये डिफ़ॉल्ट रूप से identical हैं, लेकिन जब यूज़र अपनी system font-size preference बदलता है तो sp scale होता है, जबकि dp नहीं होता [14][15]। Android की अपनी accessibility guidance इस बारे में साफ़ है: text sizes sp में होनी चाहिए, बस यही नियम है, वरना system-wide \u0026ldquo;make text bigger\u0026rdquo; सेटिंग आपकी स्क्रीन्स के लिए चुपचाप कुछ नहीं करती [14]। iOS Dynamic Type पर निर्भर करता है, जहाँ text styles (जैसे .body या .headline) semantic categories हैं जो यूज़र के चुने हुए text size के आधार पर साथ में scale होते हैं — यह hardcoded points की तुलना में, semantic class names के साथ rem इस्तेमाल करने की भावना के ज़्यादा करीब है। Design systems और frameworks आम तौर पर rem को ही default के रूप में शामिल करते हैं। उदाहरण के लिए, Tailwind CSS अपनी पूरी type scale rem में ship करता है, जिसमें text-base, font-size: 1rem; line-height: 1.5rem से मैप होता है, जो default root size पर 16px/24px के बराबर होता है [16]। अगर आपने कभी सोचा है कि Tailwind के spacing नंबर 16 के fractions जैसे क्यों दिखते हैं, तो यही इसकी वजह है। हर platform पर pattern एक जैसा है: एक absolute unit होता है (px, dp, pt) और एक scalable unit (rem, sp, Dynamic Type), और scalable वाला ही वह है जो यूज़र की मांग का सम्मान करता है।\nअब मैं असल में क्या करता हूँ कई प्रोजेक्ट्स में इस पर आगे-पीछे सोचने के बाद, यह वह सेटअप है जिस पर मैं डिफ़ॉल्ट रूप से जाता हूँ:\nroot font-size को छुएं नहीं (100% / browser default), इसे 16px पर hardcode न करें। base font sizes और spacing tokens को rem में रखें, और एक बार CSS custom properties के रूप में define करें — --font-size-base: 1rem; --font-size-lg: 1.25rem; — ताकि पूरा scale एक ही जगह से adjustable हो। hero headings और उन सभी चीज़ों के लिए जिन्हें स्क्रीन साइज़ की एक बड़ी रेंज में scale होना है, rem bounds और vw-based middle के साथ clamp() इस्तेमाल करें। उन components के लिए जो बहुत अलग-अलग layout contexts (cards, sidebars, widgets) में reuse होते हैं, clamp() में wrap किए गए container query units (cqi) इस्तेमाल करें। readability के लिए body text को max-width: 66ch और line-height: 1.5–1.6 के साथ pair करें। सभी form inputs को कम से कम 1rem/16px पर रखें, कोई अपवाद नहीं — इस एक लाइन ने मुझे iOS zoom bug से एक से ज़्यादा बार बचाया है। raw px को borders, shadows, और अन्य पूरी तरह decorative details के लिए रिज़र्व रखें जिन्हें text scale होने पर हिलना नहीं चाहिए। उस चीज़ के लिए यह बहुत सारे units हैं जो पहले बस \u0026ldquo;एक नंबर चुनो\u0026rdquo; हुआ करती थी। लेकिन एक बार जब आप देख लेते हैं कि कोई साइट किसी ऐसे व्यक्ति के लिए बेकार हो गई जिसने सिर्फ़ एक browser setting बदली थी जिसके होने का ज़्यादातर developers को पता ही नहीं है, तो \u0026ldquo;बस एक नंबर चुनो\u0026rdquo; काफ़ी नहीं लगता।\nस्रोत font-size - CSS: Cascading Style Sheets | MDN CSS type - MDN Web Docs CSS Units गाइड - rem, em, px, vh, vw समझाया गया | Saeloun Blog REM? PX? दोनों क्यों नहीं? Accessibility: px या rem? Totally remdom, या Browsers टेक्स्ट को कैसे Zoom करते हैं - Manuel Matuzovic Viewport के आधार पर CSS clamp() से font-size को Linearly Scale करें | CSS-Tricks CSS Clamp का उपयोग करके Modern Fluid Typography — Smashing Magazine Readability के लिए Optimal Line Length: 50–75 Character Rule समझाया गया | UXPin CSS Container Query Units CSS container queries - MDN Web Docs 16px या उससे बड़ा Text iOS Form Zoom को रोकता है | CSS-Tricks Defensive CSS - iOS Safari पर Input zoom Text Scaling - Android Accessibility सहायता Android UI Design में dp और sp Font Size - Tailwind CSS ","permalink":"https://cloudmato.com/hi/posts/every-way-to-set-font-size-in-ui/","title":"UI में Font Size सेट करने के हर तरीके (और कौन सा जीतता है)"},{"content":"किसी भी डोमेन की DNS सेटिंग्स खोलिए और आपको रहस्यमय कोड्स की एक पूरी दीवार दिखेगी — A, AAAA, MX, TXT, SRV, CAA, SVCB — और सच में ऐसा लगता है जैसे किसी ने एक पुराने इंजन में बेतरतीब हिस्से जोड़ते-जोड़ते इसे बना दिया हो। और ईमानदारी से कहें तो, असल में यही हुआ है। ये सभी रिकॉर्ड टाइप्स इसलिए बने क्योंकि इंटरनेट किसी ऐसी दीवार से टकराया जिसे मौजूदा रिकॉर्ड्स पार नहीं कर सकते थे, और जब आप यह पूरी कहानी सिलसिलेवार देखते हैं, तो यह सारी गड़बड़ी असल में समझ में आने लगती है।\nअच्छा, तो DNS रिकॉर्ड आखिर है क्या? टाइमलाइन से पहले एक छोटा रिफ्रेशर ले लेते हैं, क्योंकि आगे आने वाली हर चीज़ के लिए यह ज़रूरी है।\nDNS इंटरनेट की फोनबुक है [1]। इस फोनबुक की हर एंट्री एक \u0026ldquo;रिसोर्स रिकॉर्ड\u0026rdquo; होती है, और हर रिकॉर्ड — टाइप कोई भी हो — वही बेसिक स्ट्रक्चर फॉलो करता है जो नवंबर 1987 में RFC 1035 में तय किया गया था [2]:\nexample.com. 3600 IN A 192.0.2.10 | | | | | name TTL class type data नाम (name), टाइम-टू-लिव (TTL), क्लास (class) (लगभग हमेशा \u0026ldquo;इंटरनेट\u0026rdquo; के लिए IN — अब इसके अलावा कोई और इस्तेमाल नहीं करता), टाइप (type), और फिर डेटा जिसका फॉर्मेट पूरी तरह टाइप पर निर्भर करता है। यहाँ असली कहानी type फील्ड की है। यह बस एक नंबर है। IANA के पास एक रजिस्ट्री है जो बताती है कि कौन सा नंबर किसका मतलब रखता है [16], और उसके बाद आने वाला डेटा इस नंबर के आधार पर पूरी तरह अलग तरीके से समझा जाता है।\nतो जब लोग पूछते हैं \u0026ldquo;इतने सारे DNS रिकॉर्ड टाइप्स क्यों हैं\u0026rdquo;, तो ईमानदार जवाब यह है: क्योंकि type फील्ड को शुरू से ही एक्सटेंड किए जाने के लिए डिज़ाइन किया गया था। यह बेसिकली एक प्लग-इन सिस्टम है। जब भी इंटरनेट को किसी नई चीज़ को ढूंढने की ज़रूरत पड़ी — एक मेल सर्वर, एक IPv6 एड्रेस, एक चैट सर्वर, एक सर्टिफिकेट पॉलिसी — किसी ने एक प्रोपोज़ल लिखा, IETF ने उसे एक RFC में बदला, और IANA ने एक नया type नंबर जारी कर दिया। चालीस-से-ज़्यादा सालों से \u0026ldquo;इंटरनेट को एक और चीज़ चाहिए थी\u0026rdquo; — यही वजह है कि आपका DNS पैनल किसी कंट्रोल रूम जैसा दिखता है।\nओरिजिनल टीम (1983–1987) DNS खुद हमेशा से नहीं था। 1983 से पहले, पूरा इंटरनेट (तब ARPANET) एक सिंगल टेक्स्ट फाइल HOSTS.TXT पर निर्भर था, जिसे SRI International सेंट्रली मेंटेन करता था, और हर मशीन इसे डाउनलोड करके नामों को एड्रेसेस से मैप करती थी [4]। जब कुछ सौ होस्ट्स थे तब यह ठीक काम करता था। लेकिन जब नेटवर्क एक्सपोनेंशियली बढ़ने लगा, तो यह काम नहीं कर पाया।\nपॉल मॉकेपेट्रिस (Paul Mockapetris), जो USC के इंफॉर्मेशन साइंसेज इंस्टीट्यूट में जॉन पॉस्टेल (Jon Postel) के अंडर काम कर रहे थे, को इसे ठीक करने का काम सौंपा गया। 1983 में उन्होंने RFC 882 और RFC 883 लिखे, जिनमें एक बड़ी फाइल के बजाय एक डिस्ट्रिब्यूटेड, हायरार्किकल डेटाबेस का प्रस्ताव दिया गया [3]। चार साल बाद इन्हें संशोधित करके नवंबर 1987 में RFC 1034 और RFC 1035 से बदल दिया गया [2], और यही वह डॉक्यूमेंट है जो उन मुख्य रिकॉर्ड टाइप्स को परिभाषित करता है जो आज भी ज़्यादातर काम करते हैं।\nयहाँ ओरिजिनल लाइनअप है, और यह भी कि हर एक को किसी दूसरे रिकॉर्ड पर फ्लैग बनने के बजाय अपने खुद के टाइप के रूप में क्यों मौजूद होना पड़ा:\nरिकॉर्ड यह क्या करता है इसे दूसरे टाइप में क्यों नहीं समेटा जा सका A होस्टनेम को एक IPv4 एड्रेस से मैप करता है यही बेसिक \u0026ldquo;फोनबुक\u0026rdquo; लुकअप है — DNS के होने की पूरी वजह NS बताता है कि किसी ज़ोन के लिए कौन से सर्वर अथॉरिटेटिव हैं रिज़ॉल्वर्स को यह जानना ज़रूरी था कि सवाल कहाँ पूछना है CNAME एक नाम को दूसरे नाम का उपनाम (alias) बनाता है रिकॉर्ड्स को डुप्लिकेट किए बिना www को example.com पर पॉइंट करने देता है MX डोमेन के मेल सर्वर की तरफ इशारा करता है मेल सर्वर अक्सर वेब सर्वर से अलग मशीनें होती हैं — DNS को यह कहने का तरीका चाहिए था कि \u0026ldquo;मेल यहाँ भेजो, वहाँ नहीं\u0026rdquo; SOA ज़ोन एडमिन मेटाडेटा स्टोर करता है (सीरियल नंबर, रिफ्रेश/रिट्राई टाइमर्स, एडमिन कॉन्टैक्ट) सेकेंडरी DNS सर्वर्स को यह जानना होता है कि प्राइमरी से कब फिर से सिंक करना है PTR रिवर्स लुकअप — IP एड्रेस से होस्टनेम तक A रिकॉर्ड्स से पूरी तरह उलटी दिशा का क्वेरी, इसलिए इसे अपना स्ट्रक्चर चाहिए था TXT फ्री-फॉर्म टेक्स्ट एक कैच-ऑल फील्ड जिसमें \u0026ldquo;जो चाहो लिखो\u0026rdquo; — आगे यह बेहद उपयोगी साबित हुआ (नीचे और बताया गया है) HINFO / WKS होस्ट हार्डवेयर/OS जानकारी और वेल-नोन सर्विसेज़ अब लगभग खत्म — एक रिकॉर्ड टाइप का अच्छा शुरुआती उदाहरण जो\u0026hellip; बच नहीं पाया आखिरी रो असल में बहुत कुछ सिखाती है। हर डिफाइन किया गया रिकॉर्ड टाइप टिका नहीं रहता। HINFO का मकसद यह बताना था कि कोई होस्ट किस CPU और OS पर चल रहा है — जो आज प्राइवेसी के लिहाज़ से डरावना लगता है, और सच में अब लगभग कोई इसे पब्लिश नहीं करता। DNS सिर्फ जुड़ता ही नहीं जाता; यह कभी-कभी खुद की छंटाई भी करता है।\nरुकिए — सब कुछ एक ही रिकॉर्ड में क्यों नहीं समेटा जा सकता? वाजिब सवाल है। यहाँ बताया गया है कि यह क्यों काम नहीं करता, और यही इस आर्टिकल के बाकी हिस्से को समझने की कुंजी भी है।\nहर रिकॉर्ड टाइप अपना खुद का वायर फॉर्मेट डिफाइन करता है — type फील्ड के बाद आने वाले डेटा का सटीक बाइनरी लेआउट। MX रिकॉर्ड का डेटा है \u0026ldquo;एक प्रायोरिटी नंबर प्लस एक होस्टनेम।\u0026rdquo; CAA रिकॉर्ड का डेटा है \u0026ldquo;एक फ्लैग, एक टैग, और एक वैल्यू।\u0026rdquo; SRV रिकॉर्ड का डेटा है \u0026ldquo;प्रायोरिटी, वेट, पोर्ट, और टारगेट।\u0026rdquo; ये शेप्स बुनियादी तौर पर अलग हैं, और सही तरीके से पार्स करने के लिए रिज़ॉल्वर को पहले से ही यह शेप पता होना चाहिए।\nइस डिज़ाइन का स्मार्ट हिस्सा यह है कि पुराने सॉफ्टवेयर के लिए अनजान रिकॉर्ड टाइप्स बस ओपेक ब्लॉब्स होते हैं। 1990 के दशक का कोई DNS रिज़ॉल्वर जिसने कभी CAA रिकॉर्ड के बारे में नहीं सुना, वह क्रैश होने के बजाय बस इसे बिना पार्स किए आगे भेज देगा। यही ग्रेसफुल डिग्रेडेशन का सिद्धांत है जिसने 40 से ज़्यादा सालों तक DNS को बैकवर्ड-कम्पैटिबल रखा है — पुराने क्लाइंट्स नए टाइप्स पर अटकते नहीं, वे बस जो नहीं समझ पाते उसे नज़रअंदाज़ कर देते हैं [17]।\nलेकिन यह फॉरवर्ड-कम्पैटिबिलिटी दोनों तरफ काम करती है। एक बिल्कुल नया रिकॉर्ड टाइप टेक्निकली \u0026ldquo;सपोर्टेड\u0026rdquo; तभी हो जाता है जब IANA उसे एक नंबर दे देता है, लेकिन यह उपयोगी तभी बनता है जब रजिस्ट्रार्स, DNS होस्टिंग पैनल्स, वैलिडेटर्स, और एप्लीकेशंस — सब इसके लिए साफ-साफ सपोर्ट जोड़ने की ज़हमत उठाएं। आगे हम एक बढ़िया उदाहरण देखेंगे जहाँ एक रिकॉर्ड टाइप डिफाइन हुआ और फिर एक पुराने टाइप के पक्ष में लगभग छोड़ ही दिया गया — पढ़ते रहिए।\nटाइमलाइन: हर बार जब DNS को नया टाइप मिला, और क्यों यही वह हिस्सा है जो असल में \u0026ldquo;इतने सारे क्यों हैं\u0026rdquo; का जवाब देता है — हर नया जोड़ एक खास पल से जुड़ा है, जब इंटरनेट की समस्याएं मौजूदा चीज़ों से आगे निकल गईं।\n1995 (फिर 2003): AAAA — इंटरनेट के एड्रेसेस खत्म हो रहे थे IPv4 आपको लगभग 4.3 बिलियन एड्रेसेस देता है। यह बहुत लगता है, जब तक आप यह याद नहीं करते कि हर फोन, लैपटॉप, स्मार्ट बल्ब, और फ्रिज को एक एड्रेस चाहिए। 90 के दशक के मध्य तक इंजीनियर्स को यह खत्म होते दिखने लगा था, इसलिए IPv6 को 128-बिट एड्रेसेस के साथ डिज़ाइन किया गया — यानी काफी ज़्यादा जगह।\nलेकिन RFC 1035 का A रिकॉर्ड 32-बिट IPv4 एड्रेसेस के लिए हार्डकोडेड था। इसमें 128-बिट एड्रेस को फिट करने का कोई तरीका नहीं था। इसलिए दिसंबर 1995 में, AAAA (\u0026ldquo;क्वैड-A,\u0026rdquo; क्योंकि एक IPv6 एड्रेस एक IPv4 एड्रेस से चार गुना बड़ा होता है) को RFC 1886 में पेश किया गया [5]। इसे अक्टूबर 2003 में RFC 3596 के रूप में संशोधित किया गया, जिसने रिवर्स लुकअप्स को अजीब IP6.INT डोमेन से IP6.ARPA पर भी शिफ्ट कर दिया [5]। अगर आपकी वेबसाइट पर कभी A और AAAA दोनों रिकॉर्ड्स एक साथ रहे हैं, तो इसका मतलब है कि आपका सर्वर कह रहा है \u0026ldquo;IPv4 और IPv6 दोनों से पहुंचा जा सकता है, जो पसंद हो वो चुन लो।\u0026rdquo;\n1996/2000: SRV — DNS वेब और मेल से आगे बढ़ा यहाँ एक चीज़ है जो सालों तक प्रोटोकॉल डिज़ाइनर्स को परेशान करती रही: MX रिकॉर्ड्स से आप कह सकते थे कि \u0026ldquo;इस डोमेन के लिए मेल उस सर्वर पर जाएगी, जो वेबसाइट से अलग पोर्ट/होस्ट पर है।\u0026rdquo; बढ़िया। लेकिन अगर आप कोई चैट सर्वर, या डायरेक्टरी सर्विस, या वाकई कोई भी दूसरा प्रोटोकॉल चला रहे हों तो क्या होगा? SRV से पहले, हर नए प्रोटोकॉल को अपना MX-स्टाइल हैक बनाना पड़ता था, या बस एक पोर्ट हार्डकोड करके उम्मीद करनी पड़ती थी कि सब ठीक रहेगा।\nSRV रिकॉर्ड्स ने इसे जनरलाइज़ कर दिया। पहली बार RFC 2052 (1996) में प्रोपोज़ किया गया और RFC 2782 (फरवरी 2000) में स्टैंडर्डाइज़ किया गया — एक SRV रिकॉर्ड एक प्रायोरिटी, एक वेट (लोड बैलेंसिंग के लिए), एक पोर्ट, और एक टारगेट होस्ट बताता है [6]। अब अचानक कोई भी सर्विस — XMPP चैट, SIP वॉइस कॉल्स, माइक्रोसॉफ्ट एक्टिव डायरेक्टरी, यहाँ तक कि माइनक्राफ्ट सर्वर्स — कह सकती थी कि \u0026ldquo;इस खास सर्विस के लिए एग्जैक्टली किस होस्ट और पोर्ट से कनेक्ट करना है,\u0026rdquo; और एडमिन क्लाइंट कॉन्फिग्स को तोड़े बिना चीज़ों को इधर-उधर कर सकते थे या फेलओवर सर्वर्स जोड़ सकते थे [6]।\n2000: NAPTR — जब फोन नंबरों को भी DNS की ज़रूरत पड़ी लगभग उसी समय, टेलिकॉम वर्ल्ड इंटरनेट के साथ मर्ज होने की कोशिश कर रही थी — खास तौर पर, ENUM नाम की किसी चीज़ के ज़रिए पारंपरिक फोन नंबरों (E.164 फॉर्मेट) को इंटरनेट सर्विसेज़ पर मैप करना, और SIP (Session Initiation Protocol) कॉल्स को रूट करना।\nNAPTR (Naming Authority Pointer) रिकॉर्ड्स, जिन्हें RFC 2915 (2000) में डिफाइन किया गया, ने इसे एक नाम को एक रेगुलर-एक्सप्रेशन-बेस्ड रीराइट रूल से मैप करके हल किया, जो एक नया डोमेन नेम या URI बनाता है [7]। SRV रिकॉर्ड्स के साथ मिलकर, NAPTR ने एक सिंगल फोन नंबर को DNS के ज़रिए \u0026ldquo;यह है SIP सर्वर, यह है पोर्ट, यह है प्रोटोकॉल\u0026rdquo; में रिज़ॉल्व होने दिया [7]। ज़्यादातर लोगों के लिए यह एक निच रिकॉर्ड टाइप है, लेकिन अगर आपने कभी VoIP कॉल की है, तो NAPTR पर्दे के पीछे खामोशी से काम कर रहा था।\n2005: DNSSEC का अल्फाबेट सूप — DNSKEY, RRSIG, NSEC, DS अपने पहले ~20 सालों तक, DNS में ज़ीरो ऑथेंटिकेशन था। एक रिज़ॉल्वर सवाल पूछता है, जवाब मिलता है, और बस\u0026hellip; उस पर भरोसा कर लेता है। यह एक बड़ी समस्या है अगर कोई उस जवाब को इंटरसेप्ट या फोर्ज कर सके — जिसे कैश पॉइज़निंग कहा जाता है, जहाँ एक अटैकर किसी रिज़ॉल्वर को किसी लेजिटिमेट डोमेन के लिए एक फेक IP एड्रेस कैश करने में चकमा देता है, और चुपचाप ट्रैफिक को एक मैलिशियस सर्वर पर भेज देता है।\nDNSSEC (DNS Security Extensions) डिजिटल सिग्नेचर्स के ज़रिए इसे ठीक करता है, और इसके लिए चार नए रिकॉर्ड टाइप्स की ज़रूरत पड़ी, जिन्हें RFC 4034 (मार्च 2005) में औपचारिक रूप दिया गया, जिसने 1999 की एक पहले की और ज़्यादा अव्यवस्थित कोशिश को रिप्लेस कर दिया [8]:\nDNSKEY — किसी ज़ोन के सिग्नेचर्स को वेरीफाई करने के लिए इस्तेमाल होने वाली पब्लिक की (key) रखता है RRSIG — रिकॉर्ड्स के एक सेट को कवर करने वाला असली डिजिटल सिग्नेचर NSEC — साबित करता है कि कोई रिकॉर्ड मौजूद नहीं है (ताकि अटैकर्स बिना पकड़े \u0026ldquo;ऐसा कोई डोमेन नहीं है\u0026rdquo; का दावा न कर सकें) DS — एक हैश जो किसी चाइल्ड ज़ोन की की (key) को उसके पैरेंट ज़ोन से जोड़ता है, और एक चेन ऑफ ट्रस्ट बनाता है इसे अपनाने की रफ्तार सालों तक धीमी रही — DNSSEC ज़ोन मैनेजमेंट में असली कॉम्प्लेक्सिटी जोड़ता है — लेकिन बाद के सालों में हाई-प्रोफाइल कैश-पॉइज़निंग रिसर्च की एक लहर ने इसे एक गंभीर धक्का दिया, और अब किसी भी ऐसे डोमेन के लिए DNSSEC को बेसिक ज़रूरत माना जाता है जो सुरक्षा को गंभीरता से लेता है।\n2006–2015: SPF, DKIM, DMARC — ईमेल स्पूफिंग के खिलाफ जंग अगर आपने कभी किसी कस्टम डोमेन के लिए ईमेल सेटअप किया है, तो आपका सामना इस तिकड़ी से हुआ होगा, और सच कहें तो यहीं से DNS सच में गड़बड़ हो गया — क्योंकि ये तीनों टेक्निकली उस सीधे-सादे TXT रिकॉर्ड के अंदर रहते हैं, जो शुरू में बस \u0026ldquo;यहाँ कोई फ्री-टेक्स्ट नोट लिखो\u0026rdquo; के लिए था।\nSPF (Sender Policy Framework) यह बताता है कि कौन से मेल सर्वर्स को आपके डोमेन की तरफ से ईमेल भेजने की इजाज़त है। यह RFC 4408 (अप्रैल 2006) में एक IETF एक्सपेरिमेंट के रूप में शुरू हुआ [9], और — यहाँ असल में अजीब बात है — इसे शुरू में अपना खुद का डेडिकेटेड रिकॉर्ड टाइप मिला था, टाइप 99, जिसे सीधे \u0026ldquo;SPF\u0026rdquo; कहा जाता था। किसी ने इसे इस्तेमाल नहीं किया। DNS सॉफ्टवेयर वेंडर्स और एडमिन्स SPF पॉलिसी को TXT रिकॉर्ड्स के रूप में ही पब्लिश करते रहे, क्योंकि यह पहले से ही हर जगह काम कर रहा था। RFC 7208 (अप्रैल 2014) तक, IETF ने हार मान ली और डेडिकेटेड SPF रिकॉर्ड टाइप को औपचारिक रूप से डेप्रिकेट कर दिया, और सिर्फ TXT को अनिवार्य बना दिया [9][10]। यह उस दुर्लभ केस का उदाहरण है जिसमें एक बिल्कुल नया रिकॉर्ड टाइप डिफाइन हुआ, लगभग पूरी तरह बेकार रहा, और फिर एक दशक से भी कम समय में आधिकारिक तौर पर खत्म कर दिया गया [10]। DKIM (DomainKeys Identified Mail), जिसे लगभग छह साल के डेवलपमेंट के बाद 2011 में RFC 6376 के रूप में स्टैंडर्डाइज़ किया गया, बाहर जाने वाली ईमेल्स में एक क्रिप्टोग्राफिक सिग्नेचर जोड़ता है ताकि रिसीवर्स यह वेरीफाई कर सकें कि मैसेज के साथ छेड़छाड़ नहीं हुई — यह selector._domainkey.yourdomain.com पर एक TXT रिकॉर्ड के रूप में पब्लिश होता है। DMARC (Domain-based Message Authentication, Reporting and Conformance) SPF और DKIM को आपस में जोड़ता है, और रिसीविंग सर्वर्स को बताता है कि अगर कोई मैसेज दोनों में फेल हो जाए तो क्या करना है — उसे क्वारंटीन करें, रिजेक्ट करें, या बस उसकी रिपोर्ट करें। यह एक इंडस्ट्री कंसोर्टियम (Google, Microsoft, Yahoo, PayPal, और DMARC.org के तहत अन्य) से निकला और मार्च 2015 में RFC 7489 के रूप में पब्लिश हुआ [11], जो _dmarc.yourdomain.com पर रहता है। एक रिकॉर्ड टाइप के बजाय तीन अलग-अलग चीज़ें क्यों? क्योंकि ये तीन अलग-अलग ट्रस्ट प्रॉब्लम्स हल करते हैं — भेजने की इजाज़त किसे है (SPF), क्या इस मैसेज को बदला गया (DKIM), और अगर चेक्स फेल हो जाएं तो क्या होना चाहिए, साथ ही मुझे विज़िबिलिटी भी दो (DMARC) — और इन्हें अलग-अलग समूहों ने अलग-अलग समय पर बनाया, जो ईमानदारी से DNS के इवॉल्व होने के तरीके के बिल्कुल मुताबिक है।\n2012–2013: TLSA और CAA — सर्टिफिकेट अथॉरिटीज़ के साथ भरोसे की समस्याएं लगभग 2011–2012 में, वेब PKI सिस्टम — यानी वे सर्टिफिकेट अथॉरिटीज़ (CAs) जो HTTPS के लिए पैडलॉक-आइकॉन सर्टिफिकेट्स जारी करती हैं — के लिए कुछ मुश्किल साल रहे। कई CAs को गंभीर ब्रीचेस का सामना करना पड़ा, जिसने अटैकर्स को ऐसे डोमेन्स के लिए वैलिड सर्टिफिकेट्स जारी करवाने दिए जिनके वे मालिक नहीं थे [12]। बुनियादी समस्या यह थी: आपके ब्राउज़र में मौजूद सैकड़ों ट्रस्टेड CAs में से कोई भी किसी भी डोमेन के लिए सर्टिफिकेट जारी कर सकता है, और डोमेन ओनर के पास यह कहने का कोई तरीका नहीं था कि \u0026ldquo;सिर्फ इस CA को ऐसा करने की इजाज़त है।\u0026rdquo;\nदो रिकॉर्ड टाइप्स ने इसे अलग-अलग नज़रियों से हल किया:\nTLSA, जिसे RFC 6698 (अगस्त 2012) में DANE (DNS-based Authentication of Named Entities) के हिस्से के रूप में डिफाइन किया गया, किसी डोमेन को वह एग्जैक्ट सर्टिफिकेट या CA पिन करने देता है जिसकी उसे उम्मीद है, और DNSSEC ट्रस्ट एंकर देता है — जो पूरी तरह से पारंपरिक CA सिस्टम को बायपास कर देता है [12]। प्रैक्टिस में, इसे अपनाना ज़्यादातर SMTP मेल सर्वर्स और कुछ XMPP डिप्लॉयमेंट्स तक ही सीमित रहा है [12]। CAA, जिसे पहली बार अक्टूबर 2010 में फिलिप हैलम-बेकर (Phillip Hallam-Baker) और रॉब स्ट्रैडलिंग (Rob Stradling) ने ड्राफ्ट किया, और जनवरी 2013 में RFC 6844 के रूप में पब्लिश किया गया — यह एक हल्के तरीके से काम करता है: यह डोमेन ओनर को एक सिंपल पॉलिसी पब्लिश करने देता है जो कहती है \u0026ldquo;मेरे लिए सर्टिफिकेट्स सिर्फ ये खास CAs ही जारी कर सकती हैं\u0026rdquo; [13][14]। CA/Browser Forum ने 8 सितंबर 2017 से CAA रिकॉर्ड्स की जांच को सभी पब्लिक CAs के लिए अनिवार्य बना दिया [14], और बाद में नवंबर 2019 में स्पेक को RFC 8659 के रूप में और बेहतर बनाया गया। अगर आपने कभी अपने डोमेन को Let\u0026rsquo;s Encrypt या DigiCert से लॉक करने के लिए CAA रिकॉर्ड सेट किया है, तो यही वजह है कि यह मौजूद है [15]। 2023: HTTPS और SVCB — DNS कनेक्शंस को लेकर ज़्यादा स्मार्ट हो गया यह सबसे नई एंट्री है, और इस पर खत्म करना अच्छा है क्योंकि यह दिखाता है कि यह पैटर्न अभी भी पूरी तरह ज़िंदा है।\nवेब के इतिहास के ज़्यादातर हिस्से में, किसी साइट पर जाने का मतलब था: A/AAAA रिकॉर्ड के लिए DNS लुकअप → एक TCP कनेक्शन खोलना → एक TLS हैंडशेक करना → फिर HTTP रिक्वेस्ट भेजना। हर स्टेप कुछ-कुछ अंधेरे में होता है — आपके ब्राउज़र को पहले से नहीं पता होता कि सर्वर HTTP/3 सपोर्ट करता है या नहीं, उसके अल्टरनेट एंडपॉइंट्स हैं या नहीं, या उसे कोई स्पेशल TLS कॉन्फिगरेशन चाहिए या नहीं।\nSVCB (Service Binding) और HTTPS रिकॉर्ड्स, जिन्हें RFC 9460 (नवंबर 2023) में साथ में स्टैंडर्डाइज़ किया गया, एक सिंगल DNS आंसर को पहले से ही कनेक्शन हिंट्स देने देते हैं — जैसे HTTP/3 जैसे प्रिफर्ड प्रोटोकॉल्स, अल्टरनेट पोर्ट्स, IP हिंट्स, और एन्क्रिप्टेड ClientHello [प्राइवेसी-प्रोटेक्टिंग TLS एक्सटेंशन] के लिए पैरामीटर्स [16]। HTTPS रिकॉर्ड टाइप असल में SVCB का ही एक स्पेशलाइज़्ड वर्शन है जो सिर्फ वेब ट्रैफिक के लिए है, और यह वह काम कर सकता है जो CNAME कभी नहीं कर सका: एक एपेक्स डोमेन (जैसे खुद example.com, न सिर्फ www) को किसी दूसरे नाम का उपनाम (alias) बनाना [16]। ब्राउज़र्स और CDNs अभी भी सपोर्ट रोल आउट कर रहे हैं, लेकिन यह अब तक का सबसे साफ संकेत है कि वेब के अंदरूनी प्रोटोकॉल्स बदलने के साथ-साथ DNS भी खुद को ढालता रहता है।\nचीट शीट: आपको असल में कौन सा रिकॉर्ड चाहिए? अगर आप अभी किसी DNS पैनल को देख रहे हैं और यह समझने की कोशिश कर रहे हैं कि असल में क्या कॉन्फिगर करना है, तो यहाँ एक प्रैक्टिकल मैपिंग है:\nआप क्या करना चाहते हैं आपको चाहिए रिकॉर्ड टाइप(स) अपने डोमेन को किसी सर्वर पर पॉइंट करें (IPv4) A अपने डोमेन को किसी सर्वर पर पॉइंट करें (IPv6) AAAA एक होस्टनेम को दूसरे का उपनाम बनाएं (जैसे, www → example.com) CNAME आने वाली ईमेल को अपने मेल प्रोवाइडर पर रूट करें MX सर्वर्स को आपके डोमेन की तरफ से मेल भेजने के लिए अधिकृत करें TXT (SPF पॉलिसी) बाहर जाने वाली ईमेल को क्रिप्टोग्राफिक रूप से साइन करें TXT (DKIM की, selector._domainkey पर) ईमेल ऑथ चेक्स फेल होने पर पॉलिसी सेट करें TXT (DMARC, _dmarc पर) Google/AWS/आदि को डोमेन ओनरशिप साबित करें TXT (वेरिफिकेशन टोकन) नॉन-वेब/नॉन-मेल सर्विस चलाएं (चैट, AD, गेम सर्वर) SRV यह तय करें कि कौन सी CAs आपके लिए TLS सर्टिफिकेट्स जारी कर सकती हैं CAA DNSSEC के ज़रिए एक एग्जैक्ट TLS सर्टिफिकेट पिन करें TLSA DNSSEC के लिए अपना ज़ोन साइन करें DNSKEY, DS, RRSIG, NSEC मेल सर्वर की IP के लिए रिवर्स DNS सेटअप करें PTR HTTP/3 सपोर्ट, अल्टरनेट एंडपॉइंट्स का संकेत दें SVCB / HTTPS यह तय करें कि आपके ज़ोन के लिए कौन से सर्वर्स अथॉरिटेटिव हैं NS ज़ोन मेटाडेटा डिफाइन करें (रिफ्रेश टाइमर्स, एडमिन ईमेल) SOA अगर ध्यान से देखें, तो एक पैटर्न दिखता है इस पूरी लिस्ट को शुरू से आखिर तक देखें, तो एक साफ पैटर्न नज़र आता है: DNS को फिर से डिज़ाइन नहीं किया जाता, इसे एक्सटेंड किया जाता है — रिएक्टिव तरीके से, उस समय इंटरनेट जिस संकट से गुज़र रहा होता है उसके जवाब में। एड्रेस खत्म होना → AAAA। प्रोटोकॉल्स का फैलाव → SRV। फोन/इंटरनेट का मिलन → NAPTR। कैश पॉइज़निंग → DNSSEC। स्पैम और फिशिंग → SPF/DKIM/DMARC। CA ब्रीचेस → CAA और TLSA। धीमा कनेक्शन सेटअप → SVCB/HTTPS।\nSPF टाइप-99 की कहानी शायद इस पूरी बात में मेरी सबसे फेवरेट डिटेल है — एक बिल्कुल नया रिकॉर्ड टाइप औपचारिक रूप से स्टैंडर्डाइज़ हुआ, लगभग किसी ने इसे नहीं अपनाया, और कुछ साल बाद स्पेक को फिर से लिखकर आधिकारिक तौर पर कहा गया \u0026ldquo;हाँ, बस TXT इस्तेमाल करो, जैसा सब पहले से कर ही रहे थे\u0026rdquo; [10]। यह एक याद दिलाता है कि IANA रजिस्ट्री सफल डिज़ाइनों का म्यूज़ियम नहीं है — यह हर उस आइडिया का रिकॉर्ड है जो आज़माया गया, जिनमें से कुछ कामयाब हुए और कुछ खामोशी से फीके पड़ गए।\nIANA रजिस्ट्री लगातार बढ़ती जा रही है [16], और इसके रुकने की कोई वजह नज़र नहीं आती। चाहे अगली इंटरनेट-वाइड सिरदर्दी जो भी हो — और हमेशा कोई न कोई पनप ही रही होती है — इस बात की अच्छी संभावना है कि उसका हल किसी की ज़ोन फाइल में एक नए तीन-या-चार-अक्षर वाले कोड के रूप में सामने आएगा।\nस्रोत DNS records | Cloudflare Learning Center RFC 1035 - Domain Names: Implementation and Specification (IETF Datatracker) Paul Mockapetris - Wikipedia Celebrating 30 Years of the Domain Name System (DNS) - Internet Society RFC 3596: DNS Extensions to Support IP Version 6 SRV record - Wikipedia NAPTR record - Wikipedia RFC 4034: Resource Records for the DNS Security Extensions RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email Discontinuing the SPF Record (Type 99) - DNSimple Blog RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC) RFC 6698: The DNS-Based Authentication of Named Entities (DANE) TLSA Protocol Certification Authority Authorization Checking: What is it, and Why Does it Matter? - DigiCert DNS Certification Authority Authorization - Wikipedia RFC 9460 - Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) Domain Name System (DNS) Parameters - IANA DNS record types - Cloudflare Developers ","permalink":"https://cloudmato.com/hi/posts/dns-records-explained-types-timeline/","title":"DNS रिकॉर्ड्स को समझें: इतने सारे टाइप्स क्यों हैं? (टाइमलाइन)"},{"content":"मैंने पिछले वीकेंड का एक बड़ा हिस्सा अलग-अलग टैब्स में करीब पंद्रह प्राइसिंग पेज खोलकर यह समझने में बिताया कि मेरे एक छोटे साइड प्रोजेक्ट का API बिल चुपचाप एक महीने में तीन गुना कैसे हो गया। पता चला कि जवाब \u0026ldquo;मॉडल महंगा हो गया\u0026rdquo; नहीं था — असली वजह यह थी कि मैंने काम के लिए गलत मॉडल चुना था, गलत प्लेटफॉर्म पर, और कुछ भी कैश किए बिना। तो मैं इस पूरे मामले की तह तक गया: हर बड़ा LLM API, हर क्लाउड रैपर, और वो बजट विकल्प जिनके बारे में कोई बात नहीं करता जब तक कि उनका AWS बिल सामने न आ जाए।\n\u0026ldquo;प्रति मिलियन टोकन\u0026rdquo; पूरी कहानी क्यों नहीं बताता हर प्रोवाइडर अपनी कीमतें प्रति मिलियन टोकन के हिसाब से बताता है, जिसे इनपुट और आउटपुट में बांटा जाता है। यह बंटवारा जितना लोग समझते हैं उससे कहीं ज्यादा मायने रखता है — हर प्रोवाइडर में आउटपुट टोकन लगभग हमेशा इनपुट टोकन से 3 से 5 गुना महंगे होते हैं [1][5]। अगर आपका ऐप लंबे जवाब जनरेट करता है (सारांश, कोड, रिपोर्ट), तो आपका बिल इनपुट नहीं बल्कि आउटपुट प्राइसिंग से तय होता है। अगर आप ज्यादातर बड़े-बड़े डॉक्यूमेंट्स कॉन्टेक्स्ट में डालकर छोटे जवाब वापस पा रहे हैं, तो इनपुट प्राइसिंग ही वो चीज़ है जिसे ऑप्टिमाइज़ करना चाहिए।\nयहां वो हिस्सा है जो वाकई कंफ्यूज़ करने वाला है और जिसका जिक्र लगभग कोई नहीं करता: एक ही टेक्स्ट हर मॉडल में हमेशा बराबर टोकन की कीमत नहीं लेता। Anthropic ने चुपचाप यह बताया कि Claude Opus 4.7 और उसके बाद के मॉडल एक नया टोकनाइज़र इस्तेमाल करते हैं जो \u0026ldquo;एक ही फिक्स्ड टेक्स्ट के लिए पुराने Claude मॉडल्स के मुकाबले 35% तक ज्यादा टोकन इस्तेमाल कर सकता है\u0026rdquo; [1]। तो जो मॉडल कागज़ पर प्रति टोकन 20% सस्ता दिखता है, वो टोकनाइज़ेशन के अंतर को ध्यान में रखने पर प्रति टास्क ज्यादा महंगा साबित हो सकता है। यही वो गड़बड़ी है जो भोले-भाले प्राइस कंपैरिज़न को भ्रामक बना देती है।\nदो ऐसे लीवर हैं जो वाकई आपके बिल पर असर डालते हैं:\nप्रॉम्प्ट कैशिंग – सिस्टम प्रॉम्प्ट, डॉक्यूमेंट या कन्वर्सेशन हिस्ट्री को दोबारा इस्तेमाल करना। Anthropic कैश हिट्स के लिए बेस इनपुट प्राइस का सिर्फ 10% चार्ज करता है [1]। Google की Gemini कैशिंग भी इनपुट कॉस्ट को 90% तक घटा सकती है (कैश्ड Gemini 2.5 Flash इनपुट $0.30/M से घटकर $0.03/M हो जाता है) [3]। बैच प्रोसेसिंग – ऐसी किसी भी चीज़ के लिए जिसे रियल टाइम में जवाब की ज़रूरत नहीं है (क्लासिफिकेशन, बल्क समराइज़ेशन, डेटा लेबलिंग), लगभग हर प्रोवाइडर इनपुट और आउटपुट दोनों टोकन पर सीधा 50% डिस्काउंट देता है [1][2][3][5]। अगर आप इन दोनों में से कम से कम एक का इस्तेमाल नहीं कर रहे हैं, तो चाहे आपने कोई भी मॉडल चुना हो, आप शायद बहुत ज्यादा पैसे दे रहे हैं।\nतीन बड़े दिग्गज, आमने-सामने: Claude vs GPT vs Gemini चलिए उन फ्रंटियर लैब्स से शुरू करते हैं जिन्हें हर कोई डिफॉल्ट रूप से चुनता है। जून 2026 तक, ऑफिशियल प्राइसिंग पेजेज़ के मुताबिक स्थिति कुछ ऐसी थी:\nमॉडल इनपुट ($/M टोकन) आउटपुट ($/M टोकन) बैच (इन/आउट) नोट्स Claude Opus 4.8 $5.00 $25.00 $2.50 / $12.50 Cache hit $0.50/M (90% की छूट) [1] Claude Sonnet 4.6 $3.00 $15.00 $1.50 / $7.50 1M कॉन्टेक्स्ट विंडो शामिल [1] Claude Haiku 4.5 $1.00 $5.00 $0.50 / $2.50 सबसे सस्ता Claude, फिर भी काफी सक्षम [1] GPT-5.5 (flagship) $5.00 $30.00 $2.50 / $15.00 कैश्ड इनपुट $0.50/M [2] GPT-5.4 $2.50 $15.00 ~50% की छूट कैश्ड इनपुट $0.25/M [2] GPT-5.4-mini $0.75 $4.50 ~50% की छूट कैश्ड इनपुट $0.075/M [2] GPT-5.4-nano $0.20 $1.25 ~50% की छूट कैश्ड इनपुट $0.02/M [2] GPT-4.1 nano $0.10 $0.40 — कुल मिलाकर सबसे सस्ता OpenAI मॉडल [2][14] Gemini 3.1 Pro $2.00–$4.00 $12.00–$18.00 50% की छूट 200k टोकन के बाद हायर टियर लागू होता है [3] Gemini 3.5 Flash $1.50 $9.00 $0.75 / $4.50 सबसे नया Flash, मई 2026 रिलीज़ [3] Gemini 2.5 Flash-Lite $0.10 $0.40 — उदार फ्री टियर [3] यहां कुछ बातें तुरंत ध्यान खींचती हैं। तीनों में से Anthropic की प्राइसिंग सबसे पारदर्शी है — एक ही टेबल, \u0026ldquo;शॉर्ट बनाम लॉन्ग कॉन्टेक्स्ट टियर\u0026rdquo; जैसी कोई शर्तें नहीं। इसके उलट, Google का Gemini 3.1 Pro 200k टोकन कॉन्टेक्स्ट पार करते ही अपनी कीमत दोगुनी कर देता है [3], जो आसानी से नज़रअंदाज़ हो सकता है अगर आप छोटे प्रॉम्प्ट्स से टेस्ट कर रहे हों और बाद में पूरे PDF प्रोसेस करने वाला कुछ शिप कर दें।\nएक और बात जानने लायक है: हाल ही में Anthropic ने अपनी कंपनी के इतिहास की सबसे बड़ी प्राइस कटौती की है। Opus की कीमत $15/$75 प्रति मिलियन टोकन (Opus 4.1) से घटकर $5/$25 (Opus 4.5 और उसके बाद से) हो गई — यानी 67% की कमी [4]। ऐसी चीज़ें छह महीने पुराने कॉस्ट एनालिसिस को पूरी तरह गलत बना सकती हैं, और ईमानदारी से कहूं तो यही आधी वजह है कि ऐसे कंपैरिज़न इतनी जल्दी पुराने पड़ जाते हैं।\nअगर आप सिर्फ आउटपुट-टोकन कॉस्ट के आधार पर समान \u0026ldquo;स्मार्ट लेकिन फ्लैगशिप नहीं\u0026rdquo; टियर चुन रहे हैं, तो $1/$5 पर Claude Haiku 4.5 और $0.20/$1.25 पर GPT-5.4-nano बड़े तीनों की लाइनअप में सबसे नीचे आते हैं [1][2], जबकि Gemini 2.5 Flash-Lite $0.10/$0.40 के साथ और भी सस्ता है [3] — हालांकि Flash-Lite उस कीमत के बदले रीज़निंग क्वालिटी में थोड़ा समझौता करता है।\nक्या AWS, Azure, GCP या OCI के ज़रिए जाने से वाकई पैसे बचते हैं? यही वो सवाल था जिसका जवाब मैं वाकई जानना चाहता था, क्योंकि कई कंपनियां प्रोक्योरमेंट कारणों से सब कुछ अपनी मौजूदा क्लाउड बिलिंग के ज़रिए ही रूट करती हैं। छोटा जवाब: क्लाउड प्रोवाइडर के ज़रिए जाने से चीज़ें शायद ही कभी सस्ती होती हैं, और कई बार इससे असली मार्कअप जुड़ जाता है।\nAWS Bedrock Bedrock पर Claude, Llama, Mistral, और Amazon के अपने Nova मॉडल होस्ट होते हैं। Bedrock पर Claude की प्राइसिंग बिल्कुल Anthropic की डायरेक्ट प्राइसिंग जैसी ही है — Opus 4.6 $5/$25 पर, Sonnet 4.6 $3/$15 पर, Haiku 4.5 $1/$5 पर [5]। तो वहां कोई मार्कअप नहीं है\u0026hellip; जब तक कि आप बेहतर अवेलेबिलिटी के लिए क्रॉस-रीजन इंफरेंस ऑन न करें, जो हर चीज़ पर सीधा 10% सरचार्ज जोड़ देता है (Sonnet का इनपुट $3.00 से $3.30 और आउटपुट $15.00 से $16.50 हो जाता है) [5]।\nBedrock जहां वाकई दिलचस्प हो जाता है वो है Amazon के अपने Nova मॉडल्स, जो Anthropic, OpenAI या Google के किसी भी मॉडल से कहीं ज्यादा सस्ते हैं:\nNova Pro: $0.80 / $3.20 प्रति मिलियन टोकन Nova Lite: $0.06 / $0.24 Nova Micro: $0.035 / $0.14 [5] $0.035 इनपुट पर Nova Micro आसपास के सबसे सस्ते \u0026ldquo;असली\u0026rdquo; होस्टेड मॉडल्स में से एक है — हालांकि यह इस समूह में सबसे कम सक्षम भी है, इसलिए कमिट करने से पहले इसे अपने असली टास्क पर टेस्ट करें।\nAzure OpenAI Service Azure आपको OpenAI के डायरेक्ट API जैसे ही मॉडल देता है, लेकिन इकोनॉमिक्स बदल जाती है। हेडलाइन नंबर्स सस्ते दिख सकते हैं — Azure की GPT-5 लिस्टिंग $1.25/$10 दिखाती है जबकि OpenAI का डायरेक्ट GPT-5.4 $2.50/$15 पर है [6][2] — लेकिन यह अलग-अलग मॉडल जनरेशन की तुलना है, और Azure इसमें सपोर्ट प्लान्स ($100–$1,000+/महीना), नेटवर्किंग, और इंफ्रा कॉस्ट जोड़ देता है, जो प्रोडक्शन में आमतौर पर लिस्टेड टोकन रेट्स के ऊपर 20-40% अतिरिक्त जोड़ देता है [6]। अगर आपको गारंटीड लेटेंसी के लिए प्रोविज़न्ड थ्रूपुट यूनिट्स (PTUs) चाहिए, तो वह एक अलग ~$2,448/महीना का कमिटमेंट है जो सिर्फ बड़े स्केल पर ही फायदेमंद होता है [6]।\nGCP Vertex AI Vertex AI दरअसल \u0026ldquo;Gemini है, बस एंटरप्राइज़ रैपिंग के साथ\u0026rdquo; — VPC सर्विस कंट्रोल्स, कस्टमर-मैनेज्ड एन्क्रिप्शन कीज़, रीजनल रेज़िडेंसी। टोकन प्राइसिंग Gemini Developer API जैसी ही है, लेकिन अगर आपको टाइट लेटेंसी SLA के लिए Priority टियर चाहिए, तो उम्मीद करें कि आपको Standard टियर से लगभग 80% ज्यादा चुकाना पड़ेगा [3]। ज्यादातर प्रोजेक्ट्स जिन्हें कंप्लायंस वाली अतिरिक्त सुविधाओं की ज़रूरत नहीं है, उनके लिए सीधे Google AI Studio के ज़रिए Gemini API इस्तेमाल करना ज्यादा आसान है और कीमत भी बिल्कुल वही है।\nOracle Cloud Infrastructure (OCI) OCI की Generative AI सर्विस इस लिस्ट में सबसे अलग है — यह ज्यादातर मॉडल्स के लिए टोकन की बजाय प्रति कैरेक्टर बिलिंग करती है, और इसमें मॉडल्स का सेट भी छोटा है: Cohere की Command फैमिली और Meta के Llama मॉडल्स [7]। Oracle जो प्राइसिंग रेंज पब्लिश करता है वो सस्ते सिरे पर $0.075 प्रति मिलियन टोकन से लेकर प्रीमियम सिरे पर $10.68 तक जाती है [7]। ईमानदारी से कहूं तो मैं Oracle के प्राइसिंग पेज से सटीक पर-मॉडल रेट कार्ड्स नहीं निकाल पाया (वह बार-बार ऑटोमेटेड फेच ब्लॉक कर रहा था), तो अगर OCI आपकी शॉर्टलिस्ट में है, तो थर्ड-पार्टी समरी पर भरोसा करने की बजाय उनका कॉस्ट एस्टिमेटर सीधे चलाने के लिए समय निकालें — प्रति-कैरेक्टर बिलिंग मॉडल की वजह से टोकन-आधारित सीधी तुलना भरोसेमंद नहीं रहती।\nक्लाउड प्लेटफॉर्म डायरेक्ट API के मुकाबले मार्कअप इस्तेमाल करने की सबसे अच्छी वजह AWS Bedrock Claude के लिए कोई नहीं (क्रॉस-रीजन के लिए 0% से +10%) पहले से AWS बिलिंग/IAM में गहराई से जुड़े हैं; Nova की अल्ट्रा-लो प्राइसिंग चाहिए Azure OpenAI प्रभावी रूप से ~20-40% (सपोर्ट, इंफ्रा, PTUs) एंटरप्राइज़ कंप्लायंस, Microsoft इकोसिस्टम लॉक-इन GCP Vertex AI 0% (Standard) / +80% (Priority) Gemini के साथ डेटा रेज़िडेंसी / VPC कंट्रोल्स चाहिए OCI Generative AI तुलना करना मुश्किल (प्रति-कैरेक्टर बिलिंग) पहले से Oracle Cloud Universal Credits पर हैं पैटर्न साफ है: क्लाउड प्लेटफॉर्म्स का मकसद कंप्लायंस, प्रोक्योरमेंट, और मौजूदा इंफ्रास्ट्रक्चर है — टोकन पर पैसे बचाना नहीं। अगर आपका इकलौता लक्ष्य सबसे कम बिल है, तो सीधे मॉडल प्रोवाइडर के API पर जाएं।\nवो असली सस्ते विकल्प जिनके बारे में कोई बात नहीं करता अगर आपको असली बजट टियर चाहिए, तो फ्रंटियर लैब्स अब इस बातचीत में हैं ही नहीं। प्राइस फ्लोर तय करते हैं स्पेशलाइज्ड इंफरेंस प्रोवाइडर्स पर चलने वाले ओपन-वेट मॉडल्स, और खासतौर पर एक चाइनीज़ लैब।\nDeepSeek सबसे अलग खड़ा है। DeepSeek V4 Flash की कीमत $0.14 प्रति मिलियन इनपुट टोकन (कैश मिस) और $0.28 आउटपुट है — और अगर आपका प्रॉम्प्ट स्ट्रक्चर कैश हिट करता है, तो वह इनपुट कॉस्ट घटकर $0.0028 प्रति मिलियन टोकन रह जाती है, यानी 50 गुना कमी [8]। DeepSeek ने अप्रैल 2026 में कैश-हिट प्राइसिंग को अपने लॉन्च प्राइस के दसवें हिस्से तक घटा दिया था [8], और कॉन्टेक्स्ट कैशिंग डिफॉल्ट रूप से इनेबल रहती है — अगर आपके रिक्वेस्ट्स में एक कॉमन प्रीफिक्स (जैसे सिस्टम प्रॉम्प्ट) शेयर होता है, तो आपको बिना किसी अतिरिक्त सेटअप के अपने आप डिस्काउंट मिल जाता है। हाई-वॉल्यूम, रिपीटेटिव वर्कलोड्स (जैसे: एक ही इंस्ट्रक्शंस के साथ हज़ारों मिलते-जुलते सपोर्ट टिकट्स को क्लासिफाई करना) के लिए, यह लगभग मुफ्त के बराबर है।\nफिर है ओपन-वेट + स्पेशलाइज्ड हार्डवेयर का कॉम्बो:\nGroq कस्टम LPU चिप्स पर Llama, Mixtral, Gemma, और DeepSeek-डिस्टिल्ड मॉडल्स को 500+ टोकन/सेकंड की स्पीड पर चलाता है। Llama 3.1 8B Instant की कीमत सिर्फ $0.05 इनपुट / $0.08 आउटपुट प्रति मिलियन टोकन है [10] — और यह तेज़ है, जो मायने रखता है अगर आपका ऐप लेटेंसी के प्रति संवेदनशील है। Cerebras इंफरेंस को और भी तेज़ कर देता है (अपने वेफर-स्केल चिप्स पर 1,800-2,600 टोकन/सेकंड), जिसकी प्राइसिंग Llama 3.1 8B के लिए $0.10/M से लेकर GLM-4.7 के लिए $2.30/M तक है, साथ ही रोज़ाना 1 मिलियन टोकन का फ्री टियर भी मिलता है [9]। Mistral का Ministral 3B किसी \u0026ldquo;असली\u0026rdquo; होस्टेड मॉडल के लिए लगभग सबसे सस्ता है: $0.04 इनपुट / $0.04 आउटपुट प्रति मिलियन टोकन — यानी राउंड-ट्रिप में असरदार रूप से सिर्फ 8 सेंट [8]। Mistral Small 3 की कीमत $0.10/$0.30 है, और इनका फ्लैगशिप Mistral Large 2 भी $2/$6 पर है, जो Claude Sonnet और GPT-5.4 दोनों से सस्ता है [8]। इस फासले को परिप्रेक्ष्य में रखने के लिए — और जब मैंने इसे प्लॉट किया तो यह वाकई मुझे हैरान कर गया — सबसे सस्ते और सबसे महंगे \u0026ldquo;फ्रंटियर-जैसे\u0026rdquo; मॉडल्स के बीच का अंतर सिर्फ आउटपुट टोकन पर ही 300 गुना से ज्यादा है:\nOpenRouter भी है, जो खुद मॉडल्स होस्ट नहीं करता बल्कि दर्जनों प्रोवाइडर्स के आगे एक सिंगल API की तरह काम करता है। इसका फ्री टियर आपको 28+ फ्री मॉडल्स पर 20 रिक्वेस्ट/मिनट और 50-1,000 रिक्वेस्ट/दिन देता है, जिनमें DeepSeek R1, Llama 3.3 70B, और Qwen3 Coder 480B शामिल हैं [12]। किसी एक प्रोवाइडर के पेड टियर के लिए कमिट करने से पहले यह जांचने का बढ़िया तरीका है कि कौन सा मॉडल आपके टास्क के लिए सही बैठता है — और फ्री मॉडल्स कलेक्शन नए ओपन-वेट रिलीज़ आने के साथ अपडेट होता रहता है।\nअसल में मुफ्त (और इस्तेमाल लायक) क्या है? \u0026ldquo;फ्री टियर\u0026rdquo; के दावे ज्यादातर मार्केटिंग का दिखावा होते हैं, लेकिन इनमें से कुछ वाकई प्रोटोटाइपिंग या कम-वॉल्यूम प्रोडक्शन के लिए उपयोगी हैं:\nGoogle Gemini API — बड़े प्रोवाइडर्स में सबसे उदार। फ्री टियर Gemini Flash मॉडल्स पर रोज़ाना 1,500 रिक्वेस्ट देता है, न क्रेडिट कार्ड चाहिए, न कोई एक्सपायरी [13]। Gemini 2.5 Flash और Flash-Lite दोनों फ्री टियर पर \u0026ldquo;अनलिमिटेड टोकन\u0026rdquo; दिखाते हैं (रेट लिमिट्स के अधीन) [3]। Groq — Llama 3.3 70B पर 30 रिक्वेस्ट/मिनट, 1,000 रिक्वेस्ट/दिन, और 100K टोकन/दिन की पब्लिश्ड लिमिट्स [13]। इसे उनकी LPU स्पीड के साथ मिलाएं तो यह लेटेंसी-सेंसिटिव किसी भी काम के लिए एक ठोस फ्री विकल्प बन जाता है। Cerebras — उपलब्ध सबसे तेज़ इंफरेंस हार्डवेयर पर रोज़ाना 1 मिलियन टोकन, मुफ्त [9]। OpenRouter — दो दर्जन से ज्यादा ओपन मॉडल्स पर 20 RPM / 1,000 RPD तक, कार्ड की ज़रूरत नहीं [12]। OpenAI — नए अकाउंट्स को लगभग $5 का क्रेडिट देता है जो एक्टिवेशन के तीन महीने बाद एक्सपायर हो जाता है, लेकिन शुरू से ही आपके अकाउंट में क्रेडिट कार्ड होना ज़रूरी है [13]। यह उसी मायने में असली \u0026ldquo;फ्री टियर\u0026rdquo; नहीं है। Anthropic — नए अकाउंट्स के लिए छोटे ट्रायल क्रेडिट्स, साथ ही एक अलग प्रोग्राम जो योग्य ओपन-सोर्स मेंटेनर्स को 6 महीने का Claude Max एक्सेस (लगभग $1,200 की वैल्यू, 10,000 स्पॉट्स) देता है [13]। अगर आप सिर्फ प्रोटोटाइप कर रहे हैं, तो अभी का सबसे मजबूत फ्री स्टैक है: सामान्य क्षमता के लिए Gemini, स्पीड-सेंसिटिव कॉल्स के लिए Groq, और जो भी नया ओपन मॉडल अभी-अभी आया है उसे आज़माने के लिए OpenRouter [13]।\nतो मैं असल में क्या इस्तेमाल करूंगा? ऊपर बताई गई सारी बातों के आधार पर, मैं इसे असली फैसलों में इस तरह बदलूंगा:\nआपकी स्थिति मैं क्या चुनूंगा क्यों प्रोटोटाइपिंग / हॉबी प्रोजेक्ट Gemini फ्री टियर या OpenRouter फ्री मॉडल्स जीरो कॉस्ट, ठीक-ठाक क्वालिटी, कार्ड की ज़रूरत नहीं हाई-वॉल्यूम, रिपीटेटिव टास्क (क्लासिफिकेशन, बल्क समराइज़ेशन) कैशिंग के साथ DeepSeek V4 Flash $0.0028/M पर कैश हिट्स लगभग नगण्य हैं [8] लेटेंसी-क्रिटिकल चैट/एजेंट्स Groq (Llama 3.1 8B) या Cerebras लगभग-शून्य कॉस्ट पर LPU/वेफर-स्केल स्पीड [9][10] मजबूत रीज़निंग चाहने वाला, कॉस्ट-कॉन्शियस प्रोडक्शन ऐप प्रॉम्प्ट कैशिंग के साथ Claude Haiku 4.5 या GPT-5.4-mini अच्छा क्वालिटी-टू-कॉस्ट रेश्यो, मच्योर टूलिंग [1][2] बेस्ट-इन-क्लास क्वालिटी, कॉस्ट गौण Claude Opus 4.8 या GPT-5.5 पाइपलाइन के नॉन-रियलटाइम हिस्सों के लिए Batch API इस्तेमाल करें [1][2] पहले से AWS में गहराई से जुड़े हैं और Claude चाहिए Bedrock, लेकिन क्रॉस-रीजन 10% सरचार्ज पर ध्यान दें डायरेक्ट जैसी ही प्राइसिंग, साथ ही AWS बिलिंग/IAM इंटीग्रेशन [5] एंटरप्राइज़ कंप्लायंस आवश्यकताएं Azure OpenAI या Vertex AI Standard टियर VPC कंट्रोल्स, रेज़िडेंसी, सपोर्ट SLA के लिए मार्कअप चुकाएं [6][3] इसे ठोस बनाने के लिए: Anthropic के अपने वर्क्ड एग्ज़ाम्पल के मुताबिक, स्टैंडर्ड रेट्स पर Claude Haiku 4.5 से 10,000 सपोर्ट टिकट्स प्रोसेस करने की कीमत लगभग $37 आती है — और कैशिंग के साथ यह और भी कम हो जाती है [1]। डॉलर के मुकाबले लगभग 88 रुपये की दर से, यह 10,000 कन्वर्सेशंस के लिए लगभग 3,250 रुपये बैठता है — किसी प्रोडक्शन सपोर्ट बॉट के लिए इसे मात देना सच में मुश्किल है।\nइतनी खोजबीन के बाद ईमानदार निष्कर्ष यह है: DeepSeek और ओपन-वेट प्रोवाइडर्स (Groq, Cerebras, Together AI) वो प्राइस फ्लोर बन चुके हैं जिसके सामने बड़ी लैब्स को मजबूरन मुकाबला करना पड़ रहा है [10][14]। Anthropic की 67% Opus प्राइस कटौती और OpenAI के nano/mini वेरिएंट्स की भरमार खालीपन में नहीं हो रही — ये उन मॉडल्स का सीधा जवाब हैं जिनकी कीमत चंद पैसे है और जो असली वर्कलोड्स के एक बड़े हिस्से के लिए \u0026ldquo;काफी अच्छे\u0026rdquo; हैं। क्या \u0026ldquo;काफी अच्छा\u0026rdquo; वाकई आपके टास्क के लिए काफी है, यह कोई प्राइसिंग पेज नहीं बता सकता। आपको इसे खुद टेस्ट करना होगा।\nस्रोत Claude API Pricing - Anthropic Docs OpenAI API Pricing Gemini Developer API Pricing Anthropic Claude API Pricing In 2026 - CloudZero Amazon Bedrock Pricing - AWS Azure OpenAI Service - Pricing | Microsoft Azure OCI Generative AI Pricing - Oracle Models \u0026amp; Pricing - DeepSeek API Docs Cerebras Pricing Groq API Pricing - AI Pricing Guru Mistral AI Pricing Free AI Models on OpenRouter Free LLM APIs in 2026: Every Provider With Free Tier Tested - TokenMix LLM API Pricing Comparison In 2026 - CloudZero ","permalink":"https://cloudmato.com/hi/posts/cheapest-llm-api-2026-pricing-comparison/","title":"2026 में सबसे सस्ता LLM API: Claude बनाम GPT बनाम AWS बनाम OCI"},{"content":"Chrome DevTools में Performance panel को पहली बार खोलें तो ऐसा लगता है जैसे किसी ने आपकी स्क्रीन पर रंगीन क्रेयॉन का पूरा डिब्बा उड़ेल दिया हो। दर्जनों रंग-बिरंगी बार्स, आधा दर्जन ट्रैक्स, और नीचे तीन टैब जो सब एक जैसी ही चीज़ दिखाते लगते हैं लेकिन थोड़ा अलग ढंग से। कोई आश्चर्य नहीं कि ज़्यादातर डेवलपर्स एक trace रिकॉर्ड करते हैं, घबरा जाते हैं, और वापस console.log डिबगिंग पर लौट जाते हैं। मैं भी सालों तक यही करता रहा - जब तक मैंने वाकई बैठकर यह नहीं समझा कि हर हिस्सा क्या मतलब रखता है, और अब जब भी कुछ \u0026ldquo;धीमा महसूस होता है\u0026rdquo; तो यही पहला टूल होता है जिसकी ओर मैं हाथ बढ़ाता हूँ।\nयह पैनल सीखने की मेहनत के लायक क्यों है Lighthouse आपको एक स्कोर देता है। Performance panel आपको क्यों बताता है। यह आपके पेज के चलने के दौरान ब्राउज़र द्वारा किए जाने वाले हर काम की एक पूरी टाइमलाइन रिकॉर्ड करता है - हर JavaScript फ़ंक्शन कॉल, हर लेआउट रीकैल्क्युलेशन, हर पेंट, हर नेटवर्क रिक्वेस्ट - और आपको इसे फ्रेम-दर-फ्रेम स्क्रब करने देता है [1]।\nइसे थर्मामीटर और CT स्कैन के फ़र्क की तरह सोचिए। थर्मामीटर (Lighthouse, PageSpeed Insights, आपका Core Web Vitals डैशबोर्ड) आपको बताता है कि कुछ गड़बड़ है। Performance panel आपको ठीक-ठीक बताता है कि कौन-सा \u0026ldquo;अंग\u0026rdquo; समस्या पैदा कर रहा है, और किस मिनट से वह गड़बड़ करने लगा।\nआज जब आप पैनल खोलते हैं, तो आपका स्वागत एक Live Metrics स्क्रीन से होता है जो रीयल-टाइम Core Web Vitals - LCP, CLS, और INP - दिखाती है, और जैसे-जैसे आप पेज पर क्लिक करते हैं ये अपडेट होते रहते हैं [3]। यह अपेक्षाकृत नया फ़ीचर है, और सच में काफ़ी काम का है क्योंकि यह जानने के लिए कि कुछ टूटा हुआ है या नहीं, आपको trace रिकॉर्ड करने की ज़रूरत भी नहीं पड़ती।\nअपना पहला trace रिकॉर्ड करना: runtime बनाम reload दो बिल्कुल अलग चीज़ें हैं जिन्हें आप शायद मापना चाहें, और DevTools इनमें से हर एक के लिए एक बटन देता है:\nRecord (गोल बटन) - तब की गतिविधि कैप्चर करता है जब आप किसी लाइव पेज के साथ इंटरैक्ट करते हैं। इसे स्क्रॉलिंग, टाइपिंग, बटन क्लिक करने, मोडल खोलने - यानी पेज लोड हो जाने के बाद होने वाली किसी भी चीज़ के लिए इस्तेमाल करें। Record and reload - पूरे पेज लोड को कैप्चर करता है, navigation से लेकर \u0026ldquo;fully loaded\u0026rdquo; तक। DevTools पहले बचे हुए स्क्रीनशॉट्स और traces हटाने के लिए about:blank पर जाता है, फिर आपके पेज को रीलोड करता है और लोड पूरा होने के कुछ सेकंड बाद अपने आप रिकॉर्डिंग बंद कर देता है [3]। रिकॉर्ड दबाने से पहले, capture settings खोलने के लिए गियर आइकन पर क्लिक करें। यहीं ज़्यादातर उपयोगी सेटिंग्स मौजूद होती हैं:\nScreenshots - एक फ़िल्म स्ट्रिप कैप्चर करता है ताकि आप देख सकें कि हर समय-बिंदु पर यूज़र ने वास्तव में क्या देखा था Force garbage collection - रिकॉर्डिंग शुरू होने से पहले एक GC रन ट्रिगर करता है, यह तब काम आता है जब आप मेमोरी से जुड़ी jank ढूँढ रहे हों CPU and network throttling - इस पर आगे विस्तार से बात करेंगे JavaScript samples - विस्तृत call stacks को दृश्यमान रखता है (यह डिफ़ॉल्ट रूप से ऑन रहता है, और इसे बंद करने से flame chart काफ़ी कम उपयोगी हो जाता है, इसलिए बिना किसी कारण के इसे न छेड़ें) CSS selector stats - दिखाता है कि style recalculation के दौरान कौन-से selectors महँगे साबित होते हैं Advanced paint instrumentation - paint ऑपरेशन का विस्तृत डेटा दिखाता है [2] मेरी सलाह है कि पहले एक छोटा trace रिकॉर्ड करें - किसी इंटरैक्शन के बस 3-5 सेकंड भी काफ़ी हैं। लंबी रिकॉर्डिंग्स में नेविगेट करना मुश्किल होता है और इन्हें प्रोसेस करते समय DevTools धीमा पड़ सकता है। छोटी, केंद्रित रिकॉर्डिंग्स पढ़ने में आसान और विश्लेषण में तेज़ होती हैं।\nFlame chart पढ़ना: main thread को समझना यही वह हिस्सा है जो लोगों को डराता है, तो आइए थोड़ा धीरे चलें। Flame chart Main ट्रैक में होता है और समय के साथ main thread पर हो रही हर चीज़ को विज़ुअलाइज़ करता है [1]।\nX-अक्ष समय है। बाएँ से दाएँ, बिल्कुल एक सामान्य टाइमलाइन की तरह। Y-अक्ष call stack की गहराई है। ऊपर मौजूद फ़ंक्शन अपने नीचे वाले फ़ंक्शन को कॉल करता है, जो उससे नीचे वाले किसी और फ़ंक्शन को कॉल करता है। ध्यान दें कि यह पारंपरिक flame graph के मुक़ाबले \u0026ldquo;उल्टा\u0026rdquo; है - DevTools में, parents अपने children के नीचे नहीं बल्कि ऊपर बैठते हैं [6]। हर बार एक फ़ंक्शन कॉल (या ब्राउज़र इवेंट) है। चौड़ी बार का मतलब है कि उसे एक्ज़ीक्यूट होने में ज़्यादा समय लगा। रंग कैटेगरी दर्शाते हैं - पीला scripting (आपका JS) के लिए, बैंगनी rendering (style/layout) के लिए, हरा painting के लिए, और ग्रे \u0026ldquo;other\u0026rdquo;/idle गतिविधि के लिए। यह रहा वह डायग्राम जिसने आख़िरकार मेरे लिए यह बात साफ़ कर दी:\nजैसे ही आप बार्स पर क्लिक करना शुरू करेंगे, दो शब्द आपको बार-बार दिखेंगे:\nSelf time - फ़ंक्शन खुद कितनी देर चला, उसके द्वारा कॉल की गई किसी भी चीज़ को छोड़कर। Total time - self time के साथ-साथ इसके children ने जो भी किया वह सब। एक चौड़ी processData() बार का मतलब अपने आप यह नहीं है कि processData() ही समस्या है। हो सकता है यह सिर्फ़ JSON.parse() के चारों ओर एक पतला रैपर हो, जो असल में सारा काम कर रहा हो। Self time आपको बताता है कि असली दोषी कौन है; total time आपको बताता है कि अपराध स्थल के सबसे क़रीब कौन खड़ा है [6]।\nCall Tree, Bottom-Up, Event Log: वही डेटा, तीन अलग नज़रिए जब आप flame chart में किसी बार पर क्लिक करते हैं, तो पैनल का निचला हिस्सा विवरण दिखाने लगता है। वहाँ तीन टैब होते हैं, और सच कहूँ तो यह समझने में मुझे शर्मनाक हद तक ज़्यादा समय लग गया कि कब कौन-सा टैब इस्तेमाल करना है।\nव्यू क्या दिखाता है किसके लिए सबसे अच्छा Call Tree root activities से शुरू होने वाला टॉप-डाउन व्यू, जिसे उनके children में विस्तारित किया जा सकता है प्रोग्राम के फ़्लो को फ़ॉलो करना - \u0026ldquo;किसने किसे ट्रिगर किया\u0026rdquo; Bottom-Up उल्टा व्यू, उन फ़ंक्शनों से शुरू होकर जहाँ असल में समय खर्च हुआ, पूरी रिकॉर्डिंग में एकत्रित किया गया पूरे trace में अपने सबसे बड़े अपराधी को ढूँढना Event Log हर इवेंट की कालक्रमानुसार सूची, टाइमस्टैम्प के साथ, कैटेगरी और duration के लिए फ़िल्टर के साथ यह पता लगाना कि कोई चीज़ कब हुई, ख़ासकर नेटवर्क रिक्वेस्ट्स और यूज़र इंटरैक्शन्स Call Tree इस सवाल का जवाब देता है \u0026ldquo;हम यहाँ तक कैसे पहुँचे?\u0026rdquo; - यह root activities दिखाता है और आपको यह जानने देता है कि किस फ़ंक्शन ने सबसे ज़्यादा काम किया [1]। Bottom-Up टैब इसे उलट देता है: यह हर फ़ंक्शन के Self Time को उसके सभी occurrences में एकत्रित कर देता है, जिससे जो फ़ंक्शन सबसे ज़्यादा CPU खा रहा है वह सीधे ऊपर आ जाता है, चाहे उसे कहीं से भी कॉल किया गया हो [2]। अगर आप सिर्फ़ एक ही टैब सीखना चाहें, तो यही सीखें - \u0026ldquo;ठीक है, यही फ़ंक्शन समस्या है\u0026rdquo; तक पहुँचने का यह सबसे तेज़ रास्ता है।\nEvent Log का संबंध CPU समय से कम और क्रम (sequence) से ज़्यादा है - मैं यहाँ तब जाता हूँ जब मुझे ठीक-ठीक यह जानना हो कि किसी layout shift के सापेक्ष कोई नेटवर्क रिक्वेस्ट कब फ़ायर हुई, साथ ही Loading, Scripting, Rendering, या Painting कैटेगरी के हिसाब से फ़िल्टरिंग की सुविधा भी मिलती है [2]।\nCall Tree और Bottom-Up दोनों regex search, case-sensitive मैचिंग, और \u0026ldquo;group by\u0026rdquo; विकल्पों (URL के अनुसार, कैटेगरी के अनुसार, या खुद activity के अनुसार) को सपोर्ट करते हैं, जो ज़रूरी हो जाता है जब आपके trace में हज़ारों एंट्रीज़ हों [2]।\n50-मिलीसेकंड का नियम: long tasks का शिकार इस पूरे लेख का सबसे महत्वपूर्ण अकेला नंबर यह है: 50 मिलीसेकंड। main thread पर किसी भी निर्बाध काम का ऐसा हिस्सा जो इससे ज़्यादा समय तक चलता है, उसे आधिकारिक रूप से \u0026ldquo;long task\u0026rdquo; कहा जाता है, और DevTools बार के कोने में एक लाल त्रिकोण लगाकर इसे फ़्लैग करता है, जिसमें 50ms से ऊपर वाला हिस्सा लाल रंग से शेड किया जाता है [5]।\nयह इतना मायने क्यों रखता है? क्योंकि main thread एक समय में सिर्फ़ एक ही काम कर सकता है। जब यह आपके 380ms वाले onClick हैंडलर को चलाने में व्यस्त है, तब यह किसी टैप, स्क्रॉल, या की-प्रेस का जवाब नहीं दे सकता। यूज़र का इनपुट बस एक क्यू में पड़ा रह जाता है। यही सीधा कारण है कि आपका Interaction to Next Paint (INP) स्कोर गिर जाता है - और INP Google के तीन Core Web Vitals में से एक है।\nइन्हें ढूँढने के लिए मेरा वर्कफ़्लो:\nवह इंटरैक्शन रिकॉर्ड करें जो jank जैसा महसूस होता है। लाल त्रिकोण वाली बार्स के लिए Main ट्रैक स्कैन करें। सबसे चौड़ी वाली बार पर क्लिक करें। Bottom-Up पर स्विच करें, Self Time के अनुसार सॉर्ट करें, और देखें कि कौन-सा फ़ंक्शन thread को जकड़े हुए है। उस फ़ंक्शन को ठीक करें। एक शानदार वास्तविक उदाहरण एक डेवलपर का है जिसने सर्च रिज़ल्ट्स पेज को trace किया और पाया कि हर API रिस्पॉन्स एक Redux dispatch ट्रिगर करता था, जो पूरे component tree को फिर से रेंडर कर देता था। list virtualization अपनाने के बाद एक ही हैंडलर का long task खर्च 400ms से घटकर 70ms रह गया - और उनका p75 First Input Delay 140ms से घटकर 25-30ms हो गया, मोबाइल डिवाइसों पर तो 85% सुधार देखा गया [7]। एक अन्य केस स्टडी में सिर्फ़ इनपुट को debounce करने और DOM अपडेट्स को batch करने से एक प्रोडक्ट फ़िल्टर का blocking time 118ms से घटकर 22ms हो गया [6]। ये कोई काल्पनिक आँकड़े नहीं हैं - यही वो काम है जिसके लिए यह पैनल बना है।\nतो एक बार long task मिल जाने के बाद उसे असल में ठीक कैसे करें? कुछ आज़माए हुए तरीके:\nकाम को टुकड़ों में बाँटें - setTimeout() का उपयोग करके हर टुकड़े को उसके अपने task में डालें - यह मूल, थोड़ा hacky लेकिन काम का तरीका है [5]। scheduler.yield() का इस्तेमाल करें - यह आधुनिक, इसी काम के लिए बनाया गया API है। await scheduler.yield() आपके फ़ंक्शन को रोक देता है, ब्राउज़र को किसी ज़्यादा ज़रूरी चीज़ (जैसे वह इनपुट इवेंट) को संभालने देता है, और फिर ठीक वहीं से दोबारा शुरू हो जाता है जहाँ इसे रोका गया था [5]। उन ब्राउज़रों के लिए gracefully fallback करें जो अभी इसे सपोर्ट नहीं करते: function yieldToMain() { if (globalThis.scheduler?.yield) { return scheduler.yield(); } return new Promise(resolve =\u0026gt; setTimeout(resolve, 0)); } जब काम के लिए DOM एक्सेस की बिल्कुल ज़रूरत न हो, तो Web Workers का उपयोग करके काम को main thread से पूरी तरह हटा दें। गैर-ज़रूरी स्क्रिप्ट्स को defer या lazy-load करें ताकि वे पेज लोड के दौरान main thread के लिए होड़ न करें। Throttling: अपने गेमिंग लैपटॉप को बजट Android फ़ोन जैसा महसूस कराना यह रहा एक असहज सच: आपकी dev मशीन आपसे झूठ बोल रही है। आप आठ कोर और गीगाबिट फ़ाइबर वाले लैपटॉप पर टेस्ट कर रहे हैं। आपके ज़्यादातर यूज़र्स कमज़ोर 4G वाले मिड-रेंज फ़ोन पर हैं। Performance panel की throttling सेटिंग्स ख़ास तौर पर इसी अंतर को पाटने के लिए मौजूद हैं।\nसेटिंग विकल्प यह क्या सिमुलेट करती है CPU throttling No throttling, 4x slowdown, 6x slowdown, या एक calibrated कस्टम प्रीसेट धीमे प्रोसेसर - \u0026ldquo;4x\u0026rdquo; का मतलब है कि हर चीज़ को एक्ज़ीक्यूट होने में 4 गुना ज़्यादा समय लगता है [4] Network throttling Fast 4G, Slow 4G, कस्टम प्रीसेट्स वास्तविक दुनिया की कनेक्शन स्पीड और लेटेंसी Calibrated CPU throttling आपकी असली मशीन को बेंचमार्क करता है और एक कस्टम प्रीसेट बनाता है low/mid-tier मोबाइल डिवाइसों के लिए ज़्यादा सटीक मिलान [4] यहाँ एक सीमा के बारे में ईमानदार होना ज़रूरी है: DevTools किसी फ़ोन के CPU को पूरी तरह emulate नहीं कर सकता, क्योंकि मोबाइल चिप्स का आर्किटेक्चर डेस्कटॉप CPU से मूलतः अलग होता है (अलग core types, thermal throttling, वग़ैरह) [4]। 4x/6x मल्टीप्लायर एक मोटा अनुमान भर है, न कि डिब्बे में बंद कोई फ़ोन। नया calibration फ़ीचर - जो आपकी मशीन को बेंचमार्क करके एक ज़्यादा यथार्थवादी प्रीसेट तैयार करता है - इस अंतर को पाटने की दिशा में एक सार्थक क़दम है, लेकिन मैं अब भी throttled नतीजों को \u0026ldquo;दिशा में सही\u0026rdquo; मानूँगा, न कि \u0026ldquo;बिल्कुल वैसा जैसा कोई Pixel 4a दिखाएगा।\u0026rdquo;\nफिर भी, मोटा-मोटा throttling भी काफ़ी कुछ उजागर कर देता है। मैंने ऐसे इंटरैक्शन देखे हैं जो मेरी dev मशीन पर तुरंत महसूस होते थे, लेकिन 6x CPU slowdown ऑन करते ही 600ms से ज़्यादा के freeze में बदल गए। अगर आपकी टीम में \u0026ldquo;throttling ऑन करके टेस्ट करने\u0026rdquo; की आदत नहीं है, तो शायद यही वह सबसे क़ीमती बदलाव है जो आप आज अपनी टेस्टिंग रूटीन में कर सकते हैं।\nLive metrics और Insights साइडबार: Core Web Vitals, बिल्कुल अंदर ही समाहित Performance panel के नए डिज़ाइन में एक Live Metrics लैंडिंग पेज जोड़ा गया है जो LCP, CLS, और INP को रीयल टाइम में अपडेट होते हुए दिखाता है - और सबसे ज़रूरी बात, यह आपके local (lab) डेटा और Chrome UX Report (CrUX) से लिए गए field डेटा को साथ-साथ दिखाता है, ताकि आप देख सकें कि आपका टेस्ट सेशन वास्तविक यूज़र्स के अनुभव से कितना मेल खाता है [3] [8]।\ntrace रिकॉर्ड करने के बाद, Insights साइडबार सामने आता है। यहीं हाल के बदलाव असल में चमकते हैं - यह मूल रूप से Lighthouse-शैली के audits को आपके असली trace डेटा के साथ मिला देता है [8]:\nफ़ेज़ के अनुसार LCP breakdown - आपके Largest Contentful Paint को Time to First Byte, resource load delay, resource load time, और element render delay में बाँटता है, ताकि आपको पता चले कि किस फ़ेज़ पर काम करना है [9] Render-blocking requests - उन स्क्रिप्ट्स/स्टाइल्स को फ़्लैग करता है जो first paint को रोक रहे हैं, अक्सर \u0026ldquo;इस critical CSS को inline करें\u0026rdquo; जैसा एक-लाइन का सुझाव भी देता है [9] Layout Shift clusters - CLS पैदा करने वाले shifts को \u0026ldquo;session windows\u0026rdquo; में समूहित करता है ताकि आप देख सकें कि कौन-से DOM बदलाव इसके लिए ज़िम्मेदार हैं [9] क्लिक करने योग्य culprits - फ़्लैग किए गए LCP element या INP target पर क्लिक करते ही आप सीधे Elements panel में उस नोड पर पहुँच जाते हैं [8] जल्दी से \u0026ldquo;good/needs improvement/poor\u0026rdquo; का अंदाज़ा लगाने के लिए याद रखने लायक थ्रेशोल्ड: 2.5 सेकंड से कम LCP अच्छा है, 0.1 से कम CLS अच्छा है, और 200ms से कम INP अच्छा है [9]। अगर Insights panel इनमें से किसी को लाल रंग में फ़्लैग करता है, तो वही आपका शुरुआती बिंदु है - बिना सोचे-समझे flame chart में मत भटकिए।\nएक अलग Performance Monitor panel के बारे में भी जानना उपयोगी है - यह एक हल्का, हमेशा-चालू डैशबोर्ड है जो live CPU उपयोग, JS heap साइज़, DOM नोड काउंट, और event listener काउंट दिखाता है। मुझे कुछ भी रिकॉर्ड करने से पहले इसे खोलना पसंद है, बस यह अंदाज़ा लगाने के लिए कि कहीं समय के साथ कोई चीज़ मेमोरी लीक या listeners जमा तो नहीं कर रही [15]।\nशोर को छाँटना: ignore lists और third parties को धुँधला करना एक असली trace भरा-पूरा होता है। Analytics स्क्रिप्ट्स, ad tags, चैट विजेट्स, आपके फ्रेमवर्क की आंतरिक चीज़ें - ये सब बार्स के रूप में दिखकर आपका ध्यान खींचने की होड़ करते हैं। DevTools शोर को कम करने के कुछ तरीके देता है:\nस्क्रिप्ट्स को ignore list में जोड़ें - flame chart में किसी भी एंट्री पर राइट-क्लिक करें और \u0026ldquo;Add script to ignore list\u0026rdquo; चुनें। उस स्क्रिप्ट के फ़्रेम्स एक ही एंट्री में सिमट जाते हैं, और वही ignore list तब भी लागू होती है जब आप Sources panel में कोड के बीच step कर रहे हों। ये नियम DevTools सेशन्स के बीच बने रहते हैं [11]। \u0026ldquo;Dim 3rd parties\u0026rdquo; चेकबॉक्स - trace में third-party स्क्रिप्ट्स और नेटवर्क रिक्वेस्ट्स को धूसर (grey) कर देता है ताकि first-party कोड विज़ुअली उभरकर दिखे [10]। Summary टैब की first/third-party टेबल - एक नया जोड़ है जो first-party कोड, third-party कोड, और ब्राउज़र एक्सटेंशन्स द्वारा खर्च किए गए समय को अलग-अलग दिखाता है, और trace में hover करने पर हाइलाइट हो जाता है [10]। Cmd/Ctrl+F से सर्च करें - पूरे trace में activity के नामों को खोजता है, साथ ही regex और case-sensitivity के टॉगल भी मिलते हैं [2]। नेविगेशन में एक और बदलाव जानने लायक है: DevTools अब \u0026ldquo;Modern\u0026rdquo; बनाम \u0026ldquo;Classic\u0026rdquo; स्क्रॉलिंग मोड्स देता है। Classic मोड में, आपका स्क्रॉल व्हील ज़ूम करता है और Shift+scroll pan करता है। Modern मोड में यह उल्टा है - सीधा स्क्रॉल टाइमलाइन को pan करता है, ठीक वैसे जैसा आप किसी भी अन्य पेज पर उम्मीद करते हैं, और Shift+scroll ज़ूम करता है [10]। अगर पैनल में स्क्रॉल करना आपको कभी उल्टा महसूस हुआ है, तो यही इसकी वजह है।\nईमानदारी से कहूँ तो, यह उन फ़ीचर्स में से एक है जिसके बारे में काश मुझे महीनों पहले पता होता - ignore list की मदद से यह सब समेटा जा सकता है, यह जानने से पहले मैंने \u0026ldquo;अपने\u0026rdquo; फ़ंक्शनों को ढूँढने के लिए webpack-bundled vendor कोड को मैन्युअल रूप से स्क्रॉल करते हुए बहुत ज़्यादा समय बर्बाद किया।\nअपने निष्कर्षों को annotate करना, सेव करना, और शेयर करना कुछ दिलचस्प मिला? बस उसका स्क्रीनशॉट लेकर \u0026ldquo;look at this 😬\u0026rdquo; के साथ Slack पर मत चिपकाइए - trace को खुद ही annotate करें। DevTools 131 से, आप किसी रिकॉर्डिंग पर सीधे annotations जोड़ सकते हैं [12]:\nEntries को लेबल करें - किसी भी बार पर राइट-क्लिक (या डबल-क्लिक) करें और एक टेक्स्ट नोट जोड़ें जो बताए कि यह क्या है या यह धीमा क्यों है Entries को लिंक करें - कारण-और-प्रभाव दिखाने के लिए दो trace आइटम्स के बीच एक तीर खींचें, जैसे \u0026ldquo;इस नेटवर्क रिक्वेस्ट ने इस re-render को ट्रिगर किया\u0026rdquo; Time ranges - पूरे सेक्शन को हाइलाइट करने के लिए shift-click करके खींचें (drag), यह \u0026ldquo;यह third-party चैट विजेट initialize हो रहा है\u0026rdquo; जैसा मार्क करने में उपयोगी है जब आप पूरा कर लें, तो action bar में डाउनलोड आइकन पर क्लिक करें और Save trace चुनें। आप चाहें तो पेज की सभी स्क्रिप्ट कंटेंट और source maps की एक कॉपी भी शामिल कर सकते हैं - यानी जो भी बाद में आपका trace खोलेगा उसे आपका असली सोर्स कोड और एक काम करता हुआ Sources panel मिलेगा, सिर्फ़ minified गड़बड़-कोड नहीं [13]। मदद माँगने के लिए यह सच में शानदार है: किसी समस्या को बग रिपोर्ट में बताने के बजाय, आप एक .json trace फ़ाइल अटैच करके कह सकते हैं \u0026ldquo;इसे DevTools में खोलें और Main ट्रैक में 2-सेकंड के निशान के आसपास देखें।\u0026rdquo;\nGemini को अपने साथ trace पढ़ने देना इन सबके ऊपर सबसे नई परत AI असिस्टेंस की है। Chrome के DevTools में अब एक \u0026ldquo;Debug with AI\u0026rdquo; विकल्प है (पहले इसे \u0026ldquo;Ask AI\u0026rdquo; कहा जाता था) जो किसी trace एंट्री पर राइट-क्लिक करने पर दिखाई देता है, और आपने जो भी क्लिक किया है उसके आधार पर context-aware प्रॉम्प्ट्स देता है [14]।\nइससे भी ज़्यादा दिलचस्प बात यह है कि अब आप सिर्फ़ किसी एक अलग-थलग बार के बारे में पूछने तक सीमित नहीं हैं। trace रिकॉर्ड करने के बाद, आप Gemini से पूरे trace के बारे में बातचीत कर सकते हैं - टाइमलाइन, Insights साइडबार के निष्कर्ष, और यहाँ तक कि field डेटा भी - सब एक ही बातचीत में, किसी ख़ास इवेंट में जाने से पहले [14]। AI ख़ुद-ब-ख़ुद प्रासंगिक संदर्भ (कोई ख़ास long task, कोई render-blocking रिक्वेस्ट) ला सकता है, बिना आपके पहले से उसे मैन्युअली चुने।\nईमानदारी से कहूँ तो, मुझे \u0026ldquo;AI लेकिन DevTools के लिए\u0026rdquo; वाले आइडिया पर शक था - यह पहले से ही जटिल टूल में जोड़ा गया एक गिमिक जैसा लगता था। लेकिन \u0026ldquo;यह LCP इतना धीमा क्यों है?\u0026rdquo; पूछना और इसके जवाब में सीधी-सादी भाषा में एक स्पष्टीकरण मिलना जो ज़िम्मेदार सही resource और phase की ओर इशारा करे - यह जूनियर डेवलपर्स के लिए (या मेरे लिए, सोमवार की सुबह कॉफ़ी से पहले) LCP breakdown को network waterfall के साथ मैन्युअली मिलाने से कहीं ज़्यादा तेज़ रास्ता है।\nसब कुछ एक साथ अगर आप सिर्फ़ एक वर्कफ़्लो याद रखना चाहते हैं, तो यह रहा:\nDevTools खोलें, Performance पर जाएँ, और किसी स्पष्ट red flag के लिए Live Metrics पर एक नज़र डालें। वास्तविक यूज़र्स से मेल खाने के लिए throttling चालू करके Record (या Record and reload) दबाएँ। धीमा इंटरैक्शन करें, फिर रोकें। पहले Insights साइडबार देखें - हो सकता है यह सीधे आपको जवाब दे दे। red-flagged long tasks के लिए Main ट्रैक स्कैन करें। सबसे चौड़ी दोषी बार पर क्लिक करें, Bottom-Up पर स्विच करें, Self Time के अनुसार सॉर्ट करें। असली फ़ंक्शन को ठीक करें, दोबारा रिकॉर्ड करें, और तुलना करें। अगली बार जब आपकी टीम में कोई कहे \u0026ldquo;पेज बस धीमा सा लग रहा है,\u0026rdquo; तो आपको कंधे उचकाकर \u0026ldquo;हाँ, आजकल JS भारी हो गया है\u0026rdquo; कहने की ज़रूरत नहीं है। आप एक trace खोल सकते हैं, किसी ख़ास 380ms वाली बार की ओर इशारा कर सकते हैं, और ठीक-ठीक बता सकते हैं कि यह किस फ़ंक्शन का है।\nस्रोत Performance panel: Analyze your website\u0026rsquo;s performance Performance features reference | Chrome DevTools Analyze runtime performance | Chrome DevTools Throttling | Chrome DevTools Optimize long tasks | web.dev How to Read a Flame Graph in Chrome DevTools Profiling \u0026amp; Optimizing the runtime performance with the DevTools Performance tab Brand New Performance Features in Chrome DevTools | DebugBear Performance insights: Get actionable insights on your website\u0026rsquo;s performance Improved navigation and filtering in the DevTools Performance panel Ignore List | Chrome DevTools How To Annotate A Chrome DevTools Performance Trace | DebugBear Save and share performance traces | Chrome DevTools Chat with AI assistance | Chrome DevTools Performance monitor panel | Chrome DevTools ","permalink":"https://cloudmato.com/hi/posts/chrome-devtools-performance-panel-deep-dive/","title":"Chrome DevTools Performance Panel: कोड एक्ज़ीक्यूशन का विश्लेषण"},{"content":"जब भी कोई मुझसे पूछता है, \u0026ldquo;क्या मुझे सेशन इस्तेमाल करना चाहिए या JWT?\u0026rdquo;, मुझे पता होता है कि असल में इस सवाल के पीछे क्या है। उन्होंने कुछ ब्लॉग पोस्ट पढ़ी होंगी, \u0026ldquo;stateless\u0026rdquo; शब्द को इस तरह उछलते देखा होगा जैसे यह अपने आप में बेहतर हो, और अब वे उलझन में फँस गए हैं। तो चलिए इसे ठीक से सुलझाते हैं - buzzwords से नहीं, बल्कि यह देखकर कि वायर पर और आपके सर्वर पर असल में क्या हो रहा है।\nसेशन: \u0026ldquo;हम फ्रंट डेस्क पर रिकॉर्ड रखते हैं\u0026rdquo; वाला तरीका सेशन-आधारित ऑथ को किसी होटल में चेक-इन करने जैसा समझिए। आप फ्रंट डेस्क पर एक बार अपनी ID दिखाते हैं, स्टाफ उसे वेरीफ़ाई करता है, और आपको एक रूम की key card थमा देता है। उस card में आपका नाम, पासपोर्ट नंबर, या बुकिंग की डिटेल्स नहीं होतीं - वह बस एक रैंडम नंबर होता है। होटल के कंप्यूटर सिस्टम में आपकी असली सारी जानकारी उनके डेटाबेस में स्टोर होती है, जो उस card नंबर से जुड़ी होती है।\nसेशन-आधारित प्रमाणीकरण बिल्कुल इसी तरह काम करता है:\nआप अपने username और password से लॉग इन करते हैं। सर्वर आपकी credentials चेक करता है, एक सेशन रिकॉर्ड बनाता है (आपकी user ID, roles, लॉगिन टाइम, आदि), और इसे server-side स्टोर करता है - memory में, किसी database में, या Redis [2] जैसी किसी चीज़ में। सर्वर एक रैंडम सेशन ID जनरेट करता है और उसे एक cookie के रूप में वापस भेजता है, आमतौर पर HttpOnly फ्लैग के साथ ताकि JavaScript उसे छू न सके [3]। हर अगली request पर, आपका browser अपने आप वह cookie साथ भेज देता है। सर्वर उस सेशन ID को लेता है, अपने सेशन स्टोर में उसे ढूंढता है, और सोचता है, \u0026ldquo;अच्छा, यह Amit है, यह लॉग इन है, यह रहा इसका डेटा।\u0026rdquo; यहाँ सबसे ज़रूरी बात यह है: सेशन ID का अपने आप में कोई मतलब नहीं होता। यह बस एक pointer है। असली \u0026ldquo;सच्चाई\u0026rdquo; - आप कौन हैं, आप क्या कर सकते हैं - सर्वर पर ही रहती है [1]। अगर सर्वर का सेशन स्टोर डाउन हो जाए या साफ़ कर दिया जाए, तो हर लॉग-इन यूज़र तुरंत बाहर हो जाता है, भले ही उनकी cookie तकनीकी रूप से अब भी मान्य हो।\nयही वजह है कि सेशन-आधारित ऑथ दशकों से पारंपरिक server-rendered web apps के लिए डिफ़ॉल्ट रहा है। यह सरल है, अच्छी तरह समझा जा चुका है, और access को revoke करना मामूली काम है - बस सेशन table से वह row डिलीट कर दीजिए।\nJWT: \u0026ldquo;हर बार अपना ID बैज दिखाओ\u0026rdquo; वाला तरीका अब एक अलग सिस्टम की कल्पना कीजिए - database के रिकॉर्ड को point करने वाली room key की जगह, आपको एक laminated badge मिलता है। उस badge पर आपका नाम, आपकी फोटो, आपका access level, और एक tamper-evident hologram छपा होता है। UV scanner रखने वाला कोई भी व्यक्ति बिना फ्रंट डेस्क को वापस कॉल किए यह जाँच सकता है कि hologram असली है या नहीं।\nयही है JSON Web Token (JWT)। JWT एक self-contained, digitally signed string है जो डॉट्स से अलग किए गए तीन हिस्सों से बनती है: header.payload.signature [4][5]।\nHeader: यह बताता है token का प्रकार (JWT) और उसे sign करने के लिए कौन-सा algorithm इस्तेमाल हुआ, जैसे HS256 या RS256 [5]। Payload: असली claims - जैसे sub (user ID), role, iat (issued at), और exp (expiry time)। यह बस Base64Url-encoded JSON है, encrypted नहीं, इसलिए इसमें कोई भी secret मत डालिए [5][9]। Signature: header और payload को hash करके एक secret key (या private key) से sign किया जाता है। यही साबित करता है कि token के साथ छेड़छाड़ नहीं हुई है [4]। एक decoded JWT payload कुछ इस तरह दिख सकता है:\n{ \u0026#34;sub\u0026#34;: \u0026#34;user_8821\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Amit Kumar\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;admin\u0026#34;, \u0026#34;iat\u0026#34;: 1748505600, \u0026#34;exp\u0026#34;: 1748509200 } यहाँ वह हिस्सा है जो लोगों को कन्फ्यूज़ कर देता है: सर्वर इसे कहीं भी स्टोर नहीं करता। जब आप लॉग इन करते हैं, सर्वर इस payload पर sign करता है और पूरी चीज़ आपको थमा देता है। अगली request पर, आप वह token वापस भेजते हैं (आमतौर पर Authorization: Bearer \u0026lt;token\u0026gt; header में), और सर्वर बस signature को फिर से चेक करता है। अगर signature वैध है और token expire नहीं हुआ है, तो सर्वर payload में मौजूद हर चीज़ पर भरोसा कर लेता है - किसी database lookup की ज़रूरत नहीं [6][1]।\nआप खुद jwt.io debugger पर असली tokens के साथ खेल सकते हैं - कोई भी JWT पेस्ट कीजिए और यह तुरंत header और payload को decode कर देगा [4]।\nमूल अंतर: \u0026ldquo;सच्चाई\u0026rdquo; असल में कहाँ रहती है? ठीक है, यही वह हिस्सा है जो असल में मायने रखता है, और यही टाइटल में पूछे गए सवाल का जवाब भी है।\nसेशन में, सच्चाई सर्वर पर रहती है। JWT में, सच्चाई client के साथ सफ़र करती है।\nबाकी सब कुछ - cookies बनाम headers, scalability की बहसें, revocation की सिरदर्दी - इसी एक architectural फ़ैसले का नतीजा है। सेशन ऑथ stateful होता है: सर्वर को requests के बीच आपके बारे में कुछ याद रखना पड़ता है। JWT ऑथ (ज़्यादातर) stateless होता है: हर request अपने साथ वह सब कुछ लाती है जो सर्वर को फ़ैसला लेने के लिए चाहिए, और सर्वर बस एक cryptographic signature वेरीफ़ाई करता है [6][1]।\nयह एक अंतर लगभग हर उस practical trade-off में फैल जाता है जिसका आपको सामना करना पड़ेगा। जिस request को सेशन lookup चाहिए, उसकी लागत Redis या database store के मुक़ाबले लगभग 15ms होती है, जबकि JWT signature वेरीफ़ाई करने में लगभग 20ms लगते हैं लेकिन storage round-trip पूरी तरह बच जाता है - और बड़े पैमाने पर, JWT-based सिस्टम्स को distributed servers पर लगभग 1M requests/sec हैंडल करते हुए बेंचमार्क किया गया है, जबकि centralized सेशन stores के लिए यह आँकड़ा लगभग 500K req/sec है [11]। जब आप बड़े पैमाने पर काम कर रहे हों, तो यह कोई छोटा फ़र्क़ नहीं है।\nRevocation का वह सिरदर्द जिसका ज़िक्र समस्या बनने तक कोई नहीं करता यहीं से चीज़ें थोड़ी पेचीदा हो जाती हैं, और ईमानदारी से कहूं तो, यही वह हिस्सा है जिसे ज़्यादातर \u0026ldquo;JWT बेहतर है!\u0026rdquo; वाले लेख नज़रअंदाज़ कर देते हैं।\nसेशन के साथ, यूज़र को लॉग आउट करना तुरंत होता है। आप उसका सेशन रिकॉर्ड स्टोर से डिलीट कर देते हैं, और उस cookie वाली अगली request तुरंत फेल हो जाती है। किसी security incident की वजह से सबको force-logout करना है? बस सेशन table खाली कर दीजिए। हो गया [2]।\nJWT के साथ, डिलीट करने के लिए कोई सेशन रिकॉर्ड होता ही नहीं - statelessness का पूरा मतलब यही है। एक बार जब कोई JWT sign होकर client को दे दिया जाए, तो सर्वर के पास उसे \u0026ldquo;वापस लेने\u0026rdquo; का कोई built-in तरीका नहीं होता। यह तब तक मान्य रहता है जब तक expire न हो जाए, इसके बाद चाहे जो भी हो [7][8]। चाहे यूज़र अपना compromised password रीसेट कर ले, या कोई admin उसका account deactivate कर दे, पहले से जारी किया गया JWT तब तक काम करता रहेगा जब तक उसका exp claim कुछ और न कहे [8]।\nयह कोई काल्पनिक edge case नहीं है। Redis की अपनी engineering team ने एक लेख लिखा जिसका टाइटल ही था \u0026ldquo;JSON Web Tokens (JWT) are dangerous for user sessions\u0026rdquo;, जिसमें यह बात कही गई कि वही statelessness जो JWT को आकर्षक बनाती है, वही property इसे पारंपरिक login सेशन जैसी किसी भी चीज़ के लिए जोखिम भरा बना देती है [7]।\nतो असली सिस्टम्स इससे कैसे निपटते हैं? कुछ patterns स्टैंडर्ड बन चुके हैं:\nShort-lived access tokens (5-15 मिनट) के साथ ज़्यादा लंबे समय तक चलने वाले refresh tokens का इस्तेमाल। अगर कोई access token लीक हो जाए, तो नुक़सान की विंडो बहुत छोटी होती है [8]। Token families के साथ refresh token rotation - हर refresh पर एक नया refresh token जारी होता है, और अगर कोई पुराना, पहले से इस्तेमाल हो चुका token दोबारा सामने आए, तो पूरी family revoke कर दी जाती है (चोरी का एक मज़बूत संकेत) [8]। Denylists - revoke किए गए token IDs (jti claim) की एक server-side लिस्ट Redis जैसी किसी चीज़ में रखना, जिसका TTL token की expiry से मेल खाता हो [8]। कुछ नोटिस किया? इनमें से हर एक \u0026ldquo;फिक्स\u0026rdquo; थोड़ा-बहुत server-side state वापस ले आता है। तो practice में, जैसे ही आपको real-world logout, password-reset invalidation, या permission बदलाव चाहिए, pure stateless JWT ऑथ ज़्यादातर एक मिथक बनकर रह जाता है। असल में आपको जो मिलता है वह है \u0026ldquo;ज़्यादातर stateless, साथ में एक छोटा-सा stateful safety net।\u0026rdquo; यह JWT पर कोई आरोप नहीं है - यह बस ईमानदार तस्वीर है, और OWASP की अपनी guidance भी terminated sessions के लिए denylist बनाए रखने की साफ़ सिफ़ारिश करती है [9]।\nआप टोकन को कहाँ स्टोर करते हैं, यह असल में बहुत मायने रखता है एक और चीज़ जो लोगों को उलझा देती है वह यह है: JWT बनाम सेशन का सवाल इससे बिल्कुल अलग है कि आप token को browser में कहाँ स्टोर करते हैं, लेकिन इन दोनों को अक्सर आपस में मिला दिया जाता है।\nसेशन ID लगभग हमेशा एक cookie में स्टोर होती है, आमतौर पर HttpOnly और Secure के साथ, ताकि client-side JavaScript उसे कभी पढ़ ही न सके [3]। JWT को localStorage, sessionStorage, या किसी cookie में स्टोर किया जा सकता है - और इस चुनाव के असली security परिणाम होते हैं। अगर आप JWT को localStorage में ठूँस देते हैं, तो आपकी साइट पर कोई भी सफल XSS attack उसे पढ़कर सीधे exfiltrate कर सकता है - यहाँ browser-level कोई सुरक्षा नहीं है [10]। HttpOnly फ्लैग वाली cookies को XSS के ज़रिए चुराना मुश्किल होता है क्योंकि JavaScript उन्हें पढ़ ही नहीं सकता, हालांकि इनकी अपनी एक चिंता भी है: चूँकि cookies हर request के साथ अपने आप भेज दी जाती हैं, इसलिए आपको SameSite cookie attributes या anti-CSRF tokens का इस्तेमाल करके CSRF से बचाव करना पड़ता है [10]।\nवह pattern जिसने हाल ही में काफ़ी लोकप्रियता पाई है, और जिसे मैं सच में recommend करूंगा अगर आप कुछ नया बना रहे हैं:\nShort-lived access token को memory में रखें (एक JS variable या app state में) - कभी persist न करें, ताकि page reload होते ही यह मिट जाए। Refresh token को एक HttpOnly, Secure, SameSite cookie में रखें - जो JS की पहुँच से बाहर हो, और अपने आप सिर्फ़ आपके auth endpoint पर ही भेजा जाए। Page load पर, उस cookie का इस्तेमाल करके चुपचाप अपने refresh endpoint को कॉल करें और एक नया access token बनवा लें [10]। इसमें setup का काम थोड़ा ज़्यादा है, लेकिन यह आपको दोनों का सबसे अच्छा हिस्सा देता है - XSS आसानी से किसी long-lived credential को नहीं चुरा सकता, और CSRF से बचाव सिर्फ़ एक छोटे, सीमित refresh endpoint तक सीमित रहता है।\nसेशन बनाम JWT: साथ-साथ तुलना चलिए इसे साफ़-साफ़ सामने रख देते हैं, क्योंकि अब तक आपके पास इन्हें ठीक से तौलने के लिए पर्याप्त context है।\nपहलू सेशन-आधारित JWT-आधारित \u0026ldquo;सच्चाई\u0026rdquo; कहाँ रहती है Server-side store (DB/Redis/memory) [1] खुद signed token के अंदर [6] State मॉडल Stateful ज़्यादातर stateless (कुछ शर्तों के साथ) [1][8] आम transport सेशन ID के साथ HttpOnly cookie [3] Authorization: Bearer header या cookie [4] Logout / revocation तुरंत - सेशन रिकॉर्ड डिलीट करें [2] मुश्किल - short expiry, denylist, या refresh rotation चाहिए [7][8] Cross-domain / microservices इस्तेमाल services के बीच shared सेशन store चाहिए [12] कोई भी service shared key/cert से स्वतंत्र रूप से वेरीफ़ाई कर सकती है [6] Wire पर payload का आकार बहुत छोटा (बस एक ID, ~32 बाइट्स) बड़ा - हर request पर पूरे claims भेजे जाते हैं [5] Load में scalability centralized store के साथ ~500K req/sec [11] ~1M req/sec, कोई storage round-trip नहीं [11] सबसे उपयुक्त पारंपरिक server-rendered apps, single-domain साइट्स [13] SPAs, mobile apps, APIs, distributed/microservice सिस्टम्स [12][6] तो आपको असल में कौन-सा चुनना चाहिए? ईमानदारी से कहूं तो? ज़्यादातर \u0026ldquo;सामान्य\u0026rdquo; web apps के लिए - कोई Django, Rails, या Express app जो pages render कर रहा हो और एक ही frontend serve कर रहा हो - सेशन अब भी ज़्यादा सरल, ज़्यादा सुरक्षित डिफ़ॉल्ट है। आपको instant revocation मिलता है, attack surface छोटा रहता है, और cryptographically गलत होने की एक चीज़ कम हो जाती है [1][2]।\nJWT तब असल में मायने रखने लगते हैं जब:\nआपके पास कई services हैं जिन्हें identity को स्वतंत्र रूप से वेरीफ़ाई करना है, बिना सबको एक ही auth database पर बार-बार हमला किए [6]। आप एक public API बना रहे हैं जिसे third parties, mobile apps, या अलग-अलग domains के partners इस्तेमाल करेंगे [12]। आपको सच में horizontally scale करना है, बिना किसी shared सेशन store के bottleneck बने [11]। लेकिन यहाँ मेरी ईमानदार राय है, और यह शायद विवादास्पद लगे: बहुत सारे projects JWT की तरफ़ इसलिए जाते हैं क्योंकि यह \u0026ldquo;modern\u0026rdquo; लगता है या किसी tutorial ने ऐसा कहा था, न कि इसलिए कि उनके पास असल में वह scaling या cross-service समस्या है जिसे JWT हल करता है। अगर आपका app सिर्फ़ एक Node server है जो एक Postgres database से बात करता है, तो Redis को store बनाकर एक सेशन cookie आपके लिए उतना ही अच्छा काम करेगी - शायद बेहतर - और token theft व revocation को लेकर चिंता भी बहुत कम रहेगी।\nज़्यादातर production सिस्टम्स वैसे भी एक hybrid पर पहुँच जाते हैं: असली API calls के लिए short-lived JWT access tokens (तेज़, statelessly verifiable), जिनके पीछे एक server-tracked refresh token होता है जो काफ़ी हद तक\u0026hellip; एक सेशन जैसा ही व्यवहार करता है [8][13]। जो, अगर आप सोचें, तो थोड़ा मज़ेदार है - आप आख़िर में सेशन को ही दोबारा बना रहे होते हैं, बस कुछ extra steps और ऊपर से एक cryptographic signature के साथ।\nशायद याद रखने लायक असली \u0026ldquo;मूल अंतर\u0026rdquo; यही है: यह \u0026ldquo;stateful बनाम stateless\u0026rdquo; जैसा कोई absolute मामला उतना नहीं है, बल्कि इस बारे में ज़्यादा है कि आप अपना state कहाँ रखना चाहते हैं, और client पर कितना भरोसा करते हैं कि वह उसे ईमानदारी से साथ ले जाएगा।\nस्रोत JWTs vs. sessions: which authentication approach is right for you? Session-Based Authentication - SuperTokens Blog Session vs Token Based Authentication: Cookies, JWT, \u0026amp; Best Practices - Authgear JWT.IO - JSON Web Tokens Introduction JSON Web Token Structure - Auth0 Docs Stateless Sessions for Stateful Minds: JWTs Explained - Auth0 Blog JSON Web Tokens (JWT) are dangerous for user sessions - Redis Blog JWT Token Lifecycle Management: Expiration, Refresh, and Revocation Strategies - skycloak JSON Web Token for Java - OWASP Cheat Sheet Series LocalStorage vs Cookies: Storing JWT Tokens Securely - Cyber Chief JWT vs Session Authentication: Real Scaling Differences - LoginRadius Session-Based Authentication vs. JSON Web Tokens (JWTs) in System Design - GeeksforGeeks JWT vs Session authentication - Logto Blog ","permalink":"https://cloudmato.com/hi/posts/session-vs-jwt-tokens-core-difference/","title":"सेशन बनाम JWT टोकन: मूल अंतर क्या है"},{"content":"\u0026ldquo;बस इसे Redis में कैश कर दो\u0026rdquo; — आपने यह किसी कोड रिव्यू में, सिस्टम डिज़ाइन इंटरव्यू में, या Stack Overflow कमेंट में ज़रूर सुना होगा। यह अब लगभग एक रिफ्लेक्स बन चुका है। लेकिन Redis ही क्यों? एक अच्छे इंडेक्स वाले रेगुलर डेटाबेस से क्यों नहीं, या किसी और इन-मेमोरी स्टोर से? मैंने इसके इतिहास, आर्किटेक्चर, और विकल्पों के मौजूदा परिदृश्य में गहराई से देखा — और यह कहानी मीम से कहीं ज़्यादा दिलचस्प है।\nRedis वास्तव में क्या है पहले एक बात साफ़ कर लेते हैं। Redis सिर्फ एक कैश नहीं है। यही वो भ्रांति है जो लोगों को उलझा देती है। Redis का मतलब है REmote DIctionary Server [1], और यह एक इन-मेमोरी डेटा स्ट्रक्चर स्टोर है — यानी यह डेटा को डिस्क की बजाय RAM में रखता है। यही एक फ़ैसला इसकी तेज़ी का अधिकांश हिस्सा समझाता है।\nलेकिन इसे \u0026ldquo;की-वैल्यू स्टोर\u0026rdquo; कहना इसे कम आंकना है। Redis नेटिव रूप से डेटा स्ट्रक्चर के एक समृद्ध सेट को समझता है [1]:\nStrings — बेसिक टाइप; काउंटर और बाइनरी ब्लॉब के रूप में भी उपयोग किया जाता है Lists — क्रमबद्ध, डुप्लीकेट सपोर्ट करते हैं; क्यूज़ और एक्टिविटी फ़ीड के लिए बेहतरीन Sets — यूनीक वैल्यू O(1) मेम्बरशिप चेक के साथ Sorted Sets — ऑर्डरिंग के लिए न्यूमेरिक स्कोर वाले यूनीक मेम्बर; रियल-टाइम लीडरबोर्ड के लिए उपयुक्त Hashes — एक की के भीतर मिनी हैशमैप; बिना सब कुछ सीरियलाइज़ किए ऑब्जेक्ट स्टोर करें Streams — प्रोसेसिंग के लिए अपेंड-ओनली इवेंट लॉग Bitmaps / HyperLogLogs — स्पेस-एफिशिएंट काउंटिंग और प्रोबेबिलिस्टिक डेटा Geospatial indexes — कोऑर्डिनेट्स का उपयोग करके नज़दीकी लोकेशन खोजें यही वजह है कि Redis अधिकांश आधुनिक उपयोग के मामलों में Memcached से आगे रहता है। Memcached बहुत सरल एक्सेस पैटर्न के साथ रॉ स्ट्रिंग कैशिंग के लिए तेज़ है — और बस यही एकमात्र काम वह करता है। जैसे ही आपको एक सॉर्टेड लीडरबोर्ड, पब/सब चैनल, या रेट-लिमिटिंग काउंटर की ज़रूरत होती है, Memcached आपकी मदद नहीं कर सकता।\nमूल कहानी यह वह हिस्सा है जिसके सच में अच्छा होने की मुझे उम्मीद नहीं थी।\nSalvatore Sanfilippo — जो ऑनलाइन antirez के नाम से जाने जाते हैं — एक सिसिलियन प्रोग्रामर हैं जो 2007 में LLOOGG नाम का एक रियल-टाइम वेब एनालिटिक्स टूल बना रहे थे [2]। आइडिया चतुर था: वेबसाइट मालिकों को लाइव अपने विज़िटर्स का व्यवहार दिखाना, जिसमें वे कौन से पेज देखते हैं और किस क्रम में। संदर्भ के लिए, Google Analytics ने रियल-टाइम ट्रैकिंग 2011 तक शिप नहीं की, इसलिए antirez सच में अपने समय से आगे थे [3]।\nसमस्या? MySQL इसे संभाल नहीं सका। हर पेज व्यू को इतनी तेज़ी से लिखा और क्वेरी किया जाना था कि लाइव डेटा दिखाया जा सके। असली ट्रैफिक में, MySQL का डिस्क I/O बॉटलनेक बन गया। Sanfilippo की अंतर्दृष्टि थी — डिस्क से लड़ना बंद करो। उन्होंने Tcl में LMDB (LLOOGG Memory Database) नाम का एक त्वरित प्रोटोटाइप लिखा, सिर्फ परिकल्पना परखने के लिए [2]। यह काम किया। तो उन्होंने इसे C में ठीक से फिर से लिखा।\nवही प्रोटोटाइप Redis बना। पहला पब्लिक रिलीज़ 10 अप्रैल, 2009 को गया [1]। उनके दोस्त David Welton ने इसे Hacker News पर पोस्ट किया। शुरुआती प्रतिक्रिया ज़्यादातर चुप्पी रही — सिवाय Ezra Zygmuntowicz के, जो एक प्रसिद्ध Ruby on Rails डेवलपर थे, जिन्होंने तुरंत समझ लिया कि antirez ने क्या बनाया है और इसे फैलाने में मदद की [2]।\nवहाँ से यह तेज़ी से आगे बढ़ा। यहाँ मोटा टाइमलाइन है:\n2010 — VMware ने Sanfilippo को Redis पर फुल-टाइम काम करने के लिए हायर किया [1] 2012 — GitHub ने इसे एक्टिविटी फ़ीड के लिए अपनाया; Twitter ने ट्रेंडिंग टॉपिक्स और टाइमलाइन फैनआउट के लिए इस्तेमाल किया [3] 2013 — VMware के पुनर्गठन पर Pivotal ने स्पॉन्सरशिप संभाली 2015 — Redis Labs (अब Redis Inc.) मुख्य कमर्शियल स्टीवर्ड बने 2020 — antirez ने सक्रिय विकास से पीछे कदम रखा और LLOOGG, वह एनालिटिक्स टूल जिसने सब कुछ शुरू किया? यह 2014 में बंद होने तक Redis पर चला — दो अरब से ज़्यादा पेज व्यू संभालते हुए, 350–400 कमांड प्रति सेकंड पर, एक वर्चुअल मशीन पर जिसकी लागत $150 प्रति माह थी [2]। एक साइड प्रोजेक्ट जो एक डेवलपर की MySQL परफॉर्मेंस समस्या ठीक करने के लिए बनाया गया था, वह अब ग्रह पर लगभग हर गंभीर टेक स्टैक के अंदर चलता है।\nयह इतना तेज़ क्यों है तीन आर्किटेक्चरल फ़ैसले Redis को वह बनाते हैं जो वह है।\nसब कुछ RAM में रहता है यह एक बार कहने पर स्पष्ट हो जाता है, लेकिन स्पष्ट रूप से कहना ज़रूरी है। RAM तक पहुँचना एक स्पिनिंग डिस्क से लगभग 100,000 गुना तेज़ और रैंडम रीड के लिए SSD से लगभग 10 गुना तेज़ है [4]। डिस्क-आधारित डेटाबेस बफर पूल, पेज कैश और I/O क्यूज़ मैनेज करते हैं। Redis ये सब छोड़ देता है। आप एक की मांगते हैं, वह पहले से मेमोरी में है, काम हो गया।\nसिंगल-थ्रेडेड इवेंट लूप यह लोगों को चौंकाता है। क्या सिंगल-थ्रेडेड का मतलब धीमा नहीं है? Redis के लिए नहीं — क्योंकि Redis CPU-बाउंड नहीं, I/O-बाउंड है। सिंगल-थ्रेडेड मॉडल लॉक कंटेंशन को पूरी तरह खत्म कर देता है: कोई म्यूटेक्स नहीं, कोई रेस कंडीशन नहीं, थ्रेड्स के बीच कोई सिंक्रोनाइज़ेशन ओवरहेड नहीं। कमांड अटॉमिकली और सीक्वेंशियली एक्जीक्यूट होते हैं [4]। इवेंट लूप नॉन-ब्लॉकिंग I/O (आंतरिक रूप से epoll का उपयोग करते हुए) के ज़रिए हज़ारों समवर्ती कनेक्शन हैंडल करता है, इसलिए सिंगल थ्रेड कभी किसी धीमे क्लाइंट के लिए ब्लॉक नहीं होता [11]। Redis 6.0 से, वैकल्पिक थ्रेडेड I/O नेटवर्क रीड और राइट को मल्टीपल थ्रेड्स पर ऑफलोड कर सकता है — लेकिन कमांड एक्जीक्यूशन सिंगल-थ्रेडेड ही रहता है। यह दिखने से कहीं ज़्यादा साफ़ डिज़ाइन है।\nएफिशिएंट प्रोटोकॉल और डेटा स्ट्रक्चर RESP (Redis Serialization Protocol) मिनिमल और तेज़ी से पार्स होने वाला है। कोई SQL प्लानर नहीं, कोई JOIN रिज़ॉल्यूशन नहीं, कोई ऑप्टिमाइज़र ओवरहेड नहीं। और डेटा स्ट्रक्चर जेनेरिक इम्प्लीमेंटेशन नहीं हैं — सॉर्टेड सेट्स, उदाहरण के लिए, एक साथ स्किप लिस्ट + हैश टेबल कॉम्बिनेशन का उपयोग करके इम्प्लीमेंट किए जाते हैं, O(1) स्कोर लुकअप के साथ O(log N) इंसर्ट देते हैं [5]।\nपरिणाम: एक स्टैंडर्ड Redis इंस्टेंस GET/SET ऑपरेशन के लिए लगभग 0.167 मिलीसेकंड की मीडियन लेटेंसी के साथ प्रति सेकंड 100,000 से अधिक ऑपरेशन हैंडल करता है [4]। पाइपलाइनिंग के साथ — एक नेटवर्क राउंड ट्रिप में मल्टीपल कमांड बैच करके — आप उसी हार्डवेयर पर दस लाख ops/sec से आगे जा सकते हैं।\nलोग वास्तव में Redis का उपयोग किस लिए करते हैं कैशिंग (स्पष्ट वाला) आपके पास एक Postgres क्वेरी है जो हर रिक्वेस्ट पर 180ms लेती है। आप Redis में 60-सेकंड TTL के साथ रिज़ल्ट कैश करते हैं। अब 95% रीड RAM से होती हैं और 1ms से कम में वापस आती हैं। यह प्रमुख उपयोग का मामला है — और वह कारण है कि Redis प्रभावी रूप से किसी भी कंपनी में डिफ़ॉल्ट इन्फ्रास्ट्रक्चर है जिसके पास असली ट्रैफिक है [11]।\nGitHub ने शुरुआत में इसका उपयोग अपने एक्टिविटी फ़ीड के लिए किया। हर पेज लोड पर डेटाबेस जॉइन से यूज़र की टाइमलाइन रिकंस्ट्रक्ट करने के बजाय, उन्होंने Redis में प्री-कंप्यूटेड टाइमलाइन स्टोर की और राइट इवेंट पर उन्हें अपडेट किया [3]।\nसेशन मैनेजमेंट सोचें एक सेशन में क्या होता है: यूज़र ID, ऑथ टोकन, शायद एक कार्ट ID। यह छोटा है, लगभग हर ऑथेंटिकेटेड रिक्वेस्ट पर रीड होता है, और तेज़ होना ज़रूरी है। Redis एकदम सटीक है — आप TTL के साथ एक की सेट करते हैं और जब सेशन खत्म होना चाहिए तो यह ऑटो-एक्सपायर हो जाता है। स्टेल सेशन क्लीन करने के लिए कोई क्रॉन जॉब नहीं, आपके मुख्य डेटाबेस में कोई गार्बेज नहीं। Instagram ने अपने स्केल पर Redis में इन जोड़ियों के सैकड़ों करोड़ स्टोर किए [3]।\nरेट लिमिटिंग \u0026ldquo;इस IP ने पिछले 60 सेकंड में कितनी API कॉल की हैं?\u0026rdquo; Redis एक सिंगल अटॉमिक INCR + EXPIRE से इसका जवाब देता है। कोई ट्रांजैक्शन नहीं, कोई लॉकिंग नहीं, कोई रेस कंडीशन नहीं। Twitter ने अपने पूरे प्लेटफॉर्म पर API रेट लिमिट्स लागू करने के लिए इस पैटर्न का उपयोग किया [3]। यह शायद लीकी बकेट पैटर्न का सबसे एलीगेंट इम्प्लीमेंटेशन है जो मैंने देखा है — और यह कोड की तीन लाइनें हैं।\nरियल-टाइम लीडरबोर्ड यहीं पर सॉर्टेड सेट्स अपनी उपयोगिता साबित करते हैं। ZADD leaderboard 9500 \u0026quot;player:88\u0026quot; एक स्कोर जोड़ता है। ZRANGE leaderboard 0 9 WITHSCORES REV तुरंत टॉप 10 रिटर्न करता है, बिना री-सॉर्टिंग के, O(log N) इंसर्ट [5]। इस तरह मोबाइल गेम लाखों समवर्ती स्कोर अपडेट बिना रिलेशनल डेटाबेस को दबाए हैंडल करते हैं। यह बस काम करता है।\nPub/Sub मेसेजिंग Redis में एक बिल्ट-इन पब्लिश/सब्सक्राइब मेसेजिंग सिस्टम है — पब्लिशर नेम्ड चैनल पर भेजते हैं, सब्सक्राइबर रियल टाइम में रिसीव करते हैं [9]। यह Kafka को ड्यूरेबल, रिप्लेड इवेंट स्ट्रीम के लिए रिप्लेस करने के लिए नहीं है (Redis Pub/Sub मेसेज पर्सिस्ट नहीं करता), लेकिन लाइटवेट रियल-टाइम नोटिफिकेशन के लिए — \u0026ldquo;नया चैट मेसेज\u0026rdquo;, \u0026ldquo;प्राइस अपडेट\u0026rdquo;, \u0026ldquo;फ़ॉलो इवेंट\u0026rdquo; — यह खूबसूरती से काम करता है और कोई इन्फ्रास्ट्रक्चर ओवरहेड नहीं जोड़ता।\nवेक्टर सर्च और AI वर्कलोड हाल ही में, Redis ने AI उपयोग के मामलों में गहरी रुचि ली है। Redis रेगुलर डेटा के साथ वेक्टर एम्बेडिंग स्टोर कर सकता है, जिससे यह LLM रिस्पॉन्स के सिमेंटिक कैशिंग और रिट्रीवल-ऑगमेंटेड जेनरेशन (RAG) पाइपलाइन के लिए उपयोगी है [4]। यदि आप LangChain, LangGraph, या mem0 के साथ कुछ बना रहे हैं, तो आपने शायद पहले से ही Redis को मेमोरी बैकएंड के रूप में देखा होगा। Redis 8.0 में नया Vector Sets टाइप antirez द्वारा खुद इस उपयोग के मामले के लिए लिखा गया था [13]।\nलाइसेंस ड्रामा (यह वास्तव में मायने रखता है) यह हिस्सा प्रासंगिक है यदि आप आज एक आर्किटेक्चर निर्णय ले रहे हैं। ईमानदारी से कहें, यह उलझ गया।\nमार्च 2024 में, Redis Inc. ने प्रोजेक्ट का लाइसेंस परमिसिव BSD 3-Clause से ड्यूअल RSALv2 / SSPLv1 मॉडल में बदल दिया [6]। न तो OSI-अनुमोदित ओपन सोर्स है। SSPLv1 मूल रूप से MongoDB द्वारा क्लाउड प्रोवाइडर्स को टार्गेट करने के लिए बनाया गया था — यह मूलतः कहता है: यदि आप इसे एक मैनेज्ड सर्विस के रूप में ऑफर करते हैं, तो आपको अपना पूरा प्लेटफॉर्म ओपन-सोर्स भी करना होगा।\nटार्गेट स्पष्ट था। AWS ElastiCache Redis से सैकड़ों करोड़ डॉलर कमा रहा था जबकि Redis Inc. मुफ़्त से पेड यूज़र्स में ~1% कन्वर्ज़न रेट से जूझ रहा था [6]। निराशा पूरी तरह समझ में आती है। एक्जीक्यूशन एक तबाही था।\nकम्युनिटी की प्रतिक्रिया तत्काल थी। Linux डिस्ट्रीब्यूशन (openSUSE, Fedora) अपने रेपो से Redis हटाने लगे। हफ्तों के भीतर, पूर्व Redis मेंटेनर्स ने आखिरी BSD-लाइसेंस्ड वर्ज़न फोर्क किया और अप्रैल 2024 में Linux Foundation के तहत Valkey लॉन्च किया, AWS, Google Cloud, Oracle, Alibaba, और Ericsson के समर्थन से [7]।\nफिर antirez खुद — जो 2020 में प्रोजेक्ट से पीछे हट गए थे — नवंबर 2024 में Redis Inc. में वापस आए। उन्होंने कोर्स करेक्शन के लिए ज़ोरदार दबाव डाला। 1 मई, 2025 को Redis 8.0 ट्राई-लाइसेंस: RSALv2, SSPLv1, या AGPLv3 के तहत लॉन्च हुआ [13]। AGPLv3 OSI-अनुमोदित ओपन सोर्स है — कम्युनिटी की ओर वापस एक वास्तविक कदम। Antirez ने इसके बारे में खुलकर लिखा: \u0026ldquo;मुझे खुशी है कि Redis फिर से ओपन सोर्स सॉफ्टवेयर है।\u0026rdquo;\nक्या रिवर्सल ने नुकसान ठीक किया? ज़्यादा नहीं। Valkey तब तक क्रिटिकल मास हासिल कर चुका था [14]।\nविकल्प Valkey हालिया ओपन-सोर्स इतिहास में सबसे महत्वपूर्ण फोर्क। Valkey Linux Foundation के तहत Redis 7.2.4 है — पूरी तरह प्रोटोकॉल-कम्पैटिबल, लगभग हर उपयोग के मामले के लिए ड्रॉप-इन रिप्लेसमेंट [7]। AWS ने ElastiCache को इसमें माइग्रेट किया। Google Cloud Memorystore इसे सपोर्ट करता है। Aiven ने मई और अगस्त 2024 के बीच 15,000 सर्वर माइग्रेट किए।\nValkey 8.1 कथित तौर पर Redis OSS की तुलना में ~8% अधिक ops/sec पर चलता है, P99 लेटेंसी 22% कम करता है, और 20% कम मेमोरी उपयोग करता है [7]। अधिकांश टीमों के लिए, यह सबसे सुरक्षित माइग्रेशन पथ है — पैकेज नाम बदलें, इमेज स्वैप करें, काम हो गया।\nDragonfly C++ में ग्राउंड-अप रिराइट, Redis फोर्क नहीं। Dragonfly आधुनिक कंकरेंसी प्रिमिटिव — फाइबर, SIMD, शेयर्ड-नथिंग आर्किटेक्चर — का उपयोग सभी CPU कोर को एफिशिएंटली यूटिलाइज़ करने के लिए करता है [8]। दावा किए गए थ्रूपुट उसी हार्डवेयर पर Redis से 25 गुना बेहतर हैं, प्रति डेटासेट मेमोरी फुटप्रिंट भी कम।\nकैवियट: यह ~95–98% Redis-कम्पैटिबल है। एडमिनिस्ट्रेटिव कमांड में एज-केस गैप हैं [8]। अत्यधिक थ्रूपुट आवश्यकताओं वाले नए प्रोजेक्ट के लिए, एक बेंचमार्क रन के लायक है। मौजूदा सेटअप माइग्रेट करने के लिए, कमिट करने से पहले अपने विशिष्ट कमांड उपयोग का परीक्षण करें।\nKeyDB मल्टी-थ्रेडेड Redis। वही प्रोटोकॉल, वही कमांड, लेकिन यह आपके सभी कोर पर चलता है। Snap द्वारा अधिग्रहित, जिसने इसमें उचित इंजीनियरिंग संसाधन लाए [8]। FLASH फीचर (SSD पर टियर्ड स्टोरेज) उन डेटासेट के लिए सच में दिलचस्प है जो पूरी तरह RAM में फिट नहीं होते। यदि आप परिचित Redis सेमेंटिक्स पर मल्टी-थ्रेडिंग चाहते हैं, KeyDB एक सिद्ध विकल्प है।\nMemcached बुज़ुर्ग राजनेता। Memcached Redis से पहले का है और न्यूनतम ऑपरेशनल ओवरहेड के साथ प्योर स्ट्रिंग कैशिंग के लिए सच में तेज़ है [10]। कोई पर्सिस्टेंस नहीं, कोई सॉर्टेड सेट नहीं, कोई Lua स्क्रिप्टिंग नहीं, कोई pub/sub नहीं — बस तेज़ की-वैल्यू स्टोरेज। यदि आपको बस \u0026ldquo;इस डेटाबेस रिज़ल्ट को 60 सेकंड के लिए कैश करना है\u0026rdquo; और कुछ नहीं, तो Memcached की सादगी एक फीचर है। लेकिन बेसिक स्ट्रिंग कैशिंग से परे किसी भी उपयोग के मामले के लिए, Redis (या Valkey) समान लेटेंसी पर आपको काफी ज़्यादा देता है।\nRedis 8.0 Valkey 8.1 Dragonfly KeyDB Memcached लाइसेंस RSALv2/SSPL/AGPL BSD 3-Clause BSL 1.1 BSD 3-Clause BSD पर्सिस्टेंस ✓ ✓ ✓ ✓ ✗ Sorted Sets ✓ ✓ ✓ ✓ ✗ Pub/Sub ✓ ✓ ✓ ✓ ✗ मल्टी-थ्रेडेड cmd exec ✗ ✗ ✓ ✓ ✓ Redis प्रोटोकॉल कम्पैट Native Native ~95–98% Native ✗ क्लाउड मैनेज्ड Redis Cloud AWS / GCP / Aiven ज़्यादातर Self-hosted Self-hosted AWS / GCP आपको कौन सा चुनना चाहिए? एक ही जवाब नहीं, लेकिन कुछ ईमानदार शॉर्टकट:\nपहले से Redis पर हैं, काम कर रहा है — AGPLv3 के तहत Redis 8.0 में अपग्रेड करना ठीक है। AGPLv3 आपको तभी प्रभावित करता है जब आप Redis को एक मैनेज्ड सर्विस में रैप करके बेच रहे हों। नया शुरू कर रहे हैं, AWS या GCP — ElastiCache या Memorystore के ज़रिए Valkey उपयोग करें। वही प्रोटोकॉल, साफ़ लाइसेंसिंग, AWS पर 20% सस्ता [7]। अत्यधिक थ्रूपुट आवश्यकताएं और नया प्रोजेक्ट — Dragonfly को गंभीरता से बेंचमार्क करें। केवल सिंपल कैशिंग — Memcached गलत जवाब नहीं है यदि आपको सच में एक्स्ट्रा की ज़रूरत नहीं है। Redis प्रोटोकॉल पर मल्टी-थ्रेडिंग चाहिए — KeyDB। इस सब का अजीब फुटनोट: LLOOGG — वह एनालिटिक्स टूल जिसने सब कुछ शुरू किया — एक दशक से अधिक पहले बंद हो गया। वह साइड प्रोजेक्ट जो antirez ने एक डेवलपर की MySQL परफॉर्मेंस समस्या ठीक करने के लिए बनाया था, अब ग्रह पर लगभग हर गंभीर टेक स्टैक के अंदर चलता है। वे 2020 में हटे, 2024 में वापस आए, देखा कि एक फोर्क बारह महीनों के भीतर प्रमुख क्लाउड प्रोवाइडर पर डिफ़ॉल्ट बन गया, और फिर Redis को ओपन सोर्स की ओर वापस धकेलने में मदद की।\nआप सच में इस आर्क की योजना नहीं बना सकते।\nसमाप्त\nस्रोत Redis - Wikipedia Story: Redis and its creator antirez — Brachiosoft Blog History of Redis: From Side Project to Industry Standard — OneUptime Complete Guide to Redis in 2026 — DragonflyDB Redis sorted sets | Docs — redis.io Redis tightens its license terms, pleasing no one — The Register Valkey Turns One: How the Community Fork Left Redis in the Dust — Momento 8 Best Redis Alternatives — DragonflyDB Complete Guide to Redis Publish Subscribe — GeeksforGeeks The Good and the Bad of Redis In-Memory Database — AltexSoft What is Redis Explained? — IBM Redis Switches to SSPLv1: Restrictive License Sparks Fork — InfoQ Redis is open source again — antirez.com Redis Returns to Open Source under AGPL License: Is It Too Late? — InfoQ Redis is now available under the AGPLv3 open source license — redis.io Understanding Redis Threading — DEV Community ","permalink":"https://cloudmato.com/hi/posts/why-use-redis-history-alternatives/","title":"Redis क्यों? इतिहास, उपयोग के मामले और बेहतरीन विकल्प"},{"content":"आपका ऐप समय के साथ धीमा होता जा रहा है। स्क्रॉल पोज़िशन अचानक बदल जाती है। टैब्स 800 MB RAM खा रहे हैं। आप Task Manager खोलते हैं और देखते हैं कि Chrome मेमोरी ऐसे खा रहा है जैसे बुफे लगी हो। कुछ लीक हो रहा है — लेकिन कहाँ? Chrome DevTools का Memory tab वहीं मौजूद है, और ज़्यादातर डेवलपर्स या तो इसे नज़रअंदाज़ करते हैं या एक बार खोलकर \u0026ldquo;Shallow Size\u0026rdquo; और \u0026ldquo;Retainers\u0026rdquo; देखकर भ्रमित हो जाते हैं और चुपचाप बंद कर देते हैं। यह गाइड उन लोगों के लिए है जो इसे वास्तव में उपयोग करना चाहते हैं।\nJavaScript में मेमोरी लीक इतनी चालाक क्यों होती हैं JavaScript गार्बेज कलेक्टेड है। V8 — Chrome का JavaScript इंजन — स्वचालित रूप से मेमोरी मुक्त करता है जब वह तय करता है कि कोई ऑब्जेक्ट अब पहुँच योग्य नहीं है [1]। एल्गोरिदम सिद्धांत में सरल है: यदि कोई भी किसी ऑब्जेक्ट का संदर्भ नहीं रखता, तो उसे एकत्र किया जा सकता है।\nसमस्या? JavaScript में संयोग से संदर्भों को जीवित रखना बहुत आसान है। एक event listener। एक closure जिसने एक वेरिएबल को कैप्चर कर लिया। एक detached DOM node जो अभी भी एक global array द्वारा इंगित है। गार्बेज कलेक्टर यहाँ आपकी मदद नहीं कर सकता — ऑब्जेक्ट्स पहुँच योग्य हैं, बस जानबूझकर नहीं। JavaScript में मेमोरी प्रबंधन तकनीकी रूप से \u0026ldquo;स्वचालित\u0026rdquo; है, लेकिन इसका मतलब लीक-मुक्त नहीं है [1]।\nतीन पैटर्न JavaScript मेमोरी लीक की विशाल बहुमत के लिए जिम्मेदार हैं [2]:\nभूले हुए event listeners — आप DOM से एक element हटाते हैं लेकिन कभी removeEventListener नहीं बुलाते। listener (और उसके closure में सब कुछ) जीवित रहता है। बड़े ऑब्जेक्ट्स रखने वाले Closures — एक फ़ंक्शन जिसने एक बड़े वेरिएबल को बंद कर लिया, जो जीवित रहता है क्योंकि कोई event या timer अभी भी उस फ़ंक्शन का संदर्भ रखता है। Detached DOM nodes — पेज से हटाए गए elements लेकिन अभी भी कहीं किसी JavaScript ऑब्जेक्ट द्वारा संदर्भित। Memory tab में चार अलग-अलग टूल हैं। प्रत्येक एक अलग प्रकार की समस्या खोजने के लिए अनुकूलित है। गलत टूल खोलना आपका समय बर्बाद करता है।\nMemory Tab: चार टूल, एक नहीं DevTools → Memory खोलें। आपको चार रेडियो बटन दिखेंगे [3]:\nHeap snapshot — heap पर सब कुछ की एक समय-बिंदु तस्वीर Allocation instrumentation on timeline — समय के साथ allocations को जैसे वे होती हैं रिकॉर्ड करता है Allocation sampling — उपरोक्त का एक हल्का, सांख्यिकीय संस्करण Detached elements — DOM nodes की सूची जो अनाथ हैं लेकिन अभी भी संदर्भित हैं प्रत्येक एक अलग प्रश्न का उत्तर देता है। यहाँ गहराई में जाने से पहले त्वरित निर्णय मैट्रिक्स है:\nटूल सर्वश्रेष्ठ उपयोग ओवरहेड अवधि Heap Snapshot \u0026ldquo;अभी क्या जीवित है?\u0026rdquo; अधिक (GC रोकता है) तत्काल Allocations on Timeline \u0026ldquo;क्या allocate हुआ और कभी मुक्त नहीं हुआ?\u0026rdquo; मध्यम छोटा सत्र Allocation Sampling \u0026ldquo;कौन से फ़ंक्शन सबसे ज़्यादा allocate करते हैं?\u0026rdquo; कम लंबे सत्र Detached Elements \u0026ldquo;कौन से हटाए गए DOM nodes अभी भी रखे हैं?\u0026rdquo; कम तत्काल Heap Snapshot यह वह है जिसे ज़्यादातर लोग पहले आज़माते हैं। यह एक ही समय बिंदु पर JavaScript heap का एक पूर्ण snapshot कैप्चर करता है — प्रत्येक ऑब्जेक्ट, प्रत्येक DOM node, प्रत्येक string, प्रत्येक संदर्भ [3]।\nआप एक लेते हैं, उसे देखते हैं, और यदि आपने पहले कभी ऐसा नहीं किया है, तो आप तुरंत हज़ारों constructors और संख्याओं से अभिभूत महसूस करते हैं। यह सामान्य है। यहाँ वास्तव में क्या देखना है।\nViews snapshot result के ऊपर-बाईं ओर dropdown बदलें। तीन views हैं [4]:\nSummary — डिफ़ॉल्ट। heap पर वर्तमान में जीवित ऑब्जेक्ट्स बनाने वाले प्रत्येक constructor फ़ंक्शन की सूची। महत्वपूर्ण कॉलम:\nShallow size — ऑब्जेक्ट द्वारा स्वयं अधिकृत मेमोरी, संदर्भों को अनदेखा करते हुए Retained size — वह मेमोरी जो मुक्त होगी यदि यह ऑब्जेक्ट (और जो कुछ भी यह अकेले जीवित रखता है) garbage collected हो जाए [5] Comparison — कोई क्रिया करने के बाद दूसरा snapshot लें, फिर इसे पहले से तुलना करें। # New, # Deleted, # Delta दिखाता है। यहाँ लीक स्पष्ट हो जाती हैं। Heap snapshots की तुलना यह पुष्टि करने का सबसे विश्वसनीय तरीका है कि लीक वास्तविक है [6]।\nContainment — window और closures जैसी roots से शुरू होने वाले ऑब्जेक्ट graph का bird\u0026rsquo;s-eye view। तब उपयोगी जब आप पहले से किसी विशिष्ट ऑब्जेक्ट पर संदेह करते हैं और ठीक यह trace करना चाहते हैं कि इसे क्या जीवित रख रहा है [4]।\nShallow बनाम Retained Size — यह भाग वास्तव में मायने रखता है सच कहूँ तो, यह इस पूरे panel में सबसे भ्रामक अवधारणा है, लेकिन एक बार समझ में आ जाए तो यह सरल है।\nShallow size बस ऑब्जेक्ट स्वयं है। कुछ properties वाला एक plain JS ऑब्जेक्ट {} 64 bytes shallow हो सकता है। Retained size वह सब कुछ है जो मुक्त होगा यदि यह ऑब्जेक्ट गायब हो जाए [5]। यदि वह plain ऑब्जेक्ट 10,000 items की Array का संदर्भ रखता है, तो उसका retained size 64 bytes + उस सारी array memory है।\nलीक खोजते समय, Retained size के अनुसार sort करें, Shallow के नहीं। 64 bytes shallow लेकिन 50 MB retained वाला ऑब्जेक्ट बिल्कुल वही है जो आप खोज रहे हैं।\nHeap Snapshots के साथ क्लासिक लीक-खोज वर्कफ़्लो Memory tab खोलें, Heap snapshot चुनें Take snapshot क्लिक करें — यह आपकी baseline है वह क्रिया करें जिस पर आपको लीक का संदेह है (modal खोलें, route navigate करें, बार-बार बटन क्लिक करें) उल्टा करें (modal बंद करें, वापस navigate करें) दूसरा snapshot लें snapshot 2 में, view को Comparison में बदलें # Delta के अनुसार descending sort करें यदि वे ऑब्जेक्ट्स जिन्हें एकत्र किया जाना चाहिए था (modal के internal components, route के views) अभी भी क्रिया को उल्टा करने के बाद positive delta दिखाते हैं — आपने अपनी लीक पा ली। नीचे का Retainers section आपको बताता है उन्हें क्या रोक रहा है।\nHeap Snapshot कब उपयोग करें: आप पहले से जानते हैं कि कुछ लीक हो रहा है और आप ठीक यह पहचानना चाहते हैं कि वह क्या है। before/after analysis के लिए भी अच्छा — जैसे, \u0026ldquo;क्या यह refactor वास्तव में मेमोरी उपयोग कम करता है?\u0026rdquo;\nAllocations on Timeline Heap snapshots आपको मेमोरी की स्थिति दिखाते हैं। Allocation Timeline आपको कहानी दिखाती है — क्या allocate हुआ, कब, और क्या वह बचा [7]।\nजब आप Record क्लिक करते हैं, DevTools आपके पूरे सत्र में समय-समय पर micro-snapshots लेता है (लगभग हर 50ms)। प्रत्येक allocation एक vertical bar के रूप में दिखाई देती है [7]:\nनीली bar — यहाँ allocate किए गए ऑब्जेक्ट रिकॉर्डिंग रोकने पर अभी भी जीवित हैं ग्रे bar — यहाँ allocate किए गए ऑब्जेक्ट बाद में garbage collected हो गए ✓ जिनकी आपको परवाह है वे नीले वाले हैं जो नीले नहीं होने चाहिए। यदि आप बटन क्लिक करते हैं, कोई क्रिया करते हैं, और नीली bars का एक समूह देखते हैं जो कितना भी इंतजार करने पर कभी ग्रे नहीं होता — वे ऑब्जेक्ट मुक्त नहीं हो रहे।\nइसे कैसे उपयोग करें Allocation instrumentation on timeline चुनें Start दबाएँ संदिग्ध क्रिया करें (scroll, click, navigate) रिकॉर्डिंग रोकें timeline में persistent नीली bars देखें किसी भी bar पर क्लिक करके नीचे Constructor list फ़िल्टर करें — उस window के दौरान allocate किए गए केवल वे ऑब्जेक्ट्स दिखाता है जो अभी भी live हैं Heap Snapshot से अंतर महत्वपूर्ण है। Timeline आपको बताती है कि allocations कब हुईं, जो किसी allocation को किसी विशिष्ट user interaction से जोड़ना बहुत आसान बनाती है। आप हर बार एक निश्चित बटन क्लिक करने पर एक स्पष्ट spike देख सकते हैं — वह आपके दोषी का timestamp है [8]।\nAllocations on Timeline कब उपयोग करें: आप यह isolate करने की कोशिश कर रहे हैं कि कौन सा user interaction वृद्धि का कारण है। आपको एक सामान्य अहसास है कि कुछ लीक हो रहा है लेकिन आप नहीं जानते कि कौन सी क्रिया इसे trigger करती है।\nएक सावधानी यहाँ overhead वास्तविक है। DevTools हर 50ms पर heap को effectively snapshot कर रहा है [7]। इस टूल से 10 मिनट का सत्र रिकॉर्ड न करें — आपको एक विशाल profile मिलेगी जिसे analyze करना कठिन होगा, और रिकॉर्डिंग के दौरान आपका ऐप उल्लेखनीय रूप से धीमा होगा। रिकॉर्डिंग छोटी रखें और उस विशिष्ट interaction पर केंद्रित रखें जिसकी आप जाँच कर रहे हैं।\nAllocation Sampling यह वह है जिसे अधिकांश डेवलपर्स छोड़ देते हैं, जो एक गलती है। Allocation Sampling Timeline का हल्का संस्करण है — यह हर allocation रिकॉर्ड करने की बजाय सांख्यिकीय sampling का उपयोग करता है [3]।\ntrade-off: कम सटीक, लेकिन लगभग शून्य overhead। आप अपने ऐप के प्रदर्शन को महत्वपूर्ण रूप से प्रभावित किए बिना मिनटों या घंटों के लिए रिकॉर्ड कर सकते हैं। यह महत्वपूर्ण है क्योंकि कुछ मेमोरी वृद्धि क्रमिक होती है — दृश्यमान होने से पहले 20 मिनट के उपयोग की आवश्यकता होती है। Timeline उसके लिए अनुपयोगी होगी। Allocation Sampling उसी के लिए डिज़ाइन किया गया है।\nयह क्या दिखाता है परिणाम एक flame chart / call tree जैसे दिखते हैं। आपको profile की अवधि में प्रत्येक फ़ंक्शन द्वारा allocate की गई heap memory का breakdown मिलता है, जिसमें बाद में मुक्त किए गए allocations भी शामिल हैं [3]। डिफ़ॉल्ट view \u0026ldquo;Heavy (Bottom Up)\u0026rdquo; है — सबसे अधिक मेमोरी allocate करने वाले फ़ंक्शन शीर्ष पर सूचीबद्ध हैं।\nयह अन्य टूल्स से अलग प्रश्न का उत्तर देता है: \u0026ldquo;क्या लीक हुआ\u0026rdquo; नहीं बल्कि \u0026ldquo;कौन सा कोड allocation-heavy है।\u0026rdquo; एक फ़ंक्शन जो 200 MB allocate करता है, भले ही इसका अधिकांश हिस्सा collect हो जाए, performance दृष्टिकोण से देखने लायक है।\nAllocation Sampling कब उपयोग करें: लंबे चलने वाले profiling सत्र जहाँ आप Timeline का overhead वहन नहीं कर सकते। जब आप समझना चाहते हैं कि कौन से फ़ंक्शन सबसे बड़े allocators हैं (ज़रूरी नहीं कि लीक हो, बस महंगे)। जब आप लीक hunting की बजाय मेमोरी optimization कर रहे हों।\nDetached Elements यह दूसरों की तुलना में अधिक targeted है। पूरे heap को दिखाने की बजाय, यह विशेष रूप से वे DOM nodes खोजता है जिन्हें page के DOM tree से हटाया गया है लेकिन अभी भी JavaScript द्वारा संदर्भित हैं [9]।\nयह क्यों मायने रखता है? जब आप element.remove() बुलाते हैं या innerHTML साफ करते हैं, तो आप उम्मीद करते हैं कि वे nodes garbage collected हो जाएँगे। लेकिन यदि कोई भी JS variable, array, closure, या event handler अभी भी उस element का संदर्भ रखता है, तो V8 इसे collect नहीं कर सकता [2]। node \u0026ldquo;detached\u0026rdquo; है — पेज में अब दृश्यमान नहीं, लेकिन मेमोरी में बहुत जीवित।\nयह single-page applications में बेहद सामान्य है। एक ऐसे component framework के बारे में सोचें जो पहले render किए गए elements का cache रखता है, या एक list जो उन rows के संदर्भ संग्रहीत करती है जिन्हें आपने viewport से पहले ही हटा दिया है।\nDetached Elements बनाने वाला सामान्य कोड // Classic detached node scenario let detachedList = []; function addAndRemove() { const el = document.createElement(\u0026#39;div\u0026#39;); document.body.appendChild(el); detachedList.push(el); // saved the reference document.body.removeChild(el); // removed from DOM // el is now detached — detachedList holds it alive } detachedList array हर div को जीवित रखता है भले ही वे सब पेज से चले गए हों [2]।\nDetached Elements Profiler का उपयोग Detached elements चुनें Get detached elements क्लिक करें (या Take snapshot — label Chrome संस्करण के अनुसार भिन्न होता है) परिणामी list आपके JavaScript द्वारा अभी भी संदर्भित प्रत्येक अनाथ DOM node दिखाती है [9] प्रत्येक entry expandable है — आप parent/child nodes देख सकते हैं जो भी retain हो रहे हैं \u0026ldquo;Analyze\u0026rdquo; बटन क्लिक करके देखें कि कौन से JS ऑब्जेक्ट उनके संदर्भ रखते हैं नीचे का \u0026ldquo;Retainers\u0026rdquo; panel महत्वपूर्ण है। यह आपको वह सटीक variable या closure दिखाता है जो node को जीवित रख रहा है। वहीं जाकर आप fix लिखते हैं [10]।\nDetached Elements कब उपयोग करें: जब भी आपको संदेह हो कि DOM nodes साफ नहीं हो रहे। dynamic rendering, virtual lists, या show/hide किए जाने वाले modals वाले SPAs में विशेष रूप से उपयोगी। cleanup logic काम कर रही है यह पुष्टि करने के लिए major refactor के बाद भी चलाएँ [9]।\nध्यान दें — detached elements हमेशा लीक नहीं होते। एक framework performance कारणों से कुछ nodes वैध रूप से cache कर सकता है। संदर्भ मायने रखता है। लेकिन यदि आपके पास समय के साथ बढ़ते सैकड़ों detached elements हैं, तो यह एक समस्या है [9]।\nइसे एक साथ रखना: एक वास्तविक Debugging सत्र आप देखते हैं कि आपके SPA की मेमोरी कुछ मिनटों के उपयोग के बाद 50 MB से 400 MB तक बढ़ जाती है। यहाँ मैं इसे कैसे approach करूँगा:\nHeap Snapshot comparison से शुरू करें। एक baseline snapshot लें, 2 मिनट के लिए ऐप उपयोग करें, दूसरा लें। Comparison view में switch करें, delta के अनुसार sort करें। यदि आप एक स्पष्ट class या constructor type बढ़ते देखते हैं — आप जानते हैं कि क्या investigate करना है।\nयदि snapshot DOM nodes बढ़ते दिखाता है, Detached Elements पर switch करें और snapshot लें। यह पुष्टि करता है कि क्या हटाए गए elements जमा हो रहे हैं।\nयदि आपको trigger पहचानने की ज़रूरत है, एक focused 30-second रिकॉर्डिंग के लिए Allocations on Timeline का उपयोग करें। एक विशिष्ट interaction करें और नीली bars देखें जो ग्रे नहीं होतीं।\nयदि आपको एक लंबे सत्र को profile करने की ज़रूरत है (जैसे, कई मिनटों तक चलने वाला background polling loop), Allocation Sampling का उपयोग करें। इसे चलने दें, रोकें, और देखें कि कौन से फ़ंक्शन सबसे बड़े allocators हैं।\nचारों को एक साथ उपयोग करने की कोशिश न करें। वह चुनें जो आपके तत्काल प्रश्न का उत्तर देता है, जो आपको मिले उस पर कार्य करें, फिर re-profile करें।\nकुछ जानने योग्य बातें पहले garbage collection force करें। तुलना के लिए snapshot लेने से पहले, Memory tab में trash-can icon (\u0026ldquo;Collect garbage\u0026rdquo;) क्लिक करें। यह GC को मैन्युअल रूप से चलाता है ताकि आप ऐसे snapshots की तुलना न करें जो केवल इसलिए अलग हों क्योंकि GC अभी तक नहीं चला [3]।\nHeap Snapshot में Distance कॉलम GC root से ऑब्जेक्ट तक के hops की संख्या दिखाता है। बहुत छोटी Distance (जैसे 2 या 3) वाले ऑब्जेक्ट global scope से सीधे पहुँच योग्य हैं — अक्सर उन globals के संकेत जिन्हें आप साफ करना भूल गए।\n(string) और (array) constructors अक्सर Summary view पर हावी होते हैं। यह आमतौर पर सामान्य है। जब तक snapshots के बीच उनका retained size न बढ़े, उनके बारे में घबराएँ नहीं।\nRetainer chains लंबी हो सकती हैं। कभी-कभी आप किसी चीज़ को जीवित रखने वाले वास्तविक variable तक पहुँचने से पहले 6-7 ऑब्जेक्ट्स की chain का पीछा करेंगे। reference graphs ऐसे ही काम करते हैं। उसका पालन करें।\nसमाप्त\nस्रोत मेमोरी प्रबंधन — MDN Web Docs JavaScript में मेमोरी लीक के कारण और उनसे कैसे बचें Memory panel overview — Chrome DevTools Heap snapshots रिकॉर्ड करें — Chrome DevTools Shallow Size और Retained Size के बीच का अंतर Heap snapshots की तुलना करके मेमोरी लीक खोजें — DevTools Tips Allocation Timeline Tool का उपयोग कैसे करें — Chrome DevTools Chrome के Allocation Timeline से मेमोरी लीक isolate करना — LogRocket मेमोरी लीक की जाँच के लिए detached DOM elements प्राप्त करें — DevTools Tips DOM मेमोरी लीक debug करें — Microsoft Edge DevTools मेमोरी समस्याएँ ठीक करें — Chrome DevTools मेमोरी शब्दावली — Chrome DevTools ","permalink":"https://cloudmato.com/hi/posts/chrome-devtools-memory-tab-guide/","title":"Chrome DevTools Memory Tab: एक व्यावहारिक गाइड"},{"content":"आपका वेब ऐप शायद ऐसे काम कर रहा है जिन्हें आपने कभी वास्तव में डीबग नहीं किया। यूज़र के कुछ भी क्लिक करने से पहले pages prerender हो रहे हैं, form submissions ऑफलाइन रहते हुए चुपचाप queue में जा रहे हैं, push notifications एक सोए हुए service worker पर आ रही हैं, sessions cryptographically hardware keys से bound हैं — यह सब Chrome के background service APIs के ज़रिए होता है, पूरी तरह अदृश्य रूप से। Chrome DevTools का Background Services पैनल वह जगह है जहाँ आप अंततः यह सब देख पाते हैं।\nपैनल खोजना DevTools खोलें (F12 या राइट-क्लिक \u0026gt; Inspect), Application टैब पर जाएं, और बाईं साइडबार को तब तक स्क्रॉल करें जब तक आपको \u0026ldquo;Background Services\u0026rdquo; सेक्शन न मिल जाए। आपको एक लिस्ट मिलेगी जो essentially Chrome द्वारा support की जाने वाली हर \u0026ldquo;अदृश्य\u0026rdquo; API को कवर करती है:\nBack/forward cache Background fetch Background sync Bounce tracking mitigations Notifications Payment handler Periodic background sync Push messaging Reporting API Device bound sessions इस पैनल को वास्तव में उपयोगी बनाने वाली बात यह है कि कई टैब्स तीन दिनों तक events रिकॉर्ड कर सकते हैं, यहाँ तक कि जब DevTools खुला न हो [1]। एक रिकॉर्डिंग सेट करें, चले जाएं, अगली सुबह वापस आएं — events वहाँ होंगे। यह browser tooling के लिए असामान्य है, और यह बदल देता है कि आप async व्यवहार को कैसे डीबग करते हैं जिसे मांग पर reproduce करना मुश्किल होता है।\nBack/Forward Cache back/forward cache (bfcache) उन browser features में से एक है जो 2020 से मौजूद है लेकिन फिर भी developers को आश्चर्यचकित करती है — आमतौर पर जब उन्हें एहसास होता है कि उनका पेज इसका उपयोग नहीं कर रहा। विचार यह है: जब कोई यूज़र आपके पेज से नेविगेट करता है, Chrome पूरे पेज को — JavaScript heap, DOM, scroll position, सब कुछ — मेमोरी में frozen रखता है। अगर वे back बटन दबाते हैं, Chrome उसे तुरंत thaw करके restore करता है, बिना किसी network round trips, re-rendering, या JS re-execution के [2]।\nमापे गए performance gains महत्वपूर्ण हैं। Bfcache restores 100ms से कम में हो सकते हैं — पारंपरिक load optimisation के ज़रिए प्राप्त किसी भी चीज़ से तेज़ [2]। यह essentially back/forward navigation को मुफ़्त बना देता है।\nनिराशाजनक हिस्सा यह था कि यह जानना मुश्किल था कि आपका पेज वास्तव में eligible है या नहीं। Chrome 123 में दो चीज़ों के साथ यह काफी हद तक सुधरा:\nDevTools में Test back/forward cache बटन (Application \u0026gt; Back/forward cache \u0026gt; Run Test)। Chrome आपको दूर नेविगेट करता है और वापस लाता है, फिर स्पष्ट रूप से बताता है कि bfcache काम किया या नहीं — और अगर नहीं किया, तो बिल्कुल क्यों। notRestoredReasons API, जो आपको programmatically query करने देता है कि किसी नेविगेशन पर bfcache को क्या blocked किया [3]। पैनल blockers को \u0026ldquo;Actionable\u0026rdquo; (जो आप ठीक कर सकते हैं) या \u0026ldquo;Not actionable\u0026rdquo; (browser-level decisions) के रूप में categorise करता है। सामान्य actionable blockers में शामिल हैं:\nपेज पर attached unload event listeners — इन्हें pagehide handlers से replace करें जो event.persisted check करते हैं Open IndexedDB transactions जो navigation से पहले close नहीं हुए Cache-Control: no-store headers — ऐतिहासिक रूप से एक hard block, लेकिन Chrome ने इन pages के लिए bfcache की अनुमति देना शुरू किया सीमित शर्तों के तहत 2025 की शुरुआत में, अप्रैल 2025 में 100% उपयोगकर्ताओं तक इसका पूर्ण rollout पूरा हुआ [4] अगर test आपके पेज को ineligible flag करता है, तो reasons को ध्यान से पढ़ें। पैनल इतना specific है कि actionable हो — यह बताता है कि कौन सा frame, कौन सी script, कौन सा reason। सिर्फ \u0026ldquo;blocked\u0026rdquo; नहीं।\nSpeculative Loads अगर bfcache back बटन को optimize करता है, तो Speculative Loads forward बटन को target करता है। Speculation Rules API आपको Chrome को instruct करने देता है कि वह उन pages को prefetch या prerender करे जिन पर user के अगला navigate करने की संभावना है [5]।\nदो modes के बीच का अंतर मायने रखता है:\nMode Chrome क्या करता है Resource cost Prefetch HTML + कुछ subresources download करता है कम — कोई JS execution नहीं Prerender पेज को एक hidden background process में fully render करता है अधिक — पूरा page lifecycle Prerender प्रभावशाली है। जब यह काम करता है और user क्लिक करता है, navigation तुरंत होता है — पेज पहले से fully rendered है, Largest Contentful Paint पहले ही हो चुका है, JavaScript पहले ही चल चुका है।\nReal-world results इसकी पुष्टि करते हैं। Monrif, एक Italian media group, ने 2025 की शुरुआत में अपने highest-traffic article URLs पर prerendering लागू किया और LCP में 17.9% तक का सुधार और कुछ audience segments में user engagement में peak 8.9% की वृद्धि देखी [6]। ये सामान्य performance win numbers नहीं हैं। इस तरह का uplift product dashboards को हिला देता है।\nDevTools में debug करने के लिए: Application \u0026gt; Background Services \u0026gt; Speculative loads। सेक्शन में तीन views हैं [7]:\nSpeculative loads — पेज के लिए current speculative status, plus कौन सी URLs यह preload करने की कोशिश कर रहा है Rules — पेज पर currently active JSON speculation rule sets Speculations — हर attempt की एक table जिसमें target URL, action (prefetch या prerender), कौन सा rule triggered हुआ, और current status है अगर कोई speculation fail होती है, तो Speculations table में उस row को click करने से पूरा failure reason दिखता है। URL mismatches, opted-out origins, या prerender quota limits track करने के लिए उपयोगी। जब एक prerender actively चल रहा होता है, DevTools आपको उसके context में switch करके उस hidden background render को directly inspect करने देता है — उस पेज के अंदर Network, Console, या Performance चलाना जिस पर user अभी navigate नहीं हुआ है।\nध्यान देने योग्य: WordPress 6.8 (मार्च 2025 में released) ने Speculation Rules API को WordPress core में शामिल किया। अगर आप WordPress site चलाते हैं और आपने हाल ही में इस पैनल को नहीं देखा है, तो संभावना है कि speculations पहले से चल रहे हों [7]।\nBackground Fetch Standard fetch() requests tab बंद होते ही खत्म हो जाते हैं। यह जानबूझकर किया गया है — यह alarming होगा अगर arbitrary web pages indefinitely background में network requests चला सकते। Background Fetch इसका explicitly permitted version है — एक download जो tab closure के बाद भी survive करती है, user-visible progress और native cancellation controls के साथ।\nइस API को motivate करने वाले use cases बड़े media files थे: एक podcast app को 300MB episode चाहिए, एक streaming service offline content cache कर रही है, एक game assets pre-load कर रहा है। लेकिन एक नया angle है जो तेजी से relevant हो रहा है। AI model downloads के लिए Background Fetch use करने पर Web.dev की guidance उस case को cover करती है जहाँ model weights कई gigabytes हो सकते हैं — page lifecycle के अंदर download करना पूरी तरह impractical, लेकिन background fetch के रूप में manageable [9]।\nFlow service worker के ज़रिए काम करता है:\nregistration.backgroundFetch.fetch() को एक ID और resources की list के साथ call करें Browser download handle करता है, native progress UI दिखाता है (users pause या cancel कर सकते हैं) Complete होने पर, browser आपके service worker को downloaded response process करने के लिए wake करता है Debug करने के लिए: Application \u0026gt; Background Services \u0026gt; Background Fetch \u0026gt; Record क्लिक करें। अपने पेज से fetch trigger करें, table में events log होते देखें, किसी भी event को click करके full detail देखें। तीन दिन का recording window मतलब है कि आप एक background download verify कर सकते हैं जो DevTools बंद करने के काफी बाद complete होती है [1]।\nएक caveat: Background Fetch एक Chromium-specific feature है [10]। यह Firefox या Safari में मौजूद नहीं है। अगर आप cross-browser build कर रहे हैं, तो एक fallback path plan करें।\nBackground Sync Background Sync इसका counterpart है — यह data reliably भेजने के बारे में है, receive करने के नहीं। Scenario: एक user flaky connection पर form submit करता है, एक message queue करता है, या analytics event fire करता है। Standard fetch चुपचाप fail हो जाता है। Background Sync request को queue करता है और अगली बार जब device की reliable connection हो तब deliver करता है, बिना manual retry की ज़रूरत के [8]।\nWorkbox Background Sync module इसे practical बनाता है। इसका BackgroundSyncPlugin fetch failure events में hook करता है — specifically, जब network error exception throw करता है, न कि जब आपको 4xx या 5xx response मिलता है — और failed requests को exponential backoff के साथ बाद के retry के लिए IndexedDB में queue करता है।\nएक testing mistake जो लोगों को trip करती है: Application panel के Service Workers सेक्शन में \u0026ldquo;Offline\u0026rdquo; checkbox service worker network requests को block नहीं करता। यह only page-level fetch calls को affect करता है। अगर आप background sync behaviour test कर रहे हैं, तो आपको actually अपना network adapter disable करना होगा या Network panel के throttling presets use करने होंगे। Service worker offline checkbox के साथ testing करने से sync ऐसे काम करते दिखेगा जैसे उसे नहीं करना चाहिए।\nDebug करने के लिए: Application \u0026gt; Background Services \u0026gt; Background Sync \u0026gt; Record क्लिक करें। Background sync activity trigger करें, table में events populate होते देखें जिसमें tag name, origin, और timestamp होगा।\nPush Messaging और Notifications ये दोनों साथ काम करते हैं, इसलिए इन्हें side by side देखना समझदारी है। Push Messaging वह तरीका है जिससे आपका server user के browser को message deliver करता है, यहाँ तक कि जब वे आपकी site पर न हों। Notifications वह तरीका है जिससे वह message user को दिखाया जाता है।\nPush के साथ debugging problem timing है। आपको एक server चाहिए जो इसे भेजे, delivery asynchronous है, और service worker इसे background में process करता है। Push Messaging टैब इन events को तीन दिनों तक रिकॉर्ड करता है — तो आप अपने server से push trigger करने से पहले एक recording सेट कर सकते हैं और exactly inspect कर सकते हैं कि क्या arrived, किस order में, किस payload के साथ [1]।\nNotifications के लिए: Application \u0026gt; Background Services \u0026gt; Notifications \u0026gt; Record क्लिक करें। जब आपका service worker self.registration.showNotification() call करता है, event full detail के साथ log होता है — title, body, icon, badge, actions, हर option जो आपने pass किया।\nएक shortcut है जिसके लिए आपके server की बिल्कुल ज़रूरत नहीं: sidebar में Service Workers सेक्शन (Background Services के ठीक ऊपर) में एक Push input field और button है। एक payload type करें, Push click करें, और DevTools आपके registered service worker पर एक synthetic push event fire करता है। Server infrastructure खड़ी किए बिना आपके push handler logic verify करने के लिए ideal।\nPayment Handler Payment Handler API एक web app को standard Web Payments flow के अंदर payment method के रूप में act करने देती है [14]। Users को third-party payment processor पर redirect करने के बजाय, आपका service worker payment request intercept करता है और transaction in-context handle करता है — wallets, buy-now-pay-later services, और web-based payment apps के लिए cleaner UX।\nदो service worker events पूरी चीज़ drive करते हैं:\ncanmakepayment — तब fire होता है जब कोई merchant new PaymentRequest() call करता है। आपका service worker respond करता है कि क्या वह इस particular payment को handle कर सकता है। paymentrequest — तब fire होता है जब user browser payment sheet से आपका payment app select करता है और confirm tap करता है। यहाँ आप actual transaction करते हैं। Debug करने के लिए: Application \u0026gt; Background Services \u0026gt; Payment Handler \u0026gt; Record क्लिक करें। दोनों events table में payment method data और merchant info की full detail के साथ log होते हैं।\nPractical local development note: Payment Request API को HTTPS चाहिए, लेकिन Chrome default रूप से localhost को exempt करता है। आप self-signed certificate setup किए बिना locally test कर सकते हैं।\nBounce Tracking Mitigations ईमानदारी से कहें तो, यह पैनल में सबसे niche टैब है। लेकिन अगर आपका काम analytics, ad tech, SSO flows, या cross-site redirects से जुड़ी किसी भी चीज़ को छूता है, तो आपको इसके बारे में जानना होगा — क्योंकि यह silently उस state को delete कर सकता है जिस पर आप depend करते हैं।\nBounce tracking एक privacy evasion technique है। एक user एक link click करता है, एक सेकंड से कम में transparently एक tracker domain के ज़रिए bounce होता है, और वह tracker first-party context में cookies set या read करता है — यहाँ तक कि third-party cookies पूरी तरह blocked होने पर भी। इसीलिए third-party cookies को block करना अकेले cross-site tracking को solve नहीं करता।\nChrome का mitigation उन sites की identify करता है जो ये patterns exhibit करती हैं और उनकी stored state को completely delete करता है — cookies, localStorage, cache storage, सब कुछ [11]। Application \u0026gt; Background Services \u0026gt; Bounce Tracking Mitigations का DevTools टैब आपको deletion check manually force-run करने देता है और exactly देखने देता है कि किन site origins की state remove हुई।\nइसे test करने के लिए:\nchrome://flags में, \u0026ldquo;Bounce Tracking Mitigations\u0026rdquo; को Enabled With Deletion पर set करें Chrome Settings \u0026gt; Privacy and security में third-party cookies block करें Application \u0026gt; Background Services \u0026gt; Bounce Tracking Mitigations \u0026gt; Force Run क्लिक करें Issues टैब suspicious redirect chains के लिए एक warning भी surface करेगा: \u0026ldquo;Chrome may soon delete state for intermediate websites in a recent navigation chain.\u0026rdquo; अगर आपका OAuth या SSO implementation वह warning trigger करता है, तो आपके पास एक investigation है। Legitimate auth redirects bounce tracking जैसे लग सकते हैं अगर hop timing similar हो।\nReporting API Reporting API boring लगता है जब तक आपको एहसास न हो कि यह आपको silent production failures की visibility दे रहा है जिन्हें observe करने का आपके पास कोई दूसरा mechanism नहीं है [12]। API CSP violations, deprecated API calls, network errors, Permission Policy violations, और crash reports collect करता है, फिर उन्हें आपके configure किए गए endpoint पर भेजता है।\nConfiguration एक single response header है:\nReporting-Endpoints: default=\u0026#34;https://yoursite.com/csp-reports\u0026#34; Chrome reports batch करता है और उस URL पर deliver करता है। DevTools पैनल (Application \u0026gt; Background Services \u0026gt; Reporting API) इसे तीन sections में break करता है:\nReports table — हर pending और sent report, जिसमें type, URL, timestamp, और delivery status है Report body — full JSON payload देखने के लिए किसी report row को click करें Endpoints — configured endpoints और क्या Chrome ने उन्हें successfully reach किया, इसका summary Practice में status column सबसे उपयोगी हिस्सा है। Reports states के ज़रिए flow करती हैं: Queued → Pending → Success (या MarkedForRemoval अगर fail हो)। अगर reports indefinitely \u0026ldquo;Pending\u0026rdquo; में बैठी हैं, तो आपके endpoint में कुछ गड़बड़ है — commonly एक CORS misconfiguration, एक 4xx response, या header value में typo।\nCSP violations सबसे common use case हैं और शायद Reporting API को wire up करने का सबसे अच्छा argument, यहाँ तक कि अगर आप इसके साथ और कुछ नहीं कर रहे। इसके बिना, आप content security policy deploy करते हैं और production में क्या block हो रहा है इसका zero signal मिलता है। इसके साथ, आपको हर real user session में हर violation का structured log मिलता है।\nDevice Bound Sessions यह पैनल में सबसे नई entry है और arguably सबसे security-significant feature जो Chrome ने वर्षों में ship किया है। Device Bound Session Credentials (DBSC) एक specific, well-understood attack को address करता है: session cookie theft।\nAttack इस तरह काम करता है। User की machine पर malware, एक compromised browser extension, या local privilege escalation एक attacker को session cookies export करने देता है। वे cookies, attacker की machine से replay किए गए, victim के रूप में authenticate करते हैं — MFA हो या न हो, क्योंकि MFA पहले ही satisfy हो चुका था और cookie ही credential है।\nDBSC इसे session को specific physical device से cryptographically bind करके तोड़ता है [13]। Login पर, Chrome एक key pair generate करता है और private key को device के secure hardware में store करता है — जब available हो तो Trusted Platform Module (TPM)। Sessions short-lived cookies use करते हैं। जब कोई cookie expire होती है, Chrome को server द्वारा नई cookie issue करने से पहले private key के possession का proof देना होगा। एक attacker जो cookie steal करता है वह किसी key के possession का proof नहीं दे सकता जो device कभी नहीं छोड़ी।\nDBSC implement करने वाले developers के लिए, server-side changes हैं [14]:\nअपने login response में एक Secure-Session-Registration header include करें, refresh endpoint URL और session configuration specify करते हुए एक refresh endpoint expose करें जो नई cookies issue करने से पहले cryptographic key possession proof validate करता है DBSC 2026 की शुरुआत में Chrome 146 पर Windows users के लिए generally available हुआ, macOS expansion जल्द बाद announce हुई [14]। एक second origin trial October 2025 में real-world implementation feedback collect करने के लिए खुला।\nDevTools में, Application panel का Device Bound Sessions सेक्शन आपको active DBSC sessions view करने, उनके bound domains inspect करने, और उन्हें delete करने देता है — यह verify करने के लिए उपयोगी है कि आपका logout flow sessions correctly terminate करता है, और confirm करने के लिए कि session binding expected origin के लिए registered है। Full debugging tooling अभी भी build हो रही है; अभी के लिए, Chrome histograms और network response headers उन gaps को fill करते हैं जो पैनल अभी तक cover नहीं करता।\nUnderlying spec W3C Web Application Security working group के ज़रिए develop हो रहा है, इसलिए DBSC को eventual cross-browser adoption के लिए design किया जा रहा है — एक permanent Chrome-only feature नहीं।\nbfcache के near-instant back navigation देने, speculative loads के users के click करने से पहले pages prerender करने, background sync के यह सुनिश्चित करने के बीच कि कोई भी user action flaky connection पर silently drop न हो, और DBSC के session hijacking को hardware level पर prevent करने के साथ — Background Services पैनल quietly Chrome DevTools के सभी sections में सबसे महत्वपूर्ण और सबसे कम-explore किए गए sections में से एक है।\nअंत\nस्रोत Debug background services | Chrome DevTools Back/forward cache | web.dev Back/forward cache notRestoredReasons API | Chrome for Developers Enabling bfcache for Cache-Control: no-store | Chrome for Developers Prerender pages in Chrome for instant page navigations | Chrome for Developers How Monrif improved engagement by 8.9% and reduced LCP by 17.9% with Speculation Rules prerender | web.dev Debug speculation rules with Chrome DevTools | Chrome for Developers workbox-background-sync | Chrome for Developers Download AI models with the Background Fetch API | web.dev Introducing Background Fetch | Chrome for Developers Help test bounce tracking mitigations | Chrome for Developers Monitor your web application with the Reporting API | Chrome for Developers Device Bound Session Credentials (DBSC) | Chrome for Developers Device Bound Session Credentials now available on Windows | Chrome for Developers Web-based Payment Handler API | MDN Web Docs ","permalink":"https://cloudmato.com/hi/posts/chrome-devtools-background-services/","title":"Chrome DevTools Background Services: संपूर्ण गाइड"},{"content":"DevTools खोलें, Application पर क्लिक करें, और बाईं ओर की साइडबार देखें। Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage, Shared Storage, Background Services\u0026hellip; यह काफी कुछ है। मैंने सीनियर डेवलपर्स को भी हर चीज़ के लिए localStorage का इस्तेमाल करते देखा है — ऑथ टोकन, शॉपिंग कार्ट, यहाँ तक कि मेगाबाइट्स में API रिस्पॉन्स — सिर्फ इसलिए क्योंकि यह वही है जिसे वे जानते हैं। यह हमेशा गलत नहीं होता, लेकिन यह शायद ही कभी सबसे अच्छा विकल्प होता है। आइए असल में देखें कि इनमें से हर मैकेनिज्म क्या करता है, DevTools में आपको यह कहाँ मिलेगा, और — सबसे ज़रूरी — आपको इसे बाकी छह विकल्पों के बजाय कब चुनना चाहिए जो ठीक बगल में बैठे हैं।\nApplication पैनल का महत्व क्यों है ब्राउज़रों में एकीकृत स्टोरेज इंस्पेक्टर आने से पहले, \u0026ldquo;मेरा डेटा क्यों नहीं टिक रहा\u0026rdquo; को डीबग करने का मतलब था अंदाज़े के सहारे console.log का सहारा लेना। Chrome DevTools के Application पैनल ने यह बदल दिया — यह आपको कुकीज़, लोकल स्टोरेज, सेशन स्टोरेज, IndexedDB डेटाबेस, कैश स्टोरेज एंट्रीज़, सर्विस वर्कर्स, और यहाँ तक कि Shared Storage और Interest Groups जैसी नई Privacy Sandbox फ़ीचर्स को देखने, संपादित करने और मैन्युअल रूप से डिलीट करने के लिए एक जगह देता है [1]।\nयह इसलिए मायने रखता है क्योंकि इन हर तरह के स्टोरेज का व्यवहार अलग-अलग होता है — अलग-अलग साइज़ लिमिट, अलग-अलग जीवनकाल, अलग-अलग सिंक/एसिंक व्यवहार, सर्वर को अलग-अलग दृश्यता। गलत विकल्प चुनना सिर्फ एक स्टाइल चॉइस नहीं है; यह आपके ऐप के परफॉर्मेंस को बिगाड़ सकता है, टैब्स के बीच डेटा लीक कर सकता है, या बिना आपको पता चले चुपचाप ब्राउज़र द्वारा मिटाया जा सकता है। चलिए इसमें गहराई से उतरते हैं।\nपूरी तस्वीर — एक झलक में तुलना हर एक में गहराई से जाने से पहले, यहाँ वह चीट-शीट है जो काश कोई मुझे सालों पहले दे देता:\nमैकेनिज्म क्षमता (लगभग) टैब बंद होने पर बचता है? सर्वर को भेजा जाता है? सिंक या एसिंक? किसके लिए सबसे बेहतर Cookies ~4KB प्रति कुकी expires पर निर्भर हाँ, अपने आप सिंक (document.cookie) ऑथ/सेशन टोकन, सर्वर-रीड फ़्लैग sessionStorage ~5MB नहीं (टैब के अनुसार) नहीं सिंक विज़ार्ड/फॉर्म स्टेट, एक बार का पेज डेटा localStorage ~5–10MB हाँ नहीं सिंक (ब्लॉकिंग) यूज़र प्रेफरेंस, छोटे कैश, फीचर फ्लैग IndexedDB सैकड़ों MB–GBs हाँ नहीं एसिंक ऑफ़लाइन डेटा, बड़े स्ट्रक्चर्ड रिकॉर्ड्स Cache Storage (Service Worker) ओरिजिन कोटा साझा करता है हाँ नहीं एसिंक कैश की गई नेटवर्क रिक्वेस्ट्स, ऑफ़लाइन एसेट्स OPFS (Origin Private File System) ओरिजिन कोटा साझा करता है हाँ नहीं एसिंक/सिंक (वर्कर्स में) ब्राउज़र-इन डेटाबेस, फ़ाइल-भारी ऐप्स Shared Storage छोटा, राइट-ओनली रीड हाँ नहीं (क्रॉस-साइट, प्राइवेसी-प्रिज़र्विंग) एसिंक प्राइवेसी-सुरक्षित क्रॉस-साइट मेज़रमेंट ये क्षमताएँ और व्यवहार सीधे उस तुलना डेटा से लिए गए हैं जिसे Chrome और MDN प्रकाशित करते हैं, और यह लगभग वैसा ही है जैसा मैं खुद DevTools में टटोलते वक्त देखता हूँ — सेशन/लोकल स्टोरेज प्रति ओरिजिन लगभग 5MB के आसपास रहता है, कुकीज़ की सीमा लगभग 4KB है, और IndexedDB डिस्क स्पेस के आधार पर सैकड़ों मेगाबाइट्स या उससे ज़्यादा तक फैल सकता है [2]।\nअब चलिए वाकई हर एक में जाते हैं — यह किसके लिए है, और एक असली परिदृश्य जहाँ मैं इसे चुनूँगा।\nCookies — एकमात्र ऐसी चीज़ जिसे आपका सर्वर वाकई पढ़ सकता है यहाँ वह बात है जिसे लगभग सभी पहले से जानते हैं लेकिन फिर भी कहीं न कहीं गलत समझ बैठते हैं: कुकीज़ ही एकमात्र क्लाइंट स्टोरेज मैकेनिज्म हैं जो हर मैचिंग HTTP रिक्वेस्ट के साथ अपने आप सर्वर को भेज दी जाती हैं [2]। जब आपको सर्वर-साइड सेशन वैलिडेशन की ज़रूरत हो तो यह एक फ़ीचर है, और जब आप उनमें मेगाबाइट्स का कचरा भरने लगते हैं तो यह एक परफॉर्मेंस टैक्स बन जाता है।\nDevTools में, ये आपको Application → Storage → Cookies → (कोई ओरिजिन चुनें) के अंतर्गत मिलेंगी। आप वैल्यूज़ को इनलाइन एडिट कर सकते हैं, नई जोड़ सकते हैं, नाम से फ़िल्टर कर सकते हैं, और HttpOnly, Secure, और SameSite जैसे फ़्लैग वहीं टेबल में देख सकते हैं [1]।\nअसली इस्तेमाल का मामला: ऑथेंटिकेशन सेशन। जब कोई यूज़र लॉगिन करता है, तो सर्वर एक HttpOnly कुकी सेट करता है जिसमें सेशन ID होती है। चूंकि यह HttpOnly है, JavaScript इसे पढ़ नहीं सकता (इसलिए कोई XSS बग इसे सीधे चुरा नहीं सकता), और चूंकि यह एक कुकी है, यह हर रिक्वेस्ट के साथ चली जाती है ताकि सर्वर यूज़र को \u0026ldquo;याद रखने\u0026rdquo; के लिए आपको क्लाइंट-साइड कोड लिखे बिना ही सेशन वैलिडेट कर सके।\nएक दूसरा, बहुत मौजूदा इस्तेमाल का मामला है: सहमति और पर्सनलाइज़ेशन फ़्लैग जिनकी सर्वर को रेंडर के समय ज़रूरत होती है — जैसे कि यूज़र किस A/B टेस्ट बकेट में है, या उसने कुकी बैनर स्वीकार किया है या नहीं — क्योंकि सर्वर को यह HTML बनाने से पहले जानना ज़रूरी है।\nयह जानना भी ज़रूरी है कि थर्ड-पार्टी कुकी की कहानी एक रोलरकोस्टर रही है। Google ने पहले घोषणा की थी कि वह थर्ड-पार्टी कुकीज़ को पूरी तरह खत्म कर देगा, फिर 2024 के मध्य में इसे वापस ले लिया — अब Chrome उन्हें पूरी तरह ब्लॉक करने के बजाय यूज़र को एक \u0026ldquo;चॉइस\u0026rdquo; प्रॉम्प्ट दिखाता है [3][4]। Safari और Firefox पहले से ही डिफ़ॉल्ट रूप से थर्ड-पार्टी कुकीज़ ब्लॉक करते हैं, इसलिए अगर आपका ऐप ट्रैकिंग या एम्बेड्स के लिए क्रॉस-साइट कुकीज़ पर निर्भर है, तो आप पहले से ही आंशिक रूप से कुकीज़-रहित दुनिया में जी रहे हैं, चाहे Chrome इसे ज़बरदस्ती करे या न करे [4]। और चाहे फर्स्ट-पार्टी हो या थर्ड-पार्टी, क्रॉस-साइट कुकीज़ में SameSite=None; Secure होना ज़रूरी है — यह Chrome 80 के बाद से एक सख्त शर्त रही है [4]।\nlocalStorage — वह आसान दराज़ जिसमें सब कुछ ठूंस दिया जाता है localStorage एक सिंक्रोनस की-वैल्यू स्टोर है, जो ओरिजिन के दायरे में सीमित है, और ब्राउज़र रीस्टार्ट के बाद भी टिका रहता है। यह आपको Application → Storage → Local Storage → (ओरिजिन) के अंतर्गत मिलेगा, जहाँ DevTools आपको सीधे टेबल में एंट्रीज़ जोड़ने, संपादित करने और मिटाने देता है [1]।\nयह वाकई किसके लिए अच्छा है:\nयूज़र प्रेफरेंस — थीम (डार्क/लाइट), भाषा, लेआउट डेंसिटी छोटे फीचर फ्लैग या \u0026ldquo;यह टूलटिप दोबारा मत दिखाओ\u0026rdquo; जैसे मार्कर छोटे, कम बदलने वाले API रिस्पॉन्स की हल्की कैशिंग (सोचिए: देशों के कोड्स की एक सूची, यूज़र के पूरे ऑर्डर इतिहास की नहीं) जहाँ मैंने इसे गलत होते देखा है: लोग \u0026ldquo;सुविधा\u0026rdquo; के लिए localStorage में JWT स्टोर करते हैं, यह समझे बिना कि पेज पर चलने वाली कोई भी स्क्रिप्ट — चाहे वह किसी समझौता किए गए npm पैकेज से आई हो या किसी XSS छेद से — इसे पढ़ सकती है। HttpOnly वाली कुकीज़ कम से कम आपके टोकन और मनमानी JavaScript के बीच एक दीवार खड़ी कर देती हैं। अगर आपको क्लाइंट-साइड पर टोकन स्टोर करना ही पड़े और कुकीज़ का इस्तेमाल न कर सकें, तो कम से कम यह समझ लें कि आप XSS-प्रतिरोध को सुविधा के बदले में दे रहे हैं।\nदूसरी समस्या: localStorage सिंक्रोनस है और मेन थ्रेड को ब्लॉक करता है। किसी टेक्स्ट एडिटर में हर कीस्ट्रोक पर कुछ सौ KB JSON लिख दीजिए, और आपको अपने UI में हकलाहट महसूस होने लगेगी। मैंने वाकई एक \u0026ldquo;साधारण\u0026rdquo; ऑटोसेव फीचर को इनपुट रिस्पॉन्सिवनेस को तबाह करते देखा है क्योंकि कोई हर oninput इवेंट पर localStorage.setItem(JSON.stringify(hugeObject)) कर रहा था। यह बिल्कुल वैसी ही \u0026ldquo;मेरी मशीन पर तो काम कर रहा है\u0026rdquo; वाली बग है जिसे Application पैनल पकड़ने में मदद करता है — Storage टैब खोलें, साइज़ को रियल टाइम में बढ़ते देखें, और आप समस्या को अपने यूज़र्स से पहले पकड़ लेंगे।\nsessionStorage — वह जो एक टैब अपने पड़ोसी के साथ साझा नहीं करेगा sessionStorage DevTools में बिल्कुल localStorage जैसा दिखता है (वही टेबल, वही एडिट/डिलीट UI, बस साइडबार में अलग एंट्री [1]), लेकिन इसमें एक अहम फर्क है: यह सिर्फ एक टैब के दायरे में सीमित है, और जब वह टैब बंद होता है तो यह गायब हो जाता है। यहाँ तक कि बिल्कुल एक ही ओरिजिन की ओर इशारा करने वाले दो टैब भी sessionStorage डेटा साझा नहीं करेंगे — पहली बार इसका सामना करने पर यह बहुत लोगों को चौंका देता है।\nअसली इस्तेमाल के मामले:\nमल्टी-स्टेप फॉर्म्स / चेकआउट विज़ार्ड्स — \u0026ldquo;स्टेप 2 ऑफ 4\u0026rdquo; डेटा स्टोर करना ताकि रीफ्रेश करने पर यूज़र की प्रगति बर्बाद न हो, लेकिन आप नहीं चाहते कि यह हमेशा के लिए बना रहे डुप्लिकेट फॉर्म सबमिशन रोकना — फॉर्म सबमिट होने पर एक फ़्लैग सेट करना, दोबारा सबमिट होने देने से पहले उसे जांचना एक बार का ऑनबोर्डिंग फ़्लो जिसे रीसेट हो जाना चाहिए अगर यूज़र नए टैब में ऐप ताज़ा खोलता है ईमानदारी से कहूं तो, यह सबसे कम इस्तेमाल किया जाने वाला है। लोग आदतन localStorage को डिफ़ॉल्ट चुनते हैं भले ही उस डेटा का मौजूदा टैब सेशन के बाद टिके रहने का कोई कारण न हो — जिसका मतलब है कि बाद में आपको खुद उसे साफ करना याद रखना पड़ता है। इसे ब्राउज़र पर छोड़ दीजिए।\nIndexedDB — जब आपको वाकई ब्राउज़र में एक डेटाबेस चाहिए यहीं से चीज़ें ज़्यादा दिलचस्प हो जाती हैं — और, ईमानदारी से कहूं तो, यहीं से ये थोड़ी मुश्किल भी हो जाती हैं। IndexedDB एक पूर्ण ट्रांज़ैक्शनल, एसिंक्रोनस, NoSQL-जैसा डेटाबेस है जो ब्राउज़र में बना हुआ है, जो स्ट्रक्चर्ड डेटा, ब्लॉब्स, और फ़ाइलों को स्टोर कर सकता है, साथ ही इंडेक्स और रेंज क्वेरीज़ का समर्थन भी करता है [2][5]। DevTools में यह Application → Storage → IndexedDB के अंतर्गत मिलता है, जहाँ आप व्यक्तिगत डेटाबेस, ऑब्जेक्ट स्टोर्स, और यहाँ तक कि व्यक्तिगत रिकॉर्ड्स में भी जा सकते हैं [1]।\nअसली इस्तेमाल के मामले जिनके लिए मैं इसे वाकई चुनूँगा:\nऑफ़लाइन-फर्स्ट ऐप्स — नोट लेने वाले ऐप्स, टू-डू ऐप्स, ईमेल क्लाइंट जिन्हें कमज़ोर कनेक्शन पर भी काम करना हो बड़े API रिस्पॉन्स सेट्स को कैश करना — जैसे कोई प्रोजेक्ट मैनेजमेंट टूल जो हज़ारों टास्क कैश करता है ताकि UI तुरंत महसूस हो क्लाइंट-साइड पर फ़ाइलें/ब्लॉब्स स्टोर करना — इमेज एडिटर्स, PDF व्यूअर्स, बाइनरी डेटा से जुड़ी कोई भी चीज़ जो localStorage की स्ट्रिंग-ओनली, ~5MB दुनिया के लिए बहुत बड़ी हो समझौता यह है कि IndexedDB का API मशहूर रूप से अटपटा है — कच्चा IndexedDB कोड नेस्टेड कॉलबैक्स और onsuccess/onerror हैंडलर्स से भरा होता है जो 2010 के किसी कोड जैसा लगता है (क्योंकि, खैर, यह कुछ हद तक है ही)। ज़्यादातर टीमें इसे Dexie.js या idb जैसी लाइब्रेरी से रैप करती हैं ताकि इसे झेलना आसान हो जाए। अगर आप इसे डीबग कर रहे हैं, तो Application पैनल का IndexedDB व्यूअर सच में DevTools के सबसे सुहावने हिस्सों में से एक है — आप ऑब्जेक्ट स्टोर्स को विस्तृत कर सकते हैं, रिकॉर्ड्स का निरीक्षण कर सकते हैं, और बिना एक भी लाइन कोड लिखे एक पूरा डेटाबेस मिटा सकते हैं।\nइतिहास का एक अंश जो बताता है कि IndexedDB क्यों जीता: Chrome पहले Web SQL Database का भी समर्थन करता था, जो SQLite-आधारित रिलेशनल API था। इसे डिप्रिकेट करके Chromium 119 से पूरी तरह हटा दिया गया क्योंकि यह कभी मानकीकृत नहीं हुआ — सिर्फ Chromium ने ही इसके स्पेक को पूरी तरह लागू किया था [6]। अब आधिकारिक सलाह यह है कि ज़्यादातर मामलों के लिए Web Storage APIs या IndexedDB का इस्तेमाल करें, और गंभीर रिलेशनल/परफॉर्मेंस ज़रूरतों वाले ऐप्स के लिए, Origin Private File System के ऊपर चलने वाले WebAssembly में कंपाइल किए गए SQLite का इस्तेमाल करें [6] — जो हमें सुविधाजनक रूप से अगले सेक्शन तक ले आता है।\nCache Storage और Service Workers — ऐसी चीज़ें बनाना जो ऑफ़लाइन काम करें यह वह जोड़ी है जो Progressive Web Apps को शक्ति देती है। एक service worker एक स्क्रिप्ट है जो आपके पेज और नेटवर्क के बीच बैठती है, रिक्वेस्ट्स को इंटरसेप्ट करती है, और Cache API / Cache Storage वह जगह है जहाँ यह असली रिस्पॉन्स ऑब्जेक्ट्स को छिपाती है [7][8]। DevTools में:\nApplication → Application → Service Workers रजिस्ट्रेशन स्टेटस, स्कोप दिखाता है, और आपको अपडेट ट्रिगर करने, फ़ोर्स एक्टिवेशन करने, या ऑफ़लाइन होने का अनुकरण करने देता है [9] Application → Storage → Cache Storage Cache API के ज़रिए कैश की गई हर चीज़ की एक रीड-ओनली ब्राउज़ करने योग्य सूची है — आप निरीक्षण कर सकते हैं, URL के अनुसार फ़िल्टर कर सकते हैं, और अलग-अलग एंट्रीज़ मिटा सकते हैं [1][7] असली इस्तेमाल का मामला: एक न्यूज़ साइट जो चाहती है कि लेख बिना सिग्नल वाली सबवे में भी पढ़े जा सकें। सर्विस वर्कर नेविगेशन रिक्वेस्ट्स को इंटरसेप्ट करता है, पहले Cache Storage को जांचता है, और सिर्फ ज़रूरत पड़ने पर ही नेटवर्क पर जाता है। या Twitter/X के \u0026ldquo;आप ऑफ़लाइन हैं\u0026rdquo; स्क्रीन के बारे में सोचिए जो अब भी आपकी आखिरी लोड हुई टाइमलाइन दिखाती है — यही Cache Storage अपना काम कर रहा है।\nसमझने वाली मुख्य अवधारणा — और मुझे यह तब तक ठीक से समझ नहीं आई जब तक मैंने इसे मुश्किल तरीके से डीबग नहीं किया — यह है कि Cache API सामान्य HTTP कैश से बिल्कुल अलग मैकेनिज्म है। HTTP कैश रिस्पॉन्स हेडर्स और ब्राउज़र हेयुरिस्टिक्स द्वारा संचालित होता है; Cache Storage API पूरी तरह कोड-संचालित है — आप तय करते हैं कि क्या कैश होगा, कब, और कितनी देर के लिए [8][7]। यह शक्तिशाली है, लेकिन इसका मतलब यह भी है कि पुराने एंट्रीज़ को इनवैलिडेट करना आपकी ज़िम्मेदारी है; ब्राउज़र इसे Cache-Control हेडर्स के आधार पर अपने आप नहीं करेगा जैसा वह HTTP कैश के लिए करता है।\nएक डीबगिंग टिप जिसने मुझे एक झुंझलाने वाली दोपहर से बचाया: सर्विस वर्कर को अनरजिस्टर करने से उसके कैश साफ नहीं होते। ये स्वतंत्र हैं। अगर सर्विस वर्कर को मारने के बाद आपकी \u0026ldquo;फिक्स\u0026rdquo; दिख नहीं रही है, तो Cache Storage को अलग से जांचें — या बस Application → Storage के अंतर्गत बड़े लाल Clear storage बटन को दबाएं, जो एक क्लिक में सर्विस वर्कर्स को अनरजिस्टर करता है और सभी जुड़े हुए स्टोरेज को मिटा देता है [9][10]। उस एक बटन ने मुझे \u0026ldquo;मेरा पुराना कोड अब भी क्यों चल रहा है\u0026rdquo; जैसी सिरदर्दी से जितनी बार बचाया है, मैं उतना मानने को भी तैयार नहीं।\nनए (और अजीब) वाले: OPFS, Shared Storage, और Storage Buckets Application पैनल बढ़ता ही रहता है क्योंकि वेब प्लेटफ़ॉर्म बढ़ता ही रहता है। कुछ नई एंट्रीज़ जिनके बारे में जानना उपयोगी है:\nOrigin Private File System (OPFS) — एक सैंडबॉक्स्ड, ओरिजिन-स्कोप्ड फ़ाइल सिस्टम जो बाइट-स्तर पर, उच्च-प्रदर्शन फ़ाइल एक्सेस देता है, जिसमें Web Workers से सिंक्रोनस रीड/राइट भी शामिल हैं [11]। यह ब्राउज़र-इन SQLite (WASM के ज़रिए) का पसंदीदा घर बन गया है और RxDB और ElectricSQL जैसी लोकल-फर्स्ट परियोजनाओं द्वारा इस्तेमाल होता है [11]। पकड़? DevTools के पास अभी तक नेटिव OPFS समर्थन नहीं है — आपको इसके फ़ाइल ट्री को DevTools के अंदर से ब्राउज़ करने के लिए OPFS Explorer जैसा थर्ड-पार्टी एक्सटेंशन चाहिए [12]। Shared Storage — Privacy Sandbox पहल का हिस्सा, यह साइट्स को क्रॉस-साइट डेटा स्टोर करने देता है बिना इसे सीधे JavaScript के सामने उजागर किए — आप सिर्फ प्राइवेसी-संरक्षित \u0026ldquo;वर्कलेट्स\u0026rdquo; के ज़रिए समग्र अंतर्दृष्टि निकाल सकते हैं। असली इस्तेमाल के मामलों में अद्वितीय विज्ञापन अभियान की पहुंच को मापना या थर्ड-पार्टी कुकीज़ पर निर्भर हुए बिना क्रिएटिव्स को घुमाना शामिल है [13]। आप कच्चे की-वैल्यू पेयर्स को Application → Storage → Shared Storage के अंतर्गत देख सकते हैं [1][13]। Storage Buckets — एक उभरता हुआ API जो आपको किसी ओरिजिन के स्टोरेज को अलग-अलग \u0026ldquo;बकेट्स\u0026rdquo; में बांटने देता है, जिनमें अपना खुद का कोटा और परसिस्टेंस व्यवहार होता है, ताकि आप, मसलन, महत्वपूर्ण ऑफ़लाइन डेटा वाले बकेट को persistent के रूप में चिह्नित कर सकें जबकि डिस्पोज़ेबल कैश डेटा वाले बकेट को दबाव में पहले बेदखल होने दें [14]। संभवतः आप इनमें से ज़्यादातर को रोज़मर्रा में नहीं छूएंगे जब तक आप विज्ञापन-तकनीक या भारी ऑफ़लाइन-फर्स्ट ऐप्स नहीं बना रहे — लेकिन यह जानना उपयोगी है कि अगली बार जब आप उस साइडबार में कोई अपरिचित एंट्री देखें और सोचें कि वह वहां क्या कर रही है, तो ये मौजूद हैं।\nExtension Storage — DevTools से chrome.storage को डीबग करना अगर आप Chrome एक्सटेंशन बनाते या डीबग करते हैं, तो यह एक छिपा हुआ रत्न है। Application → Storage → Extension Storage के तहत, DevTools हर इंस्टॉल किए गए एक्सटेंशन को उसके chrome.storage.local और chrome.storage.sync डेटा के साथ निरीक्षण योग्य, संपादन योग्य की-वैल्यू पेयर्स के रूप में सूचीबद्ध करता है [17]।\nदोनों स्टोरेज क्षेत्र बहुत अलग तरह से व्यवहार करते हैं। chrome.storage.local वर्तमान मशीन पर डेटा स्टोर करता है — तेज़, कोई आकार सीमा नहीं। chrome.storage.sync ऐसा डेटा लिखता है जिसे Chrome उन सभी डिवाइसों में चुपचाप सिंक कर देता है जहां यूज़र साइन इन है [18]। DevTools पैनल का असली फायदा: आप किसी भी की में क्लिक करके वैल्यू को लाइव एडिट कर सकते हैं और तुरंत देख सकते हैं कि आपका एक्सटेंशन अलग-अलग स्टोर्ड स्टेट्स पर कैसे रिस्पॉन्ड करता है।\nStorage Buckets — ब्राउज़र को बताना कि पहले क्या हटाना है Storage Buckets API एक असली प्रोडक्शन समस्या का Chromium का जवाब है: स्टोरेज प्रेशर इवेक्शन ओरिजिन के हिसाब से all-or-nothing होता है। Storage Buckets इसे ठीक करते हैं: आप स्टोरेज को अलग-अलग कोटा सीमाओं, इवेक्शन प्राथमिकता और परसिस्टेंस फ्लैग्स के साथ नामांकित बकेट्स में विभाजित कर सकते हैं [14]।\nconst criticalBucket = await navigator.storageBuckets.open(\u0026#34;user-docs\u0026#34;, { durability: \u0026#34;strict\u0026#34;, persisted: true, }); const cacheBucket = await navigator.storageBuckets.open(\u0026#34;temp-cache\u0026#34;, { durability: \u0026#34;relaxed\u0026#34;, persisted: false, }); user-docs बकेट strict + persisted: true के साथ चिह्नित है — ब्राउज़र इसे दबाव में नहीं छूएगा। temp-cache relaxed + persisted: false है — इवेक्शन के लिए उचित खेल। Application → Storage → Storage Buckets में आप हर नामांकित बकेट का निरीक्षण कर सकते हैं और सत्यापित कर सकते हैं कि आपकी परसिस्टेंस सेटिंग्स वही हैं जो आप सोचते हैं [14]।\nPrivate State Tokens — निगरानी के बिना एंटी-फ्रॉड Private State Tokens (पहले Trust Tokens कहा जाता था) एक Privacy Sandbox API है जो एक जारीकर्ता — जैसे कि एक साइट जो पहले से जानती है कि आप एक वास्तविक इंसान हैं — को किसी अन्य साइट पर आपके लिए बिना आपकी पहचान जोड़े या क्रॉस-साइट ट्रैकिंग सक्षम किए गारंटी देने देता है [19]।\nApplication → Storage → Private State Tokens में, DevTools दिखाता है कि किन जारीकर्ताओं ने वर्तमान ब्राउज़र प्रोफाइल में टोकन स्टोर किए हैं और हर जारीकर्ता के लिए कितने टोकन बचे हैं। नेटवर्क पैनल व्यक्तिगत जारी करने और रिडेम्पशन अनुरोधों को भी लॉग करता है ताकि आप पूरे फ्लो को ट्रेस कर सकें [19]। आप इनसे मिलेंगे अगर आप कोई एंटी-फ्रॉड या बॉट-डिटेक्शन सेवा एकीकृत कर रहे हैं जो थर्ड-पार्टी कुकीज़ से दूर चली गई है।\nInterest Groups — ब्राउज़र खुद का विज्ञापन नीलामी कैसे चलाता है Interest Groups Protected Audience API (पहले FLEDGE) का हिस्सा हैं। तीसरे पक्ष की कुकीज़ के बजाय, ब्राउज़र खुद आपको स्थानीय रूप से रुचि समूहों में जोड़ता है और डिवाइस पर बोली लगाने की नीलामी चलाता है [20]। आपका ब्राउज़िंग इतिहास कभी आपकी मशीन नहीं छोड़ता।\nApplication → Storage → Interest Groups में DevTools हर रुचि समूह दिखाता है जिसमें वर्तमान पेज ने आपके ब्राउज़र को जोड़ने के लिए कहा है, जिसमें मालिक, बिडिंग लॉजिक URL और उस समूह से जुड़े विज्ञापनों की सूची शामिल है [20]। इवेंट टाइमलाइन joined, bid, win, और leave इवेंट लॉग करती है। एक व्यावहारिक नोट: अगर आप पेज लोड होने के बाद Application पैनल खोलते हैं, तो आपको join इवेंट नहीं दिखेंगे — DevTools पहले से खुला रखकर पेज रिफ्रेश करें [20]।\nकोटा, बेदखली, और आपका डेटा कभी-कभी क्यों\u0026hellip; गायब हो जाता है क्या कभी किसी यूज़र ने रिपोर्ट किया है कि \u0026ldquo;मेरा डेटा गायब हो गया\u0026rdquo; और आपको इसका कोई अंदाज़ा नहीं था कि क्यों? आमतौर पर इसका जवाब यही है: स्टोरेज अनंत नहीं है, और ब्राउज़र वह डेटा बेदखल कर देगा जिसे वह ज़रूरी नहीं समझता।\nChromium-आधारित ब्राउज़र आम तौर पर किसी ओरिजिन के स्टोरेज को कुल डिस्क स्पेस के एक प्रतिशत पर सीमित कर देते हैं — और विशेष सीमा इस बात पर निर्भर करती है कि उस ओरिजिन को \u0026ldquo;persistent\u0026rdquo; स्टोरेज दिया गया है या वह \u0026ldquo;best-effort\u0026rdquo; मोड में काम कर रहा है [15]। बेस्ट-एफर्ट मोड में, जब ब्राउज़र पर स्टोरेज का दबाव आता है, तो वह सबसे पहले सबसे कम हाल ही में इस्तेमाल किए गए ओरिजिन्स को बेदखल करना शुरू करता है — और किसी भी ऐसे ओरिजिन को छोड़ देता है जिसने navigator.storage.persist() को कॉल किया हो और उसे परसिस्टेंस मिल गया हो [15]।\nआप navigator.storage.estimate() API के ज़रिए ठीक-ठीक देख सकते हैं कि आपका ऐप कहाँ खड़ा है, जो आपका वर्तमान usage और आपका quota दोनों लौटाता है — दोनों ही इस बात के आधार पर बदलते रहते हैं कि डिवाइस पर वाकई कितनी खाली डिस्क जगह है [16]। और DevTools में, Application → Storage का अवलोकन शाब्दिक रूप से आपको एक पाई चार्ट खींचकर दिखाता है कि आपके ओरिजिन का कोटा कुकीज़, IndexedDB, कैश स्टोरेज, इत्यादि में कैसे बंटा हुआ है [1] — साथ ही एक स्लाइडर भी जो छोटे कोटा का अनुकरण करता है, जो यह टेस्ट करने के लिए शानदार है कि असली यूज़र को उस दीवार से टकराने से पहले आपका ऐप तंग स्टोरेज में कैसा व्यवहार करता है।\nव्यावहारिक डीबगिंग चेकलिस्ट जिसे मैं हमेशा अपनाता हूँ जब स्टोरेज अजीब व्यवहार करता है:\nApplication → Storage खोलें और उपयोग पाई चार्ट देखें — क्या किसी एक प्रकार का स्टोरेज अप्रत्याशित रूप से बहुत बड़ा है? जांचें कि क्या ओरिजिन को परसिस्टेंस मिला है (navigator.storage.persisted()) — अगर नहीं, तो दबाव में बेदखली निष्पक्ष खेल है कम-स्टोरेज स्थितियों का अनुकरण करने के लिए कोटा ओवरराइड स्लाइडर का इस्तेमाल करें और देखें क्या टूटता है साफ शुरुआत के लिए Clear storage दबाएं, फिर समस्या को शुरू से दोहराएं खासतौर पर सर्विस-वर्कर समस्याओं के लिए, Cache Storage और Service Workers को अलग-अलग जांचें — एक को साफ करने से दूसरा साफ नहीं होता [9] तो मैं वाकई कौन सा चुनूँ? यहाँ वह निर्णय फ्रेमवर्क है जिसका मैं वाकई इस्तेमाल करता हूँ जब किसी नए फीचर की शुरुआत करता हूँ जिसे क्लाइंट पर कुछ याद रखने की ज़रूरत है:\nक्या सर्वर को हर रिक्वेस्ट पर इसे पढ़ने की ज़रूरत है? → Cookie. कुछ और अपने आप नहीं भेजा जाता [2]। क्या यह छोटा है (कुछ KB), सरल की-वैल्यू है, और टैब से ज़्यादा टिकना चाहिए? → localStorage. क्या यह छोटा, सरल है, और टैब बंद होने पर मर जाना चाहिए? → sessionStorage. क्या यह स्ट्रक्चर्ड, बड़ा, बाइनरी है, या इसे क्वेरींग/इंडेक्सिंग की ज़रूरत है? → IndexedDB (शायद Dexie या idb में रैप किया हुआ)। क्या आप ऑफ़लाइन इस्तेमाल के लिए नेटवर्क रिस्पॉन्स कैश कर रहे हैं? → Cache Storage, सर्विस वर्कर द्वारा संचालित। क्या आपको असली फ़ाइल सिस्टम या ब्राउज़र-इन SQL डेटाबेस चाहिए? → OPFS, संभवतः SQLite-WASM के साथ जोड़ा हुआ [6][11]। क्या आप यूज़र की प्राइवेसी का उल्लंघन किए बिना क्रॉस-साइट मेज़रमेंट करने की कोशिश कर रहे हैं? → Shared Storage [13]। क्या आपके पास महत्वपूर्ण डेटा है जो स्टोरेज इवेक्शन से बचना चाहिए? → persisted: true के साथ Storage Buckets [14]। Chrome एक्सटेंशन बना या डीबग कर रहे हैं? → Extension Storage (chrome.storage.local / chrome.storage.sync) [17][18]। Privacy Sandbox के साथ एड-टेक काम कर रहे हैं? → Private State Tokens (एंटी-फ्रॉड सिग्नल) और Interest Groups (ऑन-डिवाइस विज्ञापन नीलामी) [19][20]। परिदृश्य यह चुनें क्यों \u0026ldquo;मुझे याद रखें\u0026rdquo; लॉगिन सेशन Cookie (HttpOnly, Secure, SameSite) सर्वर को इसकी ज़रूरत है, और JS इसे पढ़ नहीं पाना चाहिए डार्क मोड टॉगल localStorage छोटा, सरल, विज़िट के बीच टिकना चाहिए मल्टी-स्टेप साइनअप फॉर्म sessionStorage अगर इस टैब में छोड़ दिया जाए तो गायब हो जाना चाहिए ऑफ़लाइन-सक्षम टू-डू ऐप IndexedDB + Cache Storage स्ट्रक्चर्ड डेटा + कैश्ड ऐप शेल सबवे में पढ़ी जा सकने वाली न्यूज़ साइट Service Worker + Cache Storage लेखों को पहले से कैश करें, ऑफ़लाइन होने पर कैश से परोसें ब्राउज़र-इन स्प्रेडशीट/SQL टूल OPFS + SQLite-WASM असली फ़ाइल I/O और रिलेशनल क्वेरीज़ चाहिए प्राइवेसी-सुरक्षित विज्ञापन पहुंच मापन Shared Storage कच्ची पहचान उजागर किए बिना क्रॉस-साइट अंतर्दृष्टि महत्वपूर्ण डेटा जो बेदखल न हो Storage Buckets (persisted: true) स्टोरेज दबाव से बचता है; डिस्पोज़ेबल डेटा पहले बेदखल होता है डिवाइसों में सिंक एक्सटेंशन प्रेफरेंस chrome.storage.sync Chrome इसे अपने आप सिंक करता है; Extension Storage में देखें कुकीज़ के बिना बॉट/धोखाधड़ी डिटेक्शन Private State Tokens ब्राउज़र-जारी एंटी-फ्रॉड सिग्नल, प्राइवेसी-संरक्षित ट्रैकिंग के बिना रुचि-आधारित विज्ञापन Interest Groups (Protected Audience) ऑन-डिवाइस नीलामी; ब्राउज़िंग इतिहास ब्राउज़र नहीं छोड़ता वैसे, इनमें से कोई भी एक-दूसरे को बाहर नहीं करता — ज़्यादातर गंभीर वेब ऐप्स इनमें से कई को एक साथ इस्तेमाल करते हैं। एक PWA ऑथ के लिए कुकीज़, थीम प्रेफरेंस के लिए localStorage, ऑफ़लाइन कंटेंट के लिए IndexedDB, और ऐप शेल के लिए Cache Storage — सब एक साथ इस्तेमाल कर सकता है। Application पैनल वही टूल है जो आपको यह सब एक साथ, एक ही जगह पर, बिना एक भी डीबग console.log लिखे काम करते (या न करते) देखने देता है।\nअगली बार जब कुछ \u0026ldquo;बस सेव नहीं हो रहा है\u0026rdquo;, तो अंदाज़े लगाना छोड़ें — DevTools खोलें, Application पर क्लिक करें, और वाकई देखें। दस में से नौ बार, जवाब बिल्कुल आपकी आंखों के सामने बैठा होता है।\nस्रोत Application panel overview | Chrome DevTools | Chrome for Developers Browser Storage Explained: LocalStorage vs SessionStorage vs IndexedDB vs Cookies - DEV Community Third-Party Cookie Deprecation Testing and Debugging - Chromium Third-Party Cookie Deprecation: The 2026 Guide | Ethyca 9 differences between IndexedDB and LocalStorage - DEV Community Deprecating and removing Web SQL | Blog | Chrome for Developers CacheStorage - Web APIs | MDN Service workers and the Cache Storage API | Articles | web.dev Debug Progressive Web Apps | Chrome DevTools | Chrome for Developers Tips and Tricks for Debugging Service Workers The origin private file system | Articles | web.dev OPFS Explorer - Chrome DevTools extension - GitHub Shared Storage overview | Privacy Sandbox | Chrome for Developers Not all storage is created equal: introducing Storage Buckets | Blog | Chrome for Developers Storage quotas and eviction criteria - Web APIs | MDN Estimating Available Storage Space | Blog | Chrome for Developers View and edit extension storage | Chrome DevTools | Chrome for Developers chrome.storage API Reference | Chrome for Developers Private State Tokens | Privacy Sandbox | Chrome for Developers Protected Audience API overview | Privacy Sandbox | Chrome for Developers ","permalink":"https://cloudmato.com/hi/posts/chrome-devtools-storage-mechanisms-explained/","title":"Chrome DevTools स्टोरेज: हर मैकेनिज्म की पूरी जानकारी (असली इस्तेमाल के साथ)"},{"content":"मुझे समझ आता है कि यह सवाल बार-बार क्यों उठता है। एक WebSocket खुला रहता है, याद रखता है कि आप कौन हैं, और सर्वर को बार-बार पूछे बिना ही आपको डेटा भेजने देता है। तो फिर हम एक ही पेज लोड के लिए सौ अलग-अलग HTTP रिक्वेस्ट क्यों भेजते रहते हैं, जब हम सिर्फ एक परसिस्टेंट पाइप खोलकर काम चला सकते हैं? सच कहूं तो यह सवाल जितना समझदार लगता है, उतनी क्रेडिट लोग इसे नहीं देते — और इसका जवाब \u0026ldquo;क्योंकि HTTP बेहतर है\u0026rdquo; नहीं है। मामला इससे कहीं ज़्यादा बारीक है।\nरुकिए, क्या एक स्टेटफुल कनेक्शन साफ़ तौर पर ज़्यादा कुशल नहीं है? कागज़ पर, हाँ। एक बार जब शुरुआती HTTP \u0026ldquo;अपग्रेड\u0026rdquo; हैंडशेक के ज़रिए WebSocket कनेक्शन स्थापित हो जाता है, तो क्लाइंट और सर्वर दोनों किसी भी समय एक-दूसरे को डेटा भेज सकते हैं, और हर मैसेज पर फ़्रेमिंग का ओवरहेड बहुत कम होता है [1]। न दोहराए जाने वाले हेडर्स, न हर रिक्वेस्ट के साथ चलने वाले कुकीज़, न हर एक्सचेंज पर यह दोबारा साबित करना कि आप कौन हैं। हैंडशेक के बाद, WebSocket डेटा फ़्रेम्स में HTTP के मुक़ाबले बहुत कम प्रोटोकॉल ओवरहेड होता है, जहाँ हर रिक्वेस्ट और रिस्पॉन्स के साथ कुकीज़, यूज़र-एजेंट स्ट्रिंग्स, और कैश-कंट्रोल डायरेक्टिव्स जैसे हेडर्स घसीटे जाते हैं [2]।\nतो यह सहज समझ बनती है: अगर कनेक्शन को पहले से पता है कि मैं कौन हूँ और वह खुला रहता है, तो मुझे हर पेज पर सौ बार अपना परिचय क्यों देना पड़े?\nलेकिन यहीं पेच है — जो चीज़ WebSocket को रियल-टाइम कम्युनिकेशन में बेहतरीन बनाती है (यानी स्टेटफुलनेस), वही चीज़ इसे बड़े पैमाने पर चलाना महंगा भी बनाती है। यह कोई मुफ़्त की सुविधा नहीं है। यह एक सौदा है जो आप कर रहे हैं, और एक सामान्य वेब पेज के लिए ज़्यादातर समय यह सौदा फ़ायदेमंद नहीं होता।\n\u0026ldquo;सर्वर को आप याद हैं\u0026rdquo; — इसकी छुपी हुई कीमत जब आप कोई सामान्य HTTP रिक्वेस्ट भेजते हैं, तो REST APIs स्टेटलेस होते हैं — सर्वर रिक्वेस्ट्स के बीच क्लाइंट की डिटेल्स याद नहीं रखता, जिससे ज़्यादा सर्वर जोड़ना और लोड बाँटना बेहद आसान हो जाता है [3]। आपके बेड़े का कोई भी सर्वर किसी भी रिक्वेस्ट का जवाब दे सकता है, क्योंकि कॉल्स के बीच कोई आपके बारे में कुछ \u0026ldquo;याद\u0026rdquo; नहीं रख रहा होता।\nWebSocket इस पूरी तस्वीर को पलट देता है। सर्वर को हर एक कनेक्शन का हिसाब रखना पड़ता है — कौन जुड़ा है, उसकी स्थिति क्या है, उसने किन चीज़ों को सब्सक्राइब किया है — जब तक वह सॉकेट जीवित है। और यह मुफ़्त नहीं है:\nहर खुला हुआ WebSocket कनेक्शन सिर्फ़ निष्क्रिय बैठे रहने के लिए लगभग 2–10 KB मेमोरी खा जाता है, और जब बात लाखों यूज़र्स की हो तो यह जल्दी ही बहुत बड़ा आँकड़ा बन जाता है [4]। हर कनेक्शन सर्वर पर एक फ़ाइल डिस्क्रिप्टर भी घेरता है, और ऑपरेटिंग सिस्टम्स में इस बात की सख़्त सीमा होती है कि एक साथ कितने खुले रह सकते हैं [4]। सर्वर कनेक्शन्स को ज़िंदा रखने में ही CPU जलाता रहता है — हार्टबीट्स भेजना, रीकनेक्ट्स संभालना, जो कुछ भी इधर-उधर से रिसता है उसे प्रोसेस करना [5]। अब इसे \u0026ldquo;हर पेज लोड पर एक सॉकेट\u0026rdquo; से गुणा कीजिए। अगर आपकी साइट पर कुछ हज़ार लोग एक साथ आते हैं, तो अचानक आपके पास कुछ हज़ार लंबे समय तक टिके रहने वाले, मेमोरी खाने वाले, स्टेटफुल कनेक्शन्स आ जाते हैं, जिनकी देखभाल आपके सर्वर्स को करनी पड़ती है — उन पेजेज़ के लिए, जिन्हें असल में बस कुछ JSON लाकर एक बार रेंडर करना था।\nलोड बैलेंसर का वह दर्द जिसका कोई ज़िक्र नहीं करता यहीं पर बैकएंड टीमों के लिए असली परेशानी शुरू होती है। चूँकि WebSocket स्टेटफुल होता है, इसलिए जो सर्वर वह कनेक्शन पकड़े हुए है, सिर्फ़ वही जानता है कि उस क्लाइंट के साथ क्या चल रहा है। इसका मतलब है कि लोड-बैलेंस्ड माहौल में WebSocket कनेक्शन्स को सेशन एफ़िनिटी (यानी \u0026ldquo;स्टिकी सेशन्स\u0026rdquo;) की ज़रूरत होती है [4]। एक बार जब क्लाइंट सर्वर B से जुड़ जाता है, तो उस क्लाइंट के लिए हर भविष्य की बातचीत को सर्वर B पर ही जाना पड़ता है — आपका लोड बैलेंसर बस कंधे उचका कर उसे जहाँ खाली जगह हो वहाँ नहीं भेज सकता।\nयह तब तक मैनेज करने लायक लगता है जब तक आप इसे असल में प्रोडक्शन में नहीं चलाते:\nजब सर्वर B क्रैश होता है, तो उससे जुड़ा हर एक क्लाइंट एक झटके में अपनी सेशन स्थिति खो देता है [6]। अपने पूरे बेड़े में लोड को फिर से बाँटना काफ़ी मुश्किल हो जाता है, क्योंकि कनेक्शन्स को आज़ादी से इधर-उधर नहीं किया जा सकता [6]। रोलिंग डिप्लॉयमेंट्स एक उथल-पुथल भरी घटना बन जाती हैं, क्योंकि अपडेट के लिए किसी सर्वर को ख़ाली करने का मतलब है उससे जुड़े हर स्टिकी क्लाइंट को ज़बरदस्ती डिस्कनेक्ट करना [6]। इसका \u0026ldquo;इलाज\u0026rdquo; यह है कि सेशन स्टेट को Redis जैसी किसी चीज़ में बाहर निकाल दिया जाए ताकि कोई भी सर्वर किसी भी क्लाइंट को संभाल सके [6] — जो बिल्कुल किया जा सकता है, लेकिन ज़रा गौर कीजिए कि यहाँ क्या हो गया: आप \u0026ldquo;किसी शेयर्ड स्टेट की ज़रूरत नहीं\u0026rdquo; (HTTP) से \u0026ldquo;अब मुझे एक डिस्ट्रिब्यूटेड स्टेट स्टोर चाहिए ताकि मेरा स्टेटफुल प्रोटोकॉल स्टेटलेस जैसा बर्ताव कर सके\u0026rdquo; तक पहुँच गए। एक ऐसा पेज बनाने के लिए यह बहुत सारे अतिरिक्त चलते-पुर्ज़े हैं, जो HTTP के साथ बिना किसी झंझट के काम कर जाता।\n\u0026ldquo;लेकिन HTTP तो कितने सारे कनेक्शन्स बर्बाद करता है!\u0026rdquo; — अब असल में ऐसा नहीं है मुझे लगता है कि यही वह बिंदु है जहाँ लोग सबसे ज़्यादा भटक जाते हैं, क्योंकि यह सोच सन् 2009 की HTTP की समझ में अटकी हुई है। हाँ, ब्राउज़र्स ऐतिहासिक रूप से HTTP/1.1 के तहत आपको प्रति डोमेन 6 समानांतर कनेक्शन्स तक सीमित रखते थे [9], और हाँ, इसका मतलब यह था कि एक \u0026ldquo;बातूनी\u0026rdquo; पेज ऐसा महसूस करा सकता था मानो रिक्वेस्ट्स एक-दूसरे के पीछे कतार में लगी हों।\nलेकिन दो चीज़ों ने इस तस्वीर को काफ़ी हद तक बदल दिया:\nHTTP/1.1 कीप-अलाइव। \u0026ldquo;Connection: keep-alive\u0026rdquo; मेकेनिज़्म ब्राउज़र को हर बार नया कनेक्शन खोलने के बजाय एक ही TCP कनेक्शन को कई रिक्वेस्ट्स के लिए दोबारा इस्तेमाल करने देता है [8], जो लोगों के मन में बैठे HTTP के \u0026ldquo;ओवरहेड\u0026rdquo; का एक बड़ा हिस्सा यूँ ही ख़त्म कर देता है। HTTP/2 मल्टीप्लेक्सिंग। HTTP/2 के साथ, ब्राउज़र प्रति डोमेन सिर्फ़ एक TCP कनेक्शन खोलता है और उसी पर एक साथ कई रिक्वेस्ट/रिस्पॉन्स \u0026ldquo;स्ट्रीम्स\u0026rdquo; चलाता है [9]। यह पुरानी प्रति-डोमेन रुकावट को लगभग पूरी तरह मिटा देता है — आपको WebSocket की वह पसंदीदा कुशलता (एक कनेक्शन, कई एक्सचेंज) मिल जाती है, बिना स्टेटलेसनेस को छोड़े। यहाँ एक तुलना है जो असली ट्रेड-ऑफ़्स को काफ़ी साफ़ कर देती है:\nपहलू HTTP/1.1 (कीप-अलाइव) HTTP/2 WebSocket प्रति पेज कनेक्शन्स प्रति डोमेन 6 तक [9] प्रति डोमेन 1 (मल्टीप्लेक्स्ड) [9] 1 (परसिस्टेंट) सर्वर को आपको \u0026ldquo;याद\u0026rdquo; रखना पड़ता है नहीं नहीं हाँ — कनेक्शन की पूरी उम्र भर [3] CDN/प्रॉक्सी द्वारा कैश हो सकता है हाँ [12] हाँ [12] नहीं — कैश करने के लिए कुछ है ही नहीं, यह एक लाइव स्ट्रीम है बिना पूछे सर्वर डेटा भेज सकता है नहीं (पहले रिक्वेस्ट आना ज़रूरी) नहीं हाँ, कभी भी [2] सख़्त कॉर्पोरेट फ़ायरवॉल्स के पीछे काम करता है हाँ (पोर्ट 443 हमेशा खुला रहता है) हाँ अक्सर ब्लॉक हो जाता है या फ़ॉलबैक चाहिए [15] स्केलिंग मॉडल स्टेटलेस — कोई भी सर्वर, कहीं भी स्टेटलेस — कोई भी सर्वर, कहीं भी स्टिकी सेशन्स या शेयर्ड स्टेट चाहिए [4][6] इस टेबल को देखकर सवाल का जवाब लगभग ख़ुद ही मिल जाता है: HTTP/2 ने \u0026ldquo;बहुत ज़्यादा कनेक्शन्स\u0026rdquo; की समस्या को बिना स्टेटलेसनेस छोड़े पहले ही सुलझा दिया है। आपको कैशिंग, आसान हॉरिज़ॉन्टल स्केलिंग, और फ़ायरवॉल-फ़्रेंडलीनेस — सब बना रहता है — और WebSocket का सहारा सिर्फ़ तभी लेना पड़ता है जब आपको उसकी एक सच में अनोखी ख़ासियत चाहिए हो: सर्वर का अपनी मर्ज़ी से डेटा भेजना, न कि तब जब आप पूछें।\nआप कैशिंग खो देंगे — और यह जितना लगता है उससे कहीं बड़ी बात है यह वो बिंदु है जिसे लोग सबसे ज़्यादा कम आँकते हैं। हर जगह WebSocket इस्तेमाल करने का मतलब है कि आप कुछ भी कैश नहीं कर सकते, और यह चुपके से आपकी सर्वर लागत को काफ़ी ऊपर पहुँचा देता है [3]। ज़रा सोचिए कि एक सामान्य पेज लोड में असल में क्या-क्या शामिल होता है — आपकी CSS, इमेजेज़, उन चीज़ों के API रिस्पॉन्स जो शायद ही कभी बदलते हों, आपका यूज़र अवतार, प्रोडक्ट लिस्टिंग्स। इसका एक बड़ा हिस्सा हज़ारों यूज़र्स के लिए बिल्कुल एक जैसा होता है और मिनट-दर-मिनट मुश्किल से ही बदलता है।\nसादे HTTP के साथ, CDN और रिवर्स प्रॉक्सी आपके सर्वर्स के आगे बैठकर यह सब कुछ कैश कर लेते हैं, और दोहराई गई रिक्वेस्ट्स को सीधे एज से परोस देते हैं, बिना आपके ओरिजिन सर्वर को पसीना बहाए [12]। यह स्टेटलेस रिक्वेस्ट/रिस्पॉन्स मॉडल में बुनी हुई एक मूलभूत बढ़त है — क्योंकि कोई कुछ याद नहीं रख रहा, इसलिए कहीं भी मौजूद कोई भी कैश जवाब दे सकता है।\nWebSocket एक लाइव, दो-तरफ़ा स्ट्रीम है। यहाँ कैश करने के लिए कोई \u0026ldquo;रिस्पॉन्स\u0026rdquo; नहीं है — बस एक चलती हुई बातचीत है जो उस एक कनेक्शन के लिए अनोखी है। जिस पल आप सब कुछ सॉकेट्स के ज़रिए धकेलना शुरू करते हैं, आप वेब के सबसे सस्ते और सबसे आज़माए हुए परफ़ॉर्मेंस टूल — मामूली से दिखने वाले HTTP कैश — को फेंक चुके होते हैं।\nऔर फिर वह कोई-न-कोई कॉर्पोरेट फ़ायरवॉल है जो बस मना कर देता है क्या कभी आपने कुछ ऐसा बनाया है जो घर के वाई-फ़ाई पर एकदम सही चला, और फिर जैसे ही किसी ने उसे ऑफ़िस के नेटवर्क से चलाया, पूरी तरह बिगड़ गया? WebSocket को यह समस्या लगातार झेलनी पड़ती है। ज़्यादातर वेब प्रॉक्सी और सख़्त कॉर्पोरेट फ़ायरवॉल WebSocket कनेक्शन्स को सीधे ब्लॉक कर देते हैं, अक्सर इसलिए क्योंकि वे एक ट्रांसपेरेंट प्रॉक्सी के ज़रिए सिर्फ़ पोर्ट 80 और 443 पर सादे HTTP ट्रैफ़िक को ही जाने देने के लिए कॉन्फ़िगर किए गए होते हैं [15][16]।\nपोर्ट सही होने पर भी, प्रोडक्शन में WebSocket फ़ेल होने का सबसे आम कारण यह है कि रिवर्स प्रॉक्सीज़ को उस HTTP \u0026ldquo;अपग्रेड\u0026rdquo; हैंडशेक को आगे भेजने के लिए साफ़ तौर पर कॉन्फ़िगर करना पड़ता है जो WebSocket कनेक्शन शुरू करता है [15]। अगर वह कॉन्फ़िगरेशन गायब है — और अक्सर ऐसा होता ही है, क्योंकि हर ऑप्स टीम इसे जोड़ने की नहीं सोचती — तो आपका सॉकेट कनेक्ट ही नहीं होगा, और अब आपको फ़ॉलबैक लॉजिक (लॉन्ग-पोलिंग, रीट्राई लूप्स, वग़ैरह) लिखनी पड़ेगी, बस इसलिए कि आपकी ऐप अच्छे से डिग्रेड हो सके।\nसादे HTTP के साथ यह समस्या नहीं होती। यह वही चीज़ है जिसे धरती पर हर प्रॉक्सी, फ़ायरवॉल और कॉर्पोरेट नेटवर्क समझने और जाने देने के लिए बना है। यह कोई छोटी बढ़त नहीं है — यह \u0026ldquo;होटल के वाई-फ़ाई पर बैठा अकाउंटेंट भी आपकी ऐप सच में चला पा रहा है\u0026rdquo; वाली बढ़त है।\nतो बड़ी रियल-टाइम ऐप्स असल में यह कैसे करती हैं? यह वह हिस्सा है जो मुझे सच में सीखने लायक लगता है, क्योंकि Slack और Discord जैसी कंपनियाँ परसिस्टेंट कनेक्शन्स पर भारी भरोसा करती हैं — लेकिन ध्यान दीजिए, वे सॉकेट्स से HTTP की जगह नहीं लेतीं। वे दोनों को साथ-साथ चलाती हैं, हर एक वही करता है जिसमें वह अच्छा है।\nDiscord का Gateway एक परसिस्टेंट WebSocket कनेक्शन है जो रियल-टाइम इवेंट्स पुश करता है — किसी चैनल का नाम बदला गया, कोई रोल बनाया गया, कोई ऑनलाइन आया। लेकिन Discord साफ़ तौर पर कहता है कि ज़्यादातर मामलों में उसके रिसोर्सेज़ पर सामान्य ऑपरेशन्स को Gateway के बजाय सामान्य HTTP API से होकर जाना चाहिए, क्योंकि गेटवे कनेक्शन्स को खोलना, बनाए रखना और डिस्कनेक्ट से उबरना कहीं ज़्यादा जटिल है [13]। Slack का Socket Mode भी मिलता-जुलता है — ऐप्स लाइव इवेंट्स पाने के लिए WebSocket इस्तेमाल करते हैं, लेकिन Slack साफ़ तौर पर सलाह देता है कि जवाब वापस भेजने के लिए स्टैंडर्ड Web API (सादा HTTPS) ही इस्तेमाल किया जाए [14]। एक चैनल \u0026ldquo;मुझे बताओ अभी क्या हुआ\u0026rdquo; के लिए, और दूसरा \u0026ldquo;मैं इसके बारे में क्या करना चाहता हूँ\u0026rdquo; के लिए। पैटर्न दिखा? परसिस्टेंट कनेक्शन सिर्फ़ उस एक काम के लिए सुरक्षित रखा जाता है जो HTTP वाक़ई अच्छे से नहीं कर सकता: सर्वर का अपनी मर्ज़ी के समय पर डेटा भेजना। बाक़ी सब कुछ — लॉगिन करना, मैसेज हिस्ट्री लाना, प्रोफ़ाइल अपडेट करना, सर्च करना — अब भी सादे, स्टेटलेस HTTP रिक्वेस्ट्स पर ही चलता है, क्योंकि यही वह मॉडल है जो अच्छे से कैश होता है, बिना ड्रामे के हॉरिज़ॉन्टली स्केल करता है, और कॉर्पोरेट फ़ायरवॉल से बच निकलता है।\nतो \u0026ldquo;हर पेज पर एक सॉकेट\u0026rdquo; आख़िर कब सही मायने रखता है? मैं यह नहीं कहना चाहता कि WebSocket किसी तरह की ग़लती हैं — वे नहीं हैं। वे सही चुनाव हैं जब:\nसर्वर को बिना पूछे डेटा भेजने की ज़रूरत हो — लाइव चैट, मल्टीप्लेयर गेम स्टेट, स्टॉक टिकर्स, कोलैबोरेटिव एडिटिंग जहाँ एक व्यक्ति की हर कीस्ट्रोक को मिलीसेकंड्स के भीतर बाक़ी सबको पहुँचना ज़रूरी है [3]। अपडेट की फ़्रीक्वेंसी इतनी ज़्यादा हो कि पोलिंग बेकार साबित हो — अगर आप वैसे भी हर सेकंड किसी एंडपॉइंट को \u0026ldquo;बस एहतियातन\u0026rdquo; पीटते रहते, तो सॉकेट साफ़ तौर पर ज़्यादा ईमानदार डिज़ाइन है। लेटेंसी का अनुभव पर असल फ़र्क़ पड़े — टाइपिंग इंडिकेटर में आधे सेकंड की देरी ठीक है; एक प्रतिस्पर्धी मल्टीप्लेयर गेम में आधे सेकंड की देरी ठीक नहीं है। लेकिन एक सामान्य पेज लोड के लिए — किसी प्रोडक्ट पेज, डैशबोर्ड, ऑर्डर्स की सूची, या किसी यूज़र की प्रोफ़ाइल को लाने के लिए — इनमें से कोई भी शर्त असल में लागू नहीं होती। आप एक बार कुछ माँगते हैं, जवाब पाते हैं, और आगे बढ़ जाते हैं। यह बिल्कुल वही आकार है जिसके लिए HTTP बनाया गया था, और बिल्कुल वही आकार है जिसे कैशिंग, स्टेटलेसनेस का फ़ायदा मिलता है — और जिसे यह ज़रूरत नहीं पड़ती कि आपकी ऑप्स टीम चीज़ों को चालू रखने के लिए स्टिकी सेशन्स और शेयर्ड Redis स्टेट कॉन्फ़िगर करे।\nमेरी ईमानदार राय अगर मुझे इसे एक लाइन में समेटना हो तो: WebSocket का \u0026ldquo;स्टेटफुल\u0026rdquo; पहलू कोई मुफ़्त का बोनस फ़ीचर नहीं है — यह वह बिल है जो आप पुश पाने की सुविधा के बदले चुकाते हैं। जब आपको सच में पुश की ज़रूरत हो, तब यह बढ़िया सौदा है। जब ज़रूरत न हो, तब यह बुरा सौदा है, क्योंकि आप एक ऐसे फ़ीचर के लिए सारी लागतें (प्रति-कनेक्शन मेमोरी, स्टिकी सेशन्स, फ़ायरवॉल की कमज़ोरी, ज़ीरो कैशिंग) उठाते रहते हैं जिसका आप इस्तेमाल ही नहीं कर रहे।\nHTTP/2 की मल्टीप्लेक्सिंग ने पहले ही हमें \u0026ldquo;एक कुशल पाइप\u0026rdquo; का वह ज़्यादातर फ़ायदा दे दिया है जिसे लोग सॉकेट्स से जोड़ते हैं, और वह भी बिना ऑपरेशनल सिरदर्द के [9]। तो \u0026ldquo;हर पेज पर एक सॉकेट क्यों नहीं\u0026rdquo; का असली जवाब \u0026ldquo;क्योंकि HTTP अच्छा है और सॉकेट्स बुरे हैं\u0026rdquo; नहीं है — बल्कि यह है कि दोनों प्रोटोकॉल विपरीत समस्याओं के लिए बनाए गए हैं, और बिना सोचे-समझे स्टेटफुल वाले को चुन लेना उस समस्या को बदल देता है जो आपके पास नहीं है (बहुत ज़्यादा रिक्वेस्ट्स) कई ऐसी समस्याओं से जो आपके पास ज़रूर आएंगी (मेमोरी का दबाव, स्टिकी सेशन्स, कैश इनवैलिडेशन, और रात के दो बजे एक बहुत उलझन में पड़ा हुआ ऑप्स इंजीनियर)।\nस्रोत How Do WebSockets Work? — Postman Blog WebSocket vs HTTP: When to Use Each Protocol — WebSocket.org WebSocket vs REST: Key differences and which to use — Ably WebSocket Connection Limits: The Real Bottlenecks — WebSocket.org WebSockets at Scale: Architecture for Millions of Connections — WebSocket.org How to scale WebSockets for high-concurrency systems — Ably How to Scale WebSocket Connections — OneUptime Connection management in HTTP/1.x — MDN Web Docs Chrome\u0026rsquo;s 6 TCP connections limit — HTTP/1.1 WebSocket Handshake: HTTP Upgrade at Protocol Level — WebSocket.org RFC 6455 — The WebSocket Protocol Web (HTTP/S) Cache and Caching Proxy — Imperva CDN Guide Gateway Documentation — Discord Developers Comparing HTTP \u0026amp; Socket Mode — Slack Developer Docs How to Fix \u0026lsquo;Connection Refused\u0026rsquo; WebSocket Errors — OneUptime Getting through firewalls — RTC Quickstart Guide ","permalink":"https://cloudmato.com/hi/posts/websocket-vs-http-one-socket-per-page/","title":"क्या एक पेज में हर बार HTTP की जगह सिर्फ एक WebSocket इस्तेमाल करना बेहतर नहीं है?"},{"content":"मैं लगातार सुनता रहा \u0026ldquo;रियल-टाइम चीज़ों के लिए वेबसॉकेट इस्तेमाल करो\u0026rdquo; बिना यह समझे कि वायर पर असल में होता क्या है। तो मैंने जाकर RFC पढ़ा, कुछ सर्वर्स को टटोला, और सोचा कि जो कुछ मुझे पता चला वह लिख दूं — जिसमें वह हिस्सा भी शामिल है जिसने मुझे सबसे ज़्यादा उलझाया: क्या वेबसॉकेट अपने आप में एक प्रोटोकॉल है या सिर्फ HTTP के ऊपर कोई चालाक तरकीब?\nतो वेबसॉकेट है क्या? वेबसॉकेट एक स्थायी (persistent), फुल-डुप्लेक्स कम्युनिकेशन चैनल है जो ब्राउज़र (या किसी भी क्लाइंट) और सर्वर के बीच एक ही TCP कनेक्शन पर खुलता है [1]। फुल-डुप्लेक्स का मतलब है कि दोनों पक्ष जब चाहें संदेश भेज सकते हैं — सिर्फ़ किसी अनुरोध के जवाब में नहीं। यही वह हिस्सा है जो वेब के सामान्य मानसिक मॉडल को तोड़ देता है।\nइसकी तुलना उस तरीके से करें जिस तरह से आप शायद अपने पूरे करियर में वेब ट्रैफ़िक के बारे में सोचते आए हैं:\nक्लाइंट एक अनुरोध भेजता है। सर्वर एक जवाब वापस भेजता है। कनेक्शन (तार्किक रूप से) बंद हो जाता है या अगले अनुरोध तक निष्क्रिय पड़ा रहता है। वेबसॉकेट के साथ, एक बार कनेक्शन खुल जाने के बाद, कोई भी पक्ष किसी भी क्षण डेटा भेज सकता है — पहले किसी अनुरोध की ज़रूरत नहीं। सर्वर आपको यह पूछने का इंतज़ार किए बिना ही, कि \u0026ldquo;कुछ नया है क्या?\u0026rdquo;, कुछ होते ही तुरंत संदेश भेज सकता है [2]।\nक्या वेबसॉकेट एक प्रोटोकॉल है? हाँ — और यह एक असली मानक है यह वह हिस्सा है जिसके बारे में मैं वाकई अनिश्चित था। वेबसॉकेट कोई जावास्क्रिप्ट तरकीब या लाइब्रेरी फ़ीचर नहीं है — यह एक मानकीकृत प्रोटोकॉल है, जिसे 2011 में IETF द्वारा RFC 6455 में परिभाषित किया गया [1][3]। इसकी अपनी URI स्कीमें भी हैं: सामान्य वेबसॉकेट ट्रैफ़िक के लिए ws:// (डिफ़ॉल्ट पोर्ट 80) और TLS पर वेबसॉकेट के लिए wss:// (डिफ़ॉल्ट पोर्ट 443, यानी एन्क्रिप्टेड संस्करण जिसे आपको प्रोडक्शन में वास्तव में इस्तेमाल करना चाहिए) [1]।\nस्टैक में इसकी जगह की बात करें तो: HTTP और वेबसॉकेट दोनों ही एप्लिकेशन-लेयर (लेयर 7) प्रोटोकॉल हैं जो TCP (लेयर 4) के ऊपर चलते हैं [4]। तो वेबसॉकेट न तो TCP की जगह ले रहा है और न ही मूलभूत स्तर पर HTTP से प्रतिस्पर्धा कर रहा है — यह HTTP का एक सहोदर प्रोटोकॉल है जो संयोग से अपनी ज़िंदगी की शुरुआत HTTP बोलकर करता है।\n\u0026ldquo;वेबसॉकेट प्रोटोकॉल एक नियंत्रित वातावरण में अविश्वसनीय कोड चला रहे क्लाइंट और एक दूरस्थ होस्ट के बीच, जिसने उस कोड से संचार के लिए सहमति दी हो, द्विदिश संचार सक्षम करता है।\u0026rdquo; — RFC 6455 [3]\nवह \u0026ldquo;सहमति दी हो\u0026rdquo; वाला वाक्यांश महत्वपूर्ण है — सर्वर को प्रोटोकॉल बदलने के लिए स्पष्ट रूप से सहमत होना पड़ता है। यही हमें हैंडशेक तक ले आता है।\nहैंडशेक: एक HTTP अनुरोध वेबसॉकेट में कैसे बदलता है यह डिज़ाइन का सबसे चतुर हिस्सा है, और ईमानदारी से कहूं तो यही वजह है कि वेबसॉकेट मौजूदा इंटरनेट पर इतनी अच्छी तरह काम करता है। एक बिल्कुल नया कनेक्शन तंत्र गढ़ने के बजाय, जिसे फायरवॉल, प्रॉक्सी और कॉर्पोरेट नेटवर्क सभी को नए सिरे से सीखना पड़ता, वेबसॉकेट खुद को Upgrade हेडर का इस्तेमाल करते हुए एक सामान्य HTTP अनुरोध के ज़रिए बूटस्ट्रैप करता है [5][6]।\nअसली क्रम इस तरह है:\nक्लाइंट एक सामान्य दिखने वाला HTTP GET अनुरोध भेजता है, लेकिन उसमें अतिरिक्त हेडर होते हैं: Upgrade: websocket, Connection: Upgrade, और एक यादृच्छिक रूप से बना Sec-WebSocket-Key [1][6]। यदि सर्वर वेबसॉकेट को सपोर्ट करता है, तो वह HTTP/1.1 101 Switching Protocols के साथ जवाब देता है, जिसमें Upgrade: websocket और Connection: Upgrade को दोहराया जाता है, साथ ही एक Sec-WebSocket-Accept हेडर भी होता है [6]। वह Sec-WebSocket-Accept मान मनमाना नहीं होता — सर्वर क्लाइंट की कुंजी लेता है, उसमें एक निश्चित \u0026ldquo;मैजिक\u0026rdquo; GUID (258EAFA5-E914-47DA-95CA-C5AB0DC85B11) जोड़ता है, उसे SHA-1 से गुज़ारता है, और परिणाम को base64 में एन्कोड करता है। इससे यह साबित होता है कि सर्वर ने वाकई वेबसॉकेट अनुरोध को समझा है, न कि कोई भी रैंडम सर्वर सिर्फ़ हेडर वापस भेज रहा है [6]। इस बिंदु से आगे, वही अंतर्निहित TCP सॉकेट HTTP बोलना पूरी तरह बंद कर देता है और वेबसॉकेट फ्रेम का आदान-प्रदान शुरू कर देता है — एक हल्का बाइनरी फ्रेमिंग फ़ॉर्मेट जिसमें प्रति संदेश मात्र 2-6 बाइट्स का ओवरहेड होता है, और जो टेक्स्ट फ्रेम, बाइनरी फ्रेम, तथा कंट्रोल फ्रेम (ping/pong/close) को सपोर्ट करता है [2][1]। एक बार यह हैंडशेक पूरा हो जाने पर, कनेक्शन अब \u0026ldquo;एक HTTP कनेक्शन जो संयोग से कुछ खास करता है\u0026rdquo; नहीं रह जाता। यह पूरी तरह से एक वेबसॉकेट कनेक्शन बन चुका होता है — वही TCP पाइप, लेकिन उस पर चल रहा एक बिल्कुल अलग प्रोटोकॉल।\nवेबसॉकेट बनाम HTTP — असली अंतर यहीं से यह दिलचस्प हो जाता है, क्योंकि दोनों प्रोटोकॉल मूलभूत रूप से अलग-अलग समस्याएं हल करते हैं, भले ही एक दूसरे के ज़रिए बूटस्ट्रैप होता हो।\nपहलू HTTP वेबसॉकेट संचार मॉडल अनुरोध–प्रतिक्रिया, क्लाइंट हमेशा शुरुआत करता है [2] फुल-डुप्लेक्स — कोई भी पक्ष कभी भी भेज सकता है [1][2] कनेक्शन की आयु अल्पकालिक; हर आदान-प्रदान पर खुलता-बंद होता है (या पूल/पुनःउपयोग किया जाता है) [2] स्थायी; हैंडशेक के बाद स्पष्ट रूप से बंद किए जाने तक खुला रहता है [2] प्रति-संदेश ओवरहेड हर अनुरोध/प्रतिक्रिया पर सैकड़ों बाइट्स के हेडर [2] मात्र 2–6 बाइट्स का फ्रेम ओवरहेड [2] स्टेटफुलनेस डिज़ाइन से ही स्टेटलेस — हर अनुरोध स्वतंत्र होता है स्टेटफुल — सर्वर कनेक्शन (और अक्सर सेशन संदर्भ) को जीवित रखता है [4] सर्वर-आरंभित पुश स्वाभाविक रूप से संभव नहीं; क्लाइंट को पूछना ही होता है सहज — सर्वर डेटा तैयार होते ही उसे पुश कर सकता है [2] URI स्कीम http://, https:// ws://, wss:// [1] अंतर्निहित ट्रांसपोर्ट TCP (लेयर 4), खुद लेयर 7 वही TCP (लेयर 4), वही लेयर 7 [4] सबसे बड़ा अंतर है \u0026ldquo;बातचीत शुरू करने की इजाज़त किसे है।\u0026rdquo; HTTP में, सर्वर कभी भी आपको खुद से संदेश नहीं भेज सकता — उसे पूछे जाने का इंतज़ार करना पड़ता है। यही वजह है कि जिन ऐप्स को सादे HTTP पर लाइव अपडेट चाहिए होते हैं, वे पोलिंग (हर कुछ सेकंड में \u0026ldquo;कुछ नया है क्या?\u0026rdquo; पूछना) या लॉन्ग-पोलिंग (पूछना और सर्वर को अनुरोध तब तक खुला रखने देना जब तक कुछ न हो जाए) जैसी तरकीबों का सहारा लेते हैं। दोनों काम करती हैं, लेकिन वे खाली प्रतिक्रियाओं पर बैंडविड्थ बर्बाद करती हैं और आपके पोलिंग अंतराल के अनुपात में देरी जोड़ती हैं [7]।\nवेबसॉकेट इस बाधा को पूरी तरह हटा देता है। हैंडशेक पूरा होते ही, सर्वर कुछ होते ही तुरंत पाइप में संदेश डाल सकता है — कोई पोलिंग नहीं, कोई इंतज़ार नहीं, \u0026ldquo;कुछ नया नहीं\u0026rdquo; वाले बेकार राउंड ट्रिप नहीं [7]।\nआप वेबसॉकेट का इस्तेमाल वास्तव में कब करेंगे ईमानदारी से कहूं — ज़्यादातर CRUD ऐप्स और डैशबोर्ड्स के लिए, जो हर कुछ सेकंड में रिफ्रेश होते हैं, पोलिंग या लॉन्ग-पोलिंग के साथ सादा HTTP चलाना ज़्यादा आसान और काफ़ी है [7]। वेबसॉकेट तब अपनी जटिलता को सही ठहराते हैं जब अपडेट की आवृत्ति और दिशा अनुरोध-प्रतिक्रिया मॉडल को बोझिल बना देती है:\nचैट एप्लिकेशन — किसी भी प्रतिभागी के संदेश को बाकी सभी तक लगभग तुरंत पहुंचना ज़रूरी होता है, और यहां मानक तरीका वेबसॉकेट ही है, और इसकी अच्छी वजह भी है [7]। मल्टीप्लेयर गेमिंग — गेम की स्थिति को अक्सर प्रति सेकंड 20–60 बार सिंक करना पड़ता है; इसके अलावा कुछ भी एक स्थायी सॉकेट की प्रति-फ्रेम क्षमता के आसपास नहीं पहुंचता। सहयोगी संपादन (collaborative editing) — हर कीस्ट्रोक को न्यूनतम देरी के साथ प्रसारित होना ज़रूरी है (जैसे Google Docs जैसे टूल्स)। वित्तीय ट्रेडिंग / लाइव प्राइस फ़ीड — उसी कनेक्शन पर ऑर्डर सबमिट करने की क्षमता के साथ 100 मिलीसेकंड से कम के अपडेट [7]। लाइव नोटिफ़िकेशन और डैशबोर्ड जिन्हें वाकई समय-समय पर रिफ्रेश के बजाय हर सेकंड पुश की ज़रूरत होती है। अगर आपकी \u0026ldquo;रियल-टाइम\u0026rdquo; ज़रूरत असल में सिर्फ़ \u0026ldquo;हर 30 सेकंड में अपडेट होना ठीक है\u0026rdquo; है, तो सिर्फ़ इसलिए वेबसॉकेट मत अपनाइए कि यह आधुनिक लगता है। यह ट्रेड-ऑफ असली है — वेबसॉकेट के लिए आपको कनेक्शन स्टेट, पुनर्संयोजन (reconnection) तर्क, और हज़ारों लंबे समय तक चलने वाले सॉकेट्स को स्केल करना पड़ता है, जो लोड बैलेंसर के पीछे चल रहे स्टेटलेस HTTP सर्वरों की तुलना में एक सार्थक रूप से अलग परिचालन बोझ है [7]।\nएन्क्रिप्शन पर एक संक्षिप्त नोट जिस तरह HTTP का HTTPS होता है, उसी तरह वेबसॉकेट का wss:// होता है, जो वेबसॉकेट प्रोटोकॉल को TLS पर चलाता है [1]। प्रोडक्शन में ws:// भेजने की कोई अच्छी वजह नहीं है — wss:// का इस्तेमाल वैसे ही कीजिए जैसे आप सादे http:// पर लॉगिन फ़ॉर्म भेजने से इनकार करेंगे। हैंडशेक अब भी अपग्रेड होने से पहले एक HTTPS अनुरोध के रूप में शुरू होता है, इसलिए आपको वही प्रमाणपत्र-आधारित विश्वास मॉडल मिलता है जिसके आप पहले से अभ्यस्त हैं।\nसमापन वेबसॉकेट HTTP पर जोड़ी गई कोई जुगाड़ नहीं है — यह अपने आप में एक IETF-मानकीकृत प्रोटोकॉल (RFC 6455) है, जो HTTP के Upgrade तंत्र का इस्तेमाल बस यह विनम्रता से पूछने के तरीके के रूप में करता है कि \u0026ldquo;क्या हम इस बातचीत के लिए ज़्यादा उपयुक्त किसी चीज़ पर स्विच कर सकते हैं?\u0026rdquo; [1][3][6]। एक बार जब सर्वर 101 Switching Protocols के साथ हां कह देता है, तो आप अब बिल्कुल भी HTTP-लोक में नहीं रहते — आप एक ऐसे कनेक्शन पर हल्के फ्रेमों का आदान-प्रदान कर रहे होते हैं जो खुला रहता है और दोनों पक्षों को जब चाहें बात करने देता है [6][2]।\nक्या आपको वाकई इसकी ज़रूरत है, यह सवाल इससे अलग है कि यह सुनने में कितना दिलचस्प लगता है। ज़्यादातर चीज़ों के लिए, आपको ज़रूरत नहीं है। चैट, गेम्स, और लाइव सहयोगी टूल्स के लिए, आपको वाकई ज़रूरत है।\nस्रोत WebSocket Protocol: RFC 6455 Handshake, Frames \u0026amp; More — WebSocket.org WebSockets vs HTTP: Key Differences Explained — Postman Blog RFC 6455 — The WebSocket Protocol (RFC Editor) What is a WebSocket? — IP With Ease Protocol upgrade mechanism — HTTP — MDN Web Docs Writing WebSocket servers — Web APIs — MDN Web Docs Long Polling vs WebSockets: Choosing the Right Transport for Real-Time Feeds — GetStream ","permalink":"https://cloudmato.com/hi/posts/what-are-websockets-vs-http/","title":"वेबसॉकेट क्या है और यह HTTP से कैसे अलग है?"},{"content":"तीन लोगों से पूछिए कि इस समय AI में \u0026ldquo;लूप\u0026rdquo; का क्या मतलब है और आपको तीन अलग-अलग जवाब मिलेंगे। एक कहेगा एजेंट लूप। दूसरा मॉडल कोलैप्स और फीडबैक लूप्स की बात करने लगेगा। तीसरा किसी कंप्लायंस मीटिंग में सुने ह्यूमन-इन-द-लूप का ज़िक्र करेगा। ये सभी सही हैं, और बिलकुल यही वजह है कि यह शब्द इतना उलझाने वाला बन गया है।\nमैं 8 साल से ज़्यादा समय से सॉफ़्टवेयर लिख रहा हूँ, और मैंने बहुत-से शब्दजाल को घूम-फिरकर वापस आते देखा है। पर \u0026ldquo;लूप\u0026rdquo; खास है क्योंकि यह एक ट्रेंड नहीं है — यह कम से कम चार अलग-अलग विचार हैं जो संयोग से एक ही शब्द साझा करते हैं, और ये सभी लगभग एक ही समय पर चर्चा में आए। तो चलिए इन्हें सुलझाते हैं।\nतो आख़िर यहाँ \u0026ldquo;लूप\u0026rdquo; का मतलब क्या है? लूप, सादे प्रोग्रामिंग अर्थ में, बस कोई ऐसी चीज़ है जो किसी शर्त के पूरा होने तक दोहराती रहती है। while not done: do_something()। बस इतना ही। इसमें कोई जादू नहीं।\nजो बदला वह यह है कि लूप के अंदर क्या बैठता है। दशकों तक लूप का बॉडी वह डिटरमिनिस्टिक कोड हुआ करता था जिसे आप हाथ से लिखते थे। अब लूप का बॉडी एक लार्ज लैंग्वेज मॉडल है जो खुद तय करता है कि आगे क्या करना है। वह एक बदलाव — तय निर्देशों से एक ऐसे मॉडल तक जो हर बार सोचकर निर्णय लेता है — ही पूरी कहानी है। इस समय जो कुछ भी ट्रेंड कर रहा है, वह सब इसी से निकलता है।\nजब लोग आज AI के संदर्भ में \u0026ldquo;लूप\u0026rdquo; कहते हैं, तो आमतौर पर उनका मतलब इनमें से एक होता है:\nएजेंटिक लूप — एक AI एजेंट सोचते, कार्य करते और देखते हुए एक चक्र में चलता है जब तक कोई काम पूरा न हो जाए। यह सबसे बड़ा वाला है। ह्यूमन-इन-द-लूप / ऑन-द-लूप — जहाँ एक व्यक्ति उस चक्र में बैठकर मंज़ूरी देता या निगरानी करता है। फीडबैक लूप्स — AI का आउटपुट वापस AI के ट्रेनिंग में जाकर, कभी-कभी मॉडलों को बिगाड़ देता है (मॉडल कोलैप्स)। ट्रेनिंग लूप — RLHF और रीइन्फोर्समेंट लर्निंग, जहाँ एक मॉडल बार-बार के रिवॉर्ड चक्रों में सुधरता है। इन्हें लगातार आपस में मिला दिया जाता है। चलिए मैं इन्हें एक-एक करके लेता हूँ, उसी से शुरू करते हुए जो सारा हाइप चला रहा है।\nएजेंटिक लूप: वह जो असल में ट्रेंड कर रहा है यहाँ सबसे साफ़ परिभाषा है जो मैंने देखी है, और यह Anthropic से आती है: एक एजेंट बस \u0026ldquo;LLMs जो स्वायत्त रूप से एक लूप में टूल्स इस्तेमाल करते हैं\u0026rdquo; है। [1] बस इतना ही। कोई रहस्यवाद नहीं। मार्केटिंग हटा दें तो एक AI एजेंट टूल्स तक पहुँच के साथ एक while लूप में फँसा हुआ मॉडल है।\nलूप के खुद चार कदम हैं जो बार-बार सामने आते हैं: देखना, तय करना, कार्य करना, अवलोकन करना। [2] मॉडल अपना कॉन्टेक्स्ट पढ़ता है, अगला कार्य चुनता है, कार्य चलता है, परिणाम वापस आता है, और लूप फिर चलता है। कुछ लोग इन चरणों को \u0026ldquo;सोचना, कार्य करना, अवलोकन करना\u0026rdquo; कहते हैं, पर विचार वही है।\nमुख्य बात — और यही एक एजेंट को सामान्य चैटबॉट से अलग करती है — यह है कि एजेंट पूरी समस्या को एक ही बार में हल करने की कोशिश नहीं करता। यह एक छोटा कदम उठाता है, देखता है कि क्या हुआ, और समायोजित करता है। [1] एक चैटबॉट एक बार जवाब देकर रुक जाता है। एक एजेंट चलता रहता है।\nसोचिए कि आप असल में किसी बग को कैसे ठीक करेंगे। आप पूरा कोडबेस पढ़कर याददाश्त से एक परफ़ेक्ट पैच नहीं उगल देते। आप एक एरर पढ़ते हैं, एक फ़ाइल जाँचते हैं, चीज़ चलाते हैं, एक नया एरर देखते हैं, दूसरी फ़ाइल जाँचते हैं, फिर से चलाते हैं। छोटे कदम, लगातार सुधार। एजेंटिक लूप बस यही व्यवहार है, जो स्वचालित कर दिया गया है।\nलूप असल में आया कहाँ से यह 2026 की खोज नहीं है। यह पैटर्न प्रिंसटन और गूगल रिसर्च के 2022 के एक पेपर तक जाता है जिसका नाम है \u0026ldquo;ReAct: Synergizing Reasoning and Acting in Language Models।\u0026rdquo; [3] विचार लगभग शर्मनाक हद तक सरल था: मॉडल से या तो सोचने (चेन-ऑफ़-थॉट) या कार्य करने (टूल कॉल करने) को कहने के बजाय, उसे दोनों को आपस में मिलाने दिया जाए। थोड़ा सोचो, थोड़ा कार्य करो, परिणाम देखो, फिर सोचो।\nपरिणाम ही असली समझाने वाली बात थे। जो मॉडल सोच सकते, कार्य कर सकते, अवलोकन कर सकते और फिर से सोच सकते थे, वे काफ़ी बेहतर रहे — ReAct पेपर ने ALFWorld बेंचमार्क पर 34% सुधार और WebShop पर लगभग 10% की रिपोर्ट दी। [3] मॉडल को किसी बाहरी एनवायरनमेंट से इंटरैक्ट करने देने से हैल्युसिनेशन भी कम हुए, क्योंकि वास्तविकता उसकी धारणाओं पर लगातार दबाव डालती रही। [4]\nतो ReAct लूप चुपचाप LLM एजेंट्स के लिए वास्तविक मानक आर्किटेक्चर बन गया। [4] आज आप जिन ज़्यादातर एजेंट फ़्रेमवर्क के बारे में सुनते हैं — चाहे वे कहें या न कहें — वे इसी के किसी न किसी रूप को चला रहे हैं।\nयह अब क्यों फूट रहा है और 2022 में क्यों नहीं यह वह सवाल है जिस पर रुककर सोचना ज़रूरी है। यह पैटर्न चार साल पुराना है। \u0026ldquo;एजेंटिक लूप\u0026rdquo; 2026 का बज़वर्ड क्यों है और 2022 का क्यों नहीं?\nईमानदारी से कहूँ तो, ऐसा इसलिए है क्योंकि लूप तभी काम करता है जब उसके अंदर का मॉडल काफ़ी अच्छा हो। कुछ चीज़ें एक साथ जुड़ गईं:\nमॉडल इतने भरोसेमंद हो गए कि कई कदमों के लिए उन पर भरोसा किया जा सके। एक लूप उतना ही अच्छा है जितना उसका हर इटरेशन। अगर मॉडल तीसरे कदम पर कोई बेवक़ूफ़ी भरा निर्णय लेता है, तो एरर कदम 4, 5, 6 तक बढ़ता जाता है। शुरुआती मॉडल बुरी तरह भटक जाते थे। नए वाले एक प्लान को इतना देर तक संभाले रखते हैं कि वे उपयोगी हों। टूल का इस्तेमाल मानकीकृत हो गया। Anthropic के Model Context Protocol (MCP) ने एजेंट्स को बाहरी टूल्स से जुड़ने का एक साझा तरीका दिया, ताकि हर किसी को हाथ से ग्लू कोड न लिखना पड़े। [1] अचानक \u0026ldquo;कार्य\u0026rdquo; कदम के पीछे एक असली इकोसिस्टम खड़ा हो गया। कॉन्टेक्स्ट विंडो बढ़ीं। लूप इतिहास जमा करता है — हर सोच, कार्य और अवलोकन आगे ले जाया जाता है। इसके लिए जगह चाहिए। बड़ी कॉन्टेक्स्ट विंडो ने लंबे लूप्स को संभव बनाया, और \u0026ldquo;कॉन्टेक्स्ट इंजीनियरिंग\u0026rdquo; अपने आप में एक अनुशासन बन गया। [5] पैसा आ गया। यह वह बेरंग वजह है। Gartner ने Q1 2024 और Q2 2025 के बीच मल्टी-एजेंट सिस्टम संबंधी पूछताछ में 1,445% की उछाल की रिपोर्ट दी। [6] एजेंटिक AI बाज़ार 2025 में $7.6 बिलियन से बढ़कर 2026 में $10.8 बिलियन होने का अनुमान है। [6] जब आँकड़े इस तरह हिलते हैं, तो हर ब्लॉग (मेरे ख़्याल से यह वाला भी) लूप्स के बारे में लिखना शुरू कर देता है। एक संरचनात्मक बदलाव भी है। 2026 के Gartner CIO सर्वे के अनुसार, सिर्फ़ लगभग 17% संगठनों ने असल में AI एजेंट्स तैनात किए हैं, पर 60% से ज़्यादा को उम्मीद है कि वे दो साल के भीतर ऐसा कर लेंगे — जिन उभरती तकनीकों को वे ट्रैक करते हैं, उनमें सबसे आक्रामक अपनाने वाला कर्व। [6] तो काफ़ी सारा शोर प्रत्याशा है, तैनाती नहीं। हाइप पर यक़ीन करने से पहले इसे ध्यान में रखना ठीक रहेगा।\nएकल एजेंट बनाम एजेंट्स की टीमें समझने लायक एक और पेच। शुरुआती तस्वीर एक सर्व-उद्देश्यीय एजेंट की थी जो आपके काम पर लूप करता रहता था। अब दिशा है विशेषज्ञ एजेंट्स की समन्वित टीमें — एक रिसर्चर एजेंट, एक कोडर एजेंट, एक रिव्यूअर एजेंट — हर एक अपना खुद का लूप चलाता है, जिन्हें एक ऑर्केस्ट्रेटर समन्वित करता है। [6]\nGartner को दिखी पूछताछ में वह 1,445% की छलांग? वह ख़ास तौर पर मल्टी-एजेंट सिस्टम्स के बारे में थी। [6] सोच यह है कि सब कुछ करने की कोशिश करने वाला एक विशाल एजेंट लंबे कामों में राह भटक जाता है, जबकि संकीर्ण काम वाले छोटे एजेंट केंद्रित रहते हैं। मुझे यहाँ थोड़ा संदेह है — कई नॉन-डिटरमिनिस्टिक लूप्स का समन्वय करना डिबगिंग का दुःस्वप्न लगता है, और मुझे शक है कि बहुत-सी टीमें इसे कठिन तरीके से समझेंगी। पर फ़ील्ड इसी दिशा पर दाँव लगा रहा है।\nजो भी हो, Anthropic की अपनी सलाह ओवर-इंजीनियरिंग की प्रवृत्ति के ख़िलाफ़ जाती है। एजेंट्स बनाने के उनके तीन सिद्धांत हैं: डिज़ाइन को सरल रखें, एजेंट के प्लानिंग चरणों को पारदर्शी बनाएँ, और अच्छे टूल डॉक्यूमेंटेशन में निवेश करें। [1] वे स्पष्ट रूप से सुझाव देते हैं कि किसी भारी फ़्रेमवर्क की ओर जाने से पहले सीधे LLM API कॉल्स से शुरुआत करें — कई पैटर्न तो कोड की कुछ ही पंक्तियाँ हैं। [1] अच्छी सलाह जिसे ज़्यादातर लोग अनदेखा कर देते हैं।\nह्यूमन-इन-द-लूप बनाम ह्यूमन-ऑन-द-लूप अब वह लूप जिसका स्वायत्तता से कोई लेना-देना नहीं और सब कुछ नियंत्रण से है। एक बार जब आपके पास खुद कार्य करने वाला एजेंट हो, तो सीधा सवाल है: इसमें एक इंसान कहाँ फ़िट होता है?\nदो जवाब, और यह फ़र्क उतना मायने रखता है जितना उसका प्यारा नामकरण सुझाता है। [7]\nह्यूमन-इन-द-लूप (HITL) ह्यूमन-ऑन-द-लूप (HOTL) इंसान की भूमिका अहम कदमों पर मंज़ूरी देता या हस्तक्षेप करता है डैशबोर्ड पर निगरानी करता है, फ़्लैग किए गए मामले देखता है निर्णय नियंत्रण अंतिम निर्णय इंसान के पास रहते हैं एजेंट क्रियान्वित करता है; इंसान निगरानी करता है उदाहरण AI ईमेल का मसौदा बनाता है, आप Send क्लिक करते हैं एजेंट ईमेल भेजता है; अलर्ट सिर्फ़ असामान्यता पर बजते हैं किसके लिए अनुकूलित नियंत्रण, जोखिम कमी गति, स्केल किसके लिए सर्वोत्तम उच्च-जोखिम, कानूनी, नैतिक निर्णय नीति सीमाओं के भीतर उच्च-मात्रा का काम ह्यूमन-इन-द-लूप का मतलब है कि एक व्यक्ति चक्र के अंदर बैठता है और एजेंट बिना सहमति के अंतिम कार्य नहीं कर सकता। [7] AI मसौदा बनाता है, आप मंज़ूरी देते हैं। धीमा, ज़्यादा सुरक्षित, स्केल अच्छा नहीं होता।\nह्यूमन-ऑन-द-लूप व्यक्ति को हर कदम से बाहर निकालकर एक निगरानी की कुर्सी पर बिठा देता है। [7] एजेंट चलता है, एक डैशबोर्ड उसे ट्रैक करता है, और अलर्ट सिर्फ़ तभी बजते हैं जब कुछ गड़बड़ लगे — असामान्य डेटा एक्सेस, अजीब API कॉल्स, ऐसा आउटपुट जो क्वालिटी बेसलाइन से मेल न खाए। इंसान फ़्लैग किए गए मामलों की समीक्षा करता है और किल स्विच दबा सकता है। [7]\n\u0026ldquo;ऑन-द-लूप\u0026rdquo; की ओर बढ़ाव इसका एक बड़ा हिस्सा है कि एजेंटिक AI अचानक बड़े पैमाने पर उपयोगी क्यों हो गया है। अगर किसी इंसान को हर एक कार्य को मंज़ूरी देनी पड़े, तो आपने असल में कुछ भी स्वचालित नहीं किया — आपने बस एक कतार जोड़ दी। पूरी उत्पादकता की दलील पीछे हटकर निगरानी पर जाने पर निर्भर है। [7] पर — और यही असहज हिस्सा है — ठीक तभी चीज़ें इतनी जल्दी बिना किसी के ध्यान दिए गड़बड़ हो सकती हैं। जो मुझे उन लूप्स तक ले जाता है जिन्हें कोई नहीं चाहता।\nजब लूप गड़बड़ हो जाते हैं: टोकन स्पाइरल और बेक़ाबू एजेंट यहीं चीज़ें पेचीदा हो जाती हैं, और यहीं मुझे लगता है कि हाइप डरावने हिस्से को छोड़ देता है।\nएक लूप जो नहीं जानता कि कब रुकना है, प्रोग्रामिंग का सबसे पुराना बग है। हम सबने एक अनंत लूप लिखा है और अपनी मशीन को फ़्रीज़ किया है। 2026 वाला संस्करण और बुरा है, क्योंकि लूप के साथ एक क्रेडिट कार्ड जुड़ा हुआ है।\nएजेंट लूप का हर कदम पूरा जमा हुआ कॉन्टेक्स्ट वापस मॉडल को भेजता है। [8] कदम 20 तक आते-आते आप वही सिस्टम प्रॉम्प्ट और बातचीत का इतिहास बीस बार के लिए भुगतान कर रहे होते हैं। लोग इसे \u0026ldquo;टोकन स्पाइरल\u0026rdquo; कह रहे हैं — आधुनिक अनंत लूप, पर आपके बैंक खाते तक सीधी लाइन के साथ। [8]\nजो आँकड़े घूम रहे हैं वे सचमुच चिंताजनक हैं। एक दर्ज मामले में एक बेक़ाबू एजेंट ने चार घंटे में $2,847 फूँक दिए, और दूसरे ने किसी के पकड़ने से पहले एक ही सेशन में $12,000 तक पहुँच गया। [8] बताया जाता है कि एजेंट उसी बातचीत के लिए एक सादे चैट से 50 गुना तक ज़्यादा टोकन फूँकते हैं, उस सारे दोहराए जाने वाले कॉन्टेक्स्ट की वजह से। [9] एक साधारण 5-कदम वाले लूप पर लागत एक वन-शॉट कॉल की लगभग 3.2 गुना होती है; 50 कदमों पर गुणक 30 गुना पार कर जाता है; 200 कदमों पर यह 100 गुना से ऊपर है। [8]\nतो अगर आप कुछ भी ऐसा बना रहे हैं जो लूप करता है, तो गार्डरेल्स वैकल्पिक नहीं हैं:\nएक सख़्त max_iterations सीमा। पाँच या दस। कभी किसी लूप को अनबाउंडेड न चलने दें। [8] यह एक नियम ज़्यादातर आपदाओं को रोक देता है। प्रति-रन एक टोकन बजट जो सीमा पार होने पर रन को बंद कर दे। [8] दोहराव की पहचान — हर टूल कॉल का फ़िंगरप्रिंट बनाएँ और एक रोलिंग विंडो से तुलना करें, ताकि आप एजेंट को बार-बार वही काम करते हुए पकड़ सकें। [8] एक स्टेप-काउंट अलर्ट जो आपको तब पिंग करे जब कोई एक रन, मान लीजिए, 15 कदम पार कर जाए। [8] मुझे यह थोड़ा मज़ेदार लगता है कि हमने सालों खुद को समाप्त होने वाले लूप लिखना सिखाया, ऐसे एजेंट बनाए जो सोच सकते हैं, और तुरंत अनंत लूप को फिर से ले आए — बस अब यह टर्मिनल को हैंग करने के बजाय असली पैसे ख़र्च करता है। तरक़्क़ी।\nफीडबैक लूप्स और मॉडल-कोलैप्स की समस्या बिलकुल अलग लूप, उतना ही अहम, और वह जो मुझे सबसे दिलचस्प लगता है क्योंकि यह धीमा और अदृश्य है।\nयह किसी एक एजेंट के चलने के बारे में नहीं है। यह पूरे AI इकोसिस्टम के खुद पर निर्भर हो जाने के बारे में है। मॉडल वेब से खुरचे गए डेटा पर ट्रेन होते हैं। उस वेब का ज़्यादा से ज़्यादा हिस्सा अब AI द्वारा लिखा जा रहा है। तो मॉडलों की अगली पीढ़ी आंशिक रूप से पिछली पीढ़ी के आउटपुट पर ट्रेन होती है। यह एक फीडबैक लूप है, और यह मॉडलों को सड़ा सकता है।\nइस परिघटना को मॉडल कोलैप्स कहा जाता है — जब AI-जनित डेटा पर ट्रेन हुए मॉडल उत्तरोत्तर क्वालिटी और विविधता खोते जाते हैं, और उस वास्तविक-दुनिया वितरण से भटक जाते हैं जिसे उन्हें सीखना था। [10] इसे 2023 के एक ऑक्सफ़ोर्ड और कैम्ब्रिज अध्ययन में औपचारिक रूप से वर्णित किया गया, जो Nature में प्रकाशित हुआ, शीर्षक \u0026ldquo;AI models collapse when trained on recursively generated data।\u0026rdquo; [11] लगातार ट्रेनिंग चक्रों में मॉडल अपनी खुद की त्रुटियों, पूर्वाग्रहों और अति-सरलीकरणों को मज़बूत करता है, और धीरे-धीरे सच्चाई पर अपनी पकड़ खो देता है। [10]\nटाइमिंग ही चिंता वाली बात है। अनुमान बताते हैं कि 2026 तक ऑनलाइन प्रकाशित होने वाले नए टेक्स्ट का एक बड़ा हिस्सा AI-जनित है। [12] 2024 से 2026 तक के वेब डेटा पर ट्रेन हुए मॉडल, चाहे कोई चाहे या न चाहे, GPT-4, Claude, Gemini और इनके साथियों के आउटपुट पर ट्रेन हो रहे हैं — जो खुद पहले के मानव वेब डेटा पर ट्रेन हुए थे। [12] यह एक फ़ोटोकॉपी की फ़ोटोकॉपी की फ़ोटोकॉपी है। हर बार थोड़ी सटीकता खो जाती है।\nकम-दाँव वाली सेटिंग्स में इसका बस यह मतलब है कि आउटपुट ज़्यादा फीका और सामान्य होगा। स्वास्थ्य सेवा, वित्त या सुरक्षा में इसका मतलब बिगड़े हुए मॉडल हो सकते हैं जो सचमुच ख़तरनाक फ़ैसले ले रहे हों — एक ग़लत निदान, एक ख़राब रिस्क स्कोर, एक छूटी हुई असामान्यता। [12] यही वजह है कि \u0026ldquo;मानव-सत्यापित डेटा\u0026rdquo; और प्रोवेनेंस ट्रैकिंग चुपचाप फिर से मूल्यवान हो गए हैं। विडंबना यह है कि असली मानव-लिखित सामग्री एक दुर्लभ संसाधन बनती जा रही है।\nमूल लूप: मॉडल सबसे पहले सीखते कैसे हैं मैं इसे संक्षिप्त रखूँगा क्योंकि यह मौजूदा हाइप से पहले का है, पर इसका ज़िक्र बनता है क्योंकि यह भी एक लूप है और लोग इसे बाक़ी के साथ मिला देते हैं।\nइससे पहले कि कोई मॉडल एजेंट लूप में बैठ सके, उसे एक ट्रेनिंग लूप आकार देता है। प्रसिद्ध वाला है RLHF — Reinforcement Learning from Human Feedback, वह तकनीक जिसने ChatGPT जैसे मॉडलों को असल में बात करने में सुखद बनाया। [13]\nलूप ऐसे काम करता है: एक रिवॉर्ड मॉडल (मूलतः एक AI जज जो मानव प्राथमिकताओं पर ट्रेन होता है) मुख्य मॉडल के जवाबों को स्कोर देता है, और वह स्कोर एक रिवॉर्ड संकेत बन जाता है जिसका उपयोग मॉडल को उन आउटपुट्स की ओर धकेलने के लिए होता है जिन्हें इंसान पसंद करते हैं। [13] जनरेट करो, मूल्यांकन करो, अनुकूलित करो, दोहराओ। मॉडल सचमुच अपने ही प्रयासों पर लूप करके और ग्रेड पाकर सीखता है। [13]\nतो आपके पास नीचे तक लूप ही लूप हैं — एक ट्रेनिंग लूप जो मॉडल को आकार देता है, और फिर एक एजेंट लूप जहाँ वह आकार पाया मॉडल काम पर लग जाता है। एक ही शब्द, बहुत अलग समय-पैमाने: एक डेटा सेंटर में हफ़्तों में होता है, दूसरा आपके काम पर सेकंडों में।\nयह सुलझाना कि कोई किस लूप की बात कर रहा है अगर आप इस सबसे एक बात लें, तो वह यह हो कि AI में \u0026ldquo;लूप\u0026rdquo; एक ओवरलोडेड शब्द है, और बोलने वाला लगभग कभी नहीं बताता कि कौन-सा। यहाँ मेरी झटपट चीट शीट है:\nलूप क्या दोहराता है समय-पैमाना यह ट्रेंड क्यों कर रहा है एजेंटिक लूप सोचना → कार्य → अवलोकन सेकंड से मिनट मॉडल आख़िरकार इतने अच्छे कि कई कदमों में भरोसा किया जा सके ह्यूमन-इन/ऑन-द-लूप मानव मंज़ूरी या निगरानी प्रति कार्य / लगातार एजेंट्स को सुरक्षित रूप से स्केल पर तैनात करने के लिए ज़रूरी फीडबैक लूप AI आउटपुट → AI ट्रेनिंग डेटा महीनों से साल वेब AI टेक्स्ट से भर रहा है; मॉडल कोलैप्स का जोखिम ट्रेनिंग लूप (RLHF) जनरेट → रिवॉर्ड → अनुकूलन हफ़्ते वह नींव जिसने ऊपर के सब को उपयोगी बनाया अगली बार जब कोई किसी मीटिंग में \u0026ldquo;लूप\u0026rdquo; गिराए, तो असली सवाल यही है: कौन-सा? ये आपस में जुड़े हैं — ये सभी बीच में एक मॉडल के साथ किसी चीज़ के दोहराने का वर्णन करते हैं — पर इंजीनियरिंग, जोखिम और समाधान पूरी तरह अलग हैं।\nएजेंटिक लूप ही वह है जो हाइप ढो रहा है, और यह सचमुच एक बड़ी बात है। पर यह सिर्फ़ इसलिए काम करता है क्योंकि इसके नीचे ट्रेनिंग लूप है, यह सिर्फ़ तभी सुरक्षित रूप से तैनात होता है जब इसे देखता हुआ एक ह्यूमन-ऑन-द-लूप हो, और पूरा इकोसिस्टम चुपचाप उस फीडबैक लूप से सड़ने का जोखिम उठाता है जिसकी कोई निगरानी नहीं कर रहा। चार लूप, एक शब्द, सब आपस में उलझे हुए। कोई हैरानी नहीं कि यह उलझाने वाला है।\nसमाप्त\nस्रोत Building effective agents — Anthropic The Agent Loop, Explained: Perceive, Decide, Act, Observe ReAct: Synergizing Reasoning and Acting in Language Models (PDF) What is a ReAct Agent? — IBM Effective context engineering for AI agents — Anthropic 7 Agentic AI Trends to Watch in 2026 — MachineLearningMastery Human-in-the-Loop vs Human-on-the-Loop in Agentic AI — TekLeaders Preventing Runaway AI Agent Costs and Token Spirals — n1n.ai AI Agents Burn 50x More Tokens Than Chats — LeanOps What Is Model Collapse? — IBM AI models collapse when trained on recursively generated data — Nature The AI feedback loop: Researchers warn of \u0026lsquo;model collapse\u0026rsquo; — VentureBeat Reinforcement Learning from Human Feedback (RLHF) for LLMs — SuperAnnotate ","permalink":"https://cloudmato.com/hi/posts/loops-in-ai-explained/","title":"AI में लूप्स: ये क्या हैं और हर कोई इनकी बात क्यों कर रहा है"},{"content":"आप किसी भी वेबसाइट को जो भी रिक्वेस्ट भेजते हैं, उसके साथ मेटाडेटा का एक छोटा-सा ढेर जाता है जिसे आप कभी देखते नहीं। हेडर्स। ये तय करते हैं कि आपका कनेक्शन एन्क्रिप्टेड है या नहीं, कोई पेज iframe में एम्बेड हो सकता है या नहीं, किस CDN एज ने आपको सर्व किया, और ब्राउज़र को कोई कुकी एक साल तक याद रखनी चाहिए या नहीं। मैं देखना चाहता था कि एक असली, व्यस्त प्रोडक्शन साइट क्या भेजती है, तो मैंने एक Amazon एंडपॉइंट पर curl चलाया और रिस्पॉन्स हेडर्स डंप कर दिए। पता चला कि समझने के लिए बहुत कुछ है।\nमैंने असल में क्या चलाया मैंने Amazon India के आंतरिक \u0026ldquo;add to cart\u0026rdquo; config एंडपॉइंट्स में से एक पर एक सादी GET रिक्वेस्ट भेजी और curl से सिर्फ़ रिस्पॉन्स हेडर्स प्रिंट करने को कहा:\ncurl -s -D - -o /dev/null \\ \u0026#34;https://www.amazon.in/cart/add-to-cart/patc-config?clientName=SiteWideActionExecutor\u0026amp;ref_=ax_patc_cfg\u0026#34; \\ -A \u0026#34;Mozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0\u0026#34; -D - हेडर्स को stdout पर डंप करता है, और -o /dev/null बॉडी को फेंक देता है (यहाँ मुझे सिर्फ़ हेडर्स की परवाह है)। मोटे तौर पर यह वापस आया:\nHTTP/2 200 content-type: application/json;charset=UTF-8 date: Sun, 07 Jun 2026 18:55:58 GMT server: Server x-amz-rid: BE1Q4YXSQ0DKN83F4JYQ set-cookie: session-id=259-8655047-0491149; Domain=.amazon.in; Expires=...; Path=/; Secure set-cookie: session-id-time=2082787201l; Domain=.amazon.in; Expires=...; Path=/; Secure set-cookie: i18n-prefs=INR; Domain=.amazon.in; Expires=...; Path=/ set-cookie: lc-acbin=en_IN; Domain=.amazon.in; Expires=...; Path=/ x-content-type-options: nosniff x-xss-protection: 1; accept-ch: ect,rtt,downlink,device-memory,...,sec-ch-ua-platform-version accept-ch-lifetime: 86400 content-security-policy-report-only: default-src \u0026#39;self\u0026#39; blob: https: data: ...;report-uri https://metrics.media-amazon.com/ content-encoding: gzip content-security-policy: upgrade-insecure-requests;report-uri https://metrics.media-amazon.com/ strict-transport-security: max-age=47474747; includeSubDomains; preload vary: X-Amazon-Wtm-Tag-...,Accept-Encoding,User-Agent x-frame-options: SAMEORIGIN x-cache: Miss from cloudfront via: 1.1 db8e720c1e186c4a9d38db72ecaa0492.cloudfront.net (CloudFront) x-amz-cf-pop: BOM78-P2 alt-svc: h3=\u0026#34;:443\u0026#34;; ma=86400 x-amz-cf-id: 4UqtO1tdgZlbHdAUl2W47T2W4MGf7vb-mx2Y-KEevkHqCcCyhE_b0Q== जो मूलतः एक config एंडपॉइंट है, उसके लिए यह आश्चर्यजनक रूप से सघन रिस्पॉन्स है। मैं इन्हें समूहों में समझाता हूँ, क्योंकि इनमें से कुछ दूसरों से कहीं ज़्यादा मायने रखते हैं।\nउबाऊ-पर-ज़रूरी बुनियादी बातें content-type content-type: application/json;charset=UTF-8 क्लाइंट को बताता है कि बॉडी में किस तरह का डेटा है और उसे कैसे डिकोड करना है। मामूली लगता है, पर यह भार उठाने वाला है। ब्राउज़र इसका उपयोग यह तय करने के लिए करता है कि रिस्पॉन्स को JSON के रूप में पार्स करे, HTML के रूप में रेंडर करे, या उसे डाउनलोड माने। charset=UTF-8 हिस्सा कैरेक्टर एन्कोडिंग बताता है ताकि उच्चारण-चिह्न वाले अक्षर और गैर-लैटिन लिपियाँ सही तरीके से आएँ।\nबात यह है — अगर कोई सर्वर कंटेंट टाइप के बारे में झूठ बोलता है या अस्पष्ट रहता है, तो पहले ब्राउज़र बॉडी को \u0026ldquo;सूँघकर\u0026rdquo; (sniff) अंदाज़ा लगाते थे। यही अंदाज़ा लगाना है जिसे x-content-type-options: nosniff (इस पर नीचे और) बंद करने के लिए मौजूद है।\ndate और server date बस सर्वर का टाइमस्टैम्प है कि उसने रिस्पॉन्स कब बनाया। कैश इसका उपयोग ताज़गी (freshness) के गणित के लिए करते हैं।\nserver: Server इस पूरे डंप में मेरा पसंदीदा सूखा मज़ाक है। ज़्यादातर सर्वर गर्व से अपना नाम बताते हैं — Server: nginx/1.24.0 या Server: Apache/2.4। Amazon का फ्रंटएंड बजाय इसके शाब्दिक शब्द Server लौटाता है। यह जानबूझकर की गई अस्पष्टता है। किसी हमलावर को ज्ञात CVEs के विरुद्ध मुफ़्त वर्ज़न-नंबर लुकअप क्यों दें? तो वे इसे किसी बेकार चीज़ तक छोटा कर देते हैं। छोटी बात, पर यह बताती है कि किसी ने इस पर सोचा था।\ncontent-encoding content-encoding: gzip का मतलब है कि बॉडी को भेजने से पहले gzip से कंप्रेस किया गया था। आपका क्लाइंट पारदर्शी रूप से इसे डीकंप्रेस करता है। इसीलिए रिस्पॉन्स तार पर (on the wire) असल JSON से छोटा होता है। कुछ भी अनोखा नहीं, पर यह सीधे आगे आने वाले Vary हेडर के साथ जुड़ता है — और यही जोड़ी वह जगह है जहाँ लोग फिसलते हैं।\nx-amz-rid x-amz-rid: BE1Q4YXSQ0DKN83F4JYQ एक Amazon-विशिष्ट रिक्वेस्ट ID है। यह एक आंतरिक कोरिलेशन टोकन है। अगर कुछ टूटता है और आप सपोर्ट टिकट दर्ज करते हैं, तो यही वह स्ट्रिंग है जिसे उनके इंजीनियर अपने लॉग्स में grep करते हैं। आपको यही विचार अंत में CloudFront हेडर्स के साथ दोहराया हुआ दिखेगा — आधुनिक इंफ्रा एक विशिष्ट रिक्वेस्ट को दर्जन भर सिस्टमों के बीच ट्रेस करने में सक्षम होने को लेकर जुनूनी है।\nकुकीज़: चार Set-Cookie हेडर्स Amazon इस एक ही रिस्पॉन्स में चार कुकीज़ सेट करता है। Set-Cookie हेडर वह तरीका है जिससे सर्वर ब्राउज़र से कोई वैल्यू स्टोर करने और भविष्य की रिक्वेस्ट्स पर वापस भेजने को कहता है। वैल्यू के बाद का हर एट्रिब्यूट यह तय करता है कि कुकी कैसे व्यवहार करे:\nएट्रिब्यूट यह क्या करता है Domain=.amazon.in कुकी amazon.in और इसके सभी सबडोमेन को भेजी जाती है Expires=...2027... स्थायी कुकी — उस तारीख तक ब्राउज़र रीस्टार्ट के बाद भी बची रहती है Path=/ साइट के हर पाथ के लिए भेजी जाती है Secure केवल HTTPS पर भेजी जाती है, सादे HTTP पर कभी नहीं दो दिलचस्प वाली:\nsession-id और session-id-time दोनों में Secure फ्लैग है। MDN के अनुसार, एक Secure कुकी केवल एन्क्रिप्टेड HTTPS रिक्वेस्ट्स से जुड़ती है, जो किसी ऑन-पाथ हमलावर को इसे गलती से हुई HTTP रिक्वेस्ट से सूँघने से रोकती है। एक सेशन आइडेंटिफ़ायर के लिए — वह चीज़ जो प्रभावी रूप से आपकी लॉग-इन स्थिति ही है — यह न्यूनतम है जो आप चाहेंगे। i18n-prefs=INR और lc-acbin=en_IN प्रेफ़रेंस कुकीज़ हैं: रुपये में मुद्रा, लोकेल अंग्रेज़ी-भारत। ध्यान दें कि इन दोनों में Secure नहीं है। यह एक उचित फ़ैसला है — यह जानना कि कोई INR पसंद करता है, संवेदनशील नहीं है, और यह कोई हाइजैकिंग जोखिम नहीं है। एक बारीकी जिसका ज़िक्र करना ज़रूरी है। शुरुआत में बिंदी (dot) के साथ Domain=.amazon.in इन कुकीज़ को हर सबडोमेन पर उपलब्ध कराता है — www.amazon.in, sellercentral.amazon.in, वगैरह। यह उस सेवा के लिए जानबूझकर किया गया है जो कई सबडोमेनों में फैली है, पर यह वैसा ही फ़ैसला है जिसे आप सचेत होकर लेना चाहेंगे, क्योंकि बहुत व्यापक रूप से स्कोप की गई कुकी का ब्लास्ट रेडियस बड़ा होता है अगर कुछ भी लीक होता है। यह सारा व्यवहार RFC 6265 स्पेक के तहत आता है अगर आप औपचारिक संस्करण चाहते हैं।\nयहाँ ख़ास तौर पर अनुपस्थित: HttpOnly और SameSite। ये आम तौर पर असल लॉगिन के दौरान सेट होने वाली ज़्यादा संवेदनशील auth कुकीज़ पर दिखते हैं, इस जैसे config एंडपॉइंट पर नहीं। तो इस ख़ास रिस्पॉन्स में इनकी अनुपस्थिति में बहुत ज़्यादा मत पढ़िए।\nसुरक्षा हेडर्स — दिलचस्प हिस्सा यहीं रिस्पॉन्स वाक़ई अध्ययन के लायक हो जाता है, क्योंकि Amazon रक्षात्मक हेडर्स का एक ढेर भेजता है और इनमें से कुछ का इतिहास रहा है।\nstrict-transport-security strict-transport-security: max-age=47474747; includeSubDomains; preload HSTS ब्राउज़र से कहता है: \u0026ldquo;अब से, मुझसे केवल HTTPS पर ही बात करना। अगर कोई तुम्हें मेरे लिए कोई http:// लिंक थमाता है, तो रिक्वेस्ट मशीन से निकलने से पहले ही उसे HTTPS में अपग्रेड कर देना।\u0026rdquo; यहाँ तीन डायरेक्टिव हैं:\nmax-age=47474747 — इस नियम को ~550 दिनों तक याद रखो (वह संख्या बस 47474747 सेकंड है; किसी को दोहराते अंक स्पष्ट रूप से पसंद आए)। includeSubDomains — नियम हर सबडोमेन को भी कवर करता है। preload — Amazon चाहता है कि वह ब्राउज़रों की हार्डकोडेड HSTS सूचियों में बेक हो जाए, ताकि आपकी सबसे पहली विज़िट भी HTTPS के लिए मजबूर हो, बिना किसी असुरक्षित पहली रिक्वेस्ट के। यह इतना मायने क्यों रखता है? HSTS के बिना, amazon.in पर आपकी पहली रिक्वेस्ट सादे HTTP के रूप में जा सकती है और HTTPS पर रीडायरेक्ट होने से पहले ही हाइजैक हो सकती है — क्लासिक SSL-stripping हमला। OWASP HSTS चीट शीट इस जोखिम को अच्छी तरह समझाती है। एक पेच: अगर HSTS हेडर सादे HTTP पर आता है तो ब्राउज़र उसे अनदेखा कर देते हैं, ख़ासतौर पर इसलिए ताकि कोई मैन-इन-द-मिडल कोई फ़र्ज़ी हेडर इंजेक्ट न कर सके। यह केवल तभी गिना जाता है जब यह पहले से सुरक्षित कनेक्शन पर आता है।\nदो Content-Security-Policy हेडर्स यही वह हिस्सा है जो मुझे सबसे बताने वाला लगा। Amazon दोनों भेजता है — एक लागू करने वाली (enforcing) पॉलिसी और एक रिपोर्ट-ओनली पॉलिसी:\ncontent-security-policy: upgrade-insecure-requests;report-uri https://metrics.media-amazon.com/ content-security-policy-report-only: default-src \u0026#39;self\u0026#39; blob: https: data: ...;report-uri https://metrics.media-amazon.com/ लागू करने वाली वाली जानबूझकर छोटी है। upgrade-insecure-requests ब्राउज़र से कहता है कि हर http:// सब-रिसोर्स (इमेज, स्क्रिप्ट, जो भी हो) को फ़ेच करने से पहले https:// में फिर से लिख दे। इतनी पुरानी साइट पर, जहाँ इतने सारे लेगेसी URLs इधर-उधर तैर रहे हैं, हर एक को मैन्युअली ठीक करना पागलपन होगा — तो वे ब्राउज़र को उन्हें थोक में अपग्रेड करने देते हैं।\nदूसरा हेडर चतुर हिस्सा है। Content-Security-Policy-Report-Only कुछ भी ब्लॉक नहीं करता। यह एक सख़्त परीक्षण पॉलिसी (default-src 'self' ...) चलाता है और, जब भी कुछ ब्लॉक हुआ होता, तो report-uri पर एक JSON उल्लंघन रिपोर्ट POST करता है। एक तंग CSP को बिना लाइव साइट तोड़े रोल आउट करने का यही तरीका है:\nसख़्त पॉलिसी को रिपोर्ट-ओनली मोड में डिप्लॉय करो। अपने मेट्रिक्स एंडपॉइंट पर आने वाली उल्लंघन रिपोर्ट्स को देखो। जो वैध चीज़ें इससे टकराती हैं उन्हें ठीक करो। एक बार शांत हो जाए, तो इसे लागू करने वाले हेडर में प्रमोट कर दो। यह मूलतः सख़्त पॉलिसी को असल हवाई जहाज़ से बाँधने से पहले एक विंड टनल में चलाने जैसा है। report-uri डायरेक्टिव तकनीकी रूप से report-to के पक्ष में अप्रचलित (deprecated) है, पर इसे उन कई ब्राउज़रों के लिए रखा गया है जो अब भी इस पर निर्भर हैं।\nx-content-type-options: nosniff छोटा हेडर, असली दाँत। nosniff ब्राउज़र से कहता है कि Content-Type पर भरोसा करो और कभी अंदाज़ा मत लगाओ। इसके बिना, कोई ब्राउज़र text/plain के रूप में सर्व की गई फ़ाइल को देखकर तय कर सकता है कि यह HTML या JavaScript \u0026ldquo;जैसी दिखती है\u0026rdquo;, और उसे चला दे — एक MIME-confusion हमला। अगर कोई हमलावर ऐसी फ़ाइल अपलोड कर सके जो वापस सर्व हो जाए, तो कंटेंट स्निफ़िंग ही वह तरीका है जिससे एक हानिरहित दिखने वाला अपलोड चलने वाली स्क्रिप्ट में बदल जाता है। nosniff उस दरवाज़े को बंद कर देता है।\nx-frame-options: SAMEORIGIN X-Frame-Options: SAMEORIGIN नियंत्रित करता है कि किसे इस पेज को \u0026lt;frame\u0026gt; या \u0026lt;iframe\u0026gt; के अंदर लोड करने की अनुमति है। SAMEORIGIN का मतलब है कि केवल Amazon पेज ही अन्य Amazon पेजों को फ़्रेम कर सकते हैं — evil-site.com नहीं कर सकता। यह clickjacking के विरुद्ध मूल बचाव है, जहाँ एक हमलावर अदृश्य रूप से आपके असली पेज को ओवरले कर देता है और आपको \u0026ldquo;Buy now\u0026rdquo; या \u0026ldquo;Confirm\u0026rdquo; क्लिक करने के लिए छलता है जबकि आपको लगता है कि आप कुछ और क्लिक कर रहे हैं। एक शॉपिंग कार्ट एंडपॉइंट के लिए, आप ठीक-ठीक देख सकते हैं कि वे इसकी परवाह क्यों करते हैं।\nx-xss-protection: 1 अब, x-xss-protection: 1 अजीब वाला है, और ईमानदारी से यह कुछ हद तक एक अवशेष है। यह पुराने Internet Explorer, Chrome और Safari की एक सुविधा थी जो रिफ़्लेक्टेड XSS का पता लगाने और पेज को ब्लॉक करने की कोशिश करती थी। पेच — और सुरक्षा वाले इस बारे में बेबाक रहे हैं — यह है कि फ़िल्टर का ख़ुद दुरुपयोग होकर अन्यथा-सुरक्षित पेजों में कमज़ोरियाँ पैदा की जा सकती थीं। आधुनिक मार्गदर्शन यह है कि इसे या तो बंद कर दो (0) या बस मत भेजो, और बजाय इसके एक असली Content-Security-Policy पर निर्भर रहो। Amazon अब भी 1 भेजता है, शायद बहुत पुराने ब्राउज़रों की लंबी पूँछ के लिए। मैं इसे किसी नए प्रोजेक्ट में कॉपी नहीं करूँगा।\nपरफ़ॉर्मेंस और प्रोटोकॉल हेडर्स accept-ch और accept-ch-lifetime accept-ch: ect,rtt,downlink,device-memory,...,sec-ch-ua-platform-version accept-ch-lifetime: 86400 यह Client Hints है। Accept-CH के साथ, सर्वर कह रहा है: \u0026ldquo;अपनी अगली रिक्वेस्ट्स पर, कृपया मुझे अपनी नेटवर्क स्पीड (ect, rtt, downlink), तुम्हारे पास कितनी डिवाइस मेमोरी है (device-memory), और कुछ user-agent विवरण भी बताना।\u0026rdquo; फिर Amazon तय कर सकता है कि वह क्या सर्व करे — मसलन धीमे 2g कनेक्शन पर हल्की इमेज।\naccept-ch-lifetime: 86400 कहता है कि इस प्रेफ़रेंस को एक दिन तक याद रखो। जानने लायक बात: Accept-CH-Lifetime अब अनुशंसित नहीं है और काफ़ी हद तक स्पेक से हटा दिया गया है, पर बहुत-सी साइटें अब भी इसे संगतता के लिए भेजती हैं। Client Hints केवल सुरक्षित कनेक्शन पर काम करते हैं, और केवल फ़र्स्ट-पार्टी ऑरिजिन को ही भेजे जाते हैं — एक गोपनीयता सुरक्षा-घेरा ताकि कोई भी रैंडम थर्ड पार्टी चुपचाप आपकी डिवाइस को फ़िंगरप्रिंट न कर सके।\nvary vary: X-Amazon-Wtm-Tag-...,Accept-Encoding,User-Agent Vary हेडर वह है जो लोगों के भूल जाने पर चुपचाप कैश को तोड़ देता है। यह Amazon और आपके बीच के हर कैश से कहता है: \u0026ldquo;यह रिस्पॉन्स इन रिक्वेस्ट हेडर्स पर निर्भर करता है, तो अपनी कैश की हुई कॉपियों को इन पर की (key) करना।\u0026rdquo;\nAccept-Encoding — gzip बॉडी और Brotli बॉडी को अलग-अलग याद रखो। इसके बिना, कोई कैश किसी ऐसे क्लाइंट को gzip ब्लॉब थमा सकता है जिसने कुछ और माँगा था। चूँकि रिस्पॉन्स gzip-एन्कोडेड है, यह एंट्री असली काम कर रही है। User-Agent — रिस्पॉन्स मोबाइल और डेस्कटॉप ब्राउज़र के बीच अलग हो सकता है, तो उन्हें अलग कैश करो। एक छोटी सावधानी जो विशेषज्ञ दोहराते रहते हैं: Vary: User-Agent एक भोथरा औज़ार है। बाहर प्रभावी रूप से असीमित User-Agent स्ट्रिंग्स हैं, तो यह हर ब्राउज़र वर्ज़न के लिए लगभग-अद्वितीय कॉपी स्टोर करके आपकी कैश हिट दर को चिथड़े-चिथड़े कर सकता है। अपने ख़ुद के CDN लॉजिक वाली बड़ी साइटें इसे झेल सकती हैं; एक छोटी साइट पर मैं दो बार सोचूँगा।\nalt-svc alt-svc: h3=\u0026#34;:443\u0026#34;; ma=86400 Alt-Svc वह हैंडशेक है जो HTTP/3 को बूटस्ट्रैप करता है। यह रिक्वेस्ट HTTP/2 पर वापस आई, पर यह हेडर Amazon की फुसफुसाहट है: \u0026ldquo;अरे, मैं पोर्ट 443 पर h3 (QUIC पर HTTP/3) भी बोलता हूँ — अगले 86400 सेकंड के लिए बेझिझक इसका उपयोग करो।\u0026rdquo; एक सक्षम ब्राउज़र चुपचाप बैकग्राउंड में HTTP/3 आज़माएगा और, अगर वह कनेक्ट हो जाए, तो तेज़, कम-लेटेंसी रिक्वेस्ट्स के लिए उस पर स्विच कर लेगा। जैसा bagder की HTTP/3 गाइड कहती है, ऐसे ही यह अपग्रेड उन क्लाइंट्स के लिए कुछ तोड़े बिना होता है जो इसका समर्थन नहीं करते।\nCloudFront की राह आख़िरी समूह आपको बताता है कि Amazon इसे अपने ख़ुद के CDN, CloudFront के ज़रिए सर्व कर रहा है:\nहेडर वैल्यू मतलब x-cache Miss from cloudfront एज कैश में नहीं — ऑरिजिन से फ़ेच किया गया via 1.1 ...cloudfront.net (CloudFront) एक CloudFront प्रॉक्सी ने रिक्वेस्ट संभाली x-amz-cf-pop BOM78-P2 मुंबई (BOM) एज लोकेशन से सर्व किया गया x-amz-cf-id 4UqtO1... इस ठीक-ठीक रिक्वेस्ट के लिए अपारदर्शी ट्रेस ID यहाँ कुछ बातें जगह पर बैठ जाती हैं:\nx-cache: Miss समझ में आता है — एक व्यक्तिगत कार्ट-config एंडपॉइंट को कैश करके सबको सर्व नहीं किया जाना चाहिए, तो मिस होना सही व्यवहार है, कोई समस्या नहीं। x-amz-cf-pop: BOM78 IATA हवाई-अड्डा कोड का उपयोग करता है। BOM मुंबई है। मैं भारत में हूँ, तो CloudFront ने मुझे निकटतम एज पर रूट किया — ठीक वही जो एक CDN को करना चाहिए। -P2 प्रत्यय कैश टियर को दर्शाता है। x-amz-cf-id पहले देखे गए x-amz-rid का CloudFront भाई-बंधु है — एक एन्क्रिप्टेड, अपारदर्शी टोकन जिसका मेरे लिए कोई मतलब नहीं है पर जो AWS Support को इस सटीक रिक्वेस्ट को उनके लॉग्स से खींचने देता है। पैटर्न पर ध्यान दें: हर परत अपनी ख़ुद की ट्रेस ID की मुहर लगाती है। यही अतिरेक (redundancy) वह तरीका है जिससे आप एक ऐसी रिक्वेस्ट को डिबग करते हैं जो CDN, फ्रंटएंड और बैकएंड से गुज़री बिना सूत्र खोए। तो निष्कर्ष क्या है? एक फेंकने लायक config रिक्वेस्ट के लिए, Amazon ने वापस भेजा एन्क्रिप्शन प्रवर्तन, XSS/clickjacking बचाव के तीन स्वाद, साथ-साथ चलती दो CSP रणनीतियाँ, कुकी स्कोपिंग, client-hint मोल-तोल, HTTP/3 विज्ञापन, और एक पूरा CDN ट्रेस ट्रेल। इनमें से कुछ भी अनोखा नहीं है — यहाँ हर हेडर MDN पर प्रलेखित है और ज़्यादातर ऐसी चीज़ें हैं जिन्हें आप ख़ुद चालू कर सकते हैं। फ़र्क़ यह है कि Amazon उन सभी को चालू करता है, defence-in-depth शैली में, और अगली कसावट को लागू करने से पहले उसे परखने के लिए एक रिपोर्ट-ओनली CSP तक भेजता है।\nअगर आप प्रोडक्शन में कुछ भी चलाते हैं, तो यह डंप एक अच्छी चेकलिस्ट है। preload के साथ HSTS, nosniff, एक असली CSP, X-Frame-Options, Secure कुकीज़, और एक समझदार Vary आपको ज़्यादातर रास्ता तय करा देंगे। और शायद — Amazon की तरह — साथ ही अपने Server हेडर को कुछ शानदार ढंग से बेकार चीज़ पर सेट कर दीजिए।\nस्रोत Strict-Transport-Security header - MDN Web Docs HTTP Strict Transport Security - OWASP Cheat Sheet Content-Security-Policy: upgrade-insecure-requests - MDN Content Security Policy (CSP) Guide - MDN Content-Security-Policy: report-uri directive - MDN HTTP Headers Cheat Sheet - OWASP X-Content-Type-Options HTTP Header - KeyCDN Accept-CH header - MDN Web Docs Set-Cookie header - MDN Web Docs RFC 6265 - HTTP State Management Mechanism Best practices for using the Vary header - Fastly Understanding The Vary Header - Smashing Magazine Alt-Svc header - MDN Web Docs Bootstrap with Alt-Svc - HTTP/3 explained X-Amz-Cf-Pop - http.dev X-Amz-Cf-Id - http.dev Amazon CloudFront Response Headers Policies - AWS ","permalink":"https://cloudmato.com/hi/posts/understanding-common-http-headers-on-amazon/","title":"Amazon पर आम HTTP हेडर्स को समझना"},{"content":"हर कोई अपने API पर \u0026ldquo;RESTful\u0026rdquo; का ठप्पा लगा देता है। कोई भी docs पेज खोलिए, मार्केटिंग कॉपी पढ़िए, और वहाँ यह लिखा मिलेगा — \u0026ldquo;हमारा साफ-सुथरा, RESTful API।\u0026rdquo; लेकिन यहाँ असहज करने वाली बात यह है: सख्त परिभाषा के अनुसार, इनमें से लगभग कोई भी असल में RESTful नहीं है। तो असल में आप यह पूछ रहे हैं कि अगर आप कुछ नियम तोड़ देते हैं तो क्या उस शब्द का अब भी कोई मतलब रह जाता है। ईमानदारी से कहूँ तो, यहीं से मामला पेचीदा हो जाता है।\nपहले संक्षिप्त जवाब, क्योंकि मुझे वे लेख पसंद नहीं जो इसे दबा देते हैं: हाँ, रोज़मर्रा की बातचीत में आप इसे अब भी RESTful कह सकते हैं, लेकिन नहीं, रॉय फील्डिंग की मूल परिभाषा के अनुसार यह तब तक REST API नहीं है जब तक यह hypertext-driven न हो। ये दोनों बातें एक साथ सच हैं, और इन दोनों के बीच का फासला ही पूरी कहानी है।\n\u0026ldquo;REST\u0026rdquo; का असल मतलब क्या है (और किसने तय किया) REST कोई protocol नहीं है। यह कोई spec नहीं है जिसे आप डाउनलोड करें। यह एक architectural style है जिसे रॉय फील्डिंग ने अपने 2000 के PhD शोध-प्रबंध में बताया, जहाँ वे मूलतः उन सिद्धांतों को reverse-engineer कर रहे थे जिन्होंने खुद वेब को scale करने लायक बनाया [1]। यह एक अहम नज़रिया है — REST वेब के काम करने के बाद आया, इस बात की व्याख्या के रूप में कि यह क्यों काम किया।\nफील्डिंग ने छह constraints परिभाषित किए। इन सभी को पूरा कर लें तो आपके पास एक RESTful सिस्टम है; गलत वाला छोड़ दें तो, उनकी परिभाषा के अनुसार, नहीं है [2][3]:\nClient–server — UI से जुड़ी चिंताओं को डेटा स्टोरेज से जुड़ी चिंताओं से अलग करें ताकि हर एक अपने हिसाब से विकसित हो सके। Stateless — हर request वह सब साथ लाती है जिसकी सर्वर को ज़रूरत होती है। सर्वर आपकी पिछली request के बारे में कुछ भी संभालकर नहीं रखता। Cacheable — responses को यह बताना चाहिए कि उन्हें cache किया जा सकता है या नहीं, ताकि clients और intermediaries उन्हें दोबारा इस्तेमाल कर सकें। Uniform interface — सबसे बड़ा वाला, और वही जिसे हर कोई आधा-अधूरा लागू करता है। इस पर नीचे और बात होगी। Layered system — एक client यह नहीं बता सकता कि वह असली सर्वर से बात कर रहा है या उसके आगे लगे किसी proxy/load balancer/gateway से। Code on demand — वैकल्पिक। सर्वर client को बढ़ाने के लिए executable code (जैसे JavaScript) भेज सकता है। यही एकमात्र constraint है जिसे फील्डिंग ने वैकल्पिक बताया। उस आखिरी शब्द पर ध्यान दें: वैकल्पिक। Code on demand ही एकमात्र है जिसे छोड़ने की आपको स्पष्ट रूप से अनुमति है। बाकी सब, सख्त व्याख्या में, अनिवार्य हैं। तो जब लोग पूछते हैं \u0026ldquo;क्या मैं कोई नियम छोड़कर भी RESTful रह सकता हूँ,\u0026rdquo; तो ईमानदार जवाब यह है कि नियमों में पहले से ही उनमें से ठीक एक के लिए छूट दी गई है, और वह वो नहीं है जिसे आप छोड़ना चाहते थे।\nUniform interface वहीं है जहाँ API चुपचाप बिखर जाते हैं Uniform interface खुद चार उप-constraints में बँट जाता है, और यहीं \u0026ldquo;RESTful\u0026rdquo; का ठप्पा डगमगाने लगता है [3]:\nResources की पहचान — हर चीज़ का एक URI होता है, जैसे /users/123। Representations के ज़रिए हेरफेर — आपके पास एक representation (JSON, XML) होता है और resource को बदलने या मिटाने के लिए वही काफ़ी होता है। Self-descriptive messages — हर message में उसे process करने के लिए पर्याप्त जानकारी होती है (media types, status codes, headers)। HATEOAS — Hypermedia As The Engine Of Application State। सर्वर के responses में links होते हैं जो client को बताते हैं कि वह आगे क्या कर सकता है। अधिकांश API पहले तीन को बखूबी पूरा करते हैं। उनके पास अच्छे /users/123 URLs होते हैं, वे JSON में बात करते हैं, वे content types और status codes सेट करते हैं। और फिर वे नंबर चार को पूरी तरह नज़रअंदाज़ कर देते हैं। यह कोई छोटी चूक नहीं है — यही वो चीज़ है जिसकी फील्डिंग को सबसे ज़्यादा परवाह थी।\nलकीर खिंच गई: \u0026ldquo;REST API को hypertext-driven होना ही चाहिए\u0026rdquo; 2008 में, शोध-प्रबंध के आठ साल बाद, फील्डिंग इतने तंग आ गए कि उन्होंने एक ब्लॉग पोस्ट लिखी जिसके शीर्षक में बहस की ज़्यादा गुंजाइश नहीं छोड़ी गई: \u0026ldquo;REST APIs must be hypertext-driven\u0026rdquo; [1]। उनके सटीक शब्द:\n\u0026ldquo;अगर application state का engine (और इसलिए API) hypertext से संचालित नहीं हो रहा, तो वह RESTful नहीं हो सकता और REST API नहीं हो सकता।\u0026rdquo;\nयह दो-टूक है। वे उन ढेर सारे API पर प्रतिक्रिया दे रहे थे जो खुद को REST कह रहे थे जबकि असल में वे HTTP के कपड़े पहने RPC-शैली के कॉल थे [11]। उनकी बात: एक सच्चा REST client को एक entry URL से शुरू होना चाहिए और बाकी सब कुछ उन links का अनुसरण करके खोजना चाहिए जो सर्वर उसे सौंपता है — ठीक वैसे ही जैसे आप किसी वेबसाइट को बिना उसका हर URL याद किए ब्राउज़ करते हैं। डेटा फ़ॉर्मेट और link relations client को बताते हैं कि क्या संभव है, न कि कोई out-of-band दस्तावेज़ जो आप किसी wiki पर पढ़ते हैं।\nसोचिए कि आप एक सामान्य वेबसाइट कैसे इस्तेमाल करते हैं। आप यह याद नहीं रखते कि checkout पेज /cart/checkout/step-3 पर है। आप पेज पर मौजूद एक बटन क्लिक करते हैं। पेज आपको बताता है कि आप आगे क्या कर सकते हैं। यही hypertext है जो application state को चला रहा है। फील्डिंग का तर्क है कि एक REST API को मशीनों के लिए भी इसी तरह काम करना चाहिए [1]।\nउस मानक के हिसाब से, यहाँ एक करारा झटका है: वही Twitter और Facebook API जिनसे सबने \u0026ldquo;REST\u0026rdquo; सीखा, hypermedia का इस्तेमाल बिल्कुल नहीं करते [8]। आपके रोज़ के काम के अधिकांश API भी नहीं करते। व्यवहार में, तथाकथित अधिकांश REST API statelessness और uniform interface को लागू करते हैं लेकिन HATEOAS को पूरी तरह नज़रअंदाज़ कर देते हैं [7][8]।\nतो क्या आपका API RESTful है? मिलिए Richardson Maturity Model से लेनार्ड रिचर्डसन ने एक मॉडल पेश किया जिसे मार्टिन फ़ाउलर ने लोकप्रिय बनाया, और आपके सवाल का जवाब देने के लिए यह सबसे उपयोगी उपकरण है क्योंकि यह \u0026ldquo;RESTful\u0026rdquo; को हाँ/नहीं मानना बंद कर देता है और इसे एक सीढ़ी में बदल देता है [4][5]। इसमें चार स्तर हैं, 0 से 3 तक [13]।\nस्तर नाम यह क्या इस्तेमाल करता है इसमें क्या कमी है 0 The Swamp of POX एक URI, एक verb (आमतौर पर POST) सब कुछ। यह RPC/SOAP-शैली है। 1 Resources कई URIs, हर resource के लिए एक HTTP verbs का अब भी गलत इस्तेमाल 2 HTTP Verbs URIs + सही GET/POST/PUT/DELETE + status codes HATEOAS 3 Hypermedia ऊपर का सब कुछ + HATEOAS links कुछ नहीं — यह \u0026ldquo;पूर्ण\u0026rdquo; REST है यहाँ हक़ीक़त का सामना कराने वाली बात है जो आपको बेहतर महसूस करा देगी: जो API गर्व से खुद को RESTful कहते हैं, उनमें से अधिकांश स्तर 2 पर बैठे हैं [6][8]। उनके पास साफ-सुथरे resource URLs हैं, वे सही HTTP methods इस्तेमाल करते हैं, वे समझदारी भरे status codes लौटाते हैं। बस वे navigational links embed नहीं करते। और स्तर 2 सचमुच अच्छी इंजीनियरिंग है — यह रहने के लिए एक बिल्कुल समझदार जगह है।\nफ़ाउलर खुद यहाँ सावधान हैं। वे कहते हैं कि यह मॉडल REST के तत्वों के बारे में सोचने का एक उपयोगी तरीका है, न कि इस बात की सख्त परिभाषा कि आपको वह शब्द कब इस्तेमाल करने की अनुमति है [4]। दूसरी ओर, फील्डिंग कहेंगे कि केवल स्तर 3 ही इस नाम का हक़दार है। दोनों नज़रिए असल दुनिया में मौजूद हैं, और यही तनाव इसकी ठीक वजह है कि आपके सवाल का कोई साफ-सुथरा जवाब नहीं है।\nHTTP API बनाम REST API — ये एक ही चीज़ नहीं हैं यह बहुत से लोगों को उलझाता है, तो मुझे इसे साफ़-साफ़ कहने दें। सभी REST API, HTTP पर चलते हैं, लेकिन हर HTTP API, REST API नहीं होता [10]। web API श्रेणी बहुत बड़ी है — जो कुछ भी आप HTTP पर कॉल कर सकते हैं, वह इसमें आता है। REST उसी श्रेणी के भीतर एक विशिष्ट architectural style है जिसमें वे छह constraints होते हैं [8]।\nजब आपका API resources के इर्द-गिर्द संरचित होता है, verbs को सही इस्तेमाल करता है, और JSON लौटाता है, लेकिन hypermedia नहीं करता, तो असल में आपके पास एक HTTP API है जो REST conventions का पालन करता है [10]। कुछ लोग इसे \u0026ldquo;REST-like\u0026rdquo; कहते हैं, कुछ इसे \u0026ldquo;pragmatic REST\u0026rdquo; कहते हैं, और कुछ बस इसे RESTful कहते रहते हैं क्योंकि यही वह शब्द है जिसे हर कोई समझता है [9]। आम बोलचाल में इनमें से कोई भी गलत नहीं है। वे बस इस बारे में ज़्यादा ईमानदार हैं कि आप सीढ़ी पर कहाँ खड़े हैं।\nबेन मॉरिस का pragmatic REST पर एक ठोस लेख है जो तर्क देता है कि hypermedia छोड़ना अधिकांश टीमों के लिए एक सोचा-समझा, उचित trade-off है, न कि कोई नाकामी [9]। मैं इससे सहमत होने को झुका हूँ, और मैं बताऊँगा कि क्यों।\nलगभग कोई भी पूर्ण HATEOAS क्यों नहीं करता अगर स्तर 3 ही \u0026ldquo;असली\u0026rdquo; REST है, तो लगभग पूरा उद्योग स्तर 2 पर ही क्यों रुक जाता है? कुछ ईमानदार वजहें:\nClients असल में dynamically navigate नहीं करते। HATEOAS का सपना एक generic client है जो runtime पर links का अनुसरण करके API को खोजता है। हक़ीक़त में, आपकी frontend टीम एक ज्ञात contract के विरुद्ध ज़रूरी endpoints को hardcode कर देती है। links वहीं बेकार पड़े रहते हैं। यह अस्पष्ट फ़ायदे के लिए ज़्यादा काम है। हर जगह _links embed करना, HAL जैसा कोई hypermedia format चुनना, relation types को संगत रखना — यह असली मेहनत है [8]। अगर कोई consumer behaviour चलाने के लिए links इस्तेमाल नहीं करता, तो आपने बेवजह बोझ बढ़ा लिया। Documentation और tooling जीत गए। OpenAPI/Swagger clients को runtime links के बजाय एक spec फ़ाइल के ज़रिए discoverability देता है। यह वह नहीं है जो फील्डिंग के मन में था, लेकिन इसने लोगों की व्यावहारिक समस्या हल कर दी। बड़े खिलाड़ियों ने इसे कभी नहीं किया। जब धरती के सबसे ज़्यादा नक़ल किए जाने वाले API hypermedia छोड़ देते हैं [8], तो वह de facto मानक बन जाता है, चाहे शोध-प्रबंध कुछ भी कहे। हालाँकि एक असली विरोधाभासी पक्ष भी है, और मैं उसके साथ अन्याय नहीं करना चाहता। API स्तर 3 पर मौजूद हैं, और कुछ बड़े उस ओर झुकते हैं — GitHub का API मशहूर रूप से अपने responses में ही संबंधित resources के URLs embed करता है ताकि आप खुद URLs बनाने के बजाय उनका अनुसरण कर सकें। जब आपके पास सचमुच कई स्वतंत्र clients हों जिन्हें आप नियंत्रित नहीं करते, या एक लंबे समय तक चलने वाला API जहाँ आप सबको तोड़े बिना resources को इधर-उधर करना चाहते हों, तो hypermedia अपनी कीमत वसूल कर लेता है। फील्डिंग जिस decoupling की बात करते थे वह कोई किताबी चीज़ नहीं है — यही वह तरीका है जिससे सर्वर एक समन्वित client redeploy के बिना URLs बदलने की आज़ादी बनाए रखता है [1][12]। अधिकांश internal API को बस उस आज़ादी की इतनी बुरी तरह कभी ज़रूरत नहीं पड़ती कि उसकी कीमत चुकाई जाए।\nएक ठोस नज़र: एक ही endpoint, तीन स्तर मुझे इसे कम अमूर्त बनाने दें। मान लीजिए आप एक order fetch कर रहे हैं। हर maturity स्तर मोटे तौर पर ऐसा दिखता है।\nस्तर 0 — दलदल। एक endpoint, हर चीज़ के लिए POST, verbs body में रहते हैं:\nPOST /api { \u0026#34;action\u0026#34;: \u0026#34;getOrder\u0026#34;, \u0026#34;id\u0026#34;: 42 } स्तर 2 — जहाँ अधिकांश \u0026ldquo;RESTful\u0026rdquo; API रहते हैं। असली resource URL, असली verb, असली status code:\nGET /orders/42 200 OK { \u0026#34;id\u0026#34;: 42, \u0026#34;status\u0026#34;: \u0026#34;shipped\u0026#34;, \u0026#34;customerId\u0026#34;: 7 } स्तर 3 — hypertext-driven। वही डेटा, लेकिन response client को बताता है कि वह आगे क्या कर सकता है:\nGET /orders/42 200 OK { \u0026#34;id\u0026#34;: 42, \u0026#34;status\u0026#34;: \u0026#34;shipped\u0026#34;, \u0026#34;_links\u0026#34;: { \u0026#34;self\u0026#34;: { \u0026#34;href\u0026#34;: \u0026#34;/orders/42\u0026#34; }, \u0026#34;customer\u0026#34;: { \u0026#34;href\u0026#34;: \u0026#34;/customers/7\u0026#34; }, \u0026#34;cancel\u0026#34;: { \u0026#34;href\u0026#34;: \u0026#34;/orders/42/cancel\u0026#34; } } } फ़र्क़ देखा? स्तर 3 पर, client को यह जानने की ज़रूरत नहीं कि cancel करना /orders/42/cancel पर रहता है। सर्वर ने उसे बता दिया। और सबसे अहम, अगर order पहले ही shipped हो चुका है, तो सर्वर बस cancel link को छोड़ सकता है — अब उपलब्ध actions state से संचालित हैं, जो \u0026ldquo;hypermedia as the engine of application state\u0026rdquo; का अक्षरशः मतलब है [1][8]। यही वो सचमुच चतुर हिस्सा है जो लोग चूक जाते हैं। यह responses को links से सजाने के बारे में नहीं है। यह सर्वर के इस नियंत्रण के बारे में है कि आगे क्या संभव है।\nतो आपको असल में अपने API को क्या कहना चाहिए? ये चीज़ें बनाने के सालों बाद यहाँ मेरी राय वाली बात है।\nअगर यह स्तर 2 है, तो आम लेखन में इसे \u0026ldquo;RESTful\u0026rdquo; कहना ठीक है। हर कोई समझता है कि आपका क्या मतलब है, और पूरे उद्योग के इस्तेमाल से लड़ना हारी हुई लड़ाई है। शब्द का अर्थ बहक गया है, और यह ठीक है। अगर आप तकनीकी रूप से सटीक होना चाहते हैं, तो कहें \u0026ldquo;REST-like\u0026rdquo; या \u0026ldquo;REST conventions का पालन करने वाला HTTP API।\u0026rdquo; Hacker News के पंडित फिर भी बहस करेंगे, लेकिन आप सही होंगे [7]। \u0026ldquo;REST API\u0026rdquo; शब्द को बिना झेंपे केवल स्तर 3 के लिए रखें। अगर कोई सख़्ती बरत रहा हो और पूछे \u0026ldquo;क्या यह एक REST API है,\u0026rdquo; और आप hypermedia नहीं करते, तो ईमानदार जवाब है \u0026ldquo;नहीं, यह REST-like है\u0026rdquo; [1][7]। जिस बात का मैं सबसे ज़ोरदार विरोध करूँगा वह है नियमों के होने का ही दिखावा करना। बहुत-सी टीमें किसी चीज़ को RESTful कहती हैं बिना यह जाने कि एक HATEOAS constraint है जिसे वे छोड़ रहे हैं। इसे जान-बूझकर छोड़ना एक अच्छा इंजीनियरिंग फ़ैसला है। इसे इसलिए छोड़ना क्योंकि आपको कभी पता ही नहीं था कि यह मौजूद है, बस अच्छी मार्केटिंग के साथ की गई अज्ञानता है।\nवे नियम जिन्हें आपको सचमुच नहीं तोड़ना चाहिए सभी constraints बराबर नहीं हैं, और यहीं मैं इस बारे में दो-टूक रहूँगा कि एक चालू API के लिए असल में क्या मायने रखता है बनाम क्या छोड़ना सुरक्षित है।\nStatelessness — इसे मत तोड़िए। जिस पल आपका सर्वर requests के बीच client state याद रखना शुरू करता है, आप horizontal scaling खो देते हैं, layered-system के फ़ायदे खो देते हैं, और आपने सचमुच REST को इस तरह पीछे छोड़ दिया है जो परिचालन के लिहाज़ से आपको नुकसान पहुँचाता है [2][12]। इसमें असली दम है। HTTP verbs और status codes का सही इस्तेमाल — इसे भी मत तोड़िए। एक GET जो डेटा बदल दे, एक असली बग है जो होने का इंतज़ार कर रहा है, क्योंकि caches और crawlers मानते हैं कि GET सुरक्षित है। यह स्तर 1-से-2 की बात है और यह बुनियादी ज़रूरत है। Cacheability — इसका सम्मान करें। सही cache headers सेट करना कम मेहनत है और यह उन चीज़ों में से एक है जिन्होंने वेब को scale करने लायक बनाया। इसे नज़रअंदाज़ करना performance को यूँ ही गँवाना है [3]। HATEOAS — जान-बूझकर छोड़ना ठीक है। यही वो है जिसे लगभग हर कोई छोड़ देता है, और अधिकांश API के लिए यह एक बचाव-योग्य trade-off है [9]। बस ऐसा करते हुए पूर्ण REST होने का दावा मत कीजिए। पैटर्न देखा? जो constraints परिचालन गुणों की रक्षा करते हैं — statelessness, caching, सही verbs — वही हैं जिन्हें तोड़ने पर आप असल में दर्द महसूस करते हैं। जो constraint विशुद्ध रूप से विकासशीलता और discoverability के बारे में है — HATEOAS — वही है जिसके बिना आप आमतौर पर गुज़ारा कर सकते हैं। यह कोई संयोग नहीं है। यही वजह है कि उद्योग जहाँ टिका वहीं टिका।\nइससे आप कहाँ खड़े होते हैं \u0026ldquo;RESTful\u0026rdquo; शब्द बहुत पहले ही द्विआधारी (binary) होना बंद कर चुका है। फील्डिंग की एक सख़्त परिभाषा है जो कहती है hypertext या कुछ नहीं [1], और डेवलपर दुनिया का एक बड़ा हिस्सा चुपचाप उसे नज़रअंदाज़ करता है क्योंकि स्तर 2 उनकी समस्याएँ बखूबी हल कर देता है [7][8]। कोई भी पक्ष झूठ नहीं बोल रहा — वे एक ही शब्द को दो अलग मानकों के लिए इस्तेमाल कर रहे हैं।\nतो क्या आप अपने API को अब भी RESTful कह सकते हैं अगर वह सभी नियमों का पालन नहीं करता? व्यवहार में, हाँ, और आप भारी बहुमत में होंगे। बस यह जान लीजिए कि आप कौन-सा नियम छोड़ रहे हैं, यह जान लीजिए कि एक शुद्धतावादी आपको टोकेगा, और यह जान लीजिए कि जिसे आप शायद छोड़ रहे हैं — HATEOAS — वही ठीक वो है जिसके बारे में रॉय फील्डिंग ने कहा था कि आप इसे छोड़ नहीं सकते। यह आपको परेशान करता है या नहीं, यह पूरी तरह इस पर निर्भर करता है कि आप एक सख़्त architecture review के लिए लिख रहे हैं या ऐसा सॉफ़्टवेयर भेज रहे हैं जिसे लोग सचमुच इस्तेमाल करते हैं।\nमुझे पता है कि मैं आमतौर पर किस पक्ष में होता हूँ। लेकिन मुझे कम से कम यह पता है कि मैं क्या छोड़ रहा हूँ।\nसमाप्त\nस्रोत REST APIs must be hypertext-driven — Roy T. Fielding The Six Constraints — REST API Tutorial REST Architectural Constraints — restfulapi.net Richardson Maturity Model — Martin Fowler Richardson Maturity Model — restfulapi.net Know how RESTful your API is: An Overview of the Richardson Maturity Model — Red Hat Developer Most RESTful APIs aren\u0026rsquo;t really RESTful — Florian Krämer When Is an API Truly REST vs REST-Like? — Nordic APIs Pragmatic REST: APIs without hypermedia and HATEOAS — Ben Morris REST over HTTP, or why your HTTP API isn\u0026rsquo;t RESTful — Christophe Maillard REST APIs Must be Hypertext-driven — Stefan Tilkov, INNOQ REST — Wikipedia Richardson Maturity Model — Wikipedia Roy Fielding on Versioning, Hypermedia, and REST — InfoQ ","permalink":"https://cloudmato.com/hi/posts/can-i-call-my-api-restful/","title":"क्या आप हर नियम के बिना भी अपने API को RESTful कह सकते हैं?"},{"content":"किसी भी ऐसे प्रोजेक्ट पर git log चलाइए जो एक साल से ज़्यादा पुराना है और आपको किसी टीम की सच्चाई दिख जाएगी। आधे messages में लिखा होगा \u0026ldquo;fix\u0026rdquo;, \u0026ldquo;update\u0026rdquo;, \u0026ldquo;wip\u0026rdquo;, \u0026ldquo;asdf\u0026rdquo;, या मेरा निजी पसंदीदा — \u0026ldquo;stuff\u0026rdquo;। और फिर एक दिन production टूट जाता है, आप गड़बड़ करने वाली line पर git blame चलाते हैं, और जिस commit ने यह पेश किया था उसमें बस लिखा है \u0026ldquo;minor changes\u0026rdquo;। बढ़िया। बहुत मददगार। शुक्रिया, बीते हुए मुझ।\nमैं एक दशक से ज़्यादा से कोड लिख रहा हूँ और मैं ईमानदारी से कहूँगा: शुरुआती कुछ सालों तक मेरे commit messages कचरा थे। तब तक समझ नहीं आया जब तक मुझे किसी और के छह महीने पुराने कोड को debug नहीं करना पड़ा (और फिर एहसास हुआ कि वह \u0026ldquo;कोई और\u0026rdquo; मैं ही था)। तब बात समझ में आई। एक diff आपको बताता है कि क्या बदला। केवल commit message आपको बता सकता है कि क्यों। बस यही पूरा खेल है।\nपरेशानी क्यों उठाएँ? वैसे भी इन्हें कोई नहीं पढ़ता यही वह झूठ है जो हम खुद से बोलते हैं। लोग बिल्कुल commit messages पढ़ते हैं — बस उस समय नहीं जब आप उन्हें लिख रहे होते हैं। वे इन्हें बाद में पढ़ते हैं, दबाव में, जब कुछ आग की तरह जल रहा होता है।\nयहाँ एक अच्छा message सचमुच अपनी कीमत वसूल करता है:\ngit blame — कोई कोड की किसी अजीब line की ओर इशारा करता है और commit उसका तर्क समझाता है ताकि आप किसी जान-बूझकर बनाए गए workaround को \u0026ldquo;fix\u0026rdquo; न कर दें। onboarding के दौरान git log — एक नया dev इतिहास पढ़कर समझता है कि कोई feature कैसे विकसित हुआ। git bisect — जब आप किसी regression का शिकार ढूँढ रहे होते हैं, तो छोटे और अच्छी तरह वर्णित commits आपको घंटों के बजाय मिनटों में दोषी ढूँढने देते हैं। git revert — जब आपको किसी बदलाव को साफ़-सुथरे ढंग से, असंबंधित चीज़ों को साथ खींचे बिना, पलटना हो। रिलीज़ नोट्स और changelogs — जो अब तेज़ी से सीधे commits से अपने आप तैयार किए जाते हैं। एक diff आपको क्या दिखाता है। commit message ही एकमात्र जगह है जहाँ क्यों बचा रहता है [1]। कोड खुद को समझा सकता है; इरादा नहीं। अब से छह महीने बाद किसी को याद नहीं रहेगा कि आपने वह retry loop इसलिए हटाया था क्योंकि upstream API ने ग्राहकों से दोगुना चार्ज लेना शुरू कर दिया था। जब तक आपने इसे लिखकर न रखा हो।\nतो नहीं, यह नौकरशाही नहीं है। यह उस व्यक्ति के लिए रास्ते के निशान छोड़ना है जिसे इसे maintain करना है — और आँकड़ों के हिसाब से वह व्यक्ति आप ही होंगे।\nवे सात नियम जिन्हें हर कोई दोहराता है (और दोहराना चाहिए) ज़्यादातर आधुनिक सलाह दो लोगों तक जाती है। Tim Pope ने 2008 की एक ब्लॉग पोस्ट में 50/72 formatting convention को लोकप्रिय बनाया [2], और Chris Beams ने बाद में इन्हें \u0026ldquo;एक शानदार commit message के सात नियम\u0026rdquo; के रूप में cbea.ms पर लिखा, जो मूलतः canonical संदर्भ बन गया है [1]। ये रहे, और इन्हें याद कर लेना सार्थक है:\nsubject को body से एक खाली line द्वारा अलग करें subject line को 50 अक्षरों तक सीमित रखें subject line को Capital अक्षर से शुरू करें subject line को period (पूर्णविराम) से न समाप्त करें subject line में imperative mood (आदेशात्मक रूप) का उपयोग करें body को 72 अक्षरों पर wrap करें body का उपयोग क्या और क्यों समझाने के लिए करें, कैसे के लिए नहीं जब तक आप हर एक के पीछे का तर्क न समझें, यह बाल की खाल निकालना लगता है। चलिए मैं गहराई में जाता हूँ, क्योंकि सच कहूँ तो इन नियमों के पीछे का क्यों खुद नियमों से ज़्यादा उपयोगी है।\nsubject line खास है — Git इसे अलग तरह से मानता है वह पहली line सिर्फ़ परंपरा नहीं है; Git खुद इसे commit के शीर्षक के रूप में मानता है। git log --oneline, git shortlog, git rebase जैसे tools और लगभग हर GitHub/GitLab UI सारांश में केवल उसी पहली line का उपयोग करते हैं [1]। उसके बाद की खाली line ही वह तरीका है जिससे Git जानता है कि शीर्षक कहाँ खत्म होता है और body कहाँ शुरू होती है। खाली line छोड़ दीजिए और आपकी सुंदर लिखी हुई body आपके इस्तेमाल किए जाने वाले आधे tools में subject के साथ मिल-जुलकर एक हो जाएगी।\n50 अक्षर ही क्यों? यह न तो मनमाना है और न ही कोई कठोर सीमा — इसे एक ज़ोरदार धक्के की तरह समझिए। GitHub आपको 50 अक्षरों पर चेतावनी देता है और 72 पर ellipsis (…) के साथ काट देता है [1]। और भी अहम बात, यह बाधा स्पष्टता को मजबूर करती है। अगर आप अपने बदलाव को 50 अक्षरों में वर्णित नहीं कर सकते, तो यह आमतौर पर एक संकेत है कि आपका commit बहुत सारी चीज़ें कर रहा है (इस पर बाद में और)। body 72 पर wrap होती है ताकि Git का डिफ़ॉल्ट indentation 80-कॉलम वाले terminal के भीतर बिना भद्दे ढंग से wrap हुए फिट हो जाए [3]।\nimperative mood वाली बात — हाँ, इससे सचमुच फ़र्क पड़ता है यह वह नियम है जिस पर लोग सबसे ज़्यादा आँखें घुमाते हैं, तो मैं इसका पक्ष रखता हूँ। लिखिए \u0026ldquo;Fix login redirect loop\u0026rdquo;, न कि \u0026ldquo;Fixed\u0026rdquo;, न \u0026ldquo;Fixes\u0026rdquo;, न \u0026ldquo;Fixing\u0026rdquo;।\nवह कसौटी जो इसे साफ़ कर देती है: आपका subject इस वाक्य को पूरा करना चाहिए \u0026ldquo;If applied, this commit will ___\u0026rdquo; (अगर लागू किया जाए, तो यह commit ___ करेगा) [4]।\n✅ If applied, this commit will Fix login redirect loop ❌ If applied, this commit will Fixed login redirect loop दूसरा बेतुका पढ़ने में लगता है। एक गहरा कारण भी है — Git खुद imperative में लिखता है। जब आप merge करते हैं, Git \u0026ldquo;Merge branch \u0026lsquo;feature\u0026rsquo;\u0026rdquo; बनाता है। जब आप revert करते हैं, यह \u0026ldquo;Revert \u0026hellip;\u0026rdquo; लिखता है। आपके commits को codebase के लिए आदेशों की तरह पढ़ा जाना चाहिए, Git की अपनी आवाज़ के अनुरूप [4]। मज़ेदार बात यह है कि इतने सारे उपदेशों के बावजूद, GitHub पर केवल लगभग 44% commits ही असल में imperative mood का उपयोग करते हैं [5]। तो इसका पालन करने से आप उस अल्पसंख्यक में आ जाते हैं जो दिखता है कि उसे पता है कि वह क्या कर रहा है।\nएक त्वरित पहले/बाद:\n❌ न करें ✅ करें fixed the bug. Fix null check in user serializer Updating README Document the env setup steps changes to api Add pagination to /orders endpoint WIP Add failing test for expired tokens body में क्या जाता है subject क्या बताता है। body वह जगह है जहाँ आप समझाते हैं कि यह बदलाव क्यों, अभी क्यों, और आपने किन विकल्पों पर विचार किया। कैसे का वर्णन न करें — diff पहले ही दिखा देता है कि कैसे। उस समस्या को समझाइए जिसे आप हल कर रहे थे और अपने दृष्टिकोण के पीछे का तर्क [1]।\nएक पूरे message का लगभग-असली उदाहरण:\nCap retry attempts on payment webhook The webhook handler retried indefinitely on a 5xx from the billing provider. During their outage last Tuesday this hammered their API and triggered duplicate charge attempts for ~30 users. Limit retries to 3 with exponential backoff, and log the final failure so support can reconcile manually. Refunds for the affected accounts are tracked in TICKET-4821. गौर कीजिए कि backoff कैसे implement किया गया है, इस बारे में एक भी line नहीं है। वह कोड दिखाता है। message उस चीज़ को कैद करता है जो वरना आप हमेशा के लिए खो देते — outage, duplicate charges, ticket। यही वह हिस्सा है जिसकी कोई जगह नहीं ले सकता।\nएक व्यावहारिक सुझाव: किसी भी गैर-तुच्छ चीज़ के लिए git commit -m का इस्तेमाल बंद कर दीजिए। -m flag चुपचाप आपको one-liners लिखना सिखाता है क्योंकि इसके साथ एक उचित body लिखना तकलीफ़देह है [6]। बस git commit चलाइए, अपने editor को खुलने दीजिए, और एक इंसान की तरह लिखिए। अपना editor git config --global core.editor \u0026quot;code --wait\u0026quot; (या vim, या जो भी हो) से सेट कर लीजिए और आप तैयार हैं।\natomic commits लिखें — यही असली राज़ है यहाँ वह बात है जो लगभग कोई शुरुआती को नहीं बताता: आपके commit message की गुणवत्ता लगभग पूरी तरह आपके commit की गुणवत्ता पर निर्भर करती है। अगर आपका commit पंद्रह असंबंधित चीज़ें बदलता है, तो धरती पर कोई message इसे अच्छी तरह सारांशित नहीं कर सकता। आप आख़िरकार \u0026ldquo;various fixes\u0026rdquo; लिखेंगे क्योंकि सच में यही एकमात्र ईमानदार विवरण है।\nएक atomic commit वह सबसे छोटा बदलाव है जो अपने आप में समझ में आता है और codebase को एक काम करने वाली स्थिति में छोड़ता है [7]। एक तार्किक बदलाव। एक bug fix को formatting cleanup के साथ और एक नई feature के साथ मत मिलाइए।\nइसके लिए एक बिलकुल सरल गंध-परीक्षण है: अगर आपकी subject line को \u0026ldquo;and\u0026rdquo; शब्द की ज़रूरत है, तो आपका commit शायद दो commits है [8]। \u0026ldquo;Add search filter and fix navbar styling\u0026rdquo; — यह तो ट्रेंच कोट पहने हुए दो commits हैं।\nयह अनुशासन इस लायक क्यों है:\ngit bisect एक महाशक्ति बन जाता है। छोटे, केंद्रित commits bisect को ठीक उसी बदलाव पर पहुँचने देते हैं जिसने bug पेश किया [9]। Reverts साफ़ होते हैं। आप एक feature को बिना गलती से किसी असंबंधित fix को पलटे, जो उसके साथ चली आई थी, undo कर सकते हैं [9]। Code review आसान हो जाता है। Reviewers एक छोटे, एकल-उद्देश्य वाले बदलाव को 600-line वाले मिले-जुले झोले की तुलना में कहीं तेज़ी से समझते हैं। इतिहास एक कहानी की तरह पढ़ा जाता है। हर commit इस बात का एक अध्याय है कि प्रोजेक्ट यहाँ तक कैसे पहुँचा [9]। मेरे लिए जो तरीका काम करता है: git add -p (patch mode) से चुनिंदा रूप से stage कीजिए ताकि आप केवल संबंधित hunks ही commit करें, भले ही आपकी working directory में कई असंबंधित बदलाव चल रहे हों। और अगर आप पहले ही local में गड़बड़ कर चुके हैं, तो interactive rebase इसी के लिए है — push करने से पहले squash और split कीजिए।\nConventional Commits: मशीनों और इंसानों दोनों के लिए संरचना एक बार जब आप मूल बातें पकड़ लें, तो एक लोकप्रिय convention है जो इसके ऊपर एक हल्की संरचना जोड़ता है: Conventional Commits। प्रारूप बेहद सरल है [10]:\n\u0026lt;type\u0026gt;[optional scope]: \u0026lt;description\u0026gt; [optional body] [optional footer(s)] तो आपकी subject line एक type से शुरू होती है। आम वाले:\nType कब इस्तेमाल करें feat एक नई feature fix एक bug fix docs केवल documentation style formatting, whitespace — कोई logic बदलाव नहीं refactor कोड बदलाव जो न bug fix करे न feature जोड़े perf एक performance सुधार test tests जोड़ना या ठीक करना build / ci build system या CI config chore नियमित रखरखाव, deps, tooling असल दुनिया के उदाहरण:\nfeat(auth): add passwordless email login fix(api): handle empty cart on checkout docs: clarify env setup in README refactor(parser): extract token validation Breaking changes को दो तरीकों से चिह्नित किया जाता है: colon से पहले एक !, या एक BREAKING CHANGE: footer [10]:\nfeat!: drop support for Node 16 BREAKING CHANGE: minimum supported runtime is now Node 18. टीमें इसे क्यों अपनाती हैं फ़ायदा सौंदर्यपरक नहीं है — यह automation है। चूँकि type machine-readable है, tooling कर सकती है:\nआपके commit इतिहास से changelogs अपने आप तैयार करना। आपके semantic version को सही ढंग से bump करना — fix → patch, feat → minor, BREAKING CHANGE → major [10]। CI में बिना किसी इंसान के version तय किए releases और publish steps को trigger करना। यह कोई आला (niche) चीज़ भी नहीं है। शीर्ष 381 NPM libraries की एक समीक्षा में पाया गया कि लगभग 95% Conventional Commits formatting का उपयोग करती थीं, जिनमें से आधी से ज़्यादा अपने पूरे इतिहास में 80%+ अनुपालन तक पहुँचीं [11]। अगर आप एक library maintain करते हैं, तो यह अब लगभग बुनियादी अपेक्षा है।\nहालाँकि सच कहूँ — क्या यह सबके लिए है? किसी solo प्रोजेक्ट या छोटे internal app पर, जहाँ आप कुछ भी auto-release नहीं कर रहे, वहाँ feat:/fix: prefixes सिर्फ़ औपचारिकता के लिए औपचारिकता जैसे लग सकते हैं। पहले बताए गए सात नियम prefix से कहीं ज़्यादा मायने रखते हैं। Conventional Commits का उपयोग तब कीजिए जब automation उस अनुशासन की कीमत चुका दे। किसी लोकप्रिय repo के करने भर से इसकी नकल मत कीजिए।\nanti-patterns — एक commit message को क्या बुरा बनाता है चलिए नाम लेकर बताता हूँ। ये वे हैं जो मुझे लगातार दिखते हैं, और ये क्यों चुभते हैं [12][8]:\n\u0026ldquo;Fix bug\u0026rdquo; — कौन-सा bug? आपको याद नहीं रहेगा। bug का नाम बताइए। \u0026ldquo;Update\u0026rdquo;, \u0026ldquo;changes\u0026rdquo;, \u0026ldquo;stuff\u0026rdquo;, \u0026ldquo;wip\u0026rdquo; — शून्य जानकारी। diff ने पहले ही बता दिया कि कुछ बदला है। files की सूची बनाना: \u0026ldquo;Update user.rb and helper.js\u0026rdquo; — git show पहले ही files की सूची दे देता है। message को बदलाव के अर्थ को समझाना चाहिए, न कि file की सूची की नकल करनी चाहिए [12]। subject में \u0026ldquo;and\u0026rdquo; — लगभग हमेशा इसका मतलब है कि commit को split किया जाना चाहिए [8]। भूतकाल / गलत mood — \u0026ldquo;Fixed\u0026rdquo;, \u0026ldquo;Added\u0026rdquo;, \u0026ldquo;Changing\u0026rdquo;। imperative चुनिए और उस पर टिके रहिए। one-liners की एक दीवार — दस commits जिनमें सब \u0026ldquo;updates\u0026rdquo; कहते हैं। यही वह है जो git commit -m के अति-उपयोग से पैदा होता है [12]। subject का स्पष्ट बात को दोहराना — \u0026ldquo;Make changes to the changes file\u0026rdquo;। बताइए क्या और क्यों। enter दबाने से पहले एक आत्म-जाँच: अपनी subject line को \u0026ldquo;If applied, this commit will ___\u0026rdquo; के रूप में वापस पढ़िए और खुद से पूछिए कि क्या कोई ऐसा व्यक्ति जो वहाँ मौजूद नहीं था, इसे छह महीने बाद समझ पाएगा। अगर जवाब नहीं है, तो अतिरिक्त तीस सेकंड खर्च कीजिए। यह आपके भविष्य की समझदारी में किया गया अब तक का सबसे सस्ता निवेश है।\nवह tooling जो आपको ईमानदार रखती है केवल इच्छाशक्ति से अनुशासन बनाए रखना कठिन है, तो इसके बजाय मशीनों को आपको टोकने दीजिए:\nCommit message template — अपने ही नियमों की एक याददहानी सेट कीजिए: git config --global commit.template ~/.gitmessage.txt उस file में एक ढाँचा (subject याददहानी, खाली line, body याददहानी) डाल दीजिए और यह हर बार commit करते समय दिख जाएगा। commitlint + Husky — एक git hook जो ऐसे commits को अस्वीकार कर देता है जो Conventional Commits का पालन नहीं करते। टीमों के लिए बढ़िया। Commitizen — एक interactive prompt जो आपको एक ठीक से formatted commit बनाने में कदम-दर-कदम मार्गदर्शन करता है। Editor integration — ज़्यादातर editors (और GitKraken जैसे tools) तब उजागर करते हैं जब आपका subject 50 अक्षरों से आगे निकल जाता है [13]। इनमें से कोई भी आपके लिए एक अच्छा message नहीं लिखता — वे बस आकार लागू करते हैं। सोचना अब भी आपका काम है। और आजकल एक AI assistant आपके diff से एक ठीक-ठाक message का मसौदा बना सकता है, जो सचमुच उपयोगी है, लेकिन इसे एक junior के पहले मसौदे की तरह समझिए। यह देख सकता है कि क्या बदला; यह पिछले मंगलवार के outage या ticket नंबर को नहीं देख सकता। वह संदर्भ केवल आपके दिमाग में रहता है, और इसे message में डालना ही पूरा उद्देश्य है।\nएक ऐसा workflow जिस पर आप सचमुच टिके रह सकते हैं सबको एक साथ जोड़कर, एक समझदार commit आदत रोज़मर्रा में ऐसी दिखती है:\nएक तार्किक बदलाव कीजिए। अगर आप असंबंधित edits में भटक गए हैं, तो git add -p से चुनिंदा रूप से stage कीजिए। git commit चलाइए (बिना -m) ताकि आपका editor खुले। ~50 अक्षरों से कम का subject लिखिए, imperative mood, Capital अक्षर, कोई period नहीं। अगर आपकी टीम Conventional Commits का उपयोग करती है तो एक type prefix जोड़िए। खाली line, फिर एक body जो क्यों समझाए — लेकिन केवल तभी जब बदलाव को संदर्भ की ज़रूरत हो। तुच्छ commits को body की ज़रूरत नहीं होती। tickets या issues का संदर्भ दीजिए footer में (Refs #421, Closes #88)। सहेजने से पहले इसे \u0026ldquo;If applied, this commit will ___\u0026rdquo; परीक्षण के साथ दोबारा पढ़िए। बस इतना ही। यह प्रति commit शायद एक मिनट जोड़ता है और बाद में घंटों बचाता है। ज़्यादा उदाहरणों के साथ एक गहरे विवरण के लिए, freeCodeCamp की step-by-step guide एक ठोस साथी पठन है [14]।\nसबसे अच्छा commit message न तो सबसे चतुर होता है न सबसे लंबा। यह वह होता है जो उस सवाल का जवाब देता है जिसे आपका भविष्य का साथी स्क्रीन पर चिल्लाने वाला है: \u0026ldquo;आख़िर यह बदला ही क्यों गया?\u0026rdquo; इसका जवाब दे दीजिए, और आपने काम कर दिया।\nसमाप्त\nस्रोत How to Write a Git Commit Message - Chris Beams Mastering Git Commit Messages: Tim Pope\u0026rsquo;s 50/72 Formatting Guide The 50/72 Rule of Git – DevIQ Imperative Git commit messages in the active tense or mood - TheServerSide What % of Git commit messages use the imperative mood? - InitialCommit Best Practices for Git Commit Message - Baeldung on Ops Mastering Atomic Commits - LeanIX Engineering \u0026ldquo;and\u0026rdquo; as anti-pattern in git commit subject - Kosta Harlan How atomic Git commits dramatically increased my productivity - DEV Community Conventional Commits v1.0.0 Conventional Commits Specification - Wikipedia Git Commit Message Anti-Patterns - AMC How to Write a Good Git Commit Message - GitKraken How to Write Better Git Commit Messages – freeCodeCamp ","permalink":"https://cloudmato.com/hi/posts/how-to-write-the-best-git-commit-message/","title":"सबसे अच्छा Git Commit Message कैसे लिखें"},{"content":"दो सवाल लगातार आपस में घुलमिल जाते हैं: \u0026ldquo;TLS टर्मिनेशन क्या है\u0026rdquo; और \u0026ldquo;क्या SSL ट्रांसपोर्ट लेयर की चीज़ है?\u0026rdquo; लोग मान लेते हैं कि दूसरे का जवाब साफ़-साफ़ हाँ है — इसका नाम ही तो शाब्दिक रूप से Transport Layer Security है, है ना? खैर। इस नामकरण ने बहुत से समझदार लोगों को भी चकमा दिया है, और यह उलझन सीधे इस बात में रिस जाती है कि लोग टर्मिनेशन के बारे में कैसे सोचते हैं। तो मुझे दोनों को सुलझाने दीजिए, क्योंकि एक बार जब लेयर वाला सवाल समझ में आ जाता है, तो टर्मिनेशन जादू जैसा लगना बंद कर देता है।\nलेयर वाले सवाल का छोटा जवाब यह रहा सीधा-सपाट संस्करण: TLS ट्रांसपोर्ट लेयर पर नहीं चलता, भले ही इसके नाम में \u0026ldquo;Transport\u0026rdquo; लिखा हो। यह ट्रांसपोर्ट लेयर के ऊपर चलता है।\nजब आपका ब्राउज़र HTTPS पर किसी सर्वर से बात करता है, तो असली ट्रांसपोर्ट अब भी TCP ही होता है। यह लेयर 4 है। TCP पोर्ट, सीक्वेंसिंग, रीट्रांसमिशन, और भरोसेमंद बाइट-स्ट्रीम वाली चीज़ें संभालता है। TLS उसके ऊपर बैठता है, बाइट्स को एन्क्रिप्शन में लपेटता है, और प्लेनटेक्स्ट को ऊपर आपके इस्तेमाल किए जा रहे ऐप्लिकेशन प्रोटोकॉल (HTTP, SMTP, IMAP, gRPC, जो भी हो) को सौंप देता है। आधिकारिक स्पेसिफ़िकेशन, RFC 8446, TLS 1.3 को एक ऐसे प्रोटोकॉल के रूप में बताती है जो \u0026ldquo;क्लाइंट/सर्वर ऐप्लिकेशन को इंटरनेट पर इस तरह संवाद करने देता है जिसे ताक-झाँक, छेड़छाड़, और संदेश की जालसाज़ी रोकने के लिए डिज़ाइन किया गया है\u0026rdquo; — और यह साफ़ तौर पर अपने नीचे TCP जैसे किसी भरोसेमंद ट्रांसपोर्ट को मानकर चलती है [1]।\nतो नाम में \u0026ldquo;Transport\u0026rdquo; क्यों? ईमानदारी से कहें तो यह ज़्यादातर ब्रांडिंग का एक ऐतिहासिक हादसा है। इस प्रोटोकॉल ने अपनी ज़िंदगी SSL (Secure Sockets Layer) के रूप में शुरू की थी, जिसे Netscape ने 90 के दशक के मध्य में बनाया था। जब IETF ने इसे अपने हाथ में लिया और 1999 में इसे मानकीकृत किया, तो उन्होंने इसका नाम बदलकर Transport Layer Security रखा — कुछ हद तक Netscape के ट्रेडमार्क के झंझट से बचने के लिए, और कुछ हद तक इसलिए क्योंकि यह ट्रांज़िट में मौजूद डेटा को सुरक्षित करता है [2]। यह नाम इरादे को बताता है, OSI स्टैक में इसकी जगह को नहीं।\nOSI मॉडल में यह असल में कहाँ फ़िट होता है अगर आप TLS को सात-लेयर वाले OSI मॉडल में सफ़ाई से बिठाने की कोशिश करेंगे, तो आपको मुश्किल होगी, और यह आपकी गलती नहीं है। जैसा कि TLS पर विकिपीडिया की एंट्री और बहुत से नेटवर्क इंजीनियर कहते हैं, TLS बस सफ़ाई से फ़िट नहीं होता [3]। सबसे आम ईमानदार वर्णन:\nयह ट्रांसपोर्ट लेयर (लेयर 4 / TCP) के ऊपर चलता है। यह ऐप्लिकेशन लेयर (लेयर 7 / HTTP) के नीचे बैठता है। OSI शब्दावली में, इसके किए जाने वाले काम — एन्क्रिप्शन, सेशन की स्थापना — मोटे तौर पर प्रेज़ेंटेशन (6) और सेशन (5) लेयर पर मैप होते हैं। TCP/IP मॉडल में (जो असल इंटरनेट से मेल खाता है), कोई अलग प्रेज़ेंटेशन या सेशन लेयर नहीं होती, इसलिए लोग अक्सर अपने मूड के हिसाब से TLS को आलसी ढंग से \u0026ldquo;ट्रांसपोर्ट\u0026rdquo; या \u0026ldquo;ऐप्लिकेशन\u0026rdquo; के खाते में डाल देते हैं। दोनों में से कोई भी ठीक-ठीक सही नहीं है। सबसे टिकाऊ बात जो आप कह सकते हैं: TLS एक सेशन/प्रेज़ेंटेशन-लेयर सुरक्षा प्रोटोकॉल है जो अपना काम करने के लिए एक ट्रांसपोर्ट-लेयर प्रोटोकॉल पर निर्भर करता है [4]।\nयह टर्मिनेशन के लिए मायने क्यों रखता है? क्योंकि TLS का TCP को लपेटने वाली एक अलग लेयर होना बिल्कुल वही चीज़ है जो किसी लोड बैलेंसर को इसे छीलकर, संभालकर, और भीतरी ट्रैफ़िक को आगे भेजने देती है। अगर एन्क्रिप्शन खुद TCP में ही पका हुआ होता, तो आप दोनों को सफ़ाई से अलग नहीं कर पाते। यह लेयरिंग ही पूरी वजह है कि टर्मिनेशन एक अवधारणा के रूप में मौजूद है।\nतो TLS टर्मिनेशन है क्या? TLS टर्मिनेशन वह बिंदु है जहाँ एन्क्रिप्टेड कनेक्शन खत्म होता है और ट्रैफ़िक डिक्रिप्ट हो जाता है। बस इतना ही। \u0026ldquo;टर्मिनेट\u0026rdquo; शब्द का मतलब बस इतना है कि \u0026ldquo;यहीं TLS टनल रुकती है।\u0026rdquo;\nएक साधारण दुनिया में, वह बिंदु आपका ऐप्लिकेशन सर्वर होता है। क्लाइंट सीधे आपके ऐप तक एक HTTPS कनेक्शन खोलता है, ऐप के पास सर्टिफ़िकेट और प्राइवेट की होती है, यह रिक्वेस्ट को डिक्रिप्ट करता है, प्रोसेस करता है, रिस्पॉन्स को एन्क्रिप्ट करता है। एंड टू एंड, एक ही हॉप।\nलेकिन बड़े पैमाने पर लगभग कोई भी इसे इस तरह नहीं चलाता। इसके बजाय, आप आगे कुछ रखते हैं — एक लोड बैलेंसर, Nginx या HAProxy जैसा कोई रिवर्स प्रॉक्सी, एक API गेटवे, एक CDN एज नोड। वह आगे वाला डिवाइस TLS हैंडशेक करता है, ट्रैफ़िक को डिक्रिप्ट करता है, और अब प्लेनटेक्स्ट बन चुकी रिक्वेस्ट को आपके बैकएंड सर्वरों को आगे भेज देता है, आमतौर पर किसी भरोसेमंद आंतरिक नेटवर्क पर सादे HTTP के ज़रिए [5]। \u0026ldquo;टर्मिनेशन\u0026rdquo; आपके ऐप से हटकर एज पर आ गया है। इसे SSL ऑफ़लोडिंग भी कहते हैं, क्योंकि आप क्रिप्टोग्राफ़िक काम को अपने बैकएंड से उतारकर कहीं और डाल रहे होते हैं।\nयह रहा एक ठोस चित्र। एक यूज़र https://yourshop.com पर पहुँचता है। रिक्वेस्ट आपके लोड बैलेंसर पर उतरती है। लोड बैलेंसर:\nब्राउज़र के साथ TLS हैंडशेक पूरा करता है। सर्टिफ़िकेट को मान्य करता है और प्रस्तुत करता है। आने वाली बाइट्स को एक सामान्य HTTP रिक्वेस्ट में डिक्रिप्ट करता है। उस रिक्वेस्ट को आपके किसी बैकएंड ऐप सर्वर (http://10.0.1.42:8080) को आगे भेजता है। बैकएंड के सादे HTTP रिस्पॉन्स को लेता है, उसे फिर से एन्क्रिप्ट करता है, और ब्राउज़र को वापस भेज देता है। ब्राउज़र को लगता है कि उसने yourshop.com के साथ एक सुरक्षित बातचीत की — और उसने की भी, पूरे रास्ते लोड बैलेंसर तक। आपके बैकएंड ने एन्क्रिप्शन की एक भी बाइट को कभी नहीं छुआ।\nएज पर टर्मिनेट करने की झंझट क्यों उठाएँ? यह अतिरिक्त कदम जोड़ें ही क्यों? कुछ वाकई अच्छे कारण हैं:\nयह आपके बैकएंड को क्रिप्टो के काम से बचाता है। TLS हैंडशेक और भारी एन्क्रिप्शन CPU खर्च करते हैं। यह सारा काम समर्पित लोड बैलेंसर (अक्सर हार्डवेयर एक्सेलरेशन के साथ) पर धकेलने से आपके ऐप्लिकेशन सर्वर असल में ऐप्लिकेशन लॉजिक चलाने के लिए मुक्त हो जाते हैं [6]। सर्टिफ़िकेट मैनेजमेंट समझदारी भरा हो जाता है। पचास ऐप सर्वरों पर सर्टिफ़िकेट और प्राइवेट की कॉपी करने और उन सबको रिन्यू करने के बजाय, आप एक ही सर्टिफ़िकेट को एक ही जगह संभालते हैं। AWS Certificate Manager जैसे टूल बिना डाउनटाइम के अपने-आप रिन्यू और रोटेट भी कर देंगे [7]। आप लेयर-7 फ़ीचर्स खोल देते हैं। एक बार ट्रैफ़िक डिक्रिप्ट हो जाने के बाद, प्रॉक्सी उसे पढ़ सकता है। इसका मतलब है पाथ-आधारित रूटिंग, हेडर रीराइट, स्टिकी सेशन, रिक्वेस्ट-स्तरीय मेट्रिक्स, रिस्पॉन्स कंप्रेशन, कैशिंग, और Web Application Firewall (WAF) निरीक्षण। बाइट्स के अब भी एन्क्रिप्टेड होते हुए इनमें से कुछ भी संभव नहीं है [8]। स्केलिंग आसान होती है। एक नया बैकएंड इंस्टेंस चालू करें और उसे बस सादा HTTP बोलने की ज़रूरत होती है। कोई TLS कॉन्फ़िग नहीं, प्रति नोड कोई सर्टिफ़िकेट प्रोविज़निंग नहीं। लेयर-7 फ़ीचर्स वाला वह आख़िरी बिंदु ही वह है जिसे लोग कम आँकते हैं। एक लोड बैलेंसर URL पाथ के आधार पर रूट नहीं कर सकता — जैसे, /api/* को एक पूल पर और /images/* को दूसरे पर भेजना — अगर वह URL देख ही न सके। और जब तक रिक्वेस्ट एन्क्रिप्टेड है, वह URL नहीं देख सकता। दृश्यता के लिए डिक्रिप्शन ज़रूरी है। यह अकेली बात TLS के इर्द-गिर्द के ज़्यादातर आर्किटेक्चरल फ़ैसलों को चलाती है।\nतीन मॉडल: टर्मिनेशन, पासथ्रू, और री-एन्क्रिप्शन TLS टर्मिनेशन कोई एक ही चीज़ नहीं है — यह तीन पैटर्न में से एक है, और गलत वाला चुनने से असली तकलीफ़ होती है। यहाँ देखिए ये कैसे टिकते हैं।\nमॉडल TLS कहाँ डिक्रिप्ट होता है बैकएंड हॉप L7 फ़ीचर्स? एंड-टू-एंड एन्क्रिप्टेड? टर्मिनेशन (ऑफ़लोडिंग) प्रॉक्सी पर सादा HTTP हाँ नहीं पासथ्रू केवल बैकएंड पर अब भी एन्क्रिप्टेड नहीं हाँ री-एन्क्रिप्शन (ब्रिजिंग) प्रॉक्सी पर, फिर दोबारा नया TLS सेशन हाँ हाँ टर्मिनेशन / ऑफ़लोडिंग वही डिफ़ॉल्ट जिसका हमने अभी वर्णन किया। एज पर डिक्रिप्ट करो, बैकएंड को सादा HTTP। अधिकतम फ़ीचर्स, सबसे सरल बैकएंड। पेच यह है: आपके लोड बैलेंसर और आपके ऐप सर्वरों के बीच का ट्रैफ़िक बिना एन्क्रिप्शन के सफ़र करता है। किसी कसी हुई प्राइवेट VPC पर यह अक्सर स्वीकार्य होता है। किसी साझा या अविश्वसनीय नेटवर्क पर, यह एक जोखिम है — अगर कोई आपके नेटवर्क के भीतर घुस जाए, तो SSL ऑफ़लोडिंग उस आंतरिक हॉप को मैन-इन-द-मिडल ताक-झाँक के लिए खुला छोड़ सकती है [8]।\nपासथ्रू प्रॉक्सी कुछ भी डिक्रिप्ट नहीं करता। यह एन्क्रिप्टेड स्ट्रीम को बाइट-दर-बाइट बैकएंड को आगे भेज देता है, जो सर्टिफ़िकेट रखता है और खुद TLS टर्मिनेट करता है। चतुर प्रॉक्सी अब भी ClientHello में मौजूद बिना एन्क्रिप्ट किए गए SNI (Server Name Indication) फ़ील्ड में झाँककर समझदारी से रूट करते हैं — यह उन्हें पेलोड डिक्रिप्ट किए बिना ही बता देता है कि क्लाइंट किस होस्टनेम को चाहता है [9]।\nइसका फ़ायदा असली सुरक्षा है: एन्क्रिप्शन क्लाइंट से लेकर पूरे रास्ते बैकएंड तक अटूट रहता है, डिक्रिप्शन केवल मंज़िल पर होता है। नुकसान यह है कि आप लेयर 7 पर सब कुछ खो देते हैं — कोई पाथ रूटिंग नहीं, कोई हेडर हेरफेर नहीं, कोई WAF नहीं, कोई कुकी-आधारित स्टिकी सेशन नहीं। आप मूलतः एक बेअक्ल TCP पाइप होते हैं। पासथ्रू तब समझ में आता है जब बैकएंड पहले से ही अपने सर्टिफ़िकेट संभालते हैं, या जब कंप्लायंस की माँग हो कि प्रॉक्सी कभी प्लेनटेक्स्ट न देखे।\nरी-एन्क्रिप्शन / TLS ब्रिजिंग \u0026ldquo;आम के आम और गुठलियों के दाम\u0026rdquo; वाला विकल्प। प्रॉक्सी क्लाइंट के TLS को टर्मिनेट करता है, डिक्रिप्ट करता है, ज़रूरत के मुताबिक जो भी लेयर-7 जादू करना हो वह करता है, फिर बैकएंड के लिए एक बिल्कुल नया TLS कनेक्शन खोलता है और आगे भेजने से पहले उसे फिर से एन्क्रिप्ट करता है [10]। Red Hat के OpenShift दस्तावेज़ इस \u0026ldquo;री-एन्क्रिप्ट\u0026rdquo; रूट प्रकार का ठीक यही वर्णन करते हैं: TLS राउटर पर टर्मिनेट होता है, फिर राउटर पॉड के लिए ताज़ा एन्क्रिप्शन स्थापित करता है [10]।\nआपको निरीक्षण और एक एन्क्रिप्टेड आंतरिक हॉप दोनों मिलते हैं। इसकी कीमत है दोगुना क्रिप्टो काम और थोड़ी ज़्यादा कॉन्फ़िग (अब आप दो जगहों पर सर्टिफ़िकेट संभालते हैं)। नियंत्रित वर्कलोड के लिए — HIPAA के तहत हेल्थकेयर डेटा, PCI-DSS के तहत कार्ड डेटा — यह अक्सर सही जवाब होता है, क्योंकि वे ढाँचे केवल सामने के दरवाज़े पर नहीं, बल्कि अविश्वसनीय हिस्सों में ट्रांज़िट के दौरान एन्क्रिप्शन की अपेक्षा करते हैं [11]।\nजब TLS \u0026ldquo;टर्मिनेट\u0026rdquo; होता है तो असल में क्या होता है TLS को टर्मिनेट करने के लिए आपको हैंडशेक पूरा करना होता है, इसलिए यह जानना ज़रूरी है कि इसमें क्या शामिल है। लोग इसे एक जादुई कदम के रूप में सोचते हैं, लेकिन यह क्लाइंट और सर्वर के बीच एक तय किया गया नृत्य है। यह रहा TLS 1.3 का प्रवाह, मोटे तौर पर [1]:\nClientHello — ब्राउज़र नमस्ते कहता है, अपने समर्थित सिफर सूट और TLS संस्करण गिनाता है, और (1.3 में) एक राउंड ट्रिप बचाने के लिए अपना की-शेयर अनुमान पहले ही डाल देता है। ServerHello — सर्वर एक सिफर सूट चुनता है, अपना की-शेयर भेजता है, और लगभग तुरंत एन्क्रिप्ट करना शुरू कर देता है। Certificate + सत्यापन — सर्वर अपने सर्टिफ़िकेट से अपनी पहचान साबित करता है; क्लाइंट उसे भरोसेमंद Certificate Authorities के विरुद्ध जाँचता है। Finished — दोनों पक्ष पुष्टि करते हैं कि उन्होंने वही सेशन कीज़ निकाली हैं, और यहाँ से सब कुछ तेज़ सिमेट्रिक क्रिप्टो से एन्क्रिप्ट होता है। TLS 1.3 यहाँ एक बड़ी बात है क्योंकि इसने हैंडशेक को दो राउंड ट्रिप से घटाकर एक कर दिया, और लौटने वाले क्लाइंट के लिए 0-RTT रिज़म्प्शन तक का समर्थन करता है [1]। अगर आपने कभी सोचा हो कि आधुनिक HTTPS साइटें सालों पहले की तुलना में ज़्यादा फुर्तीली क्यों महसूस होती हैं, तो यह दुबला हैंडशेक उसका एक बड़ा हिस्सा है। अगर आप तार पर हर फ़ील्ड देखना चाहते हैं तो The Illustrated TLS 1.3 Connection पर एक शानदार बाइट-दर-बाइट विवरण मौजूद है [12]।\nएक बार हैंडशेक खत्म हो जाने के बाद, TLS कच्ची बाइट्स नहीं भेजता — यह बातचीत को रिकॉर्ड्स में काट देता है। हर रिकॉर्ड का एक कंटेंट टाइप होता है: हैंडशेक (22), ऐप्लिकेशन डेटा (23), या अलर्ट (21) [3]। TLS 1.3 में एक बढ़िया प्राइवेसी तरकीब: असली कंटेंट टाइप एन्क्रिप्टेड पेलोड के भीतर छिपा दिया जाता है, और बाहरी हेडर हमेशा यह दावा करता है कि यह \u0026ldquo;ऐप्लिकेशन डेटा\u0026rdquo; है। तो एक नेटवर्क पर नज़र रखने वाला यह तक नहीं बता सकता कि कौन से हैंडशेक संदेश हैं और कौन सा आपका असली ट्रैफ़िक [3]। टर्मिनेशन करने वाली चीज़ को इस पूरी रिकॉर्ड मशीनरी को समझना होता है — यही ठीक वह कारण है कि यह ऐसा गैर-मामूली काम है जिसे आप केंद्रीकृत करना चाहेंगे।\nSSL बनाम TLS पर एक बात, क्योंकि ये शब्द गड़बड़ हैं आप हर जगह \u0026ldquo;SSL टर्मिनेशन\u0026rdquo; और \u0026ldquo;TLS टर्मिनेशन\u0026rdquo; को एक-दूसरे के बदले इस्तेमाल होते देखेंगे, AWS और Nginx दस्तावेज़ों समेत। तकनीकी रूप से यह गलत है, और यह वही नामकरण वाली उलझन है जो इस लेख की शुरुआत में थी।\nSSL मर चुका है। SSL के सभी संस्करण अप्रचलित और असुरक्षित हैं। IETF ने जून 2015 में SSL 3.0 को आधिकारिक रूप से खत्म कर दिया, मुख्यतः 2014 में Google के शोधकर्ताओं द्वारा खोजे गए POODLE अटैक के कारण — एक ऐसा शोषण जो हमलावर को कनेक्शन को SSL 3.0 तक नीचे गिराकर सेशन कुकीज़ को एक-एक बाइट करके डिक्रिप्ट करने देता था [13]। TLS ने इसकी जगह मज़बूत सिफर, बेहतर प्रमाणीकरण, और ठीक उन्हीं पैडिंग व रीनेगोशिएशन के छेदों के सुधार के साथ ले ली [13]।\nतो हर कोई अब भी \u0026ldquo;SSL\u0026rdquo; क्यों कहता है? निरी विरासत। यह शब्द 90 के दशक और 2000 के दशक की शुरुआत में उद्योग के दिमाग में जल कर बैठ गया, सर्टिफ़िकेट विक्रेता अब भी \u0026ldquo;SSL सर्टिफ़िकेट\u0026rdquo; बेचते हैं, और लोग \u0026ldquo;TLS\u0026rdquo; से कहीं ज़्यादा \u0026ldquo;SSL\u0026rdquo; खोजते हैं [14]। जब कोई 2026 में \u0026ldquo;SSL टर्मिनेशन\u0026rdquo; कहता है, तो उसका लगभग निश्चित रूप से मतलब TLS टर्मिनेशन होता है — नीचे का प्रोटोकॉल TLS 1.2 या 1.3 ही होता है। शब्दावली को आपको लड़खड़ाने न दें, लेकिन यह ज़रूर पक्का करें कि आपकी असली कॉन्फ़िग SSL और पुराने TLS संस्करणों को बंद कर दे। इन संस्करणों का इतिहास, अगर आप उत्सुक हों, तो The SSL Store ने बढ़िया ढंग से समझाया है [15]।\nवह सुरक्षा समझौता जिसे आप नज़रअंदाज़ नहीं कर सकते यहाँ मैं अपनी राय रखूँगा। सादा TLS टर्मिनेशन — एज पर डिक्रिप्ट, बैकएंड को प्लेनटेक्स्ट — तब तक ठीक है जब तक यह ठीक नहीं रहता। जोखिम आंतरिक हॉप का है। आपके नेटवर्क के भीतर पैर जमाए कोई भी, एक गलत-कॉन्फ़िगर सिक्योरिटी ग्रुप, या एक समझौता किया हुआ पड़ोसी सर्विस संभावित रूप से उस ट्रैफ़िक को पढ़ सकता है जिसे आपने सुरक्षित मान लिया था क्योंकि यूज़र को एक ताला दिखा था।\nबहुत सारे केवल-आंतरिक, अच्छी तरह विभाजित सेटअप के लिए, वह जोखिम स्वीकार्य है और सरलता जीत जाती है। लेकिन जैसे ही आप नियंत्रित डेटा संभाल रहे हों, इस पर फिर से सोचें:\nHIPAA अपेक्षा करता है कि इलेक्ट्रॉनिक संरक्षित स्वास्थ्य जानकारी अविश्वसनीय नेटवर्कों में एन्क्रिप्टेड रहे, केवल सार्वजनिक हॉप पर नहीं [11]। PCI-DSS और इसी तरह के ढाँचे कार्डधारक डेटा के लिए एंड टू एंड मज़बूत एन्क्रिप्शन पर ज़ोर देते हैं [11]। ज़ीरो-ट्रस्ट आर्किटेक्चर डिफ़ॉल्ट रूप से आंतरिक नेटवर्क को शत्रुतापूर्ण मानते हैं, जो प्लेनटेक्स्ट बैकएंड हॉप को पूरी तरह बाहर कर देता है। यहीं म्यूचुअल TLS (mTLS) आता है। सामान्य TLS केवल सर्वर को क्लाइंट के सामने प्रमाणित करता है। mTLS एक दूसरी जाँच जोड़ता है: क्लाइंट भी एक सर्टिफ़िकेट प्रस्तुत करता है, ताकि दोनों पक्ष क्रिप्टोग्राफ़िक रूप से साबित करें कि वे कौन हैं [16]। एक माइक्रोसर्विसेज़ मेश में, सर्विसों के बीच mTLS का मतलब है कि एक बदमाश पॉड आपकी पेमेंट सर्विस से यूँ ही बात करना शुरू नहीं कर सकता — उसके पास एक मान्य सर्टिफ़िकेट नहीं है। आपका लोड बैलेंसर क्लाइंट से आने वाले mTLS को टर्मिनेट कर सकता है और अलग से बैकएंड के लिए mTLS स्थापित कर सकता है [11]। Google Cloud, Istio, और ज़्यादातर सर्विस मेश अब इसे अपने भीतर पका कर रखते हैं [16]।\nव्यावहारिक नियम जो मैं दूँगा: तय करें कि आपकी ट्रस्ट सीमा कहाँ है, फिर अपने टर्मिनेशन बिंदु को उस सीमा पर रखें। अगर एज आपकी सीमा है, तो वहीं टर्मिनेट करें। अगर आप अपने ही नेटवर्क पर भरोसा नहीं करते, तो री-एन्क्रिप्ट करें या mTLS का इस्तेमाल करें ताकि सुरक्षित क्षेत्र पूरे रास्ते ऐप तक फैल जाए।\nसब मिलाकर अगर आपको बस कुछ चीज़ें याद रखनी हों:\nSSL/TLS एक ट्रांसपोर्ट-लेयर प्रोटोकॉल नहीं है नाम के बावजूद। यह TCP (असली ट्रांसपोर्ट) के ऊपर सवारी करता है और एक सेशन/प्रेज़ेंटेशन लेयर रैपर की तरह बर्ताव करता है। वही लेयरिंग ही टर्मिनेशन को मुमकिन बनाती है। TLS टर्मिनेशन बस वह जगह है जहाँ एन्क्रिप्शन खत्म होता है और डिक्रिप्शन होता है — आमतौर पर बैकएंड CPU बचाने, सर्टिफ़िकेट केंद्रीकृत करने, और लेयर-7 रूटिंग व निरीक्षण खोलने के लिए किसी लोड बैलेंसर या प्रॉक्सी पर धकेल दिया जाता है। तीन किस्में हैं: टर्मिनेट (प्लेनटेक्स्ट बैकएंड), पासथ्रू (एन्क्रिप्टेड बैकएंड, कोई L7 नहीं), और री-एन्क्रिप्ट (एन्क्रिप्टेड बैकएंड के साथ L7)। इस आधार पर चुनें कि आप अपने आंतरिक नेटवर्क पर भरोसा करते हैं या नहीं। \u0026ldquo;SSL\u0026rdquo; एक मरा हुआ प्रोटोकॉल है लेकिन एक ज़िंदा शब्द। जब लोग SSL टर्मिनेशन कहते हैं तो उनका मतलब TLS होता है। अगली बार जब कोई आत्मविश्वास से आपको बताए कि SSL \u0026ldquo;ट्रांसपोर्ट लेयर की चीज़\u0026rdquo; है, तो आप शालीनता से यह बता सकते हैं कि नाम मार्केटिंग है, आर्किटेक्चर नहीं — और यह फ़र्क समझना ही वह चीज़ है जो आपको साफ़-साफ़ सोचने देती है कि कहाँ टर्मिनेट करना है।\nस्रोत RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 SSL Deprecation: Why TLS took over internet security — Sectigo Transport Layer Security — Wikipedia Transport Layer Security — which layer of OSI model? — Medium What is SSL/TLS termination? — HAProxy New – TLS Termination for Network Load Balancers — AWS Understanding TLS Termination with Load Balancers in AWS — Cloudericks TLS Termination Models: Passthrough vs Termination vs Bridging — DEV Community Understanding Nginx: TLS Termination vs. TLS Passthrough — Medium 3 ways to encrypt communications with Red Hat OpenShift Is TLS Enough for HIPAA? — HIPAA Vault The Illustrated TLS 1.3 Connection: Every Byte Explained SSL vs TLS: What\u0026rsquo;s the Difference — Authgear Is SSL Deprecated? Transition from SSL to TLS — SSL Dragon SSL and TLS Versions: Celebrating 30 Years of History — The SSL Store Mutual TLS overview — Google Cloud Load Balancing ","permalink":"https://cloudmato.com/hi/posts/tls-termination-explained/","title":"TLS टर्मिनेशन की पूरी समझ (और क्या SSL वाकई ट्रांसपोर्ट लेयर है?)"},{"content":"अधिकांश डेवलपर्स जिनसे मैं बात करता हूं उनके पास टेस्टिंग के बारे में एक अस्पष्ट समझ है — वे जानते हैं कि उन्हें यह करना चाहिए, लेकिन वे हमेशा स्पष्ट नहीं होते कि कौन से टेस्ट क्या करते हैं और क्यों यह महत्वपूर्ण है। इसलिए आप यहां एक यूनिट टेस्ट लिखते हैं, वहां कुछ मैनुअल क्लिक करते हैं, और आशा करते हैं कि सब कुछ काम करे। यह कोई रणनीति नहीं है। टेस्टिंग के विभिन्न प्रकार अलग-अलग उद्देश्यों के लिए हैं।\nआइए मैं आपको बताता हूं कि प्रत्येक टेस्टिंग प्रकार वास्तव में क्या करता है और, अधिक महत्वपूर्ण रूप से, कौन सी टेस्टिंग कंपनियां वास्तव में लागू करती हैं बनाम कौन सी अच्छी-सुंदर सिद्धांत है।\nटेस्टिंग पिरामिड व्यक्तिगत प्रकारों में गोता लगाने से पहले, मानसिक मॉडल को समझें। अधिकांश कंपनियां एक टेस्टिंग पिरामिड का पालन करती हैं: आधार पर बहुत सारी यूनिट टेस्ट (तेज, सस्ती), बीच में कुछ इंटीग्रेशन टेस्ट (धीमा, अधिक जटिल), और शीर्ष पर कुछ एंड-टू-एंड टेस्ट (सबसे धीमा, सबसे नाजुक)। [1]\nयूनिट टेस्टिंग यूनिट टेस्ट अलगाव में व्यक्तिगत फ़ंक्शन या विधियों की जांच करते हैं। एक डेवलपर एक टेस्ट लिखता है जो सत्यापित करता है कि दिए गए इनपुट के लिए कोड का एक विशिष्ट टुकड़ा अपेक्षित आउटपुट उत्पन्न करता है। [2]\nउदाहरण के लिए, यदि आपके पास एक फ़ंक्शन है जो कीमत पर कर की गणना करता है, तो एक यूनिट टेस्ट सत्यापित करता है कि calculateTax(100, 0.1) बिल्कुल 10 लौटाता है। कुछ और नहीं — डेटाबेस शामिल नहीं है, API को कॉल नहीं किया जाता है, UI रेंडर नहीं होता है।\nयह क्यों महत्वपूर्ण है: यूनिट टेस्ट जल्दी बग पकड़ते हैं। डेवलपर्स उन्हें कोड करते समय लिखते हैं, इसलिए टूटा हुआ लॉजिक तुरंत सामने आता है न कि घंटों बाद जब यह QA तक पहुंचता है।\nटूल उदाहरण: Jest (JavaScript), pytest (Python), JUnit (Java), NUnit (C#)।\nइंटीग्रेशन टेस्टिंग इंटीग्रेशन टेस्ट सत्यापित करते हैं कि विभिन्न यूनिट्स एक साथ काम करते हैं। यूनिट टेस्ट के विपरीत, इंटीग्रेशन टेस्ट घटकों को एक दूसरे से बात करने देते हैं — आपका कोड अब डेटाबेस को हिट कर सकता है, एक API को कॉल कर सकता है, या कैश के साथ इंटरैक्ट कर सकता है। [3]\nउदाहरण: एक यूनिट टेस्ट सत्यापित करता है कि आपका डेटा ट्रांसफॉर्मेशन फ़ंक्शन काम करता है। एक इंटीग्रेशन टेस्ट सत्यापित करता है कि आपका फ़ंक्शन सही तरीके से डेटाबेस से डेटा पढ़ता है और इसे ट्रांसफॉर्म करता है।\nयह क्यों महत्वपूर्ण है: घटक व्यक्तिगत रूप से ठीक काम करते हैं लेकिन एक साथ विफल हो जाते हैं। इंटीग्रेशन टेस्ट उन सीमांत समस्याओं को पकड़ते हैं।\nसामान्य इंटीग्रेशन परिदृश्य:\nकोड + डेटाबेस प्रश्न कोड + बाहरी API माइक्रोसर्विसेस एक दूसरे से बात कर रहे हैं फ्रंटएंड बैकएंड से बात कर रहा है स्मोक टेस्टिंग स्मोक टेस्टिंग तेज, उथली, और महत्वपूर्ण है। यह एक सवाल का जवाब देता है: क्या बिल्ड बिल्कुल काम करता है? [2]\nऐप चलाएं। मुख्य प्रवाह पर क्लिक करें। क्या आप लॉगिन कर सकते हैं? क्या आप डैशबोर्ड को नेविगेट कर सकते हैं? क्या चेकआउट बटन मौजूद है? यदि इनमें से कोई विफल हो, तो बिल्ड टूट गया है और आप रुक जाते हैं — एक टूटी हुई नींव पर विस्तृत टेस्ट चलाने का कोई मतलब नहीं है।\nस्मोक टेस्टिंग को एक \u0026ldquo;बिल्ड स्थिरता गेट\u0026rdquo; के रूप में सोचें। यह किसी भी गंभीर QA कार्य से पहले होता है। यदि यह विफल हो, तो डेवलपर्स को तुरंत इसे वापस मिल जाता है।\nयह क्यों महत्वपूर्ण है: यह समय बचाता है। रिग्रेशन और स्वीकृति टेस्टिंग महंगे हैं। यदि बेसिक ऐप मर चुका है तो उन्हें चलाने का कोई मतलब नहीं है।\nविशिष्ट स्मोक टेस्ट उदाहरण:\nलॉगिन और लॉगआउट करें मुख्य पृष्ठ लोड करें मुख्य सुविधाओं को नेविगेट करें बुनियादी CRUD संचालन (बनाएं, पढ़ें, अपडेट करें, हटाएं) रिग्रेशन टेस्टिंग रिग्रेशन टेस्टिंग कोड परिवर्तनों के बाद मौजूदा टेस्ट को दोहराती है यह सुनिश्चित करने के लिए कि आपने कुछ भी नहीं तोड़ा है जो पहले से काम कर रहा था। [2] [4]\nआप भुगतान मॉड्यूल में एक बग को ठीक करते हैं। अब आप सभी पुरानी टेस्ट चलाते हैं जो भुगतान, चेकआउट, ऑर्डर इतिहास, सूचनाएं — सब कुछ जो उस मॉड्यूल को छूता है या उसपर निर्भर करता है को कवर करता है। यदि कुछ टूटता है, तो रिग्रेशन ने इसे प्रोडक्शन से पहले पकड़ लिया है।\nयह क्यों महत्वपूर्ण है: जैसे-जैसे कोडबेस बढ़ता है, संभावित क्षति का सतह क्षेत्र बढ़ता है। रिग्रेशन टेस्टिंग वह है जिससे आप पुराने कोड को बदलते समय आत्मविश्वास के साथ कर सकते हैं।\nमुख्य अंतर्दृष्टि: रिग्रेशन टेस्टिंग आमतौर पर स्वचालित होती है क्योंकि आप एक ही टेस्ट बार-बार चला रहे हैं। यह वह है जहां टेस्ट ऑटोमेशन टूल्स चमकते हैं।\nस्वीकृति टेस्टिंग स्वीकृति टेस्टिंग का उत्तर देता है: क्या यह सॉफ्टवेयर वह करता है जो व्यवसाय ने मांगा था? [5]\nतकनीकी टेस्टिंग के विपरीत, स्वीकृति टेस्टिंग व्यावसायिक हितधारकों के स्वामित्व में है — प्रोडक्ट मैनेजर, व्यावसायिक विश्लेषक, कभी-कभी ग्राहक स्वयं। वे आवश्यकताओं की जानकारी के दौरान स्वीकृति मानदंड को परिभाषित करते हैं, और टेस्टर्स सत्यापित करते हैं कि सॉफ्टवेयर उन मानदंडों को पूरा करता है।\nउदाहरण: आवश्यकता यह है कि \u0026ldquo;उपयोगकर्ता कीमत और श्रेणी द्वारा उत्पादों को फ़िल्टर कर सकते हैं।\u0026rdquo; स्वीकृति टेस्टिंग पुष्टि करती है कि वह सुविधा तकनीकी आर्किटेक्चर दृष्टिकोण से नहीं बल्कि उपयोगकर्ता के दृष्टिकोण से अपेक्षित रूप से काम करती है।\nमुख्य अंतर: यूनिट, इंटीग्रेशन, और स्मोक टेस्ट डेवलपर्स या QA द्वारा चलाई जाती हैं। स्वीकृति टेस्ट व्यावसायिक उपयोगकर्ताओं या व्यावसायिक उपयोगकर्ताओं के साथ काम करने वाले QA द्वारा चलाई जाती हैं।\nएंड-टू-एंड टेस्टिंग (E2E) एंड-टू-एंड टेस्टिंग संपूर्ण एप्लिकेशन के माध्यम से वास्तविक उपयोगकर्ता यात्राओं का अनुकरण करता है। [5]\nएक उपयोगकर्ता ऐप खोलता है → उत्पादों को ब्राउज करता है → कार्ट में आइटम जोड़ता है → चेकआउट करता है → पुष्टि प्राप्त करता है → एक ईमेल प्राप्त करता है। E2E टेस्ट यह पूरी प्रवाह सत्यापित करते हैं कि काम करता है, सभी प्रणालियों सहित (फ्रंटएंड, बैकएंड, डेटाबेस, भुगतान गेटवे, ईमेल सेवा)।\nयह क्यों महत्वपूर्ण है: यूनिट टेस्ट पास हो सकते हैं, इंटीग्रेशन टेस्ट पास हो सकते हैं, लेकिन यदि उपयोगकर्ता यात्रा टूटती है, तो और कुछ महत्वपूर्ण नहीं है।\nवास्तविक उदाहरण: एक ई-कॉमर्स साइट। यूनिट टेस्ट कीमत कैलकुलेटर को जांचता है। इंटीग्रेशन टेस्ट जांचता है कि कीमतें डेटाबेस से लोड होती हैं। E2E टेस्ट वास्तव में एंड-टू-एंड एक उत्पाद खरीदता है और पुष्टि करता है कि ऑर्डर उपयोगकर्ता के खाते में दिखाई देता है और एक ईमेल भेजा जाता है।\nप्रदर्शन टेस्टिंग प्रदर्शन टेस्टिंग लोड के तहत गति, स्थिरता, और संसाधन उपयोग को मापता है। [5]\nविशिष्ट पहलु:\nप्रतिक्रिया समय: एक अनुरोध को कितना समय लगता है? थ्रूपुट: सिस्टम प्रति सेकंड कितने अनुरोध को संभाल सकता है? स्केलेबिलिटी: क्या यह 10 उपयोगकर्ताओं को संभाल सकता है? 1000? 10,000? संसाधन उपयोग: लोड के तहत CPU, मेमोरी, डेटाबेस कनेक्शन। प्रदर्शन टेस्टिंग केवल \u0026ldquo;क्या यह तेज है?\u0026rdquo; नहीं है — यह \u0026ldquo;क्या यह वास्तविक लोड के तहत स्थिर और तेज रहता है?\u0026rdquo; है।\nसिस्टम टेस्टिंग और अन्य प्रकार इसके बाहर, आप का सामना करेंगे:\nटेस्ट प्रकार यह क्या जांचता है कौन चलाता है सिस्टम टेस्टिंग आवश्यकताओं के विरुद्ध पूर्ण एकीकृत सिस्टम QA टीम सुरक्षा टेस्टिंग कमजोरियां, डेटा एक्सपोजर, प्रमाणीकरण त्रुटियां सुरक्षा टीम या विशेष QA उपयोगिता टेस्टिंग क्या UI सहज है? क्या उपयोगकर्ता समझते हैं कि इसका उपयोग कैसे करें? QA या वास्तविक उपयोगकर्ता API टेस्टिंग क्या API कॉन्ट्रैक्ट काम करता है? क्या प्रतिक्रियाएं सही हैं? डेवलपर्स या QA डेटाबेस टेस्टिंग डेटा अखंडता, क्वेरी प्रदर्शन, बैकअप/रिकवरी QA या DBA कंपनियां वास्तव में कौन सी टेस्टिंग लागू करती हैं? सिद्धांत एक चीज है। व्यवहार दूसरा है। यहां वास्तविक कंपनियों के सर्वेक्षण से पता चलता है: [6] [7] [8]\nअधिकांश कंपनियां उपयोग करती हैं:\nयूनिट टेस्टिंग (व्यापक रूप से अपनाई गई, विशेष रूप से agile/DevOps दुकानों में) रिग्रेशन टेस्टिंग (53% कंपनियों ने इसे स्वचालित किया) इंटीग्रेशन टेस्टिंग (45% कंपनियां स्वचालित इंटीग्रेशन टेस्टिंग का उपयोग करती हैं) स्मोक टेस्टिंग (तेज जीत, उच्च ROI) API टेस्टिंग (56% कंपनियां, माइक्रोसर्विसेस के लिए महत्वपूर्ण) प्रदर्शन टेस्टिंग (40% कंपनियां इसका उपयोग करती हैं) कम सामान्य:\nस्वीकृति टेस्टिंग (अक्सर होता है लेकिन हमेशा औपचारिक रूप से संरचित नहीं) एंड-टू-एंड टेस्टिंग (महंगा, धीमा, नाजुक, इसलिए न्यूनतम रखा जाता है) सुरक्षा टेस्टिंग (उद्योग पर निर्भर; fintech/healthcare के लिए महत्वपूर्ण, स्टार्टअप द्वारा अनदेखा) ऑटोमेशन विभाजन: कंपनियां लगभग 50:50 मैनुअल से स्वचालित टेस्टिंग के लिए प्रयास करती हैं, हालांकि कई 75% ऑटोमेशन की ओर बढ़ रहे हैं। [6] लगभग 77% कंपनियों के पास कुछ स्वचालित टेस्टिंग जगह में है। [6]\nवास्तविक चित्र: आपकी टेस्ट सूट में वास्तव में क्या है? यदि आप एक विशिष्ट मध्य-आकार की टेक कंपनी में हैं, तो आपकी टेस्टिंग संभवतः इस तरह दिखती है:\nडेवलपर्स यूनिट टेस्ट लिखते हैं जैसे-जैसे वे कोड करते हैं (शायद 70% कवरेज, शायद 30% — अनुशासन पर निर्भर करता है) CI/CD पाइपलाइन यूनिट + इंटीग्रेशन टेस्ट चलाती है प्रत्येक कमिट पर स्वचालित रूप से स्मोक टेस्ट चलते हैं बिल्ड को गेट करने के लिए QA रिग्रेशन टेस्ट चलाता है रिलीज से पहले (कई स्वचालित, कुछ मैनुअल) एंड-टू-एंड टेस्ट मौजूद हैं लेकिन न्यूनतम रखे जाते हैं क्योंकि वे धीमे और नाजुक होते हैं मैनुअल टेस्टिंग खोजपूर्ण टेस्टिंग, किनारे केस, और चीजें जो ऑटोमेशन आसानी से नहीं कर सकता (जैसे \u0026ldquo;क्या यह सही दिखता है?\u0026rdquo;) के लिए होती है। स्टार्टअप अक्सर चरण 5 और 6 को छोड़ देते हैं। एंटरप्राइज दुकानें स्वीकृति टेस्टिंग को औपचारिक करती हैं। सुरक्षा-महत्वपूर्ण उद्योग (fintech, healthcare) सुरक्षा और अनुपालन टेस्टिंग जोड़ते हैं।\nनिचला पंक्ति: कोई कंपनी सब कुछ टेस्ट नहीं करती है। आप जोखिम, गति, और लागत के आधार पर प्राथमिकता देते हैं। यूनिट टेस्ट सस्ते और तेज होते हैं — आप उनमें से बहुत लिखते हैं। E2E टेस्ट महंगे और धीमे होते हैं — आप बस महत्वपूर्ण पथों को कवर करने के लिए पर्याप्त लिखते हैं।\nस्रोत Types of Software Testing - GeeksforGeeks Functional Testing Types: Unit, Sanity, Smoke, and More | Perforce BlazeMeter The different types of testing in software | Atlassian Smoke Testing vs. Regression Testing: Key Differences - Ranorex Unit Testing vs End To End Testing – Key Differences 32 Software Testing Statistics for Your Presentation in 2025 Latest Software Testing Statistics (2026 Edition) Software Test Automation Statistics and Trends for 2025 | DogQ ","permalink":"https://cloudmato.com/hi/posts/types-of-software-testing-guide/","title":"सॉफ्टवेयर टेस्टिंग के सभी प्रकार समझाए गए"},{"content":"हर कोई SOLID सिद्धांतों के बारे में बात करता है। आपका सीनियर डेवलपर कोड रिव्यू में उनका जिक्र करता है। आपके आर्किटेक्चर दस्तावेज़ उनका संदर्भ देते हैं। लेकिन असली परियोजनाएं अनरक्षणीय कूड़े क्यों बन जाती हैं भले ही टीमें SOLID को \u0026ldquo;जानती\u0026rdquo; हों? उत्तर: SOLID को समझना और वास्तव में इसके साथ निर्माण करना दो बिल्कुल अलग चीजें हैं [1]।\nअधिकांश डेवलपर्स SOLID के बारे में जल्दी सीखते हैं, सिर हिलाते हैं, फिर जैसे ही कोई समय सीमा आती है ये सिद्धांतों का तुरंत उल्लंघन करते हैं। मुझे आपको दिखाने दें कि समस्या कहां शुरू होती है — और यह सुनने में जितना कठिन लगता है उससे कहीं अधिक कठिन क्यों है।\nSOLID क्या है, और आपको इसकी परवाह क्यों करनी चाहिए? SOLID पाँच डिज़ाइन सिद्धांत हैं जो कसे युग्मन को कम करते हैं और कोड रखरखाव में सुधार करते हैं [1]। संक्षिप्त नाम निम्नलिखित के लिए खड़ा है:\nS (एकल जिम्मेदारी सिद्धांत) — एक वर्ग के परिवर्तन का केवल एक कारण होना चाहिए O (खुला/बंद सिद्धांत) — वर्ग विस्तार के लिए खुले होने चाहिए, संशोधन के लिए बंद L (Liskov प्रतिस्थापन सिद्धांत) — उप-प्रकार अपने आधार प्रकारों के लिए प्रतिस्थापित होने योग्य होने चाहिए I (इंटरफेस विभाजन सिद्धांत) — क्लाइंट्स को उन इंटरफेस पर निर्भर नहीं होना चाहिए जिनका वे उपयोग नहीं करते D (निर्भरता व्युत्क्रमण सिद्धांत) — ठोस कार्यान्वयन पर नहीं, अमूर्तताओं पर निर्भर करें इन सिद्धांतों के बिना, कोडबेस कठोर हो जाता है। एक स्थान पर एक परिवर्तन पाँच अन्य स्थानों को तोड़ देता है। नई सुविधाओं के लिए विरासत कोड को छूना आवश्यक होता है जो \u0026ldquo;काम करता है लेकिन कोई इसे छूना नहीं चाहता\u0026rdquo;। परीक्षण लिखना असंभव हो जाता है। अधिकांश परियोजनाएं यहीं रहती हैं [2]।\nSOLID के साथ, आपका कोडबेस साँस लेता है। परिवर्तन अलग-थलग रहते हैं। नई सुविधाएं प्रणाली में नहीं फैलती। परीक्षण अलगाव में चलते हैं। नए डेवलपर्स को ऑनबोर्ड करने के लिए 10 साल पुराने कोड की पुरातात्विक खोज की आवश्यकता नहीं होती।\nवास्तविक-दुनिया उल्लंघन: SOLID कहां गायब है भगवान वर्ग — सब कुछ एक जगह में मैंने यह सैकड़ों बार देखा है। एक UserManager वर्ग जो उपयोगकर्ता डेटा, ईमेल भेजना, पासवर्ड हैशिंग, लॉगिंग, भुगतान प्रसंस्करण, और प्रमाणीकरण को संभालता है। सब कुछ एक फाइल में। सब कुछ उलझा हुआ [3]।\nclass UserManager { public void createUser(String email, String password) { validateEmail(email); hashPassword(password); saveToDatabase(email, password); sendWelcomeEmail(email); logUserCreation(email); chargeSignupFee(email); trackAnalyticsEvent(email); } private void sendWelcomeEmail(String email) { /* ... */ } private void saveToDatabase(String email, String password) { /* ... */ } private void chargeSignupFee(String email) { /* ... */ } // 50 more methods doing unrelated things } यह एकल जिम्मेदारी सिद्धांत का पूर्ण उल्लंघन है। ईमेल भेजने का तरीका बदलना चाहते हैं? आप UserManager को संशोधित करते हैं। भुगतान लॉजिक बदलना चाहते हैं? आप UserManager को संशोधित करते हैं। नया लॉग प्रारूप जोड़ना चाहते हैं? आप UserManager को संशोधित करते हैं। अब आप भुगतान कोड का परीक्षण कर रहे हैं जब आप केवल स्वागत ईमेल टेम्पलेट को ट्विक करना चाहते थे।\nफिक्स: अलग-अलग वर्गों में विभाजित करें [1]। एक उपयोगकर्ता दृढ़ता को संभालता है। दूसरा ईमेल भेजता है। तीसरा भुगतान प्रसंस्करण करता है। चौथा लॉगिंग को संभालता है। अब प्रत्येक वर्ग के परिवर्तन का केवल एक कारण है।\nकसा युग्मन — भुगतान प्रणाली समस्या आप कोड लिखते हैं जो सीधे एक विशिष्ट भुगतान प्रदाता पर निर्भर करता है: StripePaymentProcessor। यह काम करता है। आपका व्यवसाय बढ़ता है। अब आप PayPal का समर्थन करना चाहते हैं। या क्रिप्टोकरेंसी। या कुछ नई स्थानीय भुगतान प्रणाली [4]।\nclass OrderService { private StripePaymentProcessor stripe = new StripePaymentProcessor(); public void processOrder(Order order) { // ... validation code ... stripe.charge(order.getAmount()); } } PayPal समर्थन जोड़ने के लिए, आप OrderService को संशोधित करते हैं। क्रिप्टो जोड़ने के लिए, आप इसे फिर से संशोधित करते हैं। आप हर भुगतान प्रदाता के लिए व्यावसायिक तर्क कोड को संशोधित कर रहे हैं। यह खुला/बंद सिद्धांत का उल्लंघन करता है — आपका कोड विस्तार के लिए खुला होना चाहिए (नई भुगतान प्रकार) लेकिन संशोधन के लिए बंद [2]।\nफिक्स: एक अमूर्तता पर निर्भर करें:\ninterface PaymentGateway { void charge(BigDecimal amount); } class OrderService { private PaymentGateway gateway; public OrderService(PaymentGateway gateway) { this.gateway = gateway; } public void processOrder(Order order) { gateway.charge(order.getAmount()); } } PayPal जोड़ना? PayPalPaymentGateway बनाएं, इसे इंजेक्ट करें, हो गया। आपका OrderService कभी नहीं बदलता [4]।\nफैट इंटरफेस — अप्रयुक्त विधियों के कार्यान्वयन को मजबूर करना आप एक इंटरफेस बनाते हैं जो \u0026ldquo;व्यापक\u0026rdquo; है:\ninterface PaymentProcessor { void charge(BigDecimal amount); void refund(BigDecimal amount); void setupRecurringPayment(BigDecimal amount, Frequency frequency); void validateCard(String cardNumber); void handleChargebackDispute(String transactionId); } फिर एक CryptoCurrencyPayment वर्ग इस इंटरफेस को लागू करता है। सिवाय क्रिप्टो आवर्ती भुगतान नहीं करता। यह चार्जबैक नहीं करता। डेवलपर्स आधी विधियों के लिए NotImplementedException फेंकने के लिए मजबूर हैं [3]।\nयह इंटरफेस विभाजन सिद्धांत का उल्लंघन करता है। इसके बजाय छोटे, केंद्रित इंटरफेस बनाएं:\ninterface Chargeable { void charge(BigDecimal amount); } interface Refundable { void refund(BigDecimal amount); } interface RecurringBillable { void setupRecurring(BigDecimal amount); } अब CryptoCurrencyPayment केवल Chargeable को लागू करता है। कोई नकली कार्यान्वयन नहीं। कोई भ्रम नहीं [3]।\nSOLID सिद्धांतों का पालन करना क्यों इतना मुश्किल है नियमों को याद रखने की तुलना में यह समझना अधिक महत्वपूर्ण है कि हम SOLID का उल्लंघन क्यों करते हैं।\nसमय सीमा जाल आप स्प्रिंट के 9वें दिन हैं 10-दिनों की स्प्रिंट में से। सुविधा पूरी होनी चाहिए। आप UserManager वर्ग को रीफैक्टर कर सकते हैं, इसे सही ढंग से विभाजित कर सकते हैं, निर्भरताओं को इंजेक्ट कर सकते हैं। या आप 5 मिनट में मौजूदा वर्ग में एक विधि जोड़ सकते हैं।\nआप विधि जोड़ते हैं [5]।\nकल, एक और समय सीमा। मौजूदा वर्ग में एक और छोटा जोड़। सप्ताह दो तक, आपने SOLID का इतनी बार उल्लंघन किया है कि इसे ठीक करने में दिन लगेंगे। महीने दो तक, कोई भी उस कोड को छूने की हिम्मत नहीं करता। यह है कि कैसे अधिकांश परियोजनाएं समाप्त होती हैं। न क्योंकि डेवलपर्स आलसी हैं। क्योंकि समय सीमा वास्तविक हैं और रीफैक्टरिंग आगे समय लागत करती है।\nसिद्धांतों की अस्पष्टता एकल जिम्मेदारी सरल लगता है: परिवर्तन का एक कारण। लेकिन \u0026ldquo;एक कारण\u0026rdquo; क्या है? क्या ईमेल और पासवर्ड सत्यापन के साथ एक User वर्ग एक या दो जिम्मेदारी है? क्या चार्ज और रिफंड दोनों को संभालने वाली Payment वर्ग एक जिम्मेदारी है? [5]\nविभिन्न डेवलपर्स इसे अलग तरह से व्याख्यायित करते हैं। मैंने टीमों को देखा है जो उपयोगकर्ता ईमेल को पाँच अलग-अलग वर्गों में विभाजित करते हैं (अत्यधिक इंजीनियरिंग)। मैंने अन्य टीमों को एक वर्ग में 50 विधियाँ डालते देखा है (कम इंजीनियरिंग)। कोई चमकदार रेखा नहीं है।\nअत्यधिक इंजीनियरिंग और अत्यधिक अमूर्तता जूनियर डेवलपर्स SOLID के बारे में पढ़ते हैं और पागल हो जाते हैं। वे हर समस्या पर हर सिद्धांत को लागू करते हैं। एक सरल फॉर्म सत्यापन वर्ग को तीन अमूर्त वर्गों, दो इंटरफेस, और एक निर्भरता इंजेक्शन कंटेनर में रीफैक्टर किया जाता है [5]।\nकोड पढ़ने में कठिन हो जाता है, आसान नहीं। आप जो तीन पंक्तियों का तर्क होना चाहिए उसे समझने के लिए पाँच फाइलों के बीच कूदने की आवश्यकता है। आपका टेस्ट सूट वास्तविक कोड से अधिक जटिल हो जाता है।\nSOLID सिद्धांत उपकरण हैं, कानून नहीं। एक सरल स्क्रिप्ट को SOLID की जरूरत नहीं है। एक उपयोगिता फंक्शन को SOLID की जरूरत नहीं है। एक बार का डेटा प्रसंस्करण कार्य को SOLID की जरूरत नहीं है। SOLID उन कोडबेस के लिए महत्वपूर्ण है जो वर्षों तक रहेंगे और निरंतर परिवर्तन की आवश्यकता होगी [5]।\nटीम संरेखण मुश्किल है भले ही आपकी टीम SOLID का पालन करने के लिए सहमत हो, इसकी व्याख्या निरंतर बहस का स्रोत है [5]।\nसीनियर डेवलपर कहता है: \u0026ldquo;इस वर्ग के बहुत अधिक विधियाँ हैं, इसे विभाजित करें।\u0026rdquo; जूनियर डेवलपर कहता है: \u0026ldquo;लेकिन यह सब भुगतान से संबंधित है, एक साथ होना चाहिए।\u0026rdquo; आर्किटेक्ट कहता है: \u0026ldquo;आप दोनों यहां इंटरफेस विभाजन समस्या के बारे में नहीं सोच रहे हैं।\u0026rdquo; छह महीने में, आपका कोडबेस तीन अलग-अलग लोगों की तरह दिखता है जिन्होंने SOLID की तीन अलग-अलग व्याख्याओं के साथ इसे लिखा है। कोड रिव्यू सुविधाओं को शिप करने के बजाय सिद्धांतों पर बहस करने के बारे में हो जाता है।\nविरासत कोड रीफैक्टर करना महंगा है अधिकांश परियोजनाएं स्वच्छ रूप से शुरू नहीं होती। वे एक फाइल के साथ सब कुछ करना शुरू करते हैं। फिर यह बढ़ता है। फिर SOLID महत्वपूर्ण हो जाता है। फिर इसे रीफैक्टर करना एक दुःस्वप्न हो जाता है।\nआप केवल UserManager वर्ग को विभाजित नहीं कर सकते। इसके पास पूरे कोडबेस में 500 निर्भरताएं हैं। डेटाबेस कनेक्शन स्ट्रिंग्स कोडित। कॉन्फ़िगरेशन बेक किया हुआ। वैश्विक स्थिति हर जगह बिखरी हुई [5]।\nइसे \u0026ldquo;सही ढंग से\u0026rdquo; रीफैक्टर करना 200 फाइलों को छूना मतलब है। कुछ तोड़ने का जोखिम अधिक है। आपके परीक्षण (यदि वे मौजूद हैं) धीमे और नाजुक हैं क्योंकि वे God वर्ग पर निर्भर हैं।\nक्यों परियोजनाओं को अभी भी SOLID की जरूरत है इन सभी चुनौतियों के बावजूद, जो परियोजनाएं SOLID का पालन करती हैं वे नाटकीय रूप से बनाए रखना आसान होती हैं [1]। यह बात है: आप SOLID का उल्लंघन करने की पीड़ा पहले कुछ महीनों के लिए महसूस नहीं करते। आप एक साल बाद महसूस करते हैं।\nएक साल बाद God वर्ग में सुविधाएं जोड़ने के बाद, वह एक भुगतान प्रसंस्करण विधि अब 200 पंक्तियों लंबी है। यह तीन अलग-अलग भुगतान प्रदाताओं, विरासत भुगतान प्रकारों, और एक VIP उपयोगकर्ता स्तर प्रणाली के लिए किनारे के मामलों को संभालता है। जब आपको चौथा प्रदाता जोड़ने की आवश्यकता होती है, तो आप इस विधि को बदलने से डरते हैं।\nएक साल बाद कसे युग्मन के बाद, डेटाबेस परत को रीफैक्टर करने का मतलब 50 फाइलों को छूना है। एक साल बाद फैट इंटरफेस के बाद, नया कार्यान्वयन जोड़ने के लिए पाँच वर्गों में स्टब विधियाँ लिखनी पड़ती हैं।\nSOLID आगे महंगा है। यह लंबी अवधि में सस्ता है।\nजो परियोजनाएं इस सबक को कभी नहीं सीखीं वे \u0026ldquo;विरासत कोड\u0026rdquo; के साथ समाप्त होती हैं जिसे परिवर्तित नहीं किया जा सकता क्योंकि यह बहुत जोखिम भरा है। नई सुविधाएं हफ्तों के बजाय दिन लगते हैं। सरल बग फिक्स को छह उलझे हुए वर्गों को समझने की आवश्यकता होती है। तब लोग पूरी प्रणाली को फिर से लिखते हैं (जो लगभग कभी समाधान नहीं होता)।\nEnd\nस्रोत SOLID सिद्धांत वास्तविक जीवन उदाहरणों के साथ - GeeksforGeeks SOLID डिज़ाइन सिद्धांत समझाए गए: बेहतर सॉफ्टवेयर आर्किटेक्चर बनाना - DigitalOcean SOLID डिज़ाइन सिद्धांत: एकल जिम्मेदारी समझाया - Stackify Java में निर्भरता व्युत्क्रमण सिद्धांत - Baeldung SOLID डिज़ाइन सिद्धांतों का उपयोग करते समय 5 समस्याएं - Better Programming ","permalink":"https://cloudmato.com/hi/posts/solid-principles-real-world-examples/","title":"SOLID सिद्धांत क्यों महत्वपूर्ण हैं और डेवलपर्स उन्हें क्यों छोड़ देते हैं"},{"content":"अधिकांश डेवलपर सभी indexes को एक साथ मिला देते हैं — \u0026ldquo;बस कुछ जो queries को तेज़ बनाता है\u0026rdquo; — यह समझे बिना कि Elasticsearch और Oracle DB बिल्कुल अलग समस्याओं को हल कर रहे हैं। वे समान डेटा को मौलिक रूप से विपरीत तरीकों से index करते हैं, और यह अंतर उनके प्रदर्शन के बारे में सब कुछ निर्धारित करता है।\nमुझे आपको दिखाने दीजिए कि Oracle पर पूर्ण-पाठ खोज कठिन क्यों लगती है, जबकि Elasticsearch इसे सरल बना देता है।\nमूल समस्या: दो अलग-अलग उपयोग के मामले Oracle डेटाबेस ऐसे प्रश्नों का उत्तर देने के लिए बनाए गए हैं: \u0026ldquo;मुझे वह पंक्ति दें जहाँ user_id = 5\u0026rdquo; या \u0026ldquo;सभी आदेश खोजें जनवरी 1 और जनवरी 31 के बीच।\u0026rdquo; सटीक मिलान और range queries। डेटा संरचित है, कॉलम द्वारा indexed है, और queries आमतौर पर सटीक होती हैं।\nElasticsearch इसके लिए बनाया गया था: \u0026ldquo;मुझे सभी दस्तावेज़ खोजें जिनमें \u0026lsquo;microservices\u0026rsquo; या \u0026lsquo;distributed systems\u0026rsquo; शामिल हैं, और उन्हें प्रासंगिकता के अनुसार रैंक करें।\u0026rdquo; बड़े पैमाने पर पूर्ण-पाठ खोज। डेटा अव्यवस्थित हो सकता है, queries अस्पष्ट हैं, और उपयोगकर्ता परिणामों को प्रासंगिकता के अनुसार क्रमबद्ध देखने की अपेक्षा करते हैं, केवल लौटाया जाना नहीं।\nये केवल विभिन्न उपयोग के मामले नहीं हैं — ये विपरीत उपयोग के मामले हैं। Oracle एक के लिए डिज़ाइन किया गया दूसरे के लिए पूछने पर विफल हो जाता है।\nOracle का B-Tree: सटीकता के लिए निर्मित Oracle B-tree (balanced tree) indexes का उपयोग करता है। ये कैसे काम करते हैं [1]:\nB-tree एक क्रमबद्ध, sorted structure है। एक balanced tree को उल्टा किया गया कल्पना करें। शीर्ष पर branch blocks (interior nodes) हैं जो आपकी खोज को निर्देशित करते हैं। नीचे leaf blocks हैं जो actual key values और ROWIDs (table में rows का physical location) को store करते हैं।\nजब आप किसी value की खोज करते हैं, तो डेटाबेस tree के नीचे जाता है: branch block → branch block → leaf block → मिल गया। tree की depth उथली है (आमतौर पर लाखों rows के लिए भी 2-4 levels), इसलिए lookups बेहद तेज़ हैं — tree की height के जितने disk reads।\nप्रत्येक leaf block अगले और पिछले leaf blocks को sorted order में point करता है [1]। यह Oracle को range scans efficiently करने देता है। क्या आपको 100 से 200 तक IDs वाले सभी users चाहिए? एक बार पहला मिल जाने के बाद, linked leaf blocks के माध्यम से आगे बढ़ें। कोई jumping around नहीं।\nकीमत? B-trees एक बार में एक कॉलम के लिए निर्मित हैं (जब तक आप composite indexes का उपयोग न करें)। वे lookups के लिए optimized हैं, \u0026ldquo;इस शब्द को containing कुछ भी खोजें\u0026rdquo; के लिए नहीं।\nElasticsearch का उल्टा Index: खोज के लिए निर्मित Elasticsearch कुछ बिल्कुल अलग उपयोग करता है: एक उल्टा index [2]। और यहाँ key insight है — यह उल्टा है कि हम सामान्यतः डेटा के बारे में कैसे सोचते हैं।\nसामान्य तरीका: दस्तावेज़ → उस दस्तावेज़ में शब्दों की list।\nउल्टा तरीका: शब्द → उस शब्द को containing दस्तावेज़ों की list।\nयहाँ एक concrete example है। मान लीजिए आपके पास तीन दस्तावेज़ हैं:\nDoc 1: \u0026ldquo;Elasticsearch तेज़ है\u0026rdquo; Doc 2: \u0026ldquo;Oracle एक डेटाबेस है\u0026rdquo; Doc 3: \u0026ldquo;Elasticsearch और Oracle डेटाबेस हैं\u0026rdquo; एक उल्टा index इसे इस प्रकार store करता है:\nशब्द दस्तावेज़ elasticsearch [1, 3] तेज़ [1] oracle [2, 3] डेटाबेस [2, 3] है [1, 2, 3] सभी दस्तावेज़ खोजने के लिए जिनमें \u0026ldquo;elasticsearch\u0026rdquo; या \u0026ldquo;oracle\u0026rdquo; शामिल हैं, index बस दोनों terms को lookup करता है और उनकी document lists को merge करता है। कोई table scan नहीं। कोई हर दस्तावेज़ की जांच नहीं। तुरंत।\nOracle ऐसा efficiently नहीं कर सकता क्योंकि इसने दस्तावेज़ों को document ID से index किया है, उनके अंदर के शब्दों से नहीं। पूर्ण-पाठ खोज एक full table scan बन जाती है [3]।\nElasticsearch वास्तव में डेटा को कैसे Index करता है Elasticsearch में indexing एक simple उल्टे index से अधिक complex है [4]:\nपाठ को tokenize किया जाता है — \u0026ldquo;Elasticsearch तेज़ है\u0026rdquo; [\u0026ldquo;elasticsearch\u0026rdquo;, \u0026ldquo;तेज़\u0026rdquo;, \u0026ldquo;है\u0026rdquo;] बन जाता है Tokens को normalize किया जाता है — lowercasing, stemming, stop words को हटाना (है, एक, the) Tokens को उल्टे index में store किया जाता है — प्रत्येक unique token को document IDs से map करना Tokenization और filtering indexing के दौरान होते हैं, search के दौरान नहीं। यह है कि खोज इतनी तेज़ क्यों है — heavy lifting पहले से ही किया जाता है।\nElasticsearch में प्रत्येक index को shards में विभाजित किया जाता है [5]। एक shard एक self-contained Lucene index है। यदि आपका index बहुत बड़ा हो जाता है, तो Elasticsearch इसे कई shards में विभाजित करता है, और ये shards cluster में विभिन्न nodes (computers) पर रहते हैं। यह horizontal scaling है — अधिक दस्तावेज़? अधिक shards जोड़ें। अधिक shards जोड़ें? अधिक nodes जोड़ें।\nReplicas shards की copies हैं। Node A पर primary shard, node B पर replica [5]। यदि node A मर जाता है, तो node B संभाल लेता है। अधिक replicas का मतलब अधिक read capacity भी है — queries किसी भी replica को hit कर सकते हैं।\nOracle इस तरह काम नहीं करता। आप डेटा को manually shard कर सकते हैं (partition tables), लेकिन यह index के काम करने के तरीके के लिए native नहीं है।\nआमने-सामने: Oracle बनाम Elasticsearch पहलू Oracle B-Tree Elasticsearch उल्टा Index के लिए सर्वश्रेष्ठ सटीक मिलान, range queries (WHERE id = 5, WHERE date BETWEEN X AND Y) पूर्ण-पाठ खोज, प्रासंगिकता ranking, fuzzy queries खोज प्रकार Point lookup Term lookup \u0026ldquo;word X वाले सभी docs खोजें\u0026rdquo; पर प्रदर्शन Full table scan (बड़े पैमाने पर दर्दनाक) उल्टे index में Hash lookup (nanoseconds) डेटा structure Ordered tree, प्रति index एक column Flat उल्टा map, term → documents Scaling Vertical (बड़ा server) या manual sharding Horizontal (अधिक nodes, अधिक shards) प्रासंगिकता के अनुसार परिणामों को rank करें नहीं। Matches को return करता है, ranked नहीं। हाँ। डिफ़ॉल्ट रूप से TF-IDF और BM25 द्वारा scores करता है। Update cost Rebalance tree nodes (O(log N)) Rewrite affected posting lists structured data के लिए उपयुक्त हाँ, इसके लिए optimal। बहुत अच्छा नहीं। Semi-structured / text के लिए बेहतर। यह क्यों महत्वपूर्ण है मैंने teams को triggers और custom tables का उपयोग करके Oracle पर पूर्ण-पाठ खोज करने की कोशिश करते देखा है। यह काम करता है, मुश्किल से। या वे Oracle की पूर्ण-पाठ indexing (CTXSYS) का उपयोग करते हैं, जो slow और expensive है [1]।\nफिर वे एक ही workload को Elasticsearch में move करते हैं और आश्चर्य करते हैं कि यह 100x तेज़ क्यों है। यह magic नहीं है। यह है क्योंकि Elasticsearch की data structure समस्या के लिए designed है।\nइसके विपरीत, यदि आप ACID transactions और normalized data पर complex joins कर रहे हैं, तो Elasticsearch गलत tool है। यह Oracle की तरह consistency की guarantee नहीं देता। यह eventual-consistent है। कोई transactions नहीं। कोई foreign keys नहीं।\nप्रत्येक को कब उपयोग करें निम्नलिखित समय Oracle (या Postgres, MySQL, SQL Server) का उपयोग करें:\nडेटा structured और relational है आपको ACID guarantees की आवश्यकता है Queries सटीक हैं (सटीक मिलान, ranges) आपके पास \u0026lt; 1TB की hot data है निम्नलिखित समय Elasticsearch का उपयोग करें:\nआप text या logs को index कर रहे हैं उपयोगकर्ता keywords के साथ search करते हैं, सटीक values के साथ नहीं आपको प्रासंगिकता ranking की आवश्यकता है आपको billions के documents के लिए horizontally scale करने की आवश्यकता है बहुत सारे projects दोनों का उपयोग करते हैं। Transactional data के लिए Oracle, top पर search layer के रूप में Elasticsearch।\nभ्रम दोनों को \u0026ldquo;indexes\u0026rdquo; कहने से आता है। ये एक ही चीज़ नहीं हैं। एक tree है जो values को order करता है। दूसरा एक उल्टा map है जो दस्तावेज़ों को keywords द्वारा group करता है। विभिन्न समस्याएँ, विभिन्न समाधान।\nस्रोत Oracle B-tree Indexes कैसे काम करते हैं Inverted Index \u0026amp; Elasticsearch: आधुनिक खोज कैसे बड़े पैमाने पर काम करती है Elasticsearch index क्या है? | Elastic Blog Index fundamentals | Elastic Docs Clusters, nodes, और shards | Elastic Docs Oracle Indexes और Index-Organized Tables Elasticsearch क्या है? कैसे यह काम करता है और संपूर्ण गाइड ","permalink":"https://cloudmato.com/hi/posts/elasticsearch-vs-oracle-indexing/","title":"Elasticsearch Oracle Indexing से कैसे अलग है"},{"content":"हर कोई इन तीनों अवधारणाओं को भ्रमित करता है। आप उन्हें लगातार एक साथ उल्लेखित देखते हैं, लोग शब्दों का परस्पर उपयोग करते हैं, और अधिकांश लेख उन्हें मिलाते हैं या अंतर को जटिल शब्दावली में दफन करते हैं। यहाँ है कि वे वास्तव में क्या हैं, वे अलग क्यों हैं, और उनका उपयोग कब करें। [1]\nडिबाउंसिंग: तूफान गुजरने तक प्रतीक्षा करें डिबाउंसिंग निष्क्रियता की अवधि के बाद तक निष्पादन को विलंबित करता है।\nएक खोज बॉक्स में किसी को टाइप करते हुए कल्पना करें। हर कुंजीदबाव एक घटना है। डिबाउंसिंग के बिना, आप हर एक कुंजीदबाव के साथ एक API अनुरोध को ट्रिगर करेंगे — वर्ण 1, वर्ण 2, वर्ण 3, और इसी तरह। यह बर्बादी है।\nडिबाउंसिंग के साथ, आप एक टाइमर सेट करते हैं। जब उपयोगकर्ता एक वर्ण टाइप करता है, तो टाइमर शुरू होता है। यदि टाइमर समाप्त होने से पहले कोई अन्य वर्ण आता है, तो आप टाइमर को पुनः शुरू करते हैं। यह तब तक दोहराया जाता है जब तक उपयोगकर्ता पूरी अवधि के लिए टाइप करना बंद नहीं कर देता। तभी फ़ंक्शन निष्पादित होता है। [2]\nउदाहरण: उपयोगकर्ता \u0026ldquo;react\u0026rdquo; टाइप करता है। कुंजीदबाव 0ms, 50ms, 100ms, 150ms समय पर होते हैं। यदि आपकी डिबाउंस देरी 300ms है, तो फ़ंक्शन 450ms पर चलता है (150ms पर अंतिम कुंजीदबाव के 300ms बाद)।\nजब आप अंतिम परिणाम की परवाह करते हैं, तो डिबाउंसिंग का उपयोग करें, हर मध्यवर्ती स्थिति नहीं। सामान्य मामले:\nखोज क्षेत्र ऑटोकंप्लीट (उपयोगकर्ता टाइप करना बंद करने तक प्रतीक्षा करें) फॉर्म सत्यापन (उपयोगकर्ता संपादन बंद करने के बाद वैधता जांचें) विंडो आकार बदलने वाले हैंडलर्स (आकार बदलने के बाद लेआउट अपडेट करें) उपयोगकर्ता इनपुट द्वारा ट्रिगर किए गए API कॉल थ्रॉटलिंग: स्ट्रीम को स्थिर रखें थ्रॉटलिंग निष्पादन को एक निश्चित अंतराल तक सीमित करता है, चाहे घटना कितनी बार भी हो।\nएक वेबपेज को नीचे स्क्रॉल करने की कल्पना करें। स्क्रॉल घटना लगातार आग लगाती है — प्रति सेकंड दर्जनों बार। थ्रॉटलिंग के बिना, आप पृष्ठ लेआउट को अपडेट करते या विश्लेषण ट्रैक करते, जो अत्यधिक है।\nथ्रॉटलिंग के साथ, आप कहते हैं \u0026ldquo;इस फ़ंक्शन को हर 300 मिलीसेकंड में अधिकतम एक बार निष्पादित करें।\u0026rdquo; यदि घटना 1 सेकंड में 50 बार होती है, तो वास्तव में केवल 3-4 निष्पादन होते हैं, जो 300ms अलग होते हैं। मध्यवर्ती घटनाओं को अनदेखा किया जाता है। [3]\nउदाहरण: स्क्रॉल घटना 1 सेकंड में 50 बार होती है। थ्रॉटल विलंब 300ms है। फ़ंक्शन 0ms, 300ms, 600ms, 900ms पर निष्पादित होता है — कुल मिलाकर लगभग 3-4 बार।\nजब उपयोगकर्ता सक्रिय रूप से इंटरैक्ट कर रहा हो तो थ्रॉटलिंग का उपयोग करें। सामान्य मामले:\nस्क्रॉल ट्रैकिंग (विश्लेषण या अनंत स्क्रॉल) विंडो आकार बदलना (लेआउट को प्रतिक्रियाशील रूप से प्रवाहित करें) माउस आंदोलन (ड्रैग हैंडलर्स, एनिमेशन) रीयल-टाइम API पोलिंग मुख्य अंतर डिबाउंसिंग संयोजन-आधारित है — घटनाओं का विस्फोट → अंत में एकल निष्पादन।\nथ्रॉटलिंग दर-आधारित है — निश्चित अंतराल पर निष्पादन का स्थिर प्रवाह।\nबिल्कुल एक जैसा नहीं। करीब भी नहीं। [4]\nरेट लिमिटिंग: सर्वर का संरक्षक रेट लिमिटिंग एक कठोर अधिकतम सेट करता है: समय विंडो प्रति X अनुरोध।\nयह डिबाउंस और थ्रॉटल से अलग है। वे आपके स्वयं के कोड के निष्पादन आवृत्ति को नियंत्रित करने के बारे में हैं। रेट लिमिटिंग यह नियंत्रित करने के बारे में है कि कौन आपके सिस्टम को एक्सेस कर सकता है।\nरेट लिमिटिंग कहती है: \u0026ldquo;आप प्रति मिनट 100 अनुरोध बना सकते हैं। बस।\u0026rdquo; 101वां अनुरोध अस्वीकार कर दिया जाता है, आमतौर पर HTTP 429 त्रुटि के साथ। यह संसाधनों की सुरक्षा और दुरुपयोग को रोकने के लिए सर्वर (या API गेटवे) द्वारा लागू एक नीति है। [5]\nरेट लिमिटिंग बनाम थ्रॉटलिंग: भ्रम यहाँ है जहाँ लोग भ्रमित हो जाते हैं। कुछ \u0026ldquo;थ्रॉटलिंग\u0026rdquo; का अर्थ रेट लिमिटिंग के रूप में उपयोग करते हैं। कुछ स्रोत शब्दों का परस्पर उपयोग करते हैं। लेकिन वे विभिन्न परतों पर काम करते हैं:\nथ्रॉटलिंग (प्रदर्शन संदर्भ में): फ़ंक्शन कॉल आवृत्ति को कम करने के लिए क्लाइंट-साइड तकनीक रेट लिमिटिंग (API संदर्भ में): सर्वर-साइड नियम जो अतिरिक्त अनुरोधों को अस्वीकार या कतार में डालता है API थ्रॉटलिंग: सर्वर-साइड तकनीक जो उन्हें अस्वीकार करने के बजाय अनुरोध प्रसंस्करण को धीमा करती है अवधारणा परत क्रिया प्रभाव डिबाउंस क्लाइंट निष्पादन में देरी चुप्पी के लिए प्रतीक्षा करता है थ्रॉटल क्लाइंट/सर्वर आवृत्ति को सीमित करें स्थिर दर रेट लिमिट सर्वर अस्वीकार या कतार कठोर सीमा क्या आप उन्हें एक साथ उपयोग कर सकते हैं? हाँ। वास्तव में, आपको सही परिदृश्य में करना चाहिए। [6]\nडिबाउंस + थ्रॉटल: यह दुर्लभ लेकिन मान्य है। एक पाठ संपादक की कल्पना करें जो ड्राफ्ट सहेजता है। डिबाउंस कैप्चर करता है कि उपयोगकर्ता टाइप करना बंद कर गया, फिर थ्रॉटल सुनिश्चित करता है कि आप सर्वर को हथौड़ा न मारें भले ही उपयोगकर्ता लगातार टाइप करे। डिबाउंस चुप्पी की प्रतीक्षा करता है, थ्रॉटल गतिविधि के दौरान सुरक्षा जाल प्रदान करता है।\nडिबाउंस/थ्रॉटल + रेट लिमिटिंग: यह वह जगह है जहाँ यह सबसे महत्वपूर्ण है। फ्रंटएंड थ्रॉटलिंग और डिबाउंसिंग आपके स्वयं के अनुरोधों को अनुकूलित करते हैं, लेकिन यदि कोई उपयोगकर्ता आपके API को सीधे हथौड़ा मारता है (जैसे curl के माध्यम से, या एक बग अनुरोध भेजता है) तो वे आपकी सुरक्षा नहीं करते हैं। बैकएंड पर रेट लिमिटिंग सुनिश्चित करता है कि कोई भी एकल उपयोगकर्ता या क्लाइंट अपने फ्रंटएंड कोड की परवाह किए बिना आपके सिस्टम को अभिभूत नहीं कर सकता। इसे गहराई में रक्षा के रूप में सोचें।\nउदाहरण: एक खोज क्षेत्र डिबाउंसिंग (उपयोगकर्ता टाइप करना बंद करने तक प्रतीक्षा करें) + बैकएंड रेट लिमिटिंग (प्रति उपयोगकर्ता प्रति मिनट अधिकतम 10 खोजें) का उपयोग करता है। डिबाउंस शोर को रोकता है। रेट लिमिट दुरुपयोग को रोकता है।\nसामान्य पैटर्न: UX के लिए फ्रंटएंड पर डिबाउंस, भारी गणना या एनिमेशन के लिए थ्रॉटल, सुरक्षा के लिए बैकएंड पर रेट लिमिट। प्रत्येक एक अलग समस्या को हल करता है।\nवास्तविक दुनिया का उदाहरण एक उपयोगकर्ता खोज सुविधा का निर्माण:\nइनपुट को डिबाउंस करें — API कॉल करने से पहले उपयोगकर्ता के टाइप करना बंद करने के 300ms बाद प्रतीक्षा करें। हर कुंजीदबाव से शोर को कम करता है। API प्रतिक्रिया हैंडलर को थ्रॉटल करें — यदि प्रतिक्रियाएं जल्दी आती हैं, तो उन्हें अधिकतम 200ms में एक बार संसाधित करें। UI को थ्रैश करने से बचता है। बैकएंड पर रेट लिमिट — प्रति उपयोगकर्ता प्रति मिनट अधिकतम 30 खोज अनुरोधों की अनुमति दें। किसी को आपके डेटाबेस को स्पैम करने से रोकता है। तीनों एक साथ काम कर रहे हैं, प्रत्येक एक अलग चिंता को संबोधित कर रहे हैं।\nविनिमेय नहीं सबसे बड़ी गलती यह है कि इन्हें एक ही समस्या के विकल्प के रूप में मानना। ऐसा नहीं है। यदि आपको उपयोगकर्ता के टाइप करना बंद करने के लिए प्रतीक्षा करनी है, तो डिबाउंस उत्तर है — थ्रॉटलिंग यह नहीं करेगी। यदि आपको अपने API को दुरुपयोग से सुरक्षित करने की आवश्यकता है, तो रेट लिमिटिंग उत्तर है — डिबाउंसिंग यह नहीं करेगी।\nसही उपकरण चुनें। वे विभिन्न समस्याओं को हल करते हैं, भले ही वे सभी समय से संबंधित हों।\nEnd\nSources Difference between Debouncing and Throttling - GeeksforGeeks Debounce - Glossary - MDN Web Docs Throttling vs. Debouncing Explained | Built In Debounce and Throttling: What They Are and When to Use Them | Medium API Throttling vs. API Rate Limiting - GeeksforGeeks Understanding the Differences Between Rate Limiting, Debouncing, and Throttling - Inngest Blog ","permalink":"https://cloudmato.com/hi/posts/debounce-throttle-rate-limiting/","title":"डिबाउंस बनाम थ्रॉटल बनाम रेट लिमिटिंग"},{"content":"अगर आपने तकनीकी क्षेत्रों में \u0026ldquo;तंत्रिका नेटवर्क\u0026rdquo; शब्द सुना है, तो आप शायद कुछ जैविक कल्पना करते हैं। न्यूरॉन शब्द शुरुआती लोगों को यह सोचने के लिए प्रेरित कर सकता है कि उन्हें एआई के साथ काम करने के लिए मस्तिष्क जीव विज्ञान को समझने की जरूरत है। लेकिन वास्तव में उन्हें नहीं करनी चाहिए। एक न्यूरॉन वास्तव में क्या करता है और यह कोड में लिखे गए फंक्शन से कैसे अलग है - इस बारे में भ्रम असली है। और वह अंतर महत्वपूर्ण है [1][2]।\nन्यूरॉन वास्तव में क्या है? एआई में एक न्यूरॉन एक कम्प्यूटेशनल यूनिट है। मूल रूप से, यह एक चीज है जो इनपुट लेता है, गणना करता है, और एक आउटपुट देता है। एक फंक्शन जैसा लगता है, है ना? हाँ, कुछ हद तक। लेकिन यहीं से समानता समाप्त होती है।\nयहाँ एक कृत्रिम न्यूरॉन के अंदर क्या होता है [1]:\nइनपुट कहीं और से आते हैं (या तो मूल डेटा या पिछले न्यूरॉन्स के आउटपुट) प्रत्येक इनपुट को एक वजन से गुणा किया जाता है - एक संख्यात्मक मान जो निर्धारित करता है कि वह इनपुट कितना महत्वपूर्ण है सभी भारित इनपुट को एक साथ जोड़ा जाता है एक पूर्वाग्रह जोड़ा जाता है (एक स्वतंत्र समायोज्य संख्या) परिणाम एक सक्रियण फंक्शन से गुजरता है [3] एक एकल आउटपुट निकलता है तो न्यूरॉन कुछ इस तरह की गणना करता है: output = activation_function(sum(inputs × weights) + bias).\nयह फंक्शन से कैसे अलग है मान लीजिए आप एक पायथन फंक्शन लिखते हैं:\ndef add_numbers(a, b): return a + b यह फंक्शन हमेशा एक ही तरीके से व्यवहार करता है। इसे 2 और 3 दें, 5 मिलेगा। इसे हमेशा एक ही इनपुट दें, आपको हमेशा वही आउटपुट मिलेगा। तर्क निश्चित है।\nएक न्यूरॉन? इसका व्यवहार समय के साथ बदलता है [2]। वजन और पूर्वाग्रह स्थिरांक नहीं हैं जिन्हें आप हार्डकोड करते हैं। वे पैरामीटर हैं जो प्रशिक्षण के दौरान समायोजित किए जाते हैं। न्यूरॉन यादृच्छिक वजन के साथ शुरू होता है, अपने आउटपुट के बारे में प्रतिक्रिया प्राप्त करता है कि वे सही थे या गलत, और फिर अगली बार बेहतर करने के लिए उन वजन को समायोजित करता है। आपका हार्डकोड किया गया फंक्शन यह नहीं कर सकता।\nएक और अंतर: एक नियमित फंक्शन नियतात्मक और पारदर्शी है। मैं कोड पढ़ सकता हूँ और बिल्कुल देख सकता हूँ कि यह क्या करता है। एक न्यूरॉन की गणना दृश्यमान है, निश्चित रूप से, लेकिन यह वजन समायोजन क्यों किए गए यह कम स्पष्ट है। जब एक तंत्रिका नेटवर्क हजारों उदाहरणों पर प्रशिक्षित होता है, तो यह पता लगाना कि एक विशेष न्यूरॉन इनपुट ए के लिए वजन 0.75 के साथ क्यों समाप्त हुआ बजाय 0.73 के, यह वास्तव में कठिन हो जाता है [2]।\nवजन और पूर्वाग्रह - सीखने योग्य हिस्से यह वही बात है जो न्यूरॉन्स को फंक्शन से अलग करती है। वे वजन और पूर्वाग्रह? वे हाथ से नहीं लिखे हैं। वे सीखे जाते हैं।\nप्रशिक्षण के दौरान, एक एल्गोरिदम (आमतौर पर बैकप्रोपेगेशन कहा जाता है) न्यूरॉन द्वारा दिए गए आउटपुट को देखता है, उन्हें उस चीज़ से तुलना करता है जो उसे देना चाहिए था, और वजन और पूर्वाग्रह को उस त्रुटि को कम करने के लिए समायोजित करता है। यह लाखों बार करें अरबों पैरामीटर के लिए, और अचानक नेटवर्क ने डेटा में ऐसे पैटर्न सीख लिए हैं जो मनुष्यों ने कभी स्पष्ट रूप से प्रोग्राम नहीं किए [4]।\nएक इनपुट पर वजन नियंत्रित करता है कि वह इनपुट न्यूरॉन के आउटपुट को कितना प्रभावित करता है। उच्च वजन का अर्थ है \u0026ldquo;यह इनपुट बहुत महत्वपूर्ण है।\u0026rdquo; एक नकारात्मक वजन का अर्थ है \u0026ldquo;अगर यह इनपुट अधिक है, तो आउटपुट को कम करें।\u0026rdquo;\nपूर्वाग्रह एक ऑफसेट है। यह न्यूरॉन को अपनी निर्णय सीमा को स्थानांतरित करने का एक तरीका है भले ही सभी इनपुट शून्य हों। इसे न्यूरॉन की आधारभूत प्रवृत्ति के रूप में सोचें - क्या यह कोई डेटा आने से पहले 1 या 0 आउटपुट करने की ओर झुकता है? [4][5]\nसक्रियण फंक्शन - न्यूरॉन्स को गैर-रैखिकता की क्यों जरूरत है यहाँ एक विवरण है जो कुछ शुरुआती लोगों को हैरान करता है: अगर न्यूरॉन्स केवल सक्रियण फंक्शन के बिना भारित इनपुट को जोड़ते हैं, तो उन्हें स्टैक करने से शक्ति नहीं जुड़ती। आप केवल एक और रैखिक फंक्शन के साथ समाप्त होंगे।\n(w1*x1 + b) → (w2*(w1*x1 + b) + b2) → अभी भी सिर्फ एक लाइन सक्रियण फंक्शन इसे तोड़ता है। यह भारित योग पर लागू किया गया एक गैर-रैखिक फंक्शन है। सामान्य विकल्प:\nReLU (Rectified Linear Unit): अगर इनपुट नकारात्मक है, तो आउटपुट 0। अन्यथा, इनपुट को आउटपुट करें। सरल लेकिन शक्तिशाली। सिग्मॉइड: आउटपुट को 0 और 1 के बीच दबाता है। संभावनाओं के लिए अच्छा। Tanh: सिग्मॉइड के समान लेकिन -1 और 1 के बीच आउटपुट करता है। सक्रियण फंक्शन यह है जो न्यूरॉन्स को दिलचस्प तरीकों से जोड़ने देता है जटिल संबंधों को मॉडल करने के लिए [3]।\nएक न्यूरॉन उपयोगी नहीं है। कई हैं। एक एकल न्यूरॉन? बहुत शक्तिशाली नहीं। यह डेटा की दो श्रेणियों के बीच एक सरल रैखिक सीमा सीख सकता है। लेकिन सैकड़ों या हजारों को एक साथ जोड़ें - उन्हें परतों में व्यवस्थित करें जहाँ प्रत्येक परत का आउटपुट अगले में खिलाया जाता है - और अचानक आप अविश्वसनीय रूप से जटिल पैटर्न सीख सकते हैं [1]।\nवह स्तरबद्ध व्यवस्था तंत्रिका नेटवर्क है। पहली परत कच्चे इनपुट को संसाधित करती है। बीच की छिपी परतें संकेत को परिष्कृत करती हैं। आउटपुट परत आपको अंतिम उत्तर देता है। न्यूरॉन्स के बीच प्रत्येक कनेक्शन का अपना वजन है, और प्रशिक्षण के दौरान, ये सभी एक साथ समायोजित होते हैं [3]।\nतो इसे न्यूरॉन क्यों कहते हैं? नाम ढीली जैविक प्रेरणा से आता है। आपके दिमाग में असली न्यूरॉन्स पड़ोसी न्यूरॉन्स से संकेत प्राप्त करते हैं, उन संकेतों को जोड़ते हैं, और आग लगाते हैं या नहीं आग लगाते हैं यह इस बात पर निर्भर करता है कि योग एक सीमा से अधिक है। कृत्रिम न्यूरॉन्स कुछ गणितीय रूप से समान करते हैं - वे भारित इनपुट को जोड़ते हैं, एक पूर्वाग्रह जोड़ते हैं, एक गैर-रैखिक फंक्शन लागू करते हैं।\nसमरूपता तेजी से टूट जाती है अगर आप इसे बहुत दूर तक ले जाते हैं। असली न्यूरॉन्स बहुत अधिक जटिल हैं, विभिन्न प्रकारों के साथ, समय पर निर्भर गतिशीलता, और रासायनिक प्रक्रियाएं जो हम पूरी तरह से नहीं समझते हैं। लेकिन एआई मॉडल बनाने के उद्देश्यों के लिए, समरूपता पर्याप्त करीब है [1][2]।\nव्यावहारिक निष्कर्ष जब आप एक तंत्रिका नेटवर्क बना रहे हों या उपयोग कर रहे हों, न्यूरॉन्स को लघु प्रोग्राम के रूप में न सोचें। उन्हें समायोज्य गणितीय गेट के रूप में सोचें। प्रत्येक सरल है। अपने आप में मूर्ख भी। बुद्धिमत्ता कई से आती है, डेटा से सीखते हैं, और उनके वजन उपयोगी मानों में परिवर्तित होते हैं।\nएक फंक्शन एक निश्चित व्यवहार है जो एक बार लिखा जाता है और हमेशा के लिए चलता है। एक न्यूरॉन एक सीखने योग्य घटक है जो डेटा के आधार पर अनुकूल होता है। वह मूल अंतर है, और यह है कि तंत्रिका नेटवर्क ऐसी चीजें कर सकते हैं जो पारंपरिक प्रोग्रामित फंक्शन नहीं कर सकते।\nअंत\nस्रोत कृत्रिम न्यूरॉन क्या है? | TechTarget से परिभाषा कृत्रिम न्यूरॉन - विकिपीडिया तंत्रिका नेटवर्क: नोड्स और छिपी परतें | मशीन लर्निंग | डेवलपर्स के लिए गूगल पर्सेप्ट्रॉन क्या है? - तंत्रिका नेटवर्क की बेसिक्स | Towards Data Science पर्सेप्ट्रॉन: कृत्रिम तंत्रिका नेटवर्क का बिल्डिंग ब्लॉक ","permalink":"https://cloudmato.com/hi/posts/neurons-ai-vs-functions/","title":"एआई में न्यूरॉन्स: सिर्फ फंक्शन नहीं"},{"content":"आप एक Full HD (1920×1080) मॉनिटर खरीदते हैं और स्पेक्स की जांच करते हैं। आपका MacBook भी एक समान रेज़ोल्यूशन को आउटपुट करता है। फिर भी जब आप काम करना शुरू करते हैं, तो मॉनिटर पर टेक्स्ट ध्यान से नरम दिखता है। टूटा या अपठनीय नहीं - बस आपके MacBook की निर्मित स्क्रीन पर जो दिखता है उतना तीव्र नहीं। क्या हो रहा है?\nउत्तर रेज़ोल्यूशन नंबर के बारे में नहीं है। यह पिक्सल घनत्व के बारे में है।\nपिक्सल घनत्व की समस्या बात यह है: अलग-अलग आकारों में समान रेज़ोल्यूशन वाली दो डिस्प्ले में पूरी तरह से अलग पिक्सल घनत्व होगा [1]। एक 24-इंच Full HD मॉनिटर में लगभग 92 पिक्सल प्रति इंच (PPI) [2] है। आपका MacBook Air? 227 PPI [1] आजमाएं। आपका 16-इंच MacBook Pro? 254 PPI [1]।\nयह एक छोटा अंतर नहीं है। यह लगभग 3× का अंतर है कि कितने पिक्सल एक ही भौतिक स्थान में दबाए गए हैं।\n92 PPI पर, यदि आप ध्यान से देखते हैं तो आपकी आँख वास्तव में अलग-अलग पिक्सल देख सकती है। 227+ PPI पर, आप नहीं कर सकते। Apple ने macOS को डेस्कटॉप डिस्प्ले के लिए लगभग 218 PPI पर आरामदायक और पठनीय होने के लिए डिज़ाइन किया [1]। उससे बहुत दूर जाएं, और OS दृश्य रूप से गिरावट आती है — भले ही रेज़ोल्यूशन नंबर समान लगें।\nटेक्स्ट रेंडरिंग क्यों बदलती है यह वह जगह है जहां यह दिलचस्प हो जाता है। टेक्स्ट अब बिटमैप के रूप में प्रस्तुत नहीं किया जाता है। यह वक्रों का उपयोग करके प्रस्तुत किया जाता है जो एंटीएलिएस्ड हैं — कम दांतेदार दिखने के लिए चिकना [1]।\nलेकिन एंटीएलिएसिंग अलग-अलग स्वाद में आती है, और स्वाद पिक्सल घनत्व पर निर्भर करता है।\nकम-PPI डिस्प्ले पर (आपके 92 PPI मॉनिटर की तरह): सिस्टम सबपिक्सल एंटीएलिएसिंग पर निर्भर करता था [2]। यह LCD स्क्रीन की भौतिक ज्यामिति - लाल, हरे, और नीले सबपिक्सल - को अतिरिक्त तीक्ष्णता को नकली बनाने के लिए दोहन करता है। यह एक ट्रिक है जिसने पुरानी, कम घनत्व वाली डिस्प्ले पर फॉन्ट को स्वीकार्य दिखाया [2]।\nउच्च-PPI डिस्प्ले पर (आपके MacBook की तरह): सिस्टम इसके बजाय ग्रेस्केल एंटीएलिएसिंग का उपयोग करता है [2]। यह रंग की चाल का उपयोग न करते हुए ग्रे के शेड का उपयोग करके फॉन्ट को चिकना करता है। उच्च घनत्व पर, यह दृष्टिकोण बहुत तीक्ष्ण, पतले लेटरफॉर्म का उत्पादन करता है जो लगभग मुद्रित दिखते हैं [3]।\nयहाँ दिलचस्प बात है: macOS Mojave ने डिफ़ॉल्ट रूप से सबपिक्सल एंटीएलिएसिंग को हटा दिया [2]। Apple ने तय किया कि Retina-क्लास डिस्प्ले पर, पुरानी ट्रिक अनावश्यक थी। लेकिन गैर-Retina मॉनिटर पर? सबपिक्सल रेंडरिंग के नुकसान ने टेक्स्ट को ध्यान से नरम दिख बनाया [2]।\nस्केलिंग ट्रैप और भी बुरा, जब आप एक कम-घनत्व वाली बाहरी मॉनिटर का उपयोग करते हैं तो macOS UI तत्वों को स्केल करता है। एक 92 PPI डिस्प्ले पर 100% स्केलिंग पर, सब कुछ सिद्धांत में तीव्र होना चाहिए। लेकिन व्यावहार में, अनुप्रयोग एक उच्च तार्किक रेज़ोल्यूशन पर प्रस्तुत करते हैं, फिर भौतिक पिक्सल को फिट करने के लिए डाउनस्केल करते हैं। यह सूक्ष्म धुंधलापन का परिचय देता है - विशेष रूप से स्क्रॉलिंग और एनिमेशन में [4]।\n125% या 150% स्केलिंग पर, गणित स्वच्छ रूप से काम नहीं करती है [5]। रेंडरर को कहीं न कहीं interpolate करना पड़ता है, और आप आंशिक पिक्सल के साथ समाप्त होते हैं जो टेक्स्ट को धुंधला करते हैं [5]।\nआपको वास्तव में क्या चाहिए यदि आप Mac के लिए एक नया मॉनिटर विचार कर रहे हैं, तो पिक्सल घनत्व कच्चे रेज़ोल्यूशन नंबर से कहीं अधिक महत्वपूर्ण है।\nएक 24-इंच मॉनिटर के लिए, 1920×1080 92 PPI देता है — काम योग्य लेकिन बहुत अच्छा नहीं। एक 27-इंच 4K डिस्प्ले (3840×2160) 163 PPI देता है [2] — ध्यान से अधिक तीव्र। आदर्श रूप से, आप टेक्स्ट-भारी कार्य के लिए 160+ PPI चाहते हैं [2]।\nयही कारण है कि कई डेवलपर्स और डिज़ाइनर अपने MacBooks को 27-इंच या 32-इंच 4K मॉनिटर या यहां तक कि 5K डिस्प्ले के साथ जोड़ी देते हैं [1]। इसलिए नहीं कि उच्च रेज़ोल्यूशन हमेशा बेहतर है, बल्कि इसलिए कि उन स्क्रीन आकारों पर, पिक्सल घनत्व उस सीमा में चढ़ जाता है जहां ग्रेस्केल एंटीएलिएसिंग वास्तव में क्रिस्प टेक्स्ट का उत्पादन करता है [3]।\nसमस्या का समाधान क्या आप एक नया मॉनिटर खरीदे बिना अपने Full HD मॉनिटर पर टेक्स्ट में सुधार कर सकते हैं? हल्का-फुल्का।\nmacOS System Settings → General में, आप Font Smoothing को सक्षम कर सकते हैं (हालांकि Apple नोट करता है कि यह मुख्य रूप से गैर-Retina डिस्प्ले के लिए है) [1]। कुछ उपयोगकर्ता रिपोर्ट करते हैं कि इस सेटिंग को ट्वीक करने में मदद मिलती है, लेकिन यह उच्च-PPI डिस्प्ले की तीक्ष्णता की नकल नहीं करेगा — यह एक बैंड-एड है, एक फिक्स नहीं।\nअसली समाधान यह स्वीकार करना है कि कम पिक्सल घनत्व विभिन्न रेंडरिंग ट्रेड-ऑफ की आवश्यकता है [3]। आपका Full HD मॉनिटर टूटा नहीं है। यह केवल एक पिक्सल घनत्व सीमा में काम कर रहा है जहां मानव आंख नरमता को नोटिस करना शुरू करती है।\nअंत\nस्रोत Explainer: Pixel density and display resolution – The Eclectic Light Company The subpixel-AA debacle and font rendering | MacRumors Forums The Impact of Retina Displays On Fonts – Zit Seng\u0026rsquo;s Blog macOS, blurry texts on an external Full HD monitor? | Medium Why Text Looks Blurry at 125% or 150% Display Scaling | KTC Play ","permalink":"https://cloudmato.com/hi/posts/macbook-text-crispy-monitor-pixel-density/","title":"MacBook टेक्स्ट बनाम मॉनिटर: रेज़ोल्यूशन नंबर झूठ क्यों बोलते हैं"},{"content":"मुझे वह पहला समय याद है जब मैंने एक प्रोजेक्ट को CRA (जो अंदर से Webpack उपयोग करता है) से Vite में स्विच किया था। Dev सर्वर एक सेकंड से भी कम समय में शुरू हो गया। मैं सच में कुछ देर टर्मिनल को देखता रहा, कुछ और होने का इंतज़ार करते हुए। कुछ नहीं हुआ। बस यही था — यह तैयार था। यह Webpack की तुलना में कोई छोटा सुधार नहीं है। यह एक पूरी तरह से अलग अनुभव है।\nVite क्या है? Vite (फ्रेंच में \u0026ldquo;तेज़\u0026rdquo; का अर्थ, उच्चारण \u0026ldquo;वीट\u0026rdquo;) एक फ्रंटएंड बिल्ड टूल है जिसे Evan You ने बनाया है — वही व्यक्ति जिसने Vue.js बनाया था [1]। इसे 2020 में लॉन्च किया गया था और यह तेज़ी से बढ़ रहा है। 2025 तक, Vite प्रति सप्ताह 53 मिलियन npm डाउनलोड दर्ज करता है, जबकि Webpack के 36 मिलियन हैं [5]। इसके GitHub स्टार्स भी यही कहानी बताते हैं: 78,000 बनाम Webpack के 66,000 [5]।\nहर बिल्ड टूल के दो मुख्य काम होते हैं:\nहॉट मॉड्यूल रिप्लेसमेंट (HMR) के साथ लोकल डेवलपमेंट के दौरान आपका कोड सर्व करना प्रोडक्शन के लिए आउटपुट को बंडल और ऑप्टिमाइज़ करना Vite और Webpack दोनों यह काम करते हैं। कैसे एकदम अलग है — और यही अंतर है जो एक को मिलीसेकंड में शुरू करता है और दूसरे में आपको इंतज़ार करवाता है।\nWebpack धीमा क्यों हो जाता है Webpack का दृष्टिकोण सरल लेकिन महंगा है: पहले सब कुछ बंडल करें, फिर सर्व करें। ब्राउज़र एक भी पिक्सेल देखे इससे पहले, Webpack आपके प्रोजेक्ट की हर फ़ाइल पढ़ता है, हर इम्पोर्ट चेन को रिज़ॉल्व करता है, सब कुछ कंपाइल करता है, और एक बड़ा bundle.js आउटपुट करता है। एक मध्यम आकार का React ऐप केवल कोल्ड-स्टार्ट के लिए 15–30 सेकंड ले सकता है [1]।\nयह 2014 में समझ में आता था। उस समय ब्राउज़र ES मॉड्यूल को नेटिव रूप से नहीं संभाल सकते थे — आपको उन्हें एक प्री-प्रोसेस्ड फ़ाइल देनी होती थी। Webpack उस दुनिया के लिए बनाया गया था। समस्या यह है कि यह अभी भी काफी हद तक उसी तरह काम करता है, भले ही ब्राउज़रों ने वर्षों से नेटिव ESM को सपोर्ट किया हो।\nHMR एक और दर्द का बिंदु है। जब आप एक फ़ाइल बदलते हैं, तो Webpack आंशिक रूप से बंडल को फिर से बनाता है। बड़े प्रोजेक्ट्स पर, छोटे बदलाव भी आपको परिवर्तन दिखाने से पहले 2–5 सेकंड ले सकते हैं। यह फीडबैक लूप ध्यान को मारता है।\nकॉन्फ़िगरेशन की जटिलता एक और समस्या है। मैंने ऐसे Webpack कॉन्फ़िग इनहेरिट किए हैं जो 400+ लाइन लंबे थे, लोडर्स, प्लगइन्स, और एनवायरनमेंट-स्पेसिफिक ओवरराइड्स के साथ जिन्हें कोई पूरी तरह नहीं समझता था। State of JavaScript सर्वे के अनुसार, 86% डेवलपर्स अभी भी Webpack उपयोग करते हैं, लेकिन केवल 14% वास्तव में इसे पसंद करते हैं [8]।\nVite वास्तव में कैसे काम करता है Vite एक मूलभूत दांव लगाता है: आधुनिक ब्राउज़र ES मॉड्यूल को नेटिव रूप से समझते हैं, इसलिए डेवलपमेंट के दौरान बंडल मत करो।\nजब ब्राउज़र आपके कोड में कोई import देखता है, तो यह Vite dev सर्वर को एक रिक्वेस्ट भेजता है। Vite उस रिक्वेस्ट को इंटरसेप्ट करता है, esbuild — एक Go में लिखा बंडलर जो JavaScript-आधारित समकक्षों से लगभग 10–100× तेज़ है — का उपयोग करके सिर्फ उस एक फ़ाइल को ट्रांसफॉर्म करता है (TypeScript, JSX, जो भी हो) और इसे वापस करता है [3]।\nएक बात है: node_modules में तृतीय-पक्ष पैकेज अक्सर ESM नहीं, CommonJS होते हैं। और कुछ लाइब्रेरी में सैकड़ों आंतरिक इम्पोर्ट होते हैं जो सैकड़ों HTTP रिक्वेस्ट बना देते। इसलिए Vite स्टार्टअप पर एक बार esbuild का उपयोग करके डिपेंडेंसी को प्री-बंडल करता है, उन्हें ESM में कनवर्ट करता है, और उन्हें कैश करता है। यह चरण मिलीसेकंड में होता है [1]। उसके बाद, आपकी ऐप सोर्स फ़ाइलें मांग पर सर्व की जाती हैं — बिल्कुल बंडलिंग चरण के बिना।\nVite में HMR प्रोजेक्ट बढ़ने के साथ भी तेज़ रहता है। जब आप एक फ़ाइल बदलते हैं, तो Vite केवल उस मॉड्यूल और उसके प्रत्यक्ष निर्भरों को इनवैलिडेट करता है। यह किसी और चीज़ को नहीं छूता। HMR बाउंड्री लॉजिक सटीक है। यही कारण है कि Vite का HMR एक 10-फ़ाइल प्रोजेक्ट में तत्काल महसूस होता है और 500-फ़ाइल प्रोजेक्ट में भी तत्काल महसूस होता है — Webpack के विपरीत, जहाँ HMR गति कोडबेस बढ़ने के साथ घटती है [3]।\nVite बनाम Webpack — साथ-साथ Vite Webpack Dev सर्वर कोल्ड स्टार्ट \u0026lt; 1 सेकंड 15–30s (मध्यम ऐप) HMR गति किसी भी स्केल पर तत्काल प्रोजेक्ट साइज़ के साथ घटती है शुरू करने के लिए कॉन्फ़िग ~10 लाइनें अक्सर 100s लाइनें प्रोडक्शन बंडलर Rollup / Rolldown Webpack बंडल साइज़ (औसत) ~130 KB ~150 KB साप्ताहिक npm डाउनलोड 53 मिलियन 36 मिलियन सबसे अच्छा किसके लिए नए प्रोजेक्ट्स, आधुनिक स्टैक लीगेसी ऐप्स, एंटरप्राइज़, कस्टम लोडर्स स्रोत: [2][5]\nShopify ने Webpack से Vite में कई आंतरिक टूल्स माइग्रेट किए और ~12 सेकंड के स्टार्टअप से 800 मिलीसेकंड से कम में आ गए [2]। यह ऑप्टिमाइज़ेशन नहीं है। यह एक अलग आर्किटेक्चर है।\nVite 8 और Rolldown — अगला कदम Vite में हमेशा एक विभाजित व्यक्तित्व रहा है: डेवलपमेंट ट्रांसफॉर्म के लिए esbuild, प्रोडक्शन बिल्ड के लिए Rollup। वे अलग-अलग टूल हैं जिनके अलग-अलग व्यवहार हैं। इससे कभी-कभी सूक्ष्म बग होते थे — ऐसी चीज़ें जो dev में काम करती थीं लेकिन प्रोडक्शन में टूट जाती थीं, या इसके विपरीत।\nअब इसे Rolldown के साथ संबोधित किया जा रहा है — VoidZero (Evan You की कंपनी) द्वारा विकसित एक Rust-आधारित बंडलर जो दोनों को रिप्लेस करने के लिए बनाया गया है [6]। 2026 में रिलीज़ Vite 8, Rolldown को डिफ़ॉल्ट प्रोडक्शन बंडलर के रूप में शिप करता है, जो dev और prod दोनों बिल्ड को समान अंतर्निहित इंजन देता है [7]।\nप्रारंभिक प्रोडक्शन बिल्ड परिणाम:\nExcalidraw: 22.9s → 1.4s (16× तेज़) [8] GitLab: 2.5 मिनट → 40 सेकंड [8] सामान्य बेंचमार्क दावे: पिछले Rollup पाइपलाइन की तुलना में 10–30× तेज़ प्रोडक्शन बिल्ड [7] Dev/prod समानता की समस्या भी दूर हो जाती है। यह वर्षों से बग का एक कम महत्व दिया गया स्रोत रहा है।\nक्या Vite अंततः Webpack जैसा बन जाएगा? यही वह बात है जो हर कोई सोच रहा है लेकिन सीधे नहीं कह रहा। Webpack शुरुआत में उस राक्षस जैसा नहीं था जो वह बना। यह बढ़ा। टीमों ने लोडर्स जोड़े, कस्टम प्लगइन लिखे, एनवायरनमेंट-स्पेसिफिक ओवरराइड्स की परतें चढ़ाईं, और लीगेसी वर्कअराउंड छोड़े जिन्हें हटाने की किसी की हिम्मत नहीं थी। बीस कॉन्फ़िग फ़ाइलें और एक सीनियर इंजीनियर जो \u0026ldquo;बिल्ड सेटअप जानता है\u0026rdquo; — जो हर मध्यम आकार की कंपनी ने अनुभव किया है।\nक्या Vite उसी रास्ते पर चल सकता है? ईमानदारी से कहें तो, एक हद तक — हाँ। बड़ी टीमें बड़े कॉन्फ़िग बनाएंगी। SSR सेटअप में पहले से एज केस हैं। एंटरप्राइज़ प्रोजेक्ट्स Vite 6+ में नए Environment API को उन तरीकों से पुश करेंगे जिनके लिए गहरे Vite ज्ञान की आवश्यकता है [5]।\nलेकिन एक संरचनात्मक कारण है कि शायद यह उतना बुरा नहीं होगा। Webpack की जटिलता काफी हद तक आकस्मिक थी — पुराने ब्राउज़रों के लिए कम्पैटिबिलिटी लेयर, CommonJS-से-ESM कनवर्शन, हज़ार प्लगइन जो एज केस पैच कर रहे थे जिन्हें नेटिव टूलिंग ने अब हल कर दिया है। Vite बस आधुनिक एनवायरनमेंट की आवश्यकता करके इसमें से अधिकांश को बाईपास करता है। यह \u0026ldquo;इस अजीब लीगेसी चीज़ के लिए मुझे एक कस्टम लोडर चाहिए\u0026rdquo; की एक पूरी श्रेणी को काट देता है।\nVite का प्लगइन सिस्टम Rollup के API का एक जानबूझकर सुपरसेट है [1]। एक नया कॉन्फ़िग फ़ॉर्मेट आविष्कार करने के बजाय, यह एक अच्छी तरह से समझे गए इंटरफ़ेस का पुनः उपयोग करता है। यह एक अच्छा संकेत है — इसका मतलब है कि इकोसिस्टम ज्ञान स्थानांतरित होता है बजाय अलगाव में जमा होने के।\nVite जो जटिलता जमा करेगा वह ज्यादातर जानबूझकर होगी — उन्नत उपयोगकर्ता कस्टम SSR पाइपलाइन, मल्टी-एनवायरनमेंट सेटअप, या फ्रेमवर्क-स्तरीय टूलिंग बना रहे हैं। यह एक अलग प्रकार की गड़बड़ी है। आप आमतौर पर एक Vite कॉन्फ़िग को समझ सकते हैं जो आपने नहीं लिखा। यही बात अधिकांश इनहेरिटेड Webpack कॉन्फ़िग के बारे में नहीं कही जा सकती जिन्हें मैंने छुआ है।\nक्या Vite पाँच साल में उतना डरावना दिखेगा जितना Webpack आज दिखता है — मुझे संदेह है। लेकिन \u0026ldquo;Webpack जितना बुरा नहीं\u0026rdquo; अभी भी बहुत जगह छोड़ता है।\nसमाप्त\nस्रोत Vite क्यों — Vite आधिकारिक डॉक्स 2025 में React ऐप्स के लिए Vite बनाम Webpack: एक सीनियर इंजीनियर का नज़रिया — LogRocket Vite का मूल जादू: esbuild और नेटिव ESM फ्रंटएंड डेवलपमेंट को कैसे फिर से आविष्कार करते हैं — Leapcell Vite बनाम Webpack: एक आमने-सामने तुलना — Kinsta Webpack बनाम Vite: आधुनिक फ्रंटएंड डेवलपमेंट के लिए सही बंडलर चुनना — Syncfusion Rolldown-Vite की घोषणा — VoidZero Vite संस्करण 8: एकीकृत Rust-आधारित बंडलर और 30× तक तेज़ बिल्ड — InfoQ Rolldown-Vite बीटा: Rust-संचालित बंडलर बिल्ड समय को 16× तक कम करता है — Progosling ","permalink":"https://cloudmato.com/hi/posts/vite-vs-webpack-why-vite-is-fast/","title":"Vite समझाया गया: यह Webpack से बेहतर क्यों है और आगे क्या है"},{"content":"फ्रंटएंड इकोसिस्टम हर साल बदलता है, लेकिन 2025-2026 संरचनात्मक रूप से अलग महसूस हुआ। यह केवल नई लाइब्रेरी नहीं थीं — बुनियादी मानसिक मॉडल बदल गए। हम कैसे hydrate करते हैं, bundle करते हैं, components को structure करते हैं, और reactivity को handle करते हैं — यह सब इस तरह से बदला है जो वास्तव में apps के performance और उन्हें बनाने में लगने वाले समय को प्रभावित करता है। यहाँ वह है जिस पर ध्यान देना उचित है।\nFramework परिदृश्य विखंडित हो रहा है (एक अच्छे तरीके से) React अभी भी लगभग 45% adoption के साथ हावी है [1], लेकिन हर project type के लिए इसे default उत्तर कहना कठिन होता जा रहा है। तीन प्रतिस्पर्धी अब गंभीर हैं।\nSvelte 5 ने अपना सबसे बड़ा overhaul ship किया: Runes। ये explicit reactive primitives हैं — $state, $derived, $effect — जो Svelte 4 के implicit $: label syntax को replace करते हैं [3]। यह बदलाव महत्वपूर्ण है। Runes proper signal-based reactivity हैं जो कहीं भी काम करती हैं — components के अंदर, stores में, utility functions में — न कि केवल एक .svelte फ़ाइल के top level पर। Krausest js-framework test के benchmarks दिखाते हैं कि Svelte 5, React Compiler सक्षम होने पर भी, React 19 से 20–40% तेज़ चलता है, और memory usage 50% कम रहती है [4]।\nReact 19 भी पीछे नहीं है। React Compiler (v1.0, अक्टूबर 2025 में ship हुआ) build time पर components को auto-memoize करता है, जिसका अर्थ है कि useMemo / useCallback / React.memo की ritual अब आपकी समस्या नहीं है [3]। Server Components experimental से stable हो गए [2], और Actions API ने async mutation की कहानी को काफी हद तक साफ किया। React का नुकसान अभी भी bundle weight है — trade-off इसका विशाल talent pool और ecosystem है।\nVue 3.6 ने bundle size पर tight रहते हुए React के साथ DX gap को काफी हद तक बंद किया। byteiota.com का framework convergence article इसे अच्छी तरह से कहता है: \u0026ldquo;तीनों एक ही लक्ष्य का पीछा कर रहे हैं — कम boilerplate, तेज़ rendering, बेहतर TypeScript integration\u0026rdquo; [12]।\nSolidJS का भी उल्लेख किया जाना चाहिए। इसके adoption के आंकड़े नहीं हैं, लेकिन इसका fine-grained reactivity model (true signals, no VDOM) यह प्रभावित करता है कि React और Svelte अपने reactivity APIs को कैसे विकसित कर रहे हैं [10]।\nServer-First अब नया Default है सबसे बड़ा architectural बदलाव client-heavy SPAs से दूर selective client hydration के साथ server-first rendering की ओर है [13]। दो patterns इसका नेतृत्व कर रही हैं।\nIsland Architecture Astro 5 सबसे स्पष्ट implementation है। विचार यह है: static HTML ship करें, फिर केवल interactive components — \u0026ldquo;islands\u0026rdquo; — को JavaScript के साथ hydrate करें [5]। Astro का client:* directive set आपको एक ही page पर React, Svelte, Vue, Solid और Lit components को mix करने देता है, प्रत्येक स्वतंत्र रूप से hydrated। 2024 के अंत में, Astro ने Server Islands जोड़े — dynamic server-rendered fragments जो main page response से अलग execute होते हैं, इसलिए एक slow API call पूरे page को block नहीं करता [5]।\nContent-heavy sites के लिए, यह वह architecture है जिस पर default करने लायक है। आप एक blog post render करने के लिए 200KB का React runtime ship नहीं कर रहे।\nResumability Qwik और भी aggressive रुख अपनाता है। Resumability hydration को पूरी तरह से अस्वीकार करती है [6]। Client पर event listeners attach करने के लिए components को फिर से चलाने के बजाय, Qwik listener references को HTML में serialize करता है (on:click=\u0026quot;./chunk.js#handler\u0026quot;) और chunks को demand पर load करने के लिए एक single global listener का उपयोग करता है [6]। Page server की serialized state से \u0026ldquo;resume\u0026rdquo; होता है — कोई framework code तब तक execute नहीं होता जब तक user वास्तव में किसी चीज़ से interact नहीं करता। सैद्धांतिक रूप से, Time to Interactive शून्य के करीब पहुँच जाता है।\nAstro + Qwik integration आपको दोनों patterns एक साथ प्राप्त करने देता है: default रूप से static, interactivity के लिए resumable islands [6]।\nBuild Tools: Webpack मर गया, Rust चिरायु हो तीन गंभीर bundlers बचे हैं [7]:\nTool सबसे उपयुक्त Cold Start (बड़ा app) Notes Vite 6 नए projects ~2s Rolldown (Rust) द्वारा संचालित, esbuild की जगह [8] Rspack Webpack migrations ~1.4s ByteDance द्वारा निर्मित, webpack-compatible config [8] Turbopack Next.js shops सबसे तेज़ HMR Next.js 16 में default, अन्य framework support नहीं [7] Vite 6.0 ने अपना production build engine Rolldown पर switch किया, एक Rust-based bundler जो Rollup की जगह लेता है। esbuild को 2026 के अंत तक production के लिए phase out किया जा रहा है [8]। यदि आप एक नया project शुरू कर रहे हैं, Vite अभी भी सही विकल्प है। यदि आप एक webpack codebase migrate कर रहे हैं, Rspack सबसे कम दर्दनाक रास्ता है — यह आपका existing webpack config और plugins स्वीकार करता है।\nWebpack खुद? अभी भी हजारों companies में production में चल रहा है। लेकिन 2026 में कोई भी इस पर नए projects शुरू नहीं कर रहा।\nUI Libraries: shadcn/ui ने Model बदल दिया यहाँ दिलचस्प बदलाव कोई नई library का जीतना नहीं है — यह developers के component libraries के बारे में सोचने के तरीके में एक बदलाव है।\nshadcn/ui ने एक अलग model को लोकप्रिय बनाया: आप code के मालिक हैं [11]। एक package install करके opaque components प्राप्त करने के बजाय जिन्हें आप inspect या customize नहीं कर सकते, shadcn/ui आपको components को सीधे अपने project में copy करने देता है। Styling, markup, behaviour पर पूर्ण नियंत्रण। यह Tailwind के साथ Radix UI primitives पर बना है, और 2026 में नए React apps के लिए default शुरुआती बिंदु बन गया है [11]।\nस्थापित players कहीं नहीं गए हैं:\nMUI — 97,000+ GitHub stars, 4.5M साप्ताहिक downloads, enterprise default [11] HeroUI (पहले NextUI) — 2025 की शुरुआत में rebrand हुआ, तेज़ी से बढ़ रहा [11] Chakra UI — 40,000+ stars, 700K downloads/week, अभी भी व्यापक रूप से उपयोग किया जाता है [11] Tailwind CSS utility-first styling में हावी रहता है। वहाँ अब ज़्यादा बहस नहीं बची।\nDesign Patterns जो वास्तव में टिके कुछ patterns इस cycle में \u0026ldquo;दिलचस्प विचार\u0026rdquo; से \u0026ldquo;production standard\u0026rdquo; की ओर आए [9]:\nSignals/Fine-grained reactivity — Svelte 5 Runes, SolidJS signals, और अब TC39 में एक Signals proposal प्रगति में है। VDOM दीर्घकालिक उत्तर नहीं हो सकता। CSS Container Queries — components जो viewport नहीं, बल्कि अपने parent container size के अनुकूल होते हैं। Media query hacks के बिना component libraries को वास्तव में reusable बनाता है [13]। Feature-Sliced Design (FSD) — एक folder structure convention जो code को feature के अनुसार, फिर layer के अनुसार organize करता है (pages → widgets → features → entities → shared)। बड़े React codebases में बढ़ती adoption क्योंकि flat components/ directories जल्दी unmaintainable हो जाती हैं [10]। Atomic Design — interfaces को atoms, molecules और organisms में विभाजित करता है। नया नहीं, लेकिन container queries और Server Components ने इसे नया जीवन दिया है [9]। TypeScript और AI-सहायता प्राप्त Development TypeScript अब professional frontend work में optional नहीं है [13]। यह हर प्रमुख framework के CLI के लिए default है। React 19, Angular 21, Vue 3.6, Svelte 5 — सभी out of the box पहले दर्जे के TypeScript support के साथ ship होते हैं। TypeScript जोड़ने पर बहस करने का युग 2024 के आसपास चुपचाप समाप्त हो गया।\nAI tooling (GitHub Copilot, Cursor, आदि) ने boilerplate के लिए workflow को वास्तव में बदल दिया है। AI का उपयोग करने वाले design-to-code tools standard UI patterns के लिए concept-to-implementation time को काफी कम कर सकते हैं [9]। लेकिन — और यह स्पष्ट रूप से कहने लायक है — AI-generated code को अभी भी एक developer की ज़रूरत है जो समझता है कि क्या generate हो रहा है। इस article में वर्णित mental models वही हैं जो एक developer को जो AI का अच्छी तरह से उपयोग करता है, उससे अलग करते हैं जो LLM जो भी output करता है उसे paste कर देता है।\nReact Compiler अपने आप में एक AI-adjacent automation है: यह आपके code को statically analyse करता है और जहाँ ज़रूरत हो वहाँ memoization insert करता है, बिना आपके कुछ किए performance bugs की एक पूरी श्रेणी को हटा देता है [3]। यह वास्तव में उपयोगी है।\nWebAssembly भी परिपक्व हो रहा है — video editing, image processing और 3D rendering जैसे computationally heavy tasks अब native apps के बिना सीधे browser में चलते हैं [2]। अभी भी niche, लेकिन \u0026ldquo;web app\u0026rdquo; और \u0026ldquo;native app\u0026rdquo; के बीच का अंतर देखना मुश्किल होता जा रहा है।\nअंत\nस्रोत Best Frontend Frameworks 2026: Every Major JavaScript Framework You Need to Know 5 Frontend Frameworks That Will Dominate 2026 (Performance + AI) Svelte 5 Runes vs. React 19 Hooks: Which Reactivity Model Scales Better? React 19 Compiler vs Svelte 5: Latency Benchmark Results Islands Architecture — Astro Docs Astro + Qwik: Houston, we have Resumability! Vite vs Turbopack vs Rspack Benchmark [2026 Compared] Vite vs Rspack vs Turbopack: 2026 Frontend Bundler Comparison Frontend Trends and Design Patterns to Watch in 2026 5 Frontend Trends That Will Dominate 2026 — Feature-Sliced Design 5 Best React UI Libraries for 2026 (And When to Use Each) React 19 vs Vue 3.6 vs Svelte 5: 2026 Framework Convergence Frontend Development Trends 2026: What Modern Web Teams Should Focus on Now The 8 trends that will define web development in 2026 ","permalink":"https://cloudmato.com/hi/posts/frontend-2026-frameworks-tools-design-patterns/","title":"Frontend 2026: नए Frameworks, Tools और Design Patterns"},{"content":"रोज़ QR कोड स्कैन करें और उन तीन वर्गों के बारे में कभी न सोचें। मैं भी सालों तक उसी श्रेणी में था। असल में ये वर्ग कुछ वाकई चतुर इंजीनियरिंग का काम कर रहे हैं — और उनकी संख्या ठीक तीन क्यों है, चार नहीं, यह उतना दिलचस्प है जितना आप सोच सकते हैं।\nइनका एक नाम है: फाइंडर पैटर्न तीन बड़े वर्गों को आधिकारिक तौर पर पोज़िशन डिटेक्शन पैटर्न कहा जाता है, हालाँकि लगभग सभी लोग इन्हें फाइंडर पैटर्न कहते हैं [4]। ये हर QR कोड के ऊपर-बाएँ, ऊपर-दाएँ और नीचे-बाएँ कोनों में होते हैं — नीचे-दाएँ कभी नहीं। यह असमानता जानबूझकर है, और यही पूरी बात है।\nहर फाइंडर पैटर्न तीन नेस्टेड वर्गों से बना होता है: एक ठोस काला बाहरी वर्ग, बीच में एक सफेद रिंग, और केंद्र में एक छोटा काला वर्ग [6]। जब कोई स्कैनर इन पैटर्न में से किसी क्षैतिज या ऊर्ध्वाधर रेखा के पार पढ़ता है, तो उसे गहरे और हल्के मॉड्यूल का एक बहुत खास क्रम दिखता है: 1:1:3:1:1 — एक काला, एक सफेद, तीन काले, एक सफेद, एक काला [6]।\nयह अनुपात इस बात से परे है कि QR कोड कितना बड़ा या छोटा है, या किस कोण से स्कैन किया जा रहा है। यही एकरूपता एक कैमरे को मिलीसेकंड में पैटर्न को पकड़ने देती है।\nविशेष रूप से 1:1:3:1:1 क्यों? QR कोड का आविष्कार 1994 में जापानी कंपनी Denso Wave के मासाहिरो हारा ने किया था, मूल रूप से असेंबली लाइनों पर कार के पुर्जों को ट्रैक करने के लिए [2]। हारा की टीम को एक ऐसे पैटर्न की ज़रूरत थी जिसे एक स्कैनर तुरंत खोज सके — चाहे वह मुद्रित टेक्स्ट, लोगो या पैकेजिंग ग्राफिक्स से घिरा हो। चुनौती यह थी: आप जो भी पैटर्न चुनें, वह आसपास के डिज़ाइन में गलती से प्रकट हो सकता है, जिससे स्कैनर गलत चीज़ को कोड की सीमा के रूप में पढ़ सकता है।\nउनका समाधान व्यवस्थित था। वह पैटर्न खोजो जो सामान्य मुद्रित सामग्री में कहीं भी प्रकट होने की सबसे कम संभावना रखता हो।\nउन्होंने वास्तव में असली फ्लायर, पत्रिकाएँ और गत्ते के डिब्बे खंगाले — सब कुछ काले-सफेद मॉड्यूल अनुपात में घटाया [1]। एक संपूर्ण विश्लेषण के बाद, 1:1:3:1:1 क्रम वह निकला जो मुद्रित सामग्री में लगभग कभी स्वाभाविक रूप से प्रकट नहीं होता था। तो उन्होंने पूरे फाइंडर पैटर्न को उसी अनुपात के इर्द-गिर्द बनाया।\nपैटर्न का भौतिक रूप — संकेंद्रित बारी-बारी से वर्ग — एक गो बोर्ड से प्रेरित था। काले और सफेद पत्थरों के विपरीत रंग ने हारा को नेस्टेड बारी-बारी मॉड्यूल के साथ काम करने का दृश्य विचार दिया [1]। छोटा विवरण है, लेकिन मुझे अच्छा लगता है कि एक बोर्ड गेम ने इंटरनेट पर सबसे अधिक स्कैन की जाने वाली छवियों में से एक को प्रभावित किया।\nतीन कोने — चार क्यों नहीं? यह अधिक दिलचस्प हिस्सा है।\nतीन बिंदु एक अद्वितीय ओरिएंटेशन परिभाषित करते हैं। चार समान बिंदु नहीं करते।\nयदि आपके पास L-आकार में तीन फाइंडर पैटर्न हैं (ऊपर-बाएँ, ऊपर-दाएँ, नीचे-बाएँ), तो स्कैनर वह L देखता है और तुरंत जान लेता है: यहाँ \u0026ldquo;ऊपर\u0026rdquo; कौन सा है, यहाँ ऊपरी-बाएँ एंकर है, यहाँ ग्रिड कैसे उन्मुख है [3][5]। इससे कोई फर्क नहीं पड़ता कि QR कोड उल्टा है, 45 डिग्री घुमाया हुआ है, या किसी बोतल के किनारे पर मुद्रित है — L-आकार अस्पष्टता को बिना किसी संदेह के हल कर देता है।\nचार समान बड़े वर्ग एक समस्या होते। स्कैनर चार संभावित \u0026ldquo;सही\u0026rdquo; ओरिएंटेशन देखता और यह तय करने का कोई तरीका नहीं होता कि वास्तव में कौन सा सही है [5]। आपको अस्पष्टता को हल करने के लिए कोड में कहीं और अतिरिक्त जानकारी की ज़रूरत होती, जो डिटेक्शन पैटर्न होने के उद्देश्य को ही विफल कर देती।\nनीचे-दाएँ कोने को इसके बजाय बड़े QR कोड (Version 2 और उससे ऊपर) में एक छोटा अलाइनमेंट पैटर्न मिलता है — एक 5×5 नेस्टेड वर्ग जिसका काम अलग है: तब परिप्रेक्ष्य विकृति को सुधारना जब कोड किसी घुमावदार सतह पर हो या तीव्र कोण से पढ़ा जा रहा हो [6]। यह मदद करता है लेकिन यह फाइंडर पैटर्न नहीं है। असमानता ही विशेषता है।\nकोड संरचना का बाकी हिस्सा फाइंडर पैटर्न से परे, QR कोड में कई अन्य कार्यात्मक क्षेत्र होते हैं [4]:\nटाइमिंग पैटर्न: फाइंडर पैटर्न के बीच क्षैतिज और ऊर्ध्वाधर रूप से चलने वाली बारी-बारी काली-सफेद रेखाएँ — ये एक रूलर की तरह काम करती हैं, जिससे स्कैनर मॉड्यूल का आकार माप सकता है और डेटा ग्रिड को सटीक रूप से बिछा सकता है फॉर्मेट जानकारी: फाइंडर पैटर्न के पास एक पट्टी जो त्रुटि सुधार स्तर और कौन सा डेटा मास्क पैटर्न लागू किया गया था, एन्कोड करती है — लचीलेपन के लिए दो जगह दोहराई जाती है क्वाइट ज़ोन: पूरे कोड के चारों ओर खाली सफेद बॉर्डर — ISO 18004 के अनुसार न्यूनतम 4 मॉड्यूल चौड़ा [8]। इसे हटाएँ और स्कैनर आस-पास के ग्राफिक्स को कोड का हिस्सा समझने लगते हैं वर्शन जानकारी: Version 7 और उससे ऊपर के कोड के लिए, अतिरिक्त ब्लॉक वर्शन नंबर (1–40) स्टोर करते हैं, स्कैनर को बताते हैं कि कितनी पंक्तियाँ और कॉलम अपेक्षित हैं [4] वर्शन 1 (21×21 मॉड्यूल, ~25 अल्फान्यूमेरिक अक्षर) से 40 (177×177 मॉड्यूल, ~4,000+ अक्षर) तक जाते हैं। वर्शन बढ़ने के साथ अलाइनमेंट पैटर्न की संख्या भी बढ़ती है।\nत्रुटि सुधार: क्षतिग्रस्त QR कोड फिर भी काम क्यों करते हैं आपने यह ज़रूर देखा होगा — एक QR कोड जिसके बीच में कंपनी का लोगो लगा हो और फिर भी स्कैन होता हो। यह रीड-सोलोमन त्रुटि सुधार है, संयोग नहीं [7]।\nकोड वास्तविक पेलोड से गणना किए गए अतिरिक्त डेटा को स्टोर करता है। जब तक मॉड्यूल का पर्याप्त अनुपात बचा रहता है, स्कैनर गणितीय रूप से मूल डेटा को पुनर्निर्मित कर सकता है — भले ही बचे हुए मॉड्यूल यादृच्छिक रूप से बिखरे हों। चार त्रुटि सुधार स्तर हैं:\nस्तर अधिकतम पुनर्प्राप्त करने योग्य डेटा L 7% M 15% Q 25% H 30% Level H इसीलिए है कि आप QR कोड के लगभग 30% हिस्से को लोगो से ढककर भी स्कैन कर सकते हैं [7]। डिज़ाइनर इसका जानबूझकर फायदा उठाते हैं — Level H पर कोड जनरेट करें, फिर केंद्र पर आर्टवर्क लगाएँ। यह आमतौर पर काम करता है जब तक फाइंडर पैटर्न बरकरार रहते हैं।\nऔर यही बात है — फाइंडर पैटर्न स्वयं त्रुटि सुधार से कवर नहीं होते। वे संरचनात्मक हैं। यदि तीनों बुरी तरह क्षतिग्रस्त या अस्पष्ट हैं, तो कोई भी रीड-सोलोमन गणित स्कैन को रिकवर नहीं कर सकता। स्कैनर को पहली जगह कोड मिलेगा ही नहीं।\nतीन वर्ग सजावट नहीं हैं। वे बाकी सब चीज़ों का प्रवेश द्वार हैं।\nसमाप्त\nस्रोत QR Code Development Story — DENSO WAVE History of QR Code — QRcode.com / DENSO WAVE QR code — Wikipedia What is QR Code Structure and How Does It Work? — Scanova QR code anatomy explained — QR Code Kit QR Code Anatomy: Finder Patterns \u0026amp; Error Correction — FileFusion QR Code Error Correction Explained — Scanova What is a QR Code Quiet Zone and Why Does It Matter? — QR Code Generator ","permalink":"https://cloudmato.com/hi/posts/why-qr-codes-have-three-squares/","title":"QR कोड के कोनों में तीन वर्ग क्यों होते हैं"},{"content":"आप एक API एंडपॉइंट /api/orders/1042 एक्सपोज़ करते हैं। वह इंटीजर किसी को भी — एक प्रतिस्पर्धी, एक हमलावर, एक जिज्ञासु उपयोगकर्ता — बिल्कुल बता देता है कि आपके पास कितने ऑर्डर हैं। नंबर को 1041 में बदलें, तो पिछला ऑर्डर मिल जाता है। इसे 1 में बदलें, तो पहला ऑर्डर मिल जाता है। कोई auth bypass की ज़रूरत नहीं। ID खुद ही जानकारी का रिसाव है।\nयही एक पैराग्राफ में अनुक्रमिक ID की समस्या है। UUID इसे ठीक करने के लिए मौजूद है — और कुछ अन्य चीज़ें जो स्केल पर मायने रखती हैं।\nUUID वास्तव में क्या है? UUID का अर्थ है Universally Unique Identifier। यह एक 128-बिट संख्या है, जिसे 32 हेक्साडेसिमल कैरेक्टर के रूप में दर्शाया जाता है, जो पाँच समूहों में हाइफ़न से विभाजित होती है [1]:\n550e8400-e29b-41d4-a716-446655440000 फॉर्मेट हमेशा 8-4-4-4-12 होता है — यह प्रति समूह hex कैरेक्टर की संख्या है, चार हाइफ़न सहित कुल 36 [2]। 13वाँ कैरेक्टर वर्शन एनकोड करता है। 17वाँ कैरेक्टर वेरिएंट एनकोड करता है। तो ऊपर वाले UUID में — तीसरा समूह 4 से शुरू होता है, यानी वर्शन 4 [3]।\nUUID उत्पन्न करने के लिए किसी केंद्रीय अधिकारी की ज़रूरत नहीं। कोई डेटाबेस autoincrement सीक्वेंस नहीं। कोई क्रॉस-सर्वर समन्वय नहीं। कोई भी सिस्टम, कहीं भी, एक UUID उत्पन्न कर सकता है और लगभग निश्चित हो सकता है कि किसी और ने वही नहीं बनाया [1]।\nUUID वर्शन — ये सब एक जैसे नहीं हैं अधिकांश लेख वर्शन सूचीबद्ध करते हैं बिना यह समझाए कि यह आपके डेटाबेस के लिए वास्तव में क्यों मायने रखता है। यह मायने रखता है।\nवर्शन कैसे उत्पन्न होता है क्रमबद्ध? गोपनीयता v1 Timestamp + MAC address ✅ हाँ ❌ MAC address लीक करता है v3 namespace + name का MD5 hash ✅ निर्धारक N/A v4 पूरी तरह random (122 bits) ❌ नहीं ✅ अच्छा v5 namespace + name का SHA-1 hash ✅ निर्धारक N/A v7 Unix timestamp + random bits ✅ हाँ ✅ अच्छा v4 वह है जो अधिकांश लोग आज उपयोग करते हैं। Random, सरल, कोई गोपनीयता चिंता नहीं। लेकिन इसमें एक महत्वपूर्ण डेटाबेस परफॉरमेंस समस्या है जिस पर मैं बाद में आऊँगा [3]।\nv7 वह है जो आपको नए प्रोजेक्ट्स के लिए उपयोग करना चाहिए। RFC 9562 (मई 2024 में प्रकाशित) में पेश किया गया, v7 एक 48-बिट Unix मिलीसेकंड timestamp को 74 random bits के साथ जोड़ता है [2]। आपको अपना MAC address लीक किए बिना time-ordering मिलती है।\nCollision का सवाल \u0026ldquo;अगर दो सिस्टम एक ही UUID उत्पन्न करें तो?\u0026rdquo;\nVersion 4 UUIDs में 122 bits की randomness है। कुल संभावित मान: 2¹²⁸ ≈ 3.4×10³⁸। एक भी collision की 50% संभावना उत्पन्न करने के लिए, आपको 2.71 क्विंटिलियन v4 UUID उत्पन्न करने होंगे [4]। 1 ट्रिलियन UUID उत्पन्न करने से collision की संभावना लगभग 10⁻¹⁵ होती है [4]। यानी एक क्वाड्रिलियन में से एक संभावना।\nआप इस बारे में चिंता नहीं करने वाले।\nअनुक्रमिक IDs की असली समस्या अनुक्रमिक IDs — SERIAL या AUTO_INCREMENT — सरल और तेज़ हैं। एक सिंगल सर्वर पर छोटे ऐप के लिए, ये बिल्कुल ठीक हैं। समस्याएं दो विशिष्ट क्षेत्रों में सामने आती हैं।\nसुरक्षा: Enumeration और IDOR पूर्वानुमानित IDs Insecure Direct Object Reference (IDOR) हमलों को बेहद आसान बना देते हैं [5]। IDOR OWASP Top 10 में है — यह एक कारण से सबसे अधिक exploit की जाने वाली vulnerability classes में से एक है [6]।\nअनुक्रमिक IDs के साथ, अगर मुझे पता है कि मेरा user ID 4821 है, तो मैं 4820, 4819, 4818\u0026hellip; आज़मा सकता हूँ और अन्य उपयोगकर्ताओं के डेटा तक पहुँच सकता हूँ अगर आपके authorization checks कमज़ोर हैं या बिल्कुल नहीं हैं। UUID के साथ, a47c3f2e-91bb-4d2e-b3f0-c6e88d3f0a1c का अगला अनुमान लगाना कम्प्यूटेशनल रूप से असंभव है।\nमैं यहाँ एक बात स्पष्ट करना चाहता हूँ: UUID उचित authorization checks का विकल्प नहीं हैं। अगर आपके ऐप में IDOR vulnerabilities हैं, तो उन्हें authorization layer पर ठीक करना प्राथमिक समाधान है। UUID बस floor को काफी ऊँचा उठा देते हैं [5]।\nअनुक्रमिक IDs business intelligence भी लीक करते हैं जो आप शायद नहीं चाहते। एक प्रतिस्पर्धी जनवरी में /api/invoices/1 और दिसंबर में /api/invoices/8500 स्क्रैप करके अब पूरे साल का आपका invoice volume जान लेता है। यह वास्तव में होता है।\nवितरित प्रणालियाँ: सिंगल-नोड समस्या अनुक्रमिक IDs को केंद्रीकृत generation की ज़रूरत होती है। एक integer को एक समय में एक नोड पर reliably autoincrement करना काम करता है [7]।\nजैसे ही आपके पास एक साथ लिखने वाले कई database replicas हों, regions में data sharding, स्वतंत्र रूप से रिकॉर्ड उत्पन्न करने वाली microservices, या offline-capable mobile clients — अनुक्रमिक IDs एक coordination nightmare बन जाते हैं। अगला integer उत्पन्न करने वाले दो नोड बिना केंद्रीय coordinator के collision करेंगे।\nUUID को किसी coordinator की ज़रूरत नहीं। प्रत्येक सर्विस, प्रत्येक region, प्रत्येक डिवाइस स्वतंत्र रूप से IDs उत्पन्न कर सकता है और बाद में बिना conflicts के डेटा merge कर सकता है [1]। यह architecturally महत्वपूर्ण है।\nUUID वास्तव में कहाँ कमज़ोर पड़ता है UUID हर स्थिति में सख्ती से बेहतर नहीं हैं। मैं trade-offs के बारे में ईमानदार रहूँगा।\nStorage cost — UUID के लिए 16 bytes बनाम integer के लिए 4–8 bytes। सैकड़ों करोड़ rows और multiple foreign key references वाली table पर, यह बढ़ता जाता है [7]। Human-readability — 42 कहना support call पर 550e8400-e29b-41d4-a716-446655440000 से आसान है। यहाँ अनुक्रमिक IDs हमेशा जीतते हैं। v4 के साथ index performance — यही वह है जो production में लोगों को परेशान करता है। जब आप UUID v4 को primary key के रूप में उपयोग करते हैं, तो प्रत्येक insert B-tree index में एक random position पर जाता है। डेटाबेस को लगातार rebalance करना पड़ता है। Pages fragment हो जाते हैं। Cache locality प्रभावित होती है। v4 UUIDs के साथ high write volumes पर, index performance अनुक्रमिक integers की तुलना में स्पष्ट रूप से खराब हो जाती है [7][8]।\nv7 परफॉरमेंस समस्या को ठीक करता है इसीलिए v7 मायने रखता है। millisecond timestamp prefix का मतलब है कि v7 UUID time-ordered हैं। Inserts अधिकांशतः sequential हैं — index एक दिशा में बढ़ता है, fragmentation कम रहती है, cache behavior अच्छा है [2][8]।\nअगर आप वर्तमान में high-write tables पर primary keys के रूप में v4 UUID का उपयोग कर रहे हैं, तो v7 में migrate करना विचार करने योग्य है। अधिकांश भाषाओं और platforms की UUID libraries ने RFC 9562 आने के बाद v7 support जोड़ लिया है [2]।\nआपको मिलता है:\nUUID का distributed generation लाभ सुरक्षा लाभ (non-guessable) अनुक्रमिक integers के करीब index performance कोई MAC address रिसाव नहीं (v1 के विपरीत) अनुक्रमिक IDs अभी भी ठीक कब हैं बहुत सारे अनुप्रयोगों के लिए, अनुक्रमिक IDs सही विकल्प हैं।\nInternal tools जो कभी बाहरी रूप से exposed नहीं होते Reference/lookup tables (status codes, categories) जहाँ ID कभी user-facing नहीं होता सिस्टम जो single database node पर चलने की गारंटी है और sharding की कोई योजना नहीं गलती अनुक्रमिक IDs का उपयोग करना नहीं है — गलती है हर जगह बिना सोचे-समझे डिफ़ॉल्ट रूप से उनका उपयोग करना। 2026 में /api/users/1 को publicly expose करना और यह नहीं सोचना कि यह क्या leak कर रहा है, बस लापरवाही है।\nEnd\nस्रोत Universally unique identifier — Wikipedia RFC 9562: Universally Unique IDentifiers (UUIDs) — RFC Editor UUID Versions Explained — UUIDTools.com UUID Collision Probability: Can Two UUIDs Ever Be the Same? — SecureBin Replace Sequential IDs With UUIDs to Prevent IDOR Vulnerabilities or Scraping — HackerNoon Insecure Direct Object Reference (IDOR) — OWASP Foundation UUID vs. Sequential ID as Primary Key — Baeldung Goodbye to Sequential Integers, Hello UUIDv7! — Buildkite ","permalink":"https://cloudmato.com/hi/posts/uuid-vs-sequential-ids-explained/","title":"UUID बनाम अनुक्रमिक IDs: क्या, क्यों, और कौन सा चुनें"},{"content":"OOP 50+ साल पुराना है। Classes, objects, inheritance — यह काम करता है, सब इसे जानते हैं, और लगभग हर लोकप्रिय भाषा इसे support करती है। तो फिर लोग Functional Programming की बात ऐसे क्यों कर रहे हैं जैसे यह कोई नई खोज हो? क्योंकि OOP चीज़ों को model करने में बेहतरीन है। FP बदलावों (transformations) को model करने में। ज़्यादातर असली software में दोनों होते हैं, और इन दोनों को एक समझना ही असली उलझन की जड़ है।\nFunctional Programming वास्तव में क्या है? \u0026ldquo;class के अंदर functions\u0026rdquo; — यह नहीं। वह तो बस functions वाला OOP है।\nFunctional Programming एक paradigm है जहाँ आप software को pure functions को compose करके बनाते हैं — ऐसे functions जो एक ही input पर हमेशा एक ही output देते हैं और अपने बाहर किसी चीज़ को नहीं छूते [1]।\nइसे तीन विचार परिभाषित करते हैं:\nPure functions — कोई side effects नहीं, कोई छिपे हुए state changes नहीं। add(2, 3) हमेशा 5 ही लौटाता है, चाहे कुछ भी हो। Immutability — एक बार data बन जाने के बाद उसे बदला नहीं जाता। इसके बजाय नया data बनाया जाता है [2]। Higher-order functions — ऐसे functions जो दूसरे functions को argument के रूप में लेते हैं या उन्हें return करते हैं। map, filter, reduce इसके पाठ्यपुस्तक उदाहरण हैं [3]। बाकी सब — monads, functors, currying — इन्हीं तीन के ऊपर बने हैं। FP का फ़ायदा उठाने के लिए इन सबको समझना ज़रूरी नहीं। ज़्यादातर developers कभी monads को नहीं छूते और फिर भी हर रोज़ साफ़-सुथरा functional code लिखते हैं।\nOOP असफल नहीं होता। बस उसके कुछ अंधे कोने हैं। सीधे बात करूँ: OOP बुरा नहीं है। मैं इसे हर रोज़ इस्तेमाल करता हूँ। लेकिन कुछ खास situations में यह आपकी ज़िंदगी को सच में मुश्किल बना देता है।\nShared mutable state दुश्मन है OOP में objects state रखते हैं। उस UserService instance में एक currentUser field है। आपके CartManager में एक items array है। App के कई हिस्से इन्हें पढ़ते और लिखते हैं। और फिर किसी बिंदु पर एक ऐसा bug सामने आता है जिसे आप reliably reproduce नहीं कर सकते — क्योंकि state को एक साथ दो जगहों से बदला जा रहा था [4]।\nयह कोई काल्पनिक बात नहीं है। यह बड़े OOP codebases की रोज़मर्रा की हकीकत है। Shared state को track करना मुश्किल होता है, और किसी object को दो अलग-अलग जगहों से बदलना async या concurrent code में race conditions की नुस्खा है। FP की immutability bugs की इस पूरी श्रेणी को ही हटा देती है — आप data अंदर डालते हैं, data बाहर आता है, पर्दे के पीछे कुछ भी mutate नहीं होता [5]।\nOOP code को test करना उससे ज़्यादा मेहनत माँगता है जितनी होनी चाहिए this.db, this.cache, और this.config पर निर्भर किसी method को test करने के लिए आपको mocks चाहिए। एक test के लिए कम से कम तीन mocks। और जब class में 20 methods और 8 dependencies हों, तो आपका test setup असली test से लंबा हो जाता है।\nएक pure function को इनमें से कुछ भी नहीं चाहिए। Input दो, output check करो। बस यही test है [1]।\nहर Paradigm वास्तव में कहाँ चमकता है स्थिति बेहतर विकल्प असल दुनिया की चीज़ों को model करना (User, Order, Car) OOP Data pipelines और transformations FP Concurrent या parallel code FP Lifecycle management वाले UI components OOP Event processing, stream handling FP कई collaborating actors वाला बड़ा system OOP (सावधानी के साथ) ETL, analytics, batch jobs FP GUI frameworks, game entities OOP यह \u0026ldquo;FP जीतता है\u0026rdquo; वाली table नहीं है। बहुत सी situations में OOP सही choice है [6]।\nहाँ, आप दोनों का उपयोग कर सकते हैं — और ज़्यादातर Codebases पहले से ऐसा करते हैं JavaScript, Python, Scala, Kotlin, Java (Java 8 से), यहाँ तक कि C# — ये सब multi-paradigm languages हैं [7]। ये आपको एक तरफ़ चुनने पर मजबूर नहीं करतीं।\nएक typical JavaScript codebase देखें:\n// OOP for structure class UserRepository { constructor(db) { this.db = db; } async findById(id) { return this.db.query(`SELECT * FROM users WHERE id = ?`, [id]); } } // FP for transformation const formatUsers = (users) =\u0026gt; users .filter(u =\u0026gt; u.isActive) .map(u =\u0026gt; ({ id: u.id, name: u.name.trim().toLowerCase() })); UserRepository classic OOP है। formatUsers pure FP है — कोई side effects नहीं, एक ही input हमेशा एक ही output देता है। दोनों एक ही file में, एक ही project में, बिना किसी टकराव के रहते हैं [8]।\nयह उलझन में paradigms को मिलाना नहीं है। यह हर काम के लिए सही औज़ार इस्तेमाल करना है।\nबिना गड़बड़ी के इन्हें Actually कैसे Mix करें मेरा नियम: OOP से अपनी structure और boundaries परिभाषित करें, उन boundaries के अंदर की logic के लिए FP इस्तेमाल करें।\nव्यवहार में:\nServices, repositories, और ऐसे components के लिए classes जिन्हें lifecycle management चाहिए। Business logic, data transformations, और validation rules के लिए pure functions। Class methods के अंदर भारी transformation logic डालने से बचें — इसे pure functions में निकालें जिन्हें independently test किया जा सके। किसी variable को in-place mutate करने वाले for loops की जगह map, filter, reduce इस्तेमाल करें। Python का उदाहरण:\n# OOP for the service boundary class OrderService: def __init__(self, db): self.db = db def get_pending_orders(self, user_id): rows = self.db.fetch(user_id) return process_orders(rows) # delegate to a pure function # FP for the logic — trivial to test in isolation def process_orders(orders): return [ {**o, \u0026#34;total\u0026#34;: o[\u0026#34;price\u0026#34;] * o[\u0026#34;quantity\u0026#34;]} for o in orders if o[\u0026#34;status\u0026#34;] == \u0026#34;pending\u0026#34; ] process_orders की database, service, या किसी भी बाहरी चीज़ पर शून्य निर्भरता है। इसे test करना एक function call है, कोई mocks नहीं [8]।\nजिन Languages ने यह फ़ैसला पहले ही कर लिया Scala को सचमुच इसी के लिए design किया गया था — हर value एक ही साथ object और function दोनों है [7]। React का class components से hooks की तरफ़ बदलाव, functionally speaking, UI logic के लिए FP की दिशा में एक कदम था। Redux, JavaScript app के अंदर pure FP है। Java ने Java 8 में Stream, Optional, lambdas, और Function\u0026lt;T,R\u0026gt; को specifically एक OOP language में FP patterns लाने के लिए जोड़ा [3]।\nIndustry ने पहले ही vote कर दिया है। Multi-paradigm अब default है, exception नहीं।\nएक बात जिस पर ध्यान देना ज़रूरी है Paradigms को mix करना ठीक है। उन्हें बिना किसी स्पष्ट convention के mix करना — यही वह तरीका है जिससे आप ऐसे code के साथ फँस जाते हैं जिसे कोई नहीं समझ सकता। मैंने ऐसे codebases देखे हैं जहाँ कुछ files पूरी तरह OOP हैं, कुछ पूरी तरह functional, और कुछ बिना किसी स्पष्ट कारण के दोनों हैं। Team logic पढ़ने से ज़्यादा समय style decode करने में लगाती है।\nएक convention चुनें: shell के लिए OOP, fill के लिए FP। इसे एक बार अपनी team की guidelines में लिख दें। बस इतना काफ़ी है।\nसमाप्त\nस्रोत Functional programming vs object-oriented programming (OOP) — CircleCI Functional Programming Paradigm — GeeksforGeeks What is Functional Programming? Explained in Python, JS, and Java — Educative Functional programming vs OOP: comparing paradigms — Imaginary Cloud Functional Programming vs Object-Oriented Programming in Data Analysis — DataCamp Harnessing the Power of OOP and FP Paradigms in Software Development — DEV Community Top 5 Functional Programming Languages — Coursera Combining Object-Oriented and Functional Programming in Large Projects — DEV Community ","permalink":"https://cloudmato.com/hi/posts/functional-programming-vs-oop-do-you-need-both/","title":"जब OOP मौजूद है तो Functional Programming क्यों इस्तेमाल करें?"},{"content":"Kubernetes क्लस्टर सेटअप करने वाला हर कोई अंततः एक ही दीवार से टकराता है: मैं इस चीज़ में ट्रैफ़िक कैसे लाऊं? फिर डॉक्स में ClusterIP, NodePort, LoadBalancer, Ingress, Gateway API, MetalLB का जिक्र होता है — और मामला उलझता जाता है। इससे भी बुरी बात यह है कि Service का एक type \u0026ldquo;LoadBalancer\u0026rdquo; है और असली लोड बैलेंसर भी हैं, और ये दोनों एक ही चीज़ नहीं हैं। मैं वास्तविक विकल्पों के बारे में बताऊंगा, हर एक स्टैक में कहाँ बैठता है, और किस स्थिति में किसका उपयोग करना वाकई समझदारी है।\nदो तरह का ट्रैफ़िक कोई भी लोड बैलेंसर तंत्र चुनने से पहले यह जानना जरूरी है कि आप असल में कौन सी समस्या हल कर रहे हैं।\nईस्ट-वेस्ट ट्रैफ़िक क्लस्टर के अंदर पॉड-से-पॉड संचार है — जैसे आपकी auth service आपकी user service को कॉल कर रही हो। Kubernetes इसे नेटिव रूप से संभालता है। हर Service को एक स्थिर वर्चुअल IP और एक DNS नाम मिलता है, और हर नोड पर चलने वाला kube-proxy स्वस्थ पॉड्स में पैकेट राउंड-रॉबिन करने के लिए iptables (या बड़े क्लस्टर में IPVS) को प्रोग्राम करता है [1]। ईस्ट-वेस्ट ट्रैफ़िक के लिए आपको बाहरी लोड बैलेंसर की बिल्कुल जरूरत नहीं है।\nनॉर्थ-साउथ ट्रैफ़िक इंटरनेट से बाहरी क्लाइंट का आपके ऐप तक पहुंचना है। Kubernetes जानबूझकर बाहरी नेटवर्किंग लेयर खुद प्रोविज़न नहीं करता — वह इसे क्लाउड प्रोवाइडर इंटीग्रेशन या जो भी आप प्लग इन करते हैं उसे सौंप देता है [1]। यहीं पर नीचे दिए सभी विकल्प काम आते हैं।\nपाँच विकल्प कोई एक सही जवाब नहीं है। हर तंत्र समस्या की एक अलग लेयर को लक्षित करता है।\nविकल्प OSI लेयर बाहरी IP मिलता है? सबसे उपयुक्त ClusterIP L4 (आंतरिक) नहीं क्लस्टर के अंदर पॉड-से-पॉड NodePort L4 नोड IP के ज़रिए (हैक) केवल लोकल डेव और त्वरित परीक्षण Service type LoadBalancer L4 हाँ — प्रति Service एक थोड़े महत्वपूर्ण Services के लिए Ingress + Controller L7 (HTTP/HTTPS) साझा, सभी के लिए एक एकाधिक HTTP सेवाएं, एकल IP Gateway API L4 + L7 साझा नए क्लस्टर, Ingress की जगह ClusterIP डिफ़ॉल्ट Service type [1]। एक क्लस्टर-आंतरिक वर्चुअल IP असाइन करता है जिसे केवल क्लस्टर के अंदर के पॉड ही पहुंच सकते हैं। माइक्रोसेवाएं आपस में बात करने के लिए यही काफी है। जब तक कुछ बाहरी रूप से एक्सपोज़ करने का ठोस कारण न हो, ClusterIP को डिफ़ॉल्ट रखें। वास्तविक क्लस्टर की अधिकांश सेवाओं को बाहरी IP की ज़रूरत नहीं होती — उन्हें बस यह चाहिए कि दूसरी सेवाएं उन्हें ढूंढ सकें।\nNodePort हर नोड पर 30000–32767 रेंज में एक पोर्ट खोलता है [2]। किसी भी नोड पर उस पोर्ट पर आने वाला ट्रैफ़िक Service को फॉरवर्ड हो जाता है। तकनीकी रूप से बाहरी क्लाइंट तक पहुंचता है लेकिन यह एक हैक है — आप नॉन-स्टैंडर्ड पोर्ट एक्सपोज़ कर रहे हैं, बदलने वाले नोड IPs पर निर्भर हैं, और किसी भी असली इन्फ्रास्ट्रक्चर-स्तरीय लोड बैलेंसिंग को बायपास कर रहे हैं। मैंने kind या minikube पर NodePort का उपयोग किया है ताकि जल्दी जांच सकूं कि कुछ काम करता है या नहीं। प्रोडक्शन में कभी नहीं।\nService type LoadBalancer जब आप किसी Service पर type: LoadBalancer सेट करते हैं, तो Kubernetes अंतर्निहित क्लाउड प्रोवाइडर से वास्तविक लोड बैलेंसर प्रोविज़न करने और बाहरी IP असाइन करने के लिए कहता है [1][3]। AWS पर आपको NLB या ALB (annotations पर निर्भर) मिलता है, GCP पर एक रीजनल TCP/UDP लोड बैलेंसर, Azure पर एक Azure LB के साथ पब्लिक IP।\nसमस्या यह है: हर LoadBalancer Service अपना अलग क्लाउड लोड बैलेंसर प्रोविज़न करती है। 20-सेवा वाले एप्लिकेशन पर वह 20 प्रोविज़न किए गए लोड बैलेंसर और 20 बाहरी IPs हैं। लागत जल्दी बढ़ती है, और ऑपरेशनल ओवरहेड वास्तविक है [3]। इस type का उपयोग उन थोड़ी सी सेवाओं के लिए करें जहाँ आपको वाकई एक समर्पित बाहरी endpoint चाहिए। क्लस्टर की हर सेवा के लिए डिफ़ॉल्ट पैटर्न के रूप में नहीं।\nIngress + Controller HTTP वर्कलोड के लिए अधिकांश टीमें यहीं पहुंचती हैं। एक Ingress resource रूटिंग नियम परिभाषित करता है — /api/* को service-a पर रूट करो, /web/* को service-b पर रूट करो — और एक Ingress Controller (nginx, Traefik, HAProxy, आदि) उन्हें क्लस्टर के अंदर लागू करता है [3]।\nIngress Controller के सामने आपको अभी भी ठीक एक बाहरी लोड बैलेंसर चाहिए, लेकिन फिर आपकी सारी HTTP/HTTPS रूटिंग एकल बाहरी IP के पीछे क्लस्टर के अंदर होती है। TLS termination controller पर होती है। प्रति सेवा एक लोड बैलेंसर से बहुत सस्ता।\nहालांकि दो वास्तविक सीमाएं हैं। पहली, Ingress केवल HTTP के लिए है। TCP/UDP रूटिंग के लिए अधिकांश controllers को कस्टम annotations चाहिए, जो vendor-specific हैं और portable नहीं [4]। दूसरी, Kubernetes प्रोजेक्ट ने Ingress API को फ्रीज़ कर दिया है। कोई नई सुविधाएं नहीं जोड़ी जा रही [5]। मौजूदा सेटअप के लिए यह ठीक काम करता है, लेकिन नई सुविधाएं Gateway API में जा रही हैं।\nGateway API Gateway API, Ingress का उचित उत्तराधिकारी है, जो 2026 तक Layer 4 और Layer 7 दोनों के लिए GA हो चुका है [4][5]। यह मुख्य कमियों को दूर करता है:\nनेटिव TCP, UDP, और gRPC सपोर्ट — केवल HTTP/HTTPS नहीं रोल-ओरिएंटेड डिज़ाइन — क्लस्टर ऑपरेटर Gateway resource के मालिक हैं (इन्फ्रास्ट्रक्चर); ऐप डेवलपर HTTPRoute या TCPRoute के मालिक हैं (रूटिंग नियम)। अलग-अलग ऑब्जेक्ट, अलग-अलग RBAC। समन्वय की परेशानी नहीं [4] Portable — स्पेसिफिकेशन सभी implementations में एक समान है: Envoy Gateway, Istio, NGINX, Cilium, Kong, Traefik। vendor-specific annotations नहीं [4] अगर आप आज नया क्लस्टर शुरू कर रहे हैं, तो Gateway API का उपयोग करें। प्रमुख क्लाउड प्रोवाइडर इसे सीधे सपोर्ट करते हैं। Ingress सालों तक काम करेगा लेकिन यह सिर्फ तकनीकी ऋण जमा कर रहा है [5]।\nबेयर मेटल के बारे में क्या? क्लाउड प्रोवाइडर आपके लिए LoadBalancer Service की प्लंबिंग पारदर्शी रूप से जोड़ते हैं। बेयर मेटल पर — सेल्फ-मैनेज्ड VMs, ऑन-प्रेम रैक, k3s चलाने वाला होम लैब — कोई क्लाउड प्रोवाइडर नहीं होता। आपकी type: LoadBalancer Services अनिश्चित काल के लिए \u0026lt;pending\u0026gt; अवस्था में रहेंगी [6]।\nMetalLB मानक समाधान है। यह आपके क्लस्टर को अपना IP पूल देता है और उन IPs को Layer 2 (ARP) या BGP के ज़रिए advertise करता है [7]। आप अपने लोकल नेटवर्क पर IPs की एक रेंज निर्धारित करते हैं, MetalLB को IPAddressPool के साथ कॉन्फ़िगर करते हैं, और यह LoadBalancer Services के लिए IP असाइनमेंट संभाल लेता है।\nसामान्य बेयर-मेटल स्टैक:\nMetalLB आपके पूल से Ingress Controller की Service को एक IP असाइन करता है Ingress Controller (nginx-ingress, Traefik) HTTP रूटिंग और TLS संभालता है आंतरिक सेवाएं ClusterIP पर रहती हैं # MetalLB के लिए IPs आरक्षित करें — नोड IPs या DHCP-प्रबंधित पते दोबारा उपयोग न करें apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: local-pool namespace: metallb-system spec: addresses: - 192.168.1.200-192.168.1.210 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: default namespace: metallb-system MetalLB फेलओवर भी संभालता है — अगर IP advertise करने वाला नोड डाउन हो जाता है, तो यह दूसरे नोड से re-advertise करता है। क्लाइंट के लिए IP स्थिर रहता है [7]।\nक्लाउड क्लस्टर: AWS EKS उदाहरण EKS पर, आप AWS Load Balancer Controller इंस्टॉल करते हैं जो Kubernetes Service और Ingress ऑब्जेक्ट को असली AWS संसाधनों में बदलता है [8]। मैपिंग सीधी है:\nK8s ऑब्जेक्ट AWS संसाधन यह क्या करता है Service (type LoadBalancer) AWS Network Load Balancer (NLB) L4, स्थिर IP, TCP/UDP Ingress AWS Application Load Balancer (ALB) L7, WAF, Cognito, पाथ रूटिंग HTTPRoute (Gateway API) Gateway API controller के ज़रिए ALB L7, आधुनिक declarative config एक बात जो मुझे परेशान कर चुकी है: किसी मौजूदा Service पर service.beta.kubernetes.io/aws-load-balancer-type annotation कभी न बदलें। अगर इसे बदलना ज़रूरी है, तो Service हटाएं और दोबारा बनाएं। इन-प्लेस बदलाव से AWS संसाधन लीक होते हैं जो साफ नहीं होते [8]।\nEKS Auto Mode अब LoadBalancer Service बनाने पर NLB प्रोविज़निंग स्वचालित रूप से संभालता है — कोई अतिरिक्त controller इंस्टॉलेशन नहीं [8]। बुनियादी NLB ज़रूरतों से परे किसी भी चीज़ के लिए, Load Balancer Controller अभी भी सही टूल है।\nअंदर या बाहर? दोनों। यह सवाल ही थोड़ा गलत है। प्रोडक्शन Kubernetes लोड बैलेंसिंग हमेशा स्तरीय होती है, एक चुनने का निर्णय नहीं:\nक्लस्टर के बाहर — एक क्लाउड LB या MetalLB स्थिर बाहरी endpoint प्रदान करता है और raw L4 ट्रैफ़िक संभालता है क्लस्टर के किनारे पर (अंदर) — एक Ingress Controller या Gateway API HTTP रूटिंग, TLS termination, रेट लिमिटिंग, और पाथ-आधारित नियम संभालता है और अंदर — ClusterIP Services पॉड्स के बीच सारा ईस्ट-वेस्ट ट्रैफ़िक संभालती हैं, बाहर से कुछ भी दिखाई नहीं देता इन सबको एक तंत्र में समेटने की कोशिश हमेशा परेशानी में डालती है। प्रति Service एक बाहरी LB महंगा है। क्लाउड NLB पर सीधे जटिल L7 रूटिंग करना अजीब है। Ingress Controller को L4 TCP राउटर की तरह इस्तेमाल करने के लिए हैक चाहिए। ये लेयर एक कारण से हैं।\nNodePort वास्तव में केवल लोकल डेव या CI environments के लिए है। अगर कोई आपसे कहता है कि \u0026ldquo;इसे सरल रखने के लिए प्रोडक्शन में बस NodePort इस्तेमाल करो\u0026rdquo; — तो आपत्ति करें। आप इन्फ्रास्ट्रक्चर-स्तरीय लोड बैलेंसिंग को बायपास कर रहे हैं, नोड IPs पर निर्भर हो रहे हैं, और नॉन-स्टैंडर्ड फ़ायरवॉल पोर्ट खोल रहे हैं। पहले हफ्ते के बाद यह कुछ भी सरल नहीं करता।\nसमाप्त\nस्रोत Services, Load Balancing, and Networking | Kubernetes Kubernetes Load Balancer: What Are the Options? | Komodor The Ultimate Guide to Kubernetes Services, LoadBalancers, and Ingress | Robusta Understanding Kubernetes Gateway API: A Modern Approach to Traffic Management | CNCF Gateway API | Kubernetes Bare-metal considerations - Ingress-Nginx Controller How to Deploy MetalLB with Nginx Ingress Controller | OneUptime Load Balancing - Amazon EKS Best Practices ","permalink":"https://cloudmato.com/hi/posts/kubernetes-load-balancer-options/","title":"Kubernetes लोड बैलेंसर: अंदर, बाहर, या दोनों?"},{"content":"मैंने \u0026ldquo;ज़ीरो डे\u0026rdquo; को ब्रीच की सुर्खियों, मूवी ट्रेलर और विक्रेताओं के मार्केटिंग ईमेल में इस्तेमाल होते देखा है। लगभग हमेशा इसका मतलब \u0026ldquo;डरावना हैक\u0026rdquo; होता है। यह पूरी तरह गलत नहीं है — लेकिन यह उस सटीक बात को चूक जाता है जो एक ज़ीरो-डे को हर दूसरे अटैक से संरचनात्मक रूप से अलग बनाती है। जब आप अपने जोखिम को समझने की कोशिश कर रहे हों, तो यह सटीकता वास्तव में मायने रखती है।\nतीन शब्द जो एक समान नहीं हैं मैं इन्हें लगातार एक-दूसरे की जगह इस्तेमाल होते देखता हूँ। ये नहीं हैं।\nज़ीरो-डे वल्नरेबिलिटी: सॉफ़्टवेयर में एक सुरक्षा खामी जिसके बारे में विक्रेता को पता नहीं है। कोई पैच नहीं, कोई CVE नहीं, कोई चेतावनी नहीं। [1] ज़ीरो-डे एक्सप्लॉइट: वह विशेष कोड या तकनीक जिसे एक हमलावर उस खामी का फायदा उठाने के लिए बनाता है। [1] ज़ीरो-डे अटैक: किसी लाइव लक्ष्य के विरुद्ध उस एक्सप्लॉइट का वास्तविक दुनिया में उपयोग। [1] वल्नरेबिलिटी वह छेद है। एक्सप्लॉइट वह चाबी है जो उसमें फिट होती है। अटैक वह है जब कोई उस दरवाज़े से गुज़रता है।\nआपके पास एक ऐसी वल्नरेबिलिटी हो सकती है जिसे अभी तक किसी हमलावर ने नहीं खोजा। आपके पास एक ऐसा एक्सप्लॉइट हो सकता है जो लिखा तो गया हो लेकिन तैनात न किया गया हो। ये बहुत अलग जोखिम स्तर रखते हैं और अलग प्रतिक्रियाओं की ज़रूरत होती है। अधिकांश लेख कभी यह अंतर नहीं करते, जो निराशाजनक है, क्योंकि यही पूरी बात है।\n\u0026ldquo;ज़ीरो\u0026rdquo; वास्तव में कहाँ से आता है यह नाम विक्रेता के नज़रिए से है। ज़ीरो डे का मतलब है कि विक्रेता के पास फिक्स तैयार करने के लिए शून्य दिन थे। [2]\nसामान्य वल्नरेबिलिटी खोज इस तरह काम करती है: शोधकर्ता बग खोजता है → विक्रेता को रिपोर्ट करता है → विक्रेता पैच करता है → उपयोगकर्ता अपडेट करते हैं। ज़ीरो-डे पहले से तीसरे चरण को पूरी तरह छोड़ देते हैं। जब तक कंपनी में किसी को खामी के अस्तित्व का पता चलता है, तब तक इसे पहले से ही वास्तविक दुनिया में इस्तेमाल किया जा रहा होता है।\nयही संरचनात्मक अंतर है। यह नहीं कि \u0026ldquo;यह वाकई बुरा बग है।\u0026rdquo; यह एक ऐसा बग है जहाँ अटैक शुरू होने से पहले डिफेंडर के पास किसी भी तरह से जवाब देने का कोई समय नहीं था [2]। असमानता पूर्ण है — हमलावर के पास सारी जानकारी है, डिफेंडर के पास कोई नहीं।\nजीवनचक्र: बग से पैच तक एक ज़ीरो-डे कहीं से नहीं आता। यह एक रास्ते का अनुसरण करता है [4]:\nपरिचय — एक डेवलपर एक बग शिप करता है। बफर ओवरफ्लो, ऑथेंटिकेशन बाइपास, अनुचित इनपुट वैलिडेशन। यह कोडबेस में निष्क्रिय पड़ा रहता है। खोज — कोई इसे ढूंढ लेता है। एक हमलावर, एक सुरक्षा शोधकर्ता, एक खुफिया एजेंसी। शोषण — यदि खोजकर्ता दुर्भावनापूर्ण है (या किसी ऐसे व्यक्ति को बेचता है जो है), तो विक्रेता को खामी के अस्तित्व का पता चलने से पहले एक एक्सप्लॉइट बनाया और तैनात किया जाता है। यही ज़ीरो-डे विंडो है। प्रकटीकरण — वल्नरेबिलिटी सार्वजनिक हो जाती है। या तो कोई अटैक को प्रगति में पकड़ता है, एक शोधकर्ता इसे स्वतंत्र रूप से खोजता है, या विक्रेता को ज़िम्मेदार प्रकटीकरण के माध्यम से सूचित किया जाता है। पैच जारी — विक्रेता एक फिक्स शिप करता है। यही वह सटीक क्षण है जब ज़ीरो-डे ज़ीरो-डे होना बंद हो जाता है। पैच अपनाना — संगठन वास्तव में फिक्स को तैनात करते हैं। इसमें महीने लग सकते हैं। बग के परिचय से व्यापक पैच अपनाने तक की औसत विंडो 312 दिन है [4]। यह किसी चीज़ के चुपचाप शोषण के लिए बहुत लंबा समय है।\nज़ीरो डे ठीक कब ज़ीरो डे होना बंद हो जाता है? ठीक-ठीक: वह क्षण जब विक्रेता एक पैच शिप करता है और एक CVE पहचानकर्ता प्रकाशित होता है [3]।\nउसके बाद, इसे एन-डे वल्नरेबिलिटी कहा जाता है — जहाँ \u0026ldquo;n\u0026rdquo; पैच जारी होने के बाद से दिनों की संख्या है। एक हफ्ते बाद, अभी भी एन-डे। एक साल बाद, अभी भी एन-डे। घड़ी ऊपर गिनती है, नीचे नहीं।\nखतरा पैच आने पर खत्म नहीं होता। संगठन अपने वातावरण में सुरक्षा अपडेट तैनात करने में औसतन 60 से 150 दिन लेते हैं [4]। हमलावर उसी खामी का शोषण करते रहते हैं — अब इस बारे में पूरी सार्वजनिक दस्तावेज़ीकरण के साथ कि यह ठीक कैसे काम करती है, क्योंकि CVE विवरण सार्वजनिक हैं। यह कभी-कभी मूल ज़ीरो-डे चरण से भी बुरा होता है। एक्सप्लॉइट लोकतांत्रिक हो जाता है।\nज़ीरो-डे बनाम एन-डे: असली अंतर ज़ीरो-डे एन-डे पैच मौजूद है? नहीं हाँ विक्रेता को पता है? नहीं हाँ CVE प्रकाशित? नहीं हाँ इसे कौन इस्तेमाल करता है? राष्ट्र-राज्य, APT समूह PoC स्क्रिप्ट वाला कोई भी एक्सप्लॉइट की लागत लाखों डॉलर लगभग शून्य क्या डिफेंडर पैच कर सकता है? नहीं हाँ — लेकिन अक्सर नहीं करता ज़ीरो-डे दुर्लभ, महंगा और आमतौर पर सर्जिकल तरीके से इस्तेमाल किया जाता है [6]। एन-डे एक कमोडिटी है। एक बार जब CVE जारी होता है और GitHub पर प्रूफ-ऑफ-कॉन्सेप्ट दिखाई देता है, तो स्क्रिप्ट किडीज 24 घंटों के भीतर एक्सप्लॉइट चला सकते हैं [6]। अर्थशास्त्र पूरी तरह अलग है।\nStuxnet: एक साथ चार ज़ीरो डे जलाना आपको क्या बताता है Stuxnet 2010 में खोजा गया था। व्यापक रूप से अमेरिका और इज़राइल को जिम्मेदार ठहराया गया, इसे ईरान के परमाणु कार्यक्रम को तोड़फोड़ करने के लिए डिज़ाइन किया गया था — विशेष रूप से यूरेनियम समृद्ध करने के लिए उपयोग किए जाने वाले सेंट्रीफ्यूज [7]।\nइसने एयर-गैप्ड नेटवर्क में फैलने और Siemens औद्योगिक नियंत्रकों को दुर्भावनापूर्ण कमांड भेजने के लिए एक साथ चार अलग ज़ीरो-डे वल्नरेबिलिटी का उपयोग किया, जिसने सभी Windows को लक्षित करते हुए सेंट्रीफ्यूज को भौतिक रूप से नष्ट कर दिया [7]।\nएक मैलवेयर में चार ज़ीरो-डे लगभग अनसुना था। ज़ीरो-डे महंगे हैं। आप चार को तब तक नहीं जलाते जब तक कि आपके पास लगभग असीमित संसाधन और एक अत्यंत उच्च-मूल्य लक्ष्य न हो। जब शोधकर्ताओं ने Stuxnet पाया, तो उपयोग किए गए ज़ीरो-डे की संख्या ही सबूत था कि यह एक राज्य-स्तरीय ऑपरेशन था। सामान्य मैलवेयर यह खर्च नहीं उठा सकता।\nPegasus: ज़ीरो-क्लिक का मतलब है आपने कुछ गलत नहीं किया NSO Group का Pegasus स्पाइवेयर ज़्यादातर लोगों की सोच से आगे गया। इसने iOS ज़ीरो-डे एक्सप्लॉइट का उपयोग किया — विशेष रूप से ज़ीरो-क्लिक एक्सप्लॉइट [8]। ज़ीरो-क्लिक का मतलब है कि पीड़ित किसी लिंक पर टैप नहीं करता, कोई अटैचमेंट नहीं खोलता, बिल्कुल कुछ नहीं करता।\nआपको एक iMessage मिलता है। आपका फ़ोन समझौता हो जाता है। आपको कभी पता नहीं चला कि यह हुआ।\niOS ज़ीरो-क्लिक एक्सप्लॉइट कथित तौर पर ग्रे मार्केट पर लगभग $10 मिलियन में बिकते हैं [9]। सरकारें प्राथमिक खरीदार हैं [9]। अर्थशास्त्र यह समझाता है कि अधिकांश उच्च-गुणवत्ता वाले ज़ीरो-डे अस्पतालों को लक्षित करने वाले रैनसमवेयर अभियानों में क्यों नहीं पहुँचते — वे बहुत मूल्यवान हैं, और बहुत सीमित। एक बार उपयोग होने के बाद, एक ज़ीरो-डे का पता लगाया और पैच किया जा सकता है।\nप्रकटीकरण की समस्या सुरक्षा समुदाय में इस बारे में वास्तविक तनाव है कि विवरण सार्वजनिक होने से पहले विक्रेताओं को कुछ ठीक करने के लिए कितना समय मिलना चाहिए।\nGoogle का Project Zero एक 90+30 दिन की नीति का उपयोग करता है: विक्रेता के पैच शिप करने के लिए 90 दिन, फिर उपयोगकर्ताओं के इसे इंस्टॉल करने के लिए 30 दिन, फिर विवरण सार्वजनिक हो जाता है चाहे विक्रेता तैयार हो या न हो [10]।\nतर्क: प्रकटीकरण की समय सीमाएँ विक्रेताओं को कार्य करने के लिए मजबूर करती हैं। उनके बिना, विक्रेता वर्षों तक फिक्स में देरी कर सकते हैं जबकि उपयोगकर्ता उजागर रहते हैं।\nप्रति-तर्क: एक बार जब तकनीकी विवरण सार्वजनिक हो जाते हैं, तो दुनिया के हर हमलावर के पास एक ट्यूटोरियल होता है। एन-डे शोषण के लिए, एक प्रकाशित PoC शुरुआती बंदूक है।\nमुझे यकीन नहीं है कि कोई भी दृष्टिकोण पूरी तरह समस्या हल करता है। Pegasus ने iOS की खामियों का शोषण Apple के पैच करने से तेज़ गति से किया। जिन पत्रकारों और कार्यकर्ताओं के फ़ोन से समझौता हुआ, वे किसी भी प्रकटीकरण समय सीमा से सुरक्षित नहीं थे।\nउस चीज़ से बचाव जिसे आप आते नहीं देख सकते सिग्नेचर-आधारित पहचान अज्ञात वल्नरेबिलिटी के खिलाफ काम नहीं करती। आप किसी ऐसे पैटर्न से मिलान नहीं कर सकते जो अभी तक मौजूद नहीं है।\nयथार्थवादी बचाव व्यवहार-आधारित होने चाहिए:\nव्यवहार निगरानी — ज्ञात मैलवेयर सिग्नेचर के बजाय असामान्य प्रक्रिया गतिविधि, लेटरल मूवमेंट और असामान्य प्रिविलेज एस्केलेशन का पता लगाएं न्यूनतम-विशेषाधिकार आर्किटेक्चर — अंदर आने के बाद भी हमलावर जो एक्सेस कर सकता है उसे सीमित करें नेटवर्क सेगमेंटेशन — जब कुछ शोषित होता है तो विस्फोट त्रिज्या को सीमित करें वेब एप्लिकेशन फ़ायरवॉल — असामान्य अनुरोध पैटर्न को एप्लिकेशन परत तक पहुँचने से पहले ब्लॉक करें आक्रामक पैच तैनाती — जिस क्षण एक ज़ीरो-डे एन-डे बनता है, आपके पास एक फिक्स उपलब्ध है। इसे तेज़ी से तैनात न करने का मतलब केवल एक प्रकाशित अटैक मैनुअल के साथ एक आसान एन-डे लक्ष्य बनना है केवल 2024 में, 75 ज़ीरो-डे वल्नरेबिलिटी को वास्तविक दुनिया में इस्तेमाल किया गया [5]। Microsoft के पास 26, Google के पास 11, Ivanti के पास 7, Apple के पास 5 थे [5]। हर एक अंततः एक पैच किया गया CVE बन गया — और हर वह संगठन जिसने उस पैच को लागू करने में देरी की, उसने दरवाज़ा बंद करने की ज़रूरत से बहुत बाद तक खुला रखा।\nज़ीरो-डे विंडो पैच शिप होने पर समाप्त होती है। एन-डे की समस्या तुरंत बाद शुरू होती है।\nसमाप्त\nस्रोत ज़ीरो डे अटैक क्या है? — Fortinet ज़ीरो-डे वल्नरेबिलिटी — Wikipedia वन-डे, एन-डे और ज़ीरो-डे वल्नरेबिलिटी समझाई गई — Field Effect ज़ीरो डे वल्नरेबिलिटी जीवनचक्र और 5 रक्षात्मक उपाय — Oligo Security हैलो 0-डेज़, मेरे पुराने दोस्त: 2024 ज़ीरो-डे शोषण विश्लेषण — Google Cloud Blog ज़ीरो-डे बनाम वन-डे अटैक: मुख्य अंतर समझाए गए — Secure.com Stuxnet — Wikipedia Pegasus (स्पाइवेयर) — Wikipedia ज़ीरो-डे एक्सप्लॉइट क्या है और ये खतरनाक क्यों हैं? — Proton VPN वल्नरेबिलिटी प्रकटीकरण नीति — Google Project Zero ","permalink":"https://cloudmato.com/hi/posts/zero-day-attack-explained/","title":"ज़ीरो डे अटैक: ये क्या होते हैं और कब समाप्त होते हैं"},{"content":"94% डेवलपर Git का उपयोग करते हैं [6]। शेष छह प्रतिशत ज़्यादातर विशेष उद्योगों में हैं — गेम स्टूडियो, बड़ी वित्त कंपनियां — और वे भी धीरे-धीरे माइग्रेट हो रहे हैं। हर दूसरी संस्करण नियंत्रण प्रणाली या तो मर चुकी है, अंतिम सांसें ले रही है, या केवल एक कोने की जगह में जीवित है। यह एक अजीब परिणाम है उस सॉफ़्टवेयर के लिए जिसे एक व्यक्ति ने लगभग दो हफ्तों में लिखा था।\nवह BitKeeper घटना जिसने यह सब शुरू किया Git इसलिए नहीं आया क्योंकि किसी ने बैठकर सोचा \u0026ldquo;मैं परफेक्ट वर्शन कंट्रोल सिस्टम डिज़ाइन करूंगा।\u0026rdquo; यह इसलिए आया क्योंकि किसी ने एक मुफ्त लाइसेंस छीन लिया।\nLinux कर्नेल — अब तक बना सबसे जटिल सहयोगी सॉफ़्टवेयर प्रोजेक्टों में से एक — मुफ़्त में BitKeeper, एक मालिकाना वितरित VCS, का उपयोग कर रहा था। 2005 में, ओपन-सोर्स समुदाय के साथ विवाद के बाद BitKeeper के मालिक ने वह मुफ्त लाइसेंस रद्द कर दिया [2]। Linus Torvalds मौजूदा विकल्पों पर वापस नहीं जा सकते थे। CVS और SVN Linux के पैमाने के लिए बहुत धीमे और बहुत केंद्रीकृत थे। Mercurial समानांतर में विकसित हो रहा था लेकिन तैयार नहीं था।\nतो Torvalds लगभग दस दिनों के लिए ऑफलाइन हो गए और Git को स्क्रैच से लिखा [2]।\nयही उत्पत्ति की कहानी है। ज़रूरत, प्रेरणा नहीं। वास्तव में, गुस्सा।\nGit वास्तव में क्या है Git एक वितरित संस्करण नियंत्रण प्रणाली है। वह एक शब्द — वितरित — यही है जो इसे पहले आई हर चीज़ से अलग करता है।\nCVS और SVN जैसी पुरानी प्रणालियों में, एक केंद्रीय सर्वर होता है। हर डेवलपर कमिट करने के लिए, इतिहास देखने के लिए, कुछ भी सार्थक करने के लिए उससे जुड़ता है [3]। अगर वह सर्वर बंद हो जाए, तो आप फंस जाते हैं। अगर आप फ्लाइट पर हैं, तो आप फंस जाते हैं। अगर नेटवर्क धीमा है, तो आप पहले से जानते हैं कि क्या होगा।\nGit के साथ, हर डेवलपर के पास पूरी रिपॉज़िटरी की एक संपूर्ण कॉपी होती है — पूरा इतिहास, सभी शाखाएं, हर एक कमिट — अपनी मशीन पर स्थानीय रूप से [3]। आप स्थानीय रूप से कमिट करते हैं। आप स्थानीय रूप से ब्रांच करते हैं। आप स्थानीय रूप से diff करते हैं। नेटवर्क तभी शामिल होता है जब आप दूसरों के साथ परिवर्तन साझा करना चाहते हैं।\nयह एक मामूली आर्किटेक्चरल विकल्प की तरह लगता है। यह नहीं है। यह पूरी तरह से बदल देता है कि आप विकास के बारे में कैसे सोचते हैं।\nकुछ चीजें जो Git तकनीकी रूप से वास्तव में सही करता है:\nब्रांचिंग सस्ती है। SVN में, ब्रांचिंग पूरी डायरेक्टरी कॉपी करती है — धीमी और महंगी। Git में, एक ब्रांच सिर्फ एक कमिट की ओर एक पॉइंटर है, इसलिए एक बनाना या हटाना अनिवार्य रूप से मुफ्त है [5]। मर्जिंग वास्तव में काम करती है। Git हर कमिट के सटीक पूर्वजों को ट्रैक करता है, इसलिए जब दो शाखाएं अलग होती हैं तो यह जानता है कि सामान्य आधार के सापेक्ष क्या बदला। SVN की मर्जिंग कुख्यात रूप से कठिन थी [5]। SHA-1 कंटेंट हैशिंग। हर फ़ाइल, कमिट, और ट्री को उसके कंटेंट के क्रिप्टोग्राफिक हैश द्वारा पहचाना जाता है [1]। आप डेटा को चुपचाप खराब नहीं कर सकते — Git इसे डिटेक्ट करेगा। डिज़ाइन द्वारा गति। अधिकांश ऑपरेशन — log, diff, commit, branch switch — स्थानीय हैं और इसलिए तेज़। Git को पहले दिन से Linux कर्नेल के आकार के प्रोजेक्ट के लिए बनाया गया था [2]। SVN, Mercurial, CVS, और Perforce क्यों हारे CVS — 1980 के दशक में बना — परमाणु कमिट का भी समर्थन नहीं करता [6]। अगर आपका कमिट आधे रास्ते में क्रैश हो जाता है, तो रिपॉज़िटरी टूटी हुई असंगत स्थिति में छोड़ दी जाती है। इसमें वास्तविक रिनेम समर्थन भी नहीं है। CVS को Git ने इतना नहीं हराया जितना कि वह Git के अस्तित्व में आने से पहले ही मर रहा था।\nSVN ने CVS की अधिकांश समस्याओं को ठीक किया और कुछ समय के लिए वास्तव में प्रमुख था। लेकिन यह केंद्रीकृत है, ब्रांचिंग महंगी है, और ऑफलाइन काम बहुत सीमित है [6]। जैसे-जैसे डेवलपमेंट टीमें वितरित मॉडल की ओर स्थानांतरित हुईं — महाद्वीपों भर में ओपन-सोर्स योगदानकर्ता, कई स्वतंत्र माइक्रोसर्विस टीमें, रिमोट-फर्स्ट संगठन — SVN की धारणाएं दर्दनाक होने लगीं। 2025 तक, SVN ज़्यादातर उन लीगेसी एंटरप्राइज़ कोडबेस में पाया जाता है जिन्हें कोई छूना नहीं चाहता [6]।\nMercurial सबसे दिलचस्प कहानी है और जो Git प्रशंसकों को कम से कम थोड़ा विनम्र बनानी चाहिए। Mercurial उसी साल लॉन्च हुआ जब Git, भी BitKeeper घटना के जवाब में [2]। यह तर्कतः उपयोग में आसान है, और इसका CLI अधिक सुसंगत है। लेकिन Bitbucket ने 2020 में Mercurial समर्थन हटा दिया, जो प्रभावी रूप से मृत्युदंड था [6]। एक प्रमुख होस्टिंग प्लेटफ़ॉर्म के बिना, Mercurial का कोई नेटवर्क प्रभाव नहीं था। आज यह लगभग 2% बाज़ार हिस्सेदारी पर बैठता है [6]।\nPerforce (Helix Core) एकमात्र गंभीर विकल्प है जो अभी भी जीवित है — लेकिन केवल विशिष्ट क्षेत्रों में: गेम डेवलपमेंट, वित्त, विनियमित एंटरप्राइज़। यह Git से बेहतर बड़ी बाइनरी फ़ाइलों को संभालता है और केंद्रीकृत एक्सेस कंट्रोल है जो कुछ एंटरप्राइज़ को चाहिए। यह महंगा है, मालिकाना है, और कहीं तेज़ी से नहीं जा रहा।\nसिस्टम आर्किटेक्चर ब्रांचिंग ऑफलाइन काम 2025 बाज़ार हिस्सेदारी Git वितरित सस्ती, तत्काल पूर्ण ~94% SVN केंद्रीकृत महंगी बहुत सीमित ~5% Mercurial वितरित अच्छी पूर्ण ~2% CVS केंद्रीकृत कठिन कोई नहीं अनिवार्य रूप से मृत Perforce केंद्रीकृत मध्यम सीमित निच (गेम्स/एंटरप्राइज़) GitHub ने जीत को स्थायी बना दिया Git तकनीकी योग्यता पर जीता। GitHub ने इसे अपरिवर्तनीय बना दिया।\nGitHub 2007 में लॉन्च हुआ, Git के सिर्फ दो साल बाद [1]। इसने Git को एक सामाजिक परत दी — पुल रिक्वेस्ट, फोर्क, कोड रिव्यू, इशू ट्रैकिंग। ओपन-सोर्स प्रोजेक्ट वहां गए। कंपनियां आईं। फिर पूरा इकोसिस्टम आया। CI/CD टूल्स ने GitHub मान लिया। हायरिंग पाइपलाइन ने GitHub प्रोफाइल का संदर्भ दिया। पैकेज रजिस्ट्री ने GitHub रेपो से लिंक किया।\nजब तक Bitbucket और GitLab ने प्रतिस्पर्धा करने की कोशिश की, GitHub के नेटवर्क प्रभाव अनिवार्य रूप से अजेय थे। Mercurial का तकनीकी रूप से तुलनीय होना एक बार GitHub के अस्तित्व में आने के बाद कोई मायने नहीं रखता था। प्लेटफ़ॉर्म ने टूल को खा लिया।\n2025 Stack Overflow डेवलपर सर्वे GitHub को डेवलपर्स के बीच 81% उपयोग पर प्रमुख सहयोग प्लेटफ़ॉर्म के रूप में दिखाता है [11]।\nGit के बारे में वास्तव में क्या बुरा है यहां वह हिस्सा है जो अधिकांश ट्यूटोरियल छोड़ते हैं, या \u0026ldquo;Git में सीखने की कड़ी ढाल है\u0026rdquo; की एक पंक्ति लिखकर आगे बढ़ जाते हैं।\nCLI असंगतता की आपदा है। git checkout ब्रांच स्विच करने और फ़ाइल परिवर्तनों को त्यागने दोनों को संभालता था — दो पूरी तरह से असंबंधित ऑपरेशन, एक कमांड। उन्हें अंततः इसे git switch और git restore में विभाजित करना पड़ा [9]। एरर मैसेज अक्सर क्रिप्टिक होते हैं। \u0026ldquo;Detached HEAD state\u0026rdquo; उन लोगों को भ्रमित करता है जो वर्षों से Git का उपयोग कर रहे हैं। rebase बनाम merge बनाम cherry-pick को समझने के लिए आवश्यक मानसिक मॉडल वास्तव में गैर-तुच्छ है।\nबाइनरी फ़ाइलें एक वास्तविक आर्किटेक्चरल बेमेल हैं। Git हर फ़ाइल के हर संस्करण की पूरी सामग्री स्टोर करता है। टेक्स्ट फ़ाइलें सुंदर ढंग से संपीड़ित और डेल्टा-एनकोड होती हैं। एक 100MB Photoshop फ़ाइल या एक गेम एसेट नहीं होती [9]। बड़े बाइनरी-भारी रेपो तेज़ी से आकार में बढ़ते हैं। यही वास्तविक कारण है कि गेम स्टूडियो Perforce के साथ रहते हैं — पसंद नहीं, बल्कि Git के डिज़ाइन और उनके डेटा के बीच एक मौलिक बेमेल। Git LFS एक वर्कअराउंड के रूप में मौजूद है, लेकिन यह परिचालन जटिलता जोड़ता है और पूरी तरह से समस्या हल नहीं करता।\nमोनोरेपो बड़े पैमाने पर टूट जाते हैं। लाखों फ़ाइलों के साथ विशाल कोडबेस चलाने वाली कंपनियां पाती हैं कि Git बुरी तरह खराब हो जाता है। एक 9GB रेपो पर एक git pull छह मिनट ले सकता है [9]। Microsoft को अपनी खुद की वर्चुअल फाइलसिस्टम लेयर (VFS for Git, अब Scalar) बनानी पड़ी, बस Git में Windows सोर्स डेवलपमेंट को व्यवहार्य बनाने के लिए। यह स्केलेबिलिटी का कोई उत्साहजनक समर्थन नहीं है।\n\u0026ldquo;वितरित\u0026rdquo; आर्किटेक्चर व्यवहार में केंद्रीकृत हो गया। Git को पीयर-टू-पीयर डिज़ाइन किया गया था। वास्तव में, हर टीम GitHub पर पुश करती है, जिसमें पिछले 12 महीनों में 48 प्रमुख आउटेज हुए हैं — लगभग प्रति सप्ताह एक महत्वपूर्ण व्यवधान, मई 2025 और अप्रैल 2026 के बीच कुल 257 घटनाएं [10]। वितरित डिज़ाइन कोई वास्तविक-दुनिया लचीलापन प्रदान नहीं करता जब हर किसी का वर्कफ़्लो एक सेवा के बंद होने से अवरुद्ध हो जाता है।\nAI-जनरेटेड कोड Git की धारणाओं पर कठोरता से दबाव डाल रहा है। GitHub ने 2025 में AI-जनरेटेड प्रोजेक्ट में साल-दर-साल 206% वृद्धि देखी [10], और AI एजेंट उस मात्रा और आवृत्ति पर कमिट करते हैं जो मनुष्यों ने कभी नहीं की। Git का मर्ज कॉन्फ्लिक्ट मॉडल, पुल रिक्वेस्ट वर्कफ़्लो, और इतिहास की अर्थशास्त्र मानव गति से कोड पढ़ने और लिखने वाले मनुष्यों के लिए डिज़ाइन किए गए थे। The Register ने मई 2026 में रिपोर्ट किया कि \u0026ldquo;Git AI कोडिंग सुनामी के लिए तैयार नहीं है\u0026rdquo; [8] — और यह देखते हुए कि Git वर्तमान में इस मात्रा के स्वचालित कमिट को कैसे संभालता है, उस आकलन से बहस करना मुश्किल है।\nGit सही समय पर सही टूल के रूप में जीता, सही प्रोजेक्ट से जुड़ा, और फिर सही प्लेटफ़ॉर्म द्वारा लॉक किया गया। यह अभी भी अधिकांश चीजों के लिए अधिकांश समय सही टूल है। यह एक 20 साल पुराना डिज़ाइन भी है जो उन समस्याओं के लिए बनाया गया था जो अब काफी बदल गई हैं।\nसमाप्त\nस्रोत Git — Wikipedia Git का इतिहास: वर्चस्व की राह — Welcome to the Jungle संस्करण नियंत्रण के बारे में — Git SCM संस्करण नियंत्रण क्या है — Atlassian Git Tutorial Git बनाम अन्य संस्करण नियंत्रण प्रणालियां — GeeksforGeeks 2025 में संस्करण नियंत्रण प्रणालियों की लोकप्रियता — RhodeCode Git से परे: अन्य संस्करण नियंत्रण प्रणालियां जो डेवलपर उपयोग करते हैं — Stack Overflow Blog Git AI कोडिंग सुनामी के लिए तैयार नहीं है — The Register Git 2026 में चुपचाप क्यों पिछड़ रहा है — Medium GitHub आउटेज 2025–2026: विश्वसनीयता विश्लेषण — IncidentHub Blog 2025 Stack Overflow डेवलपर सर्वे ","permalink":"https://cloudmato.com/hi/posts/git-why-it-won-and-what-it-gets-wrong/","title":"Git: यह क्यों जीता, और यह क्या गलत करता है"},{"content":"\u0026ldquo;बस माइक्रोसर्विसेज़ स्केल करो\u0026rdquo; वाला सवाल हर बार उठता है जब Spark की बात होती है। यह तर्कसंगत लगता है — आपके पास पहले से डिस्ट्रिब्यूटेड सर्विसेज़ हैं, बस समस्या पर और फेंक दो। लेकिन यह तुलना एक बेहद बुनियादी सवाल के सामने टिकती नहीं: आप असल में किस तरह की समस्या हल कर रहे हैं?\nयह न डेटाबेस है, न कोई Queue लोग Spark के पास यह उम्मीद लेकर आते हैं कि यह किसी तेज़ डेटाबेस या होशियार Kafka जैसा होगा। दोनों गलत हैं।\nApache Spark एक unified analytics engine है, जो बड़े पैमाने पर डेटा प्रोसेसिंग के लिए बना है — single-node मशीन से लेकर पूरे cluster तक, एक ही runtime से data engineering, data science और machine learning के काम संभालता है। [1] व्यावहारिक रूप से: आप इसे एक dataset देते हैं — चाहे 50GB हो या 50TB — और यह खुद-ब-खुद काम को मशीनों में बाँट देता है, computations को parallel में चलाता है, ज़्यादातर memory में, और एक result लौटाता है।\nवह \u0026ldquo;ज़्यादातर memory में\u0026rdquo; वाली बात ही पूरा खेल है। पारंपरिक Hadoop MapReduce हर एक computation step के बाद intermediate results को disk पर लिखता था। Spark उन्हें जहाँ तक हो सके RAM में रखता है, जिससे हर round-trip पर disk I/O से बचा जाता है। प्रदर्शन का फर्क मामूली नहीं है — Spark, iterative workloads के लिए Hadoop से 100x तक तेज़ और disk-based jobs पर 10x तेज़ चलता है। [2] Yahoo ने दोनों frameworks को बड़े पैमाने के datasets पर benchmark किया और पाया कि Spark, MapReduce से 20 गुना तक तेज़ jobs पूरी करता है। [11]\nयह Java, Scala, Python और R को support करता है। [3] Batch jobs, streaming, SQL queries, machine learning, graph processing — सब एक ही engine से। इसीलिए इसे \u0026ldquo;unified\u0026rdquo; कहते हैं। आपको पाँच अलग workloads के लिए पाँच अलग tools जोड़ने की ज़रूरत नहीं।\nयह वास्तव में काम कैसे करता है Spark एक Driver-Executor model पर चलता है, जिसे एक Cluster Manager coordinate करता है। [5] तीन हिस्से होते हैं:\nDriver — आपका application code यहाँ रहता है। Driver एक SparkContext बनाता है, आपके logical plan को physical execution plan में बदलता है, उसे stages में optimize करता है, और workers को tasks बाँटता है। [6] Cluster Manager — cluster भर में CPU और memory allocate करता है। Spark अपने Standalone mode, Hadoop YARN, Kubernetes और Apache Mesos को support करता है। [5] Executors — हर node पर चलने वाले worker processes। ये tasks को अंजाम देते हैं, actual transformations करते हैं, और intermediate data को memory में cache करते हैं। [6] दूसरा अहम हिस्सा है RDDs — Resilient Distributed Datasets। [12] RDD एक immutable, fault-tolerant records का collection है जो nodes में distribute होकर parallel में process होता है। Spark हर RDD की पूरी lineage track करता है — हर वह transformation जो उसे produce करने के लिए लागू हुई, जिसे Directed Acyclic Graph (DAG) के रूप में represent किया जाता है। [4]\nअगर job के बीच में कोई worker node मर जाए, तो Spark शुरू से restart नहीं करता। यह lineage graph को follow करता है और केवल खोए हुए partitions को recompute करता है। [12] यह failure recovery पूरी तरह automatic है। आपको एक भी recovery code लिखने की ज़रूरत नहीं।\nतो क्या माइक्रोसर्विसेज़ स्केल नहीं कर सकते? यहाँ सीधा जवाब है।\nज़्यादातर application workloads के लिए — API requests, user authentication, CRUD operations — horizontal microservice scaling बिल्कुल सही कदम है। और pods, सामने load balancer, काम खत्म। मैं इसके खिलाफ बिल्कुल नहीं हूँ।\nसमस्या तब आती है जब data volume bottleneck बन जाता है, request concurrency नहीं।\nमान लीजिए आप 6 महीने के transaction records — 40 करोड़ rows — पर fraud detection job चलाना चाहते हैं। आपकी payment microservice यह नहीं कर सकती। चाहे आप उसके 50 instances spin up करें, हर एक एक बार में एक request handle करने के लिए बना है। इसमें कोई built-in mechanism नहीं है जो:\n40 करोड़ rows को उन 50 instances में बाँटे यह track करे कि कौन सी rows process हो चुकी हैं और कौन सी नहीं Job के बीच में node failure हो तो बिना काम गँवाए संभाले अंत में partial results को merge और aggregate करे यह सारी coordination logic आपको खुद बनानी पड़ती। Spark वही coordination logic है। पहले से बना हुआ, battle-tested, और Netflix, Uber, Amazon और सैकड़ों अन्य कंपनियों के production में चल रहा है। [9]\nएक और बात है जो लोग पूरी तरह से चूक जाते हैं — माइक्रोसर्विसेज़ स्केल करने से request throughput बढ़ती है, data throughput नहीं। ज़्यादा instances का मतलब है आप ज़्यादा concurrent users handle कर सकते हैं। लेकिन वे सभी instances अभी भी एक ही database से read कर रहे हैं। वह database chokepoint बन जाता है, service tier नहीं। [10] Spark इससे बचता है HDFS, S3, या data lake से सीधे data पढ़कर, cluster में in-place process करके, बिना हर record को एक shared transactional database के ज़रिए route किए।\nKubernetes पर deploy किए गए cloud-native microservices के साथ Spark को integrate करने पर एक research paper ने पाया कि combined framework ने processing latency को monolithic deployments की तुलना में 83.1% तक कम कर दिया। [8] Microservices ने API और routing layer संभाली। Spark ने data computation संभाली। वे एक-दूसरे के साथ काम करते थे — एक-दूसरे की जगह नहीं।\nमाइक्रोसर्विसेज़ स्केल करना Apache Spark हल होने वाली समस्या Request concurrency Data volume Scale की इकाई Service instance Data partition Steps के बीच state Design से stateless Lineage-tracked RDDs Failure recovery Container restart करें खोए हुए partitions recompute करें Data की जगह Shared relational DB Distributed file system / data lake Job duration का लक्ष्य प्रति request milliseconds पूरे dataset पर seconds से minutes कंपनियाँ इसका इस्तेमाल वास्तव में कैसे कर रही हैं Netflix, Kafka + Spark Streaming का इस्तेमाल करके viewer interactions से प्रतिदिन अरबों events process करता है। [9] उनकी pipeline real-time personalization चलाती है, और उन्होंने उन recommendations की सटीकता से viewer engagement में 10–20% सुधार बताया है। [9]\nUber, Spark चलाकर रोज़ाना 1.5 करोड़ से ज़्यादा trips monitor करता है — real-time ride requests, driver locations, surge pricing, route optimization, demand forecasting। [9] सब Spark pipelines।\nNVIDIA, Spark का इस्तेमाल खासतौर पर अपनी खुद की माइक्रोसर्विसेज़ से बड़े पैमाने पर telemetry और logs merge करने के लिए करती है। [13] यह गौर करने लायक है: एक कंपनी जो microservices को भारी मात्रा में चलाती है, फिर भी उन services के generate किए डेटा को समझने के लिए Spark की ज़रूरत पड़ती है।\nNetflix और Uber दोनों Spark के साथ-साथ हज़ारों microservices चलाते हैं। वे microservices Spark के results का उपयोग करती हैं। वे इसकी जगह नहीं लेतीं।\nजब Spark की शायद ज़रूरत न हो हर data problem, Spark की problem नहीं है।\nअगर आपका dataset एक मशीन पर fit हो जाता है और plain SQL या Pandas से कुछ ही मिनटों में चल जाता है, तो Spark बिना किसी फायदे के operational overhead जोड़ता है। Cluster management, resource tuning, partition sizing, executor memory configuration — यह weekend का setup नहीं है। [7]\nएक मोटा heuristic:\nकुछ सौ GB से कम, batch, कोई real-time requirement नहीं → SQL वाला एक ढंग का database ठीक है सैकड़ों GB से TB range, नियमित batch jobs → Spark समझ में आने लगता है TB+ या scale पर real-time streaming → Spark एक कारण से standard जवाब है [1] Cost का पहलू भी नज़रअंदाज़ करने लायक नहीं है। Partitioning और memory management को समझे बिना, आप आसानी से एक ऐसे Spark cluster पर पैसे बर्बाद कर सकते हैं जो धीरे और महंगे तरीके से चले। [10] यह उन लोगों को फायदा देता है जो समझते हैं कि यह internally कैसे काम करता है — न कि सिर्फ उन लोगों को जो pip install pyspark करते हैं।\nEnd\nSources Apache Spark — Unified Engine for large-scale data analytics What is Spark? — Introduction to Apache Spark and Analytics — AWS What Is Apache Spark? — IBM Apache Spark — Wikipedia Apache Spark Architecture 101: How Spark Works (2026) — Flexera Apache Spark Architecture: Complete Guide with Execution Flow — Medium / Towards Data Engineering Java Microservices and Big Data: Integrating Apache Spark — SpringFuse Integrating Apache Spark with Cloud-Native Microservices for Scalable Data Processing — ResearchGate 10 Powerful Apache Spark Use Cases Across Industries — upGrad How to Scale Apache Spark Clusters for Massive Datasets — Datatas Apache Spark vs Hadoop MapReduce — Feature Wise Comparison — DataFlair What Is a Resilient Distributed Dataset (RDD)? — IBM Merging Telemetry and Logs from Microservices at Scale with Apache Spark — NVIDIA Technical Blog ","permalink":"https://cloudmato.com/hi/posts/apache-spark-vs-scaling-microservices/","title":"Apache Spark: यह क्या है और माइक्रोसर्विसेज़ इसकी जगह क्यों नहीं ले सकतीं"},{"content":"CSS centering के साथ पहली लड़ाई कोई नहीं भूलता। आप Google करते हैं, Stack Overflow का snippet paste करते हैं, और आगे बढ़ जाते हैं — यह पूछे बिना कि क्या वह सही तरीका था या बस एक तरीका। 2026 में, div को center करने के कम से कम सात अलग-अलग तरीके हैं, और उनमें से कुछ को तो वर्षों पहले ही दफन हो जाना चाहिए था।\nयहाँ वे सभी हैं, सबसे बुरे से सबसे अच्छे तक रैंक किए गए।\nपूरी तुलना तरीका क्षैतिज ऊर्ध्वाधर निर्णय display: table-cell हाँ हाँ कभी नहीं Negative margins हाँ हाँ कभी नहीं abs + translate(-50%, -50%) हाँ हाँ बचें inset: 0 + margin: auto हाँ हाँ कभी-कभी margin: auto हाँ नहीं केवल क्षैतिज Flexbox हाँ हाँ अच्छा डिफ़ॉल्ट CSS Grid हाँ हाँ सर्वश्रेष्ठ डिफ़ॉल्ट CSS Anchor Positioning सापेक्ष सापेक्ष विशिष्ट उपयोग 1. display: table-cell — कृपया रुकें यह वह तरीका है जो लोग Flexbox के आने से पहले करते थे। आप अपने element को एक नकली table में लपेटते हैं, browser को यह सोचने पर मजबूर करते हैं कि यह एक \u0026lt;td\u0026gt; है, और vertical-align: middle का दुरुपयोग करते हैं।\n.wrapper { display: table; width: 100%; height: 300px; } .box { display: table-cell; vertical-align: middle; text-align: center; } दो तत्काल समस्याएं। पहला, table row को fake करने के लिए आपको एक अतिरिक्त wrapper div चाहिए — यह केवल layout के लिए अतिरिक्त markup है। दूसरा, आप browser से semantically झूठ बोल रहे हैं। यह 2012 में समझ में आता था। Flexbox 2013 में आया। centering के लिए display: table-cell का 2026 में कोई स्थान नहीं है। [1]\nएकमात्र अपवाद HTML emails हैं, जहाँ Outlook का rendering engine अभी भी 2003 में जी रहा है और यह तकनीक वास्तव में आवश्यक है। email templates के बाहर, इससे दूर रहें।\n2. Negative Margins — डिज़ाइन से ही कमज़ोर यहाँ विचार यह है कि element को 50% नीचे और 50% दाईं ओर धकेलें, फिर negative margins का उपयोग करके इसे अपनी dimensions के बिल्कुल आधे से वापस खींचें।\n.box { position: absolute; top: 50%; left: 50%; width: 200px; height: 100px; margin-top: -50px; /* height का आधा */ margin-left: -100px; /* width का आधा */ } आपको element की dimensions को hardcode करना होगा। जैसे ही content बदलती है और div बड़ा या छोटा होता है, आपकी centering टूट जाती है। Dynamic content — जो मूल रूप से हर वास्तविक element होता है — इस तकनीक को तुरंत विफल कर देती है। यह तो display: table-cell हैक्स से भी पुराना है। 2026 में इसे लिखने का वास्तव में कोई कारण नहीं है [2]।\n3. position: absolute + translate — क्लासिक हैक यह 2015–2020 के युग का प्रमुख snippet था। इसने translate का उपयोग करके negative margins की hardcoded-dimensions समस्या को हल किया, जो element की अपनी size के प्रतिशत के रूप में काम करता है।\n.parent { position: relative; } .box { position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%); } यह काम करता है, और dynamic content पर नहीं टूटता। लेकिन यह अभी भी एक hack है — आप position: absolute को उसके इच्छित उद्देश्य से बहुत आगे खींच रहे हैं। element को normal flow से बाहर खींचा जाता है, parent को एक defined height चाहिए, और पूरी चीज़ ऐसे लगती है जैसे किसी ने लिखी हो जो क्या जानता था लेकिन क्यों नहीं। CSS-Tricks का 2026 में state-of-centering लेख इस approach को \u0026ldquo;बचने लायक\u0026rdquo; कहता है, इसकी तुलना यह करते हुए कि कैसे float-based layouts को अंततः retire कर दिया गया जब कुछ बेहतर आया [1]। मैं सहमत हूँ।\nइसे केवल तभी उपयोग करें जब आप 2018 से पहले के legacy code को maintain कर रहे हों और structure को नहीं बदल सकते। अन्यथा, नीचे बेहतर विकल्प हैं।\n4. inset: 0 + margin: auto — सही तरीके से Absolute Positioning यदि आपको position: absolute या position: fixed के साथ काम करना ही है, तो यह उसके अंदर center करने का आधुनिक तरीका है। कोई transform गणित नहीं, कोई offset नहीं।\n.parent { position: relative; } .box { position: absolute; inset: 0; margin: auto; width: fit-content; height: fit-content; } inset: 0 top: 0; right: 0; bottom: 0; left: 0 का shorthand है। सभी चार edges को zero पर pin करने और margin: auto के साथ, browser सभी sides पर बचे हुए space को समान रूप से वितरित करता है — element को साफ तरीके से center करता है [3]।\nयह वास्तव में पठनीय है। यह वही करता है जो कहता है। नुकसान यह है कि position: absolute element को normal flow से बाहर ले जाता है, इसलिए parent को एक defined height चाहिए और आस-पास के elements इसके साथ स्वाभाविक रूप से interact नहीं करेंगे। modals, overlays, और loading spinners के लिए उपयुक्त — एक general purpose समाधान नहीं।\n5. margin: auto — अपनी सीमाओं के बारे में ईमानदार .box { width: 700px; margin: 0 auto; } इसे सभी जानते हैं। यह CSS में हमेशा से रहा है। एक block element पर width set करें, horizontal axis पर margin: auto जोड़ें, और यह अपने container के horizontal center में आ जाता है।\nmargin: auto normal flow में vertical centering के लिए कुछ नहीं करता। यह कोई bug नहीं है, यही spec का तरीका है। vertical auto margins के लिए, आपको flex या grid formatting context चाहिए। तो यह केवल horizontal के लिए एक tool है — और उस काम के लिए बहुत अच्छा है। page के center में एक content column को सीमित करना? यह बिल्कुल सही विकल्प है। इसे और अधिक करने की कोशिश न करें [4]।\n6. Flexbox — भरोसेमंद कार्यकर्ता Flexbox शायद वह है जिसे 2026 में अधिकांश frontend devs reflex से चुनते हैं, और सच कहूँ तो, यह ठीक है।\n.parent { display: flex; justify-content: center; /* क्षैतिज */ align-items: center; /* ऊर्ध्वाधर */ } दो properties। दोनों axes। काम खत्म। parent को fixed pixel height की जरूरत नहीं है — जब तक vertical space उपलब्ध है, यह काम करता है। जहाँ Flexbox Grid से वास्तव में बेहतर है वह है mixed-alignment scenarios में: एक item को center करते हुए दूसरे को right-align करना, कुछ children को stretch करते हुए दूसरों को center करना, इस तरह की चीजें [5]।\nएक बात जो लोगों को हमेशा पकड़ती है: यदि parent container की कोई defined height नहीं है, तो center करने के लिए कोई vertical space नहीं है, इसलिए कुछ भी shift नहीं लगता। min-height: 100dvh या एक fixed height set करें और यह तुरंत काम करता है। यह एकल गलतफहमी \u0026ldquo;मेरी centering क्यों काम नहीं कर रही\u0026rdquo; प्रश्नों के एक बड़े हिस्से के लिए जिम्मेदार है [6]।\n7. CSS Grid — 2026 में सर्वश्रेष्ठ डिफ़ॉल्ट दो lines।\n.parent { display: grid; place-items: center; } place-items align-items + justify-items का shorthand है। एक property, दोनों axes, कोई trick नहीं। एक full-page hero, एक centered card, या एक loading screen के लिए, यह उपलब्ध सबसे साफ विकल्प है — पठनीय, जानबूझकर, और तोड़ना लगभग असंभव [1]।\n/* पूरे viewport का centered layout */ .page { display: grid; place-items: center; min-height: 100dvh; } यदि आपको items के एक group को एक block के रूप में center करना है (प्रत्येक item को अपनी cell में center करने के बजाय), तो place-items को place-content: center से बदलें। अलग behavior, दोनों जानने लायक।\nCSS Grid 2026 में 97%+ browser support पर है [7]। कोई भी production browser नहीं है जिसे आप target कर रहे हों जो इसे support न करता हो। Grid से बचने का \u0026ldquo;browser support\u0026rdquo; बहाना लगभग 2020 में खत्म हो गया।\n8. CSS Anchor Positioning — नया, विशिष्ट, और वह नहीं जो आप सोचते हैं Anchor positioning वर्षों में CSS centering का सबसे रोमांचक addition है, लेकिन यह एक विशिष्ट समस्या को हल करता है — एक floating element को किसी अन्य विशिष्ट element के सापेक्ष center करना — न कि सामान्य centering।\n.button { anchor-name: --my-button; } .tooltip { position: absolute; position-anchor: --my-button; bottom: anchor(top); justify-self: anchor-center; } anchor-center एक नया alignment value है जो positioned element को उसके named anchor element के ऊपर center करता है — viewport नहीं, nearest positioned ancestor नहीं, बल्कि वह exact element जो आप declare करते हैं [3]। mid-2026 तक, यह Chrome 125+, Edge 125+, Safari 26+, और Firefox 147+ में supported है [7]।\nकेवल page पर div को center करने के लिए anchor positioning न चुनें। यह उन elements के लिए designed है जो किसी अन्य element का अनुसरण करते हैं — tooltips, popovers, dropdowns, context menus। यह mechanism Grid या Flexbox से पूरी तरह अलग है और उस चीज़ के लिए बहुत जटिलता लाता है जिसे वे दो एक line में हल करते हैं। इसे तब उपयोग करें जब use case वास्तव में उपयुक्त हो।\nवह एक नियम जो सभी को गलत करता है कोई फर्क नहीं पड़ता कि आप कौन सी तकनीक उपयोग करते हैं — यदि parent की कोई defined height नहीं है, तो vertical centering कोई दृश्य परिणाम नहीं देती। container अपने content को fit करने के लिए collapse हो जाता है, distribute करने के लिए शून्य empty space छोड़ता है। इस list की हर विधि उसी तरह व्यवहार करती है। parent पर min-height, एक fixed height, या 100dvh set करें। फिर centering अपेक्षित रूप से काम करती है [4]।\n99% मामलों के लिए: place-items: center के साथ Grid चुनें। जब आपको mixed-alignment children पर अधिक नियंत्रण चाहिए, Flexbox पर जाएं। specific elements से anchored floating UI elements के लिए, anchor positioning अंततः उपलब्ध है। इस list में उन तीन से ऊपर सब कुछ legacy है — या इससे भी बुरा, 2015 की एक आदत जिस पर किसी ने सवाल नहीं उठाया।\nसमाप्त\nस्रोत 2026 में CSS Centering की स्थिति | CSS-Tricks Div को Center करने के 10 प्रासंगिक तरीके — DEV Community CSS Anchor Positioning का उपयोग — MDN Web Docs Div को Center कैसे करें — अंतिम गाइड | Josh W. Comeau CSS में किसी भी Element को Center कैसे करें: 7 तरीके जो हमेशा काम करते हैं — freeCodeCamp CSS में Centering की पूरी गाइड | Modern CSS Solutions CSS Anchor Positioning API का परिचय | Chrome for Developers ","permalink":"https://cloudmato.com/hi/posts/center-a-div-css-2026/","title":"CSS में Div को Center करने के सभी तरीके, रैंकिंग के साथ (2026)"},{"content":"Kafka बाहर से देखने पर बेहद सरल लगता है — आप किसी टॉपिक पर पब्लिश करते हैं, कोई उसे पढ़ता है। पर्दे के पीछे यह एक काफी जटिल वितरित प्रणाली है जहाँ कई घटकों को यह तय करना होता है कि कौन किसका मालिक है, इससे पहले कि एक भी बाइट डिलीवर हो। मैंने इसे सुलझाने में काफी समय लगाया, और अधिकांश लेख \u0026ldquo;पार्टिशन आपको समानांतरता देते हैं\u0026rdquo; पर रुक जाते हैं, बिना वास्तविक हैंडशेक समझाए। आइए गहराई में जाएँ।\nKafka क्लस्टर वास्तव में क्या है Kafka क्लस्टर ब्रोकर्स का एक समूह है — सामान्य JVM प्रोसेस, प्रत्येक अपनी मशीन (या कंटेनर) पर चलता है। हर ब्रोकर डेटा का एक हिस्सा स्टोर करता है और बाकी क्लस्टर के बारे में जानता है [1]।\nटॉपिक वह लॉजिकल यूनिट है जिसके साथ आप इंटरैक्ट करते हैं। भौतिक रूप से, एक टॉपिक पार्टिशन में विभाजित होता है, और प्रत्येक पार्टिशन कई ब्रोकर्स में रेप्लिका के रूप में फैला होता है। उनमें से एक रेप्लिका लीडर होता है — वही एकमात्र जो उस पार्टिशन के रीड और राइट संभालता है। बाकी फॉलोअर हैं जो चुपचाप लीडर के डेटा को रेप्लिकेट करते हैं [1]।\nतो जब लोग कहते हैं \u0026ldquo;Kafka क्षैतिज रूप से स्केल करता है,\u0026rdquo; इसका अर्थ है: एक टॉपिक के लिए 100 पार्टिशन हो सकते हैं, और वे 100 पार्टिशन N ब्रोकर्स में फैले हो सकते हैं — प्रत्येक ब्रोकर एक अलग स्लाइस संभालता है, आपके ऐप का प्रत्येक कंज्यूमर समानांतर में एक अलग स्लाइस पढ़ता है।\nक्लस्टर को कौन कोऑर्डिनेट करता है — ZooKeeper बनाम KRaft यहीं पर बहुत से पुराने लेख लोगों को भ्रमित करते हैं। ऐतिहासिक रूप से, Kafka ने अपना क्लस्टर कोऑर्डिनेशन ZooKeeper को आउटसोर्स किया था। हर ब्रोकर ZooKeeper में एक एफेमेरल नोड बनाने की दौड़ में लगता था; पहला सफल होने वाला Controller ब्रोकर बन जाता था — वह जो क्लस्टर भर में पार्टिशन लीडर असाइन करने के लिए जिम्मेदार था [2]।\nवह आर्किटेक्चर अब नहीं रहा। Kafka 3.3 से इसे डिप्रेकेट किया गया है, और Kafka 4.0 से यह बस सपोर्टेड नहीं है [3]। इसका रिप्लेसमेंट KRaft (Kafka Raft) कहलाता है।\nKRaft: Kafka अपना कंसेंसस खुद चलाता है KRaft मोड में, ब्रोकर्स का एक उपसमूह (या डेडिकेटेड नोड्स) कंट्रोलर के रूप में कार्य करते हैं और एक Raft quorum बनाते हैं। वे Raft कंसेंसस एल्गोरिदम का उपयोग करके अपने बीच एक लीडर चुनते हैं — बहुमत वोट, पुराने लीडर को रोकने के लिए टर्म नंबर, और quorum को consistent रखने के लिए लॉग रेप्लिकेशन [4]।\nसभी क्लस्टर मेटाडेटा — टॉपिक कॉन्फिग, पार्टिशन असाइनमेंट, ब्रोकर रजिस्ट्रेशन — __cluster_metadata नामक एक आंतरिक Kafka टॉपिक में रहता है। सक्रिय कंट्रोलर लीडर इस लॉग में इवेंट लिखता है; फॉलोअर कंट्रोलर उन्हें रीप्ले करते हैं [3]। ब्रोकर इस मेटाडेटा स्ट्रीम को सब्सक्राइब करते हैं और अपना लोकल व्यू अपडेट रखते हैं।\nयह क्यों मायने रखता है? क्योंकि:\nफेलओवर तेज है — कोई बाहरी ZooKeeper कोऑर्डिनेशन राउंड-ट्रिप नहीं [2] मेटाडेटा लॉग खुद Kafka की गारंटी के साथ रेप्लिकेट होता है आप कम चलते-पुर्जे डिप्लॉय करते हैं पार्टिशन लीडर कैसे चुने जाते हैं जब एक ब्रोकर मर जाता है, तो किसी को उसकी पार्टिशन लीडरशिप लेनी होती है। यह काम KRaft कंट्रोलर का है।\nकंट्रोलर ISR लिस्ट (In-Sync Replicas) का उपयोग करके तय करता है कि नया लीडर कौन हो सकता है [5]। ISR उन फॉलोअर रेप्लिका का सेट है जो लीडर के साथ पूरी तरह अप-टू-डेट हैं — पिछड़े हुए रेप्लिका ISR से बाहर कर दिए जाते हैं। तो अगर कोई लीडर फेल होता है:\nकंट्रोलर पता लगाता है कि ब्रोकर गया वह मृत ब्रोकर द्वारा लीड किए जाने वाले प्रत्येक पार्टिशन के लिए ISR देखता है वह एक ISR सदस्य को चुनकर लीडर बनाता है वह उस निर्णय को __cluster_metadata में लिखता है अन्य सभी ब्रोकर मेटाडेटा स्ट्रीम से नया लीडर जान लेते हैं लीडर चुनाव के लिए केवल ISR सदस्य पात्र हैं। यह महत्वपूर्ण है — यह गारंटी देता है कि नए लीडर के पास सभी कमिटेड डेटा है और कंज्यूमर को कोई गैप नहीं दिखता [5]।\nकंज्यूमर वास्तव में सही ब्रोकर कैसे खोजता है यह वह हिस्सा है जिसे ज्यादातर लोग नजरअंदाज कर देते हैं। कंज्यूमर बस जादुई तरीके से सही ब्रोकर से नहीं जुड़ता। इसके लिए एक विशेष हैंडशेक होता है।\nचरण 1 — बूटस्ट्रैप (एकमुश्त क्लस्टर डिस्कवरी) आप bootstrap.servers को एक या अधिक ब्रोकर पतों के साथ कॉन्फिगर करते हैं। यह सूची केवल प्रारंभिक डिस्कवरी के लिए है, चल रहे ट्रैफिक के लिए नहीं [6]।\nक्लाइंट सूची से कोई भी पता चुनता है, TCP कनेक्शन खोलता है, और एक Metadata रिक्वेस्ट भेजता है। कोई भी ब्रोकर इसका जवाब दे सकता है — यह पूरी ब्रोकर लिस्ट और क्लाइंट को जिन टॉपिक की परवाह है उनके लिए पार्टिशन-टू-लीडर मैपिंग लौटाता है [6]। उस एकल रिक्वेस्ट के बाद, क्लाइंट के पास क्लस्टर का पूरा नक्शा होता है और वह सीधे जरूरत के लीडर से जुड़ता है।\nअगर आपका बूटस्ट्रैप ब्रोकर एक घंटे बाद मर जाए, क्लाइंट पहले से ठीक है — उसे बाकी क्लस्टर के बारे में पता है [6]।\nचरण 2 — ग्रुप कोऑर्डिनेटर खोजना कंज्यूमर बस किसी ब्रोकर से नहीं जुड़ते। हर कंज्यूमर ग्रुप एक विशेष ग्रुप कोऑर्डिनेटर ब्रोकर से जुड़ा होता है।\nमैपिंग निर्धारित है: Kafka group.id स्ट्रिंग को आंतरिक __consumer_offsets टॉपिक के एक पार्टिशन पर हैश करता है, और उस पार्टिशन का लीडर ग्रुप कोऑर्डिनेटर होता है [7]। एक ही group.id वाले सभी कंज्यूमर एक ही कोऑर्डिनेटर से बात करते हैं। अलग-अलग ग्रुप अलग-अलग कोऑर्डिनेटर में वितरित होते हैं।\nकंज्यूमर किसी भी ब्रोकर को FindCoordinator रिक्वेस्ट भेजता है (जिसमें उसकी group.id होती है)। वह ब्रोकर हैश रिज़ॉल्व करता है और कोऑर्डिनेटर का होस्ट और पोर्ट वापस भेजता है [7]।\nचरण 3 — JoinGroup और पार्टिशन असाइनमेंट एक बार जब ग्रुप का हर कंज्यूमर कोऑर्डिनेटर को ढूंढ लेता है, तो rebalance प्रोटोकॉल शुरू होता है:\nप्रत्येक कंज्यूमर कोऑर्डिनेटर को JoinGroup रिक्वेस्ट भेजता है कोऑर्डिनेटर एक कंज्यूमर को ग्रुप लीडर नामांकित करता है — आमतौर पर पहले जुड़ने वाला कोऑर्डिनेटर ग्रुप लीडर को पूरी सदस्य सूची भेजता है ग्रुप लीडर लोकली एक पार्टिशन असाइनमेंट स्ट्रेटेजी चलाता है और परिणाम वापस भेजता है कोऑर्डिनेटर SyncGroup रिस्पॉन्स के जरिए हर सदस्य को असाइनमेंट वितरित करता है [7][8] ग्रुप लीडर केवल एक अस्थायी लॉजिकल रोल है, स्थायी नोड नहीं। यह हर rebalance पर बदलता है [7]।\nपार्टिशन असाइनमेंट स्ट्रेटेजी Kafka कुछ बिल्ट-इन स्ट्रेटेजी के साथ आता है, जिन्हें partition.assignment.strategy के जरिए कॉन्फिगर किया जा सकता है [8]:\nस्ट्रेटेजी यह कैसे काम करती है किसके लिए सबसे अच्छी RangeAssignor कंज्यूमर्स में पार्टिशन को संख्यात्मक रूप से विभाजित करता है सरल, प्रति टॉपिक अनुमानित विभाजन RoundRobinAssignor कंज्यूमर्स में सर्कुलर वितरण टॉपिक्स में समान वितरण StickyAssignor पूर्व असाइनमेंट रखता है, rebalance पर मूवमेंट कम करता है वार्म कैश वाले stateful कंज्यूमर CooperativeStickyAssignor Sticky जैसा पर incremental rebalance की अनुमति देता है (3.0+ में डिफ़ॉल्ट) प्रोडक्शन — stop-the-world rebalance से बचाता है CooperativeStickyAssignor Kafka 3.0 से डिफ़ॉल्ट है क्योंकि यह incremental rebalance करता है — केवल वे पार्टिशन जिन्हें वास्तव में मूव होना है, रिवोक किए जाते हैं, एक साथ सभी नहीं [8]।\nकंज्यूमर क्या पढ़ सकते हैं और क्या नहीं एक सूक्ष्म बात: कंज्यूमर पार्टिशन लीडर से पढ़ते हैं, फॉलोअर से नहीं [5]। तो भले ही एक फॉलोअर रेप्लिका आपके कंज्यूमर के भौतिक रूप से करीब ब्रोकर पर हो, रीड फिर भी लीडर के पास जाता है।\nएक अपवाद है — Follower Fetching (Kafka 2.4 में पेश किया गया), जहाँ कंज्यूमर को निकटतम रेप्लिका से पढ़ने के लिए कॉन्फिगर किया जा सकता है। लेकिन डिफ़ॉल्ट रूप से, केवल लीडर रीड।\nकंज्यूमर हाई-वॉटर मार्क से परे का डेटा भी नहीं पढ़ सकते — वह नवीनतम ऑफसेट जिसे सभी ISR रेप्लिका ने स्वीकार किया है [5]। यह कंज्यूमर को ऐसा डेटा पढ़ने से रोकता है जो रोलबैक हो सकता है अगर फॉलोअर के कैच अप होने से पहले लीडर मर जाए।\nकंज्यूम करते समय ब्रोकर के फेल होने पर क्या होता है मान लें एक कंज्यूमर पार्टिशन 1 पढ़ रहा है, और उसका लीडर ब्रोकर क्रैश हो जाता है:\nKRaft कंट्रोलर ब्रोकर की विफलता का पता लगाता है वह पार्टिशन 1 के लिए ISR से नया लीडर चुनता है वह __cluster_metadata अपडेट करता है कंज्यूमर का अगला fetch रिक्वेस्ट पुराने ब्रोकर से NOT_LEADER_OR_FOLLOWER एरर (या टाइमआउट) पाता है कंज्यूमर स्वचालित रूप से अपना मेटाडेटा रिफ्रेश करता है और fetch को retry करता है — अब नए लीडर के पास [6] कंज्यूमर को मैनुअल हस्तक्षेप की जरूरत नहीं। क्लाइंट लाइब्रेरी retry और मेटाडेटा रिफ्रेश को पारदर्शी रूप से संभालती है। आपके एप्लिकेशन कोड के नजरिए से, एक संक्षिप्त विराम हो सकता है, लेकिन मेसेज खोए या डुप्लिकेट नहीं होते (सही ऑफसेट कमिट सेटिंग मानते हुए)।\nएक फ्लो में पूरी तस्वीर बूटस्ट्रैप ब्रोकर — केवल एक बार उपयोग, पूरा क्लस्टर मैप पाने के लिए ग्रुप कोऑर्डिनेटर — कंज्यूमर ग्रुप के लिए join/sync/heartbeat संभालता है पार्टिशन लीडर — वास्तविक ब्रोकर जिससे कंज्यूमर मेसेज fetch करता है ये तीन अलग-अलग ब्रोकर हो सकते हैं, या एक ही। Kafka को परवाह नहीं।\nयह डिज़ाइन टिकाऊ क्यों है आर्किटेक्चर वास्तव में सुंदर है जब आप इसे पूरा देखते हैं। मेटाडेटा डिस्कवरी, कोऑर्डिनेशन से अलग है, जो डेटा ट्रांसफर से अलग है। प्रत्येक लेयर का एक स्पष्ट मालिक है — क्लस्टर स्टेट के लिए KRaft, कंज्यूमर ग्रुप स्टेट के लिए ग्रुप कोऑर्डिनेटर, डेटा के लिए पार्टिशन लीडर।\nकिसी भी लेयर पर विफलताओं के लिए परिभाषित fallback पथ हैं। मृत बूटस्ट्रैप ब्रोकर स्टार्टअप के बाद अप्रासंगिक है। मृत ग्रुप कोऑर्डिनेटर FindCoordinator retry को ट्रिगर करता है। मृत पार्टिशन लीडर मेटाडेटा रिफ्रेश और reconnect को ट्रिगर करता है।\nलागू करने में सरल नहीं — लेकिन एक ऑपरेटर के रूप में तर्क करने में बहुत साफ।\nसमाप्त\nस्रोत Kafka Topics, Partitions, and Brokers: Core Architecture — Conduktor ZooKeeper and Apache Kafka® Explained: From Legacy to KRaft — Confluent KRaft vs ZooKeeper — Apache Kafka Official Docs KRaft Explained: How Kafka Implements Raft Consensus — Medium Understanding In-Sync Replicas (ISR) in Apache Kafka — GeeksforGeeks What is a Kafka Bootstrap Server? — Confluent Apache Kafka® Internal Architecture — Consumer Group Protocol — Confluent Developer How to Implement Kafka Consumer Assignment Strategies — OneUptime ","permalink":"https://cloudmato.com/hi/posts/kafka-cluster-management-consumer-routing/","title":"Kafka क्लस्टर को कैसे मैनेज करता है और कंज्यूमर को सही जगह कैसे रूट करता है"},{"content":"हर कुछ वर्षों में CSS में लेआउट करने का \u0026ldquo;सही\u0026rdquo; तरीका पूरी तरह बदल जाता है। अगर आपने 2015 से पहले CSS लिखना शुरू किया था, तो शायद हर बार जब कोई clearfix का उल्लेख करता है तो आपको एक हल्का आघात महसूस होता है। आइए मैं आपको बताता हूँ कि हम यहाँ तक कैसे पहुँचे — और 2026 में आपको वास्तव में किस चीज़ का उपयोग करना चाहिए।\nटेबल का युग (1990 के दशक – 2000 के दशक के मध्य) HTML टेबल कभी भी लेआउट के लिए नहीं बनाई गई थीं। वे टेबुलर डेटा प्रदर्शित करने के लिए मौजूद थीं। फिर वेब डिज़ाइनरों ने खोजा कि \u0026lt;table\u0026gt;, \u0026lt;tr\u0026gt;, और \u0026lt;td\u0026gt; आपको कुछ ऐसा देते हैं जो CSS अभी तक प्रदान नहीं कर सकती थी: पूर्वानुमानित कॉलम नियंत्रण [1]।\nतो पूरा वेब नेस्टेड टेबल के साथ बनाया गया था। सिर्फ एक परत गहरा नहीं — बहु-स्तरीय नेस्टिंग, टेबल के अंदर टेबल के अंदर टेबल। और स्पेसिंग नियंत्रित करने के लिए? एक पारदर्शी 1×1 पिक्सेल GIF इमेज (spacer.gif) जिसमें एक स्पष्ट width एट्रीब्यूट था [2]। मैं मज़ाक नहीं कर रहा। यही तकनीक थी।\nयह काम किया क्योंकि यह सुसंगत था। 90 के दशक के उत्तरार्ध में CSS सपोर्ट हास्यास्पद रूप से असंगत था। Internet Explorer और Netscape एक ही CSS को अलग-अलग तरह से रेंडर करते थे। टेबल हर जगह एक जैसी रेंडर होती थी। पूर्वानुमेयता जीती। [3]\nटेबल कभी भी लेआउट के लिए नहीं थीं। यह तथ्य कि वे डिफ़ॉल्ट बन गईं, पूरी तरह से ब्राउज़र असंगतता की एक दुर्घटना थी।\n2000 के दशक की शुरुआत तक, जब CSS सपोर्ट परिपक्व हुई और \u0026ldquo;सेपरेशन ऑफ कंसर्न्स\u0026rdquo; मुख्यधारा की सोच बन गई, समुदाय ने सामूहिक रूप से आगे बढ़ने का फैसला किया। सिवाय उस कोडबेस के जो आपकी कंपनी 2004 से मेंटेन कर रही है — उसमें अभी भी टेबल हैं।\nफ्लोट का युग (2000 के दशक की शुरुआत – ~2012) CSS float को किसी इमेज के चारों ओर टेक्स्ट लपेटने के लिए डिज़ाइन किया गया था — एक अखबार की फोटो की तरह जिसके चारों ओर टेक्स्ट बह रहा हो। बस इतना। यही इसका इच्छित उपयोग था [4]।\nकिसी ने पता लगाया कि अगर आप कई \u0026lt;div\u0026gt; एलीमेंट को बाईं ओर फ्लोट करते हैं, तो वे साथ-साथ बैठते हैं। मल्टी-कॉलम लेआउट प्राप्त हुआ। और इस तरह पूरा वेब टेबल हैक्स से फ्लोट हैक्स में स्थानांतरित हो गया।\nसमस्याएँ तत्काल थीं:\nएक फ्लोटेड एलीमेंट दस्तावेज़ प्रवाह से हटा दिया जाता है, इसलिए पैरेंट कंटेनर ढह जाता है इसे ठीक करने के लिए आपको overflow: hidden या खाली \u0026lt;div class=\u0026quot;clear\u0026quot;\u0026gt;\u0026lt;/div\u0026gt; एलीमेंट जोड़ने पड़ते थे प्रसिद्ध clearfix हैक — एक CSS छद्म-एलीमेंट ट्रिक — एक मानक कॉपी-पेस्ट स्निपेट बन गया जो हर डेवलपर अपने पास रखता था [4] /* The clearfix hack — you\u0026#39;ve seen this a thousand times */ .clearfix::after { content: \u0026#34;\u0026#34;; display: block; clear: both; } inline-block का भी उपयोग हुआ, क्षैतिज नेविगेशन आइटम के लिए। यह एक हद तक काम करता था जब तक आपको व्हाइटस्पेस समस्या का पता नहीं चलता था — आपके HTML टैग के बीच कोई भी स्पेस या न्यूलाइन एलीमेंट के बीच एक दृश्यमान अंतर के रूप में रेंडर होती थी। \u0026ldquo;ठीक\u0026rdquo; करने का तरीका था अपने समापन \u0026lt;/li\u0026gt; को अगले आइटम के शुरुआती \u0026lt;li\u0026gt; के साथ एक ही लाइन पर रखना। वास्तव में दयनीय।\nयह युग जितना चाहिए था उससे ज़्यादा लंबा चला, ज़्यादातर इसलिए क्योंकि विकल्पों के लिए ब्राउज़र सपोर्ट धीमा था।\nFlexbox (2012 – वर्तमान) CSS वर्किंग ग्रुप ने 2008 में Flex लेआउट मॉडल प्रस्तावित किया, 2009 में पहला वर्किंग ड्राफ्ट प्रकाशित किया, और फिर float/table/inline-block हैक्स पर निर्भरता हटाने के लिए 2011 में पूरी स्पेक को फिर से लिखा [1]।\ndisplay: flex लगभग 2012 के आसपास ब्राउज़र में शिप होना शुरू हुआ। वेंडर प्रीफिक्स की जुगलबंदी के बिना प्रोडक्शन के लिए सुरक्षित होने में ~2014-2015 तक का समय लगा।\nFlexbox ने वास्तव में क्या हल किया:\nवर्टिकल सेंटरिंग — आखिरकार। इसी एक चीज़ ने माइग्रेशन को उचित ठहराया। गैप नियंत्रण के साथ एक-अक्ष आइटम संरेखण आइटम जो उपलब्ध स्थान भरने के लिए आनुपातिक रूप से बढ़ते और सिकुड़ते हैं HTML को छुए बिना क्रम उलटना .nav { display: flex; align-items: center; gap: 1rem; } यह एक नेविगेशन बार है। कोई float नहीं। कोई clearfix नहीं। कोई spacer GIF नहीं। बस काम करता है।\nलेकिन Flexbox एक-आयामी है। यह एक पंक्ति या एक कॉलम संभालता है — दोनों एक साथ नहीं। केवल Flexbox का उपयोग करके हेडर, साइडबार, कंटेंट और फुटर के साथ एक पेज लेआउट बनाने की कोशिश करें और आप देखेंगे कि मेरा मतलब क्या है। आप flex कंटेनर के अंदर flex कंटेनर नेस्ट करते रहते हैं, और यह जल्दी ही अव्यवस्थित हो जाता है।\nCSS Grid (2017 – वर्तमान) यह Microsoft से आया। Microsoft के इंजीनियर अपने ब्राउज़र के लिए एक उचित लेआउट सिस्टम चाहते थे और 2012 में W3C को एक Grid Layout प्रस्ताव सबमिट किया। उन्होंने उस वर्ष -ms- वेंडर प्रीफिक्स का उपयोग करके IE10 में एक implementation शिप किया [1]।\nस्पेक वर्षों तक परिष्कृत होती रही। 2017 में, Chrome, Firefox, और Safari ने सभी ने एक दुर्लभ समन्वित रिलीज़ में एक-दूसरे के कुछ हफ्तों के भीतर CSS Grid शिप किया। यह वास्तव में एक बड़ा क्षण था।\nCSS Grid दो-आयामी है। पंक्तियाँ और कॉलम एक साथ।\n.page { display: grid; grid-template-areas: \u0026#34;header header\u0026#34; \u0026#34;sidebar content\u0026#34; \u0026#34;footer footer\u0026#34;; grid-template-columns: 250px 1fr; } यह छह लाइनों में आपका पूरा पेज लेआउट है। कोई फ्लोट नहीं। कोई clearfix नहीं। कोई नेस्टेड बकवास नहीं।\nSubgrid और Container Queries (2023 – वर्तमान) ये दो फीचर वर्तमान अग्रणी हैं। दोनों अब प्रोडक्शन में उपयोग के लिए सुरक्षित हैं।\nSubgrid क्लासिक Grid समस्या: आपके पास कार्ड का एक ग्रिड है। प्रत्येक कार्ड में एक शीर्षक, बॉडी टेक्स्ट और एक बटन है। शीर्षकों की अलग-अलग लंबाई होती है। प्रत्येक कार्ड के बटन अलग-अलग वर्टिकल पोज़ीशन पर समाप्त होते हैं। आप JavaScript हैक्स के बिना उन्हें कार्ड के पार संरेखित नहीं कर सकते — क्योंकि प्रत्येक कार्ड अपना खुद का stacking context है।\nSubgrid इसे ठीक करता है। एक चाइल्ड एलीमेंट पैरेंट ग्रिड की ट्रैक साइज़िंग इनहेरिट कर सकता है। [5]\n.card-grid { display: grid; grid-template-rows: auto 1fr auto; /* title / body / button */ } .card { display: grid; grid-row: span 3; grid-template-rows: subgrid; /* inherits parent tracks */ } अब हर बटन संरेखित है। कोई JavaScript नहीं। कोई position: absolute कलाबाजी नहीं।\n2026 तक ब्राउज़र सपोर्ट: वैश्विक स्तर पर 97%+ [6]। Firefox ने इसे 2019 में, Safari ने 2022 में, Chrome 117 ने सितंबर 2023 में शिप किया। यह हो गया — इसका उपयोग करें।\nContainer Queries मीडिया क्वेरी व्यूपोर्ट का जवाब देती हैं। Container queries पैरेंट कंटेनर का जवाब देती हैं। यह बहुत मायने रखता है जब एक ही कंपोनेंट साइडबार में और मुख्य सामग्री क्षेत्र में दिखाई देता है।\n.card-container { container-type: inline-size; } @container (min-width: 400px) { .card { flex-direction: row; } } Container queries अब सभी प्रमुख ब्राउज़र में समर्थित हैं [7]। यह वास्तव में पुन: उपयोग योग्य, रेस्पॉन्सिव कंपोनेंट बनाने का सही तरीका है जिन्हें यह जानने की जरूरत नहीं है कि उन्हें पेज पर कहाँ रखा जाएगा।\n2026 में वास्तविक सिफारिश लोग अभी भी \u0026ldquo;Flexbox बनाम Grid\u0026rdquo; के बारे में बहस करते हैं जैसे कि यह एक प्रतियोगिता है। दोनों का उपयोग करें। वे अलग-अलग समस्याएँ हल करते हैं।\nउपयोग का मामला टूल पेज संरचना (हेडर, साइडबार, कंटेंट, फुटर) CSS Grid कंपोनेंट इंटर्नल (nav आइटम, बटन ग्रुप, फॉर्म पंक्तियाँ) Flexbox कार्ड जिन्हें क्रॉस-आइटम संरेखण चाहिए CSS Grid + Subgrid व्यूपोर्ट संदर्भ के बिना रेस्पॉन्सिव कंपोनेंट Container Queries वास्तविक टेबुलर डेटा \u0026lt;table\u0026gt; — केवल वास्तविक डेटा के लिए लेआउट के लिए Float फिर कभी नहीं मानसिक मॉडल सरल है:\nGrid = आप दो आयामों में सोच रहे हैं। आप अपनी पंक्तियाँ AND कॉलम जानते हैं। Flexbox = आप एक आयाम में सोच रहे हैं। चीज़ों की एक पंक्ति, या चीज़ों का एक कॉलम। अगर आप कार्ड का ग्रिड बनाने के लिए display: flex; flex-wrap: wrap लिखते हुए खुद को पकड़ें — रुकें। यह Grid का काम है। Flexbox wrapping उन nav आइटम के लिए ठीक है जो रिफ्लो होनी चाहिए। यह संरचित मल्टी-कॉलम कार्ड के लिए अजीब है जहाँ पंक्तियों में संरेखण मायने रखता है।\nऔर कृपया — लेआउट के लिए float: left समाप्त हो गया है। 2017 से ही समाप्त हो गया। अगर आप अभी भी यह कर रहे हैं, तो उस कोडबेस को एक रिफैक्टर की जरूरत है, Stack Overflow के जवाब की नहीं।\nसमाप्त\nस्रोत CSS Grid और CSS Flexbox का इतिहास — Medium लेआउट के लिए टेबल? बेतुका। — वेब का इतिहास टेबललेस वेब डिज़ाइन — Wikipedia Clearfix: वेब डेवलपमेंट विकास में एक सबक — CSS-Tricks CSS Subgrid — web.dev CSS Subgrid ब्राउज़र सपोर्ट: पूर्ण कवरेज गाइड — FrontendTools 2026 में Container queries: शक्तिशाली, लेकिन रामबाण नहीं — LogRocket Blog CSS Grid बनाम Flexbox 2026: किसे कब उपयोग करें — StudioMeyer ","permalink":"https://cloudmato.com/hi/posts/css-layout-history-flexbox-grid-2026/","title":"CSS लेआउट का इतिहास: टेबल से ग्रिड तक — 2026 में क्या उपयोग करें"},{"content":"सभी लोग MCP को \u0026ldquo;AI के लिए बस एक API कॉलिंग लेयर\u0026rdquo; कहते हैं। यह धारणा गलत है — और यही कारण है कि \u0026ldquo;हमारे पास पहले से Swagger है\u0026rdquo; वाली आपत्ति बार-बार उठती है। दोनों बातों को समझना जरूरी है।\nMCP वास्तव में क्या है MCP का मतलब है Model Context Protocol। Anthropic ने इसे नवंबर 2024 में घोषित किया [1], और दिसंबर 2025 तक इसे Linux Foundation को Agentic AI Foundation के तहत दान कर दिया गया, जिसे Block और OpenAI के साथ मिलकर स्थापित किया गया था [2]। अकेले यह अपनाने की गति ध्यान देने योग्य है।\nएक वाक्य में: MCP एक मानक है जो बताता है कि AI मॉडल रनटाइम पर बाहरी टूल्स को कैसे खोजते और उपयोग करते हैं।\nयह JSON-RPC 2.0 पर बना है [2]। एक AI और उसके टूल्स के बीच हर संदेश एक संरचित रिमोट प्रोसीजर कॉल है — न कोई REST एंडपॉइंट, न कोई वेबहुक। वायर फॉर्मेट हमेशा एक जैसा रहता है, चाहे टूल कुछ भी करे या किसने बनाया हो।\nएक MCP सर्वर एक मॉडल को ठीक तीन प्रकार की चीजें प्रदान करता है [3]:\nTools — कॉल करने योग्य फंक्शन। जैसे get_weather(city) या create_github_issue(title, body)। Resources — संरचित डेटा जिसे मॉडल पढ़ सकता है। कोई फाइल, डेटाबेस रो, या कॉन्फिग ऑब्जेक्ट। Prompts — पूर्व-निर्मित टेम्पलेट जो बताते हैं कि मॉडल को सर्वर के साथ कैसे इंटरैक्ट करना चाहिए। मॉडल रनटाइम पर सर्वर से पूछ सकता है: आप क्या कर सकते हैं? सर्वर क्षमताओं की एक सूची के साथ जवाब देता है। मॉडल उस सूची से चुनता है। इसे ListToolsRequest [4] कहा जाता है, और यह प्रोटोकॉल का एक मुख्य हिस्सा है — कोई वैकल्पिक फीचर नहीं जिसे किसी ने बाद में जोड़ा हो।\n\u0026ldquo;प्रोटोकॉल\u0026rdquo; क्यों, न कि सिर्फ \u0026ldquo;API\u0026rdquo; एक API एक सतह है — एंडपॉइंट्स या फंक्शन का एक सेट जिसे आप कॉल करते हैं। एक प्रोटोकॉल एक अनुबंध है जो बताता है कि संचार कैसे होता है, जिसमें ट्रांसपोर्ट, मैसेज लाइफसाइकिल, एरर फॉर्मेट, क्षमता वार्ता और सेशन प्रबंधन शामिल हैं।\nHTTP एक प्रोटोकॉल है। REST एक आर्किटेक्चरल स्टाइल है जो उसके ऊपर परतदार है। MCP एक प्रोटोकॉल है।\nयहां विशेष रूप से वह है जो MCP परिभाषित करता है और जो इसे यह लेबल दिलाता है:\nट्रांसपोर्ट लेयर — तीन विकल्प: सबप्रोसेस के रूप में चलने वाले स्थानीय टूल्स के लिए STDIO, रिमोट टूल्स के लिए HTTP+SSE, और पूर्ण-डुप्लेक्स इंटरएक्टिविटी के लिए WebSocket [5]। सेशन लाइफसाइकिल — एक हैंडशेक जहां क्लाइंट और सर्वर एक बार क्षमताओं पर बातचीत करते हैं, फिर एक स्टेटफुल सेशन बनाए रखते हैं। हर बाद का JSON-RPC कॉल तेज होता है क्योंकि कोई पुनः-वार्ता नहीं होती [5]। क्षमता वार्ता — सर्वर घोषित करता है कि वह कौन सा वर्शन बोलता है, कौन से प्रिमिटिव्स प्रदान करता है, और क्या सपोर्ट करता है। क्लाइंट अनुकूलन करता है। मानकीकृत एरर फॉर्मेट — हमेशा एक ही संरचना। कोई कस्टम एरर स्कीमा नहीं। इसकी तुलना एक REST API से करें। हर एक अपनी खुद की ऑथ स्कीम, अपनी पेजिनेशन रणनीति, अपने एरर कोड, अपना वर्शनिंग बनाता है। एक डेवलपर डॉक्स पढ़ता है और एडेप्टर कोड लिखता है। MCP इन सभी के लिए मानक पैटर्न अनिवार्य करता है [4]।\nसबसे करीबी उपमा LSP — Language Server Protocol है [2]। आपके IDE को \u0026ldquo;Python भाषा सर्वर से कैसे बात करें\u0026rdquo; बनाम \u0026ldquo;TypeScript भाषा सर्वर से कैसे बात करें\u0026rdquo; के लिए अलग-अलग प्लगइन की जरूरत नहीं है। LSP बातचीत का आकार परिभाषित करता है। हर भाषा सर्वर इसे बोलता है। MCP AI टूल्स के लिए वही काम करता है।\nध्यान दें कि इस चित्र में OpenAPI कहां है — MCP सर्वर के अंदर, इससे प्रतिस्पर्धा में नहीं।\n\u0026ldquo;हमारे पास पहले से Swagger है\u0026rdquo; की आपत्ति यह सबसे आम पुशबैक है। तर्क यह है: OpenAPI पहले से ही मेरे सभी एंडपॉइंट्स का वर्णन करता है। एक AI उस स्पेक को पढ़ सकता है और API को कॉल कर सकता है। MCP को ऊपर क्यों जोड़ें?\nउचित प्रश्न। गलत निष्कर्ष।\nOpenAPI मनुष्यों के लिए लिखा गया एक दस्तावेज़ीकरण फॉर्मेट है। यह आपके API का वर्णन करता है ताकि एक डेवलपर इसे पढ़ सके और इसके खिलाफ कोड लिख सके। विवरण मानवीय संदर्भ मान लेते हैं। ऑथ पैटर्न, पेजिनेशन, एरर कोड — जैसा टीम को ठीक लगा [6]।\nएक कच्चे OpenAPI स्पेक के सामने LLM रखें और कई चीजें तुरंत टूट जाती हैं:\nGitHub API में 600 से अधिक एंडपॉइंट हैं [7]। LLM से सही एंडपॉइंट चुनने को कहें और वह भ्रमित हो जाता है — बहुत अधिक विकल्प, मानव डेवलपर्स के लिए लिखे गए विवरणों में बहुत अधिक अस्पष्टता। OpenAPI में कोई मानकीकृत रनटाइम डिस्कवरी नहीं है। आप LLM को पहले से एक स्टैटिक स्पेक फाइल देते हैं। MCP का ListToolsRequest हर सेशन में लाइव होता है, सर्वर के साथ जो यह नियंत्रित करता है कि वह क्या प्रदर्शित करता है। हर REST API कस्टम ऑथ, कस्टम पेजिनेशन, कस्टम एरर शेप्स का उपयोग करता है। आपके LLM को हर एक के लिए कस्टम एडेप्टर कोड चाहिए। MCP मानक पैटर्न अनिवार्य करता है [4]। एजेंट नियमित रूप से OpenAPI पैरामीटर कॉन्स्ट्रेंट्स को गलत समझते हैं और ऐसे फील्ड बनाते हैं जो मौजूद नहीं हैं [6]। डेवलपर्स के लिए लिखे गए विवरण, एजेंट निर्णय लेने के लिए लिखे गए विवरणों के समान नहीं हैं। यहां तुलना सीधे रखी है:\nपहलू OpenAPI / Swagger MCP प्राथमिक दर्शक मानव डेवलपर AI एजेंट (LLM) डिस्कवरी स्टैटिक स्पेक फाइल रनटाइम ListToolsRequest सेशन स्टेट स्टेटलेस HTTP स्टेटफुल सेशन ट्रांसपोर्ट विकल्प HTTP / REST STDIO, HTTP+SSE, WebSocket ऑथ पैटर्न हर API तय करता है प्रोटोकॉल में मानकीकृत विवरण किसके लिए लिखे डॉक्स पढ़ने वाला डेवलपर टूल चुनने वाला एजेंट सभी टूल्स में एकसमान काम? नहीं — कस्टम एडेप्टर हां — एकल प्रोटोकॉल वे दुश्मन नहीं हैं। एक MCP सर्वर एक मौजूदा REST API को आंतरिक रूप से लपेट सकता है, और अक्सर लपेटता है। FastMCP जैसे टूल्स एक OpenAPI स्पेक से सीधे MCP सर्वर ऑटो-जेनरेट कर सकते हैं [8]। MCP सर्वर आपके मौजूदा API के ऊपर एक क्यूरेटेड, एजेंट-फ्रेंडली फेसाड बन जाता है। आप डेवलपर-फेसिंग डॉक्स के लिए OpenAPI रखते हैं। आप एजेंट-फेसिंग इंटरैक्शन के लिए MCP जोड़ते हैं।\nN×M समस्या MCP से पहले, AI असिस्टेंट को बाहरी टूल्स से जोड़ना N×M समस्या थी [1]:\nN = AI मॉडल और असिस्टेंट की संख्या M = टूल्स और डेटा स्रोतों की संख्या हर संयोजन को अपनी खुद की इंटीग्रेशन की जरूरत थी। Claude का GitHub एडेप्टर Cursor के साथ काम नहीं करता था। Cursor का एडेप्टर अगले एजेंट के साथ काम नहीं करता था। हर टीम ने शुरुआत से अलग-अलग ग्लू कोड लिखा।\nMCP इसे N+M में बदल देता है। GitHub के लिए एक MCP सर्वर बनाएं — यह किसी भी MCP क्लाइंट के साथ काम करता है। Claude, Cursor, Windsurf, कोई भी एजेंट जो प्रोटोकॉल बोलता है। यह वास्तविक मूल्य प्रस्ताव है — \u0026ldquo;यह APIs को कॉल करता है\u0026rdquo; नहीं, बल्कि \u0026ldquo;यह यूनिवर्सल कनेक्टर शेप है ताकि आप एडेप्टर एक बार लिखें।\u0026rdquo;\nएक बात जो जाननी चाहिए आप कुछ ही मिनटों में एक मौजूदा OpenAPI स्पेक से MCP सर्वर ऑटो-जेनरेट कर सकते हैं [8]। बढ़िया लगता है। लेकिन इस पर हर गंभीर लेख एक ही बात की चेतावनी देता है: बाद में आक्रामक तरीके से छांटें [7]। 600-एंडपॉइंट वाला GitHub MCP सर्वर LLM के लिए एक आपदा है। 12-टूल वाला क्यूरेटेड सर्वर खूबसूरती से काम करता है। जेनरेशन आपको शुरू करता है। क्यूरेशन असली काम है।\nहुड के नीचे, MCP एक पाइप या HTTP स्ट्रीम पर JSON-RPC कॉल है — कोई जादू नहीं। लेकिन प्रोटोकॉल ही बात है: हर जगह बातचीत का एक ही आकार, स्टेटफुल सेशन, रनटाइम डिस्कवरी और मानक एरर हैंडलिंग के साथ। यही AI एजेंट को टूल्स और प्रोवाइडर्स के पार वास्तव में कंपोज़ेबल बनाता है।\nसमाप्त\nस्रोत Introducing the Model Context Protocol — Anthropic Model Context Protocol — Wikipedia Model Context Protocol (MCP) an overview — Phil Schmid MCP vs APIs: What\u0026rsquo;s the Real Difference? — freeCodeCamp Architecture overview — Model Context Protocol Exposing OpenAPI as MCP Tools — Christian Posta Auto-generating MCP Servers from OpenAPI Schemas: Yay or Nay? — Neon From OpenAPI (Swagger) to MCP Servers — La Rebelion ","permalink":"https://cloudmato.com/hi/posts/what-is-mcp-model-context-protocol/","title":"MCP केवल AI के लिए एक API लेयर नहीं है"},{"content":"OOP पचास साल से मौजूद है। Software में हर किसी ने इस पर एक course किया है। अधिकांश ने SOLID, inheritance, encapsulation, polymorphism के बारे में पढ़ा है। और फिर भी — मैं एक के बाद एक codebase में वही design गलतियाँ देखता रहता हूँ, startups से लेकर enterprise projects तक।\nTheory जानना अच्छा OOP लिखने के बराबर नहीं है। यहाँ जानते हैं कि वास्तव में कहाँ गलत होता है।\nGod Object एक project शुरू करें, एक UserService class बनाएं। कोई उसमें payment logic जोड़ता है। फिर notification handling। फिर authentication checks। छह महीने बाद: एक 2000-line की file जो सब कुछ करती है, सब पर निर्भर करती है, और जब भी कोई उसे छूता है तो टूट जाती है।\nएक class में बदलाव का एक, और केवल एक ही, कारण होना चाहिए। यह Single Responsibility Principle है [3]। और God Object — एक ऐसी class जो अत्यधिक जिम्मेदारियाँ जमा कर लेती है — इसका सबसे सीधा उल्लंघन है [2]।\nअसली समस्या यह नहीं है कि class बड़ी है। यह है कि इसे test करना, maintain करना, या किसी को सौंपना असंभव हो जाता है। एक method को unit test करने के लिए आपको आधे application को mock करना पड़ता है। उस class में किसी नए को onboard करने में तीन घंटे की archaeology लगती है। उसमें कुछ भी बदलें और आप निश्चित नहीं होते कि और क्या टूट जाएगा [1]।\nFix है splitting। अगर आपकी class में पूरी तरह अलग-अलग concerns — जैसे persistence और email sending — को handle करने वाले methods हैं, तो वे एक file में बंद दो classes हैं।\nInheritance कोड-शेयरिंग का टूल नहीं है यह वह है जो मुझे वास्तव में परेशान करता है, क्योंकि इसे अक्सर गलत तरीके से सिखाया जाता है — या कम से कम गलत याद रखा जाता है।\nInheritance को \u0026ldquo;is-a\u0026rdquo; relationship model करनी चाहिए। एक Dog एक Animal है। एक SavingsAccount एक BankAccount है। यही inheritance का उद्देश्य है [1]।\nइसके बजाय मैं जो देखता हूँ: एक class में पाँच उपयोगी methods हैं, और design के बारे में सोचने की बजाय, कोई उन methods तक पहुँचने के लिए उसे extend कर लेता है। इसका परिणाम है deep inheritance hierarchies, semantically असंबंधित classes के बीच tight coupling, और ऐसे codebases जहाँ एक function call trace करने में तीस मिनट लगते हैं [1]।\nक्लासिक उदाहरण है Ostrich extends Bird। Bird में fly() method है। Ostriches उड़ नहीं सकते, इसलिए Ostrich उसे override करके UnsupportedOperationException throw करता है। आपने Liskov Substitution Principle तोड़ दिया — एक subclass को program तोड़े बिना अपने parent की जगह लेने में सक्षम होना चाहिए [3][2]।\nयह real codebases में लगातार आता है, सिर्फ toy examples में नहीं।\nInheritance की जगह composition को प्राथमिकता दें [4]। Behavior inherit करने की बजाय, उसे inject करें:\n// गलत — contract तोड़ने के लिए override करता है class Ostrich extends Bird { @Override public void fly() { throw new UnsupportedOperationException(\u0026#34;Ostriches can\u0026#39;t fly\u0026#34;); } } // बेहतर — behavior compose किया गया है, inherit नहीं class Ostrich { private MovementBehavior movement; public Ostrich() { this.movement = new RunningBehavior(); } } Hierarchy flatter बन जाती है, behavior swappable बन जाता है, और जब भी requirements बदलती हैं तो आप design से लड़ना बंद कर देते हैं [4]।\npublic को Default मानना Encapsulation OOP के चार pillars में से एक है। किसी भी developer को यह दोहराने को कहें और वे सिर हिलाएंगे। फिर उनका code देखें और पाएंगे कि आधे fields public हैं और file के ऊपर तीन global variables बैठे हैं [1]।\nयह आमतौर पर जानबूझकर नहीं होता। किसी चीज़ को public mark करना यह सोचने से तेज़ है कि उसे वास्तव में किस access level की जरूरत है। लेकिन जैसे ही कुछ public होता है, अन्य classes उसे access करने लगती हैं। अब आपकी class की internal state implicitly बाकी codebase की है और आप इसे बिना चीजें तोड़े बदल नहीं सकते।\nPrivate से शुरू करें। Protected या public में तभी promote करें जब जरूरी हो। अगर आप अनिश्चित हैं कि किसी method को public होना चाहिए या नहीं, तो शायद नहीं होना चाहिए [1]।\nGlobal variables इस समस्या का extreme end हैं। एक बार कुछ global हो जाए, आपने उसका control पूरे application को सौंप दिया। Global कहाँ mutate होता है यह trace करना programming के सबसे अप्रिय debugging अनुभवों में से एक है।\nFat Interface का जाल Interface Segregation Principle SOLID परिवार में सबसे कम चर्चित है, और शायद वह जिसे मैं सबसे चुपचाप violated पाता हूँ [3]।\nClients को ऐसे interfaces implement करने के लिए मजबूर नहीं किया जाना चाहिए जिनका वे उपयोग नहीं करते [3]। इस discipline के बिना, आप read(), write(), delete(), archive(), और export() के साथ एक बड़ा IDataManager interface बनाते हैं। अब उसे implement करने वाली हर read-only service को write(), delete(), archive(), और export() भी implement करनी होगी — भले ही वह उन्हें कभी call न करे।\nपरिणाम है classes जो empty method stubs या throw new NotImplementedException() से भरी हैं। यह एक design problem है जो solution का costume पहने है।\nInterface को split करें। IReader, IWriter, IArchiver। हर class केवल वही implement करती है जो उसे वास्तव में चाहिए।\nCopy-Paste Programming यह उस समय हानिरहित लगता है। दो classes में similar logic है, बस कुछ lines हैं, और इसे extract करना overkill लगता है।\nयह हानिरहित नहीं है [5]। एक update, एक missed location, एक inconsistent bug fix — और दो copies diverge हो जाती हैं। अब application के दो हिस्सों में behavior में एक subtle difference है और कोई नहीं जानता यह कैसे आ गया [5]।\nखुद को दोहराएं नहीं। अगर वही logic दो जगह रहता है, तो वह एक जगह होना चाहिए। और अगर आप classes के बीच copy-paste कर रहे हैं, तो यह आमतौर पर संकेत है कि original design गलत था — एक shared concern है जो अपनी class बनने की प्रतीक्षा कर रही है।\nAbstraction को Over-Engineer करना ऊपर की हर बात का flip side, और सीधे कहने लायक: SOLID principles और design patterns tools हैं, goals नहीं।\nमैंने ऐसे codebases देखे हैं जहाँ दो numbers जोड़ने वाले method को एक CalculationStrategy interface, एक CalculationStrategyFactory, और एक CalculationStrategyFactoryProvider में wrap किया गया है। अतिशयोक्ति नहीं कर रहा [6]।\nAbstractions को अपना अस्तित्व justify करना चाहिए। बिना किसी concrete कारण के design patterns को over-apply करना code को पढ़ना कठिन बनाता है, आसान नहीं [7]। SOLID को over-apply करने का सबसे बड़ा खतरा यह है कि simple logic को समझने से पहले अब आपको पाँच abstract classes और dependency injection के तीन levels navigate करने पड़ते हैं [7]।\nउस complexity के लिए design करें जो आपके पास है। उस complexity के लिए नहीं जो आप theoretically कभी encounter कर सकते हैं।\nQuick Reference गलती कैसी दिखती है बेहतर तरीका God Object 10+ जिम्मेदारियों वाली एक class Single Responsibility से split करें Inheritance का दुरुपयोग Code reuse के लिए class extend करना Composition या delegation LSP violation Subclass method को exception से override करती है Hierarchy को redesign करें No encapsulation Public fields, हर जगह global state Default में private Fat interface 20 methods वाला एक interface Multiple focused interfaces Copy-paste Multiple classes में identical logic Shared component में extract करें Over-abstraction Simple addition के लिए Strategy factory Complexity justify होने पर abstraction जोड़ें End\nSources 3 Common Object-Oriented Programming Mistakes Junior Devs Make — DEV Community OOP Pitfalls in Java – Anti-patterns You Should Avoid SOLID Design Principles Explained — DigitalOcean Composition over Inheritance — Wikipedia Anti-Patterns in OOP: What to Watch Out For — Ahmed Ashraf on Medium How the SOLID Principles Guide Object-Oriented Design — Youngjun Kim on Medium When Using SOLID Principles May Not Be Appropriate — Baeldung ","permalink":"https://cloudmato.com/hi/posts/oop-mistakes-programmers-make/","title":"प्रोग्रामर जो OOP गलतियाँ बार-बार करते हैं"},{"content":"Amazon ने दुनिया का सबसे बड़ा क्लाउड प्लेटफ़ॉर्म बनाने का इरादा नहीं किया था। यह तो बस हो गया — जब कंपनी अपने इंजीनियरों को हर कुछ महीनों में एक ही इन्फ्रास्ट्रक्चर को बार-बार बनाने से रोकने की कोशिश कर रही थी।\nवह आंतरिक अराजकता जिसने सब शुरू किया लगभग 2000 के आसपास, Amazon Merchant.com बना रहा था — एक ऐसा प्रोडक्ट जो Target और Marks \u0026amp; Spencer जैसे थर्ड-पार्टी रिटेलर्स को Amazon के इन्फ्रास्ट्रक्चर पर अपनी ई-कॉमर्स स्टोर खड़ी करने देता [2]। लेकिन जो हुआ वह एक संगठनात्मक तबाही थी। हर टीम अपने-अपने स्टोरेज, कंप्यूट, और डेटाबेस प्रिमिटिव्स का अलग-अलग वर्शन बना रही थी। कोई साझा API नहीं, किसी चीज़ तक पहुँचने का कोई मानक तरीका नहीं।\nतो उन्होंने वही किया जो Amazon करता है: एक डॉक्युमेंट लिखा। 2003 की गर्मियों में, Jeff Bezos के घर पर एक एग्जेक्युटिव ऑफसाइट में, लीडरशिप टीम ने कंपनी की मूल दक्षता (core competency) पहचानने का एक अभ्यास किया। जवाब था: भरोसेमंद, स्केलेबल, वितरित सिस्टम बनाना [2]। Andy Jassy — तब एक VP, अब Amazon के CEO — ने अगला कदम साफ देखा। उन्होंने मूल AWS विज़न डॉक्युमेंट लिखा, जिसमें 57 लोगों की माँग की गई ताकि वे उसे बना सकें जिसे उन्होंने \u0026ldquo;इंटरनेट के लिए एक ऑपरेटिंग सिस्टम\u0026rdquo; कहा [2]।\nवही डॉक्युमेंट AWS बन गया।\nपहली सर्विसेज़ (2004–2006) यहाँ एक बात है जो ज़्यादातर लोग गलत जानते हैं: SQS पहली सार्वजनिक AWS सर्विस थी, न कि S3 या EC2 [6]। Amazon Simple Queue Service नवंबर 2004 में प्रीव्यू में लॉन्च हुई — स्टोरेज या कंप्यूट के सार्वजनिक होने से एक साल से भी पहले। अगर सोचें तो समझ में आता है। Amazon को अपनी आंतरिक सर्विसेज़ को डिकपल करने का तरीका चाहिए था, तभी वह कुछ और ऑफर कर सकता था।\nफिर आईं वे दो सर्विसेज़ जिन्होंने वाकई इंडस्ट्री बदल दी:\nAmazon S3 (Simple Storage Service) — 14 मार्च 2006 को लॉन्च हुई। स्केल पर ऑब्जेक्ट स्टोरेज, केवल उतना भुगतान करें जितना उपयोग करें [3] Amazon EC2 (Elastic Compute Cloud) — 24 अगस्त 2006 को प्रीव्यू; अक्टूबर 2008 में सामान्य रूप से उपलब्ध [3] EC2 से पहले, एक स्टार्टअप को फिज़िकल सर्वर खरीदने या लीज़ करने पड़ते थे, उन्हें प्रोविज़न करना पड़ता था, रैक में लगाना पड़ता था, और बस यही दुआ करनी पड़ती थी कि ट्रैफ़िक के अनुमान गलत न हों। EC2 के बाद, एक क्रेडिट कार्ड वाला डेवलपर मिनटों में जितना कंप्यूट चाहे उतना पा सकता था [1]। सॉफ़्टवेयर बनाने की अर्थव्यवस्था हमेशा के लिए बदल गई।\nलॉन्च के तीन साल बाद, AWS का वार्षिक रन रेट $58 मिलियन था [3]। आज के आंकड़ों के हिसाब से छोटा, लेकिन दिशा बिल्कुल स्पष्ट थी।\nअसली प्लेटफ़ॉर्म बनाना (2007–2012) AWS ने इन वर्षों में \u0026ldquo;सस्ते कंप्यूट और स्टोरेज\u0026rdquo; को एक ठोस क्लाउड प्लेटफ़ॉर्म में बदला। एक-एक करके कमियाँ दूर होती रहीं:\nAmazon CloudFront (2008) — दुनिया भर में एज डिलीवरी के लिए CDN [3] Amazon RDS (2009) — मैनेज्ड रिलेशनल डेटाबेस; अब raw EC2 पर MySQL की देखभाल नहीं [3] Amazon EMR (2009) — डेटा टीमों के लिए माँग पर Hadoop क्लस्टर [3] Amazon VPC (2010) — Virtual Private Cloud, AWS के अंदर अलग-थलग नेटवर्किंग [3] Amazon DynamoDB (2012) — स्केल पर NoSQL, Amazon के अपने शॉपिंग कार्ट आर्किटेक्चर से जन्मा [4] Amazon Redshift (2012) — पेटाबाइट-स्केल डेटा वेयरहाउसिंग [3] डेटाबेस सर्विसेज़ खासतौर पर महत्वपूर्ण थीं। RDS से पहले, कंपनियाँ या तो Oracle को मोटी रकम दे रही थीं या raw EC2 इंस्टेंस पर खुद MySQL मैनेज कर रही थीं और रात 2 बजे कुछ न बिगड़े इसकी दुआ करती थीं। AWS ने यह पूरी समस्या खुद में समेट ली।\nसर्वरलेस की ओर बदलाव (2013–2016) AWS re:Invent 2014 वह पल था जब इंडस्ट्री फिर आगे बढ़ी। AWS Lambda लॉन्च हुआ — यह विचार कि आपको सर्वर के बारे में बिल्कुल नहीं सोचना, बस एक फ़ंक्शन अपलोड करें और प्रति इनवोकेशन भुगतान करें [3]। Serverless की अवधारणा Lambda के पहले अस्तित्व में नहीं थी — Lambda ने इसे वास्तविक और व्यावहारिक बनाया।\nउसी समय एंटरप्राइज़ की कमियाँ भी भरी जा रही थीं:\nAmazon Aurora (2015) — MySQL/PostgreSQL-कंपेटिबल लेकिन कस्टम स्टोरेज इंजन के साथ, जो मानक MySQL से 5 गुना बेहतर परफ़ॉर्मेंस का दावा करता है [3] AWS CloudTrail (2013) — ऑडिट लॉगिंग, जो कम्प्लायंस टीमों के लिए अनिवार्य साबित हुई AWS Certificate Manager (2016) — मुफ़्त TLS सर्टिफ़िकेट; Symantec के बिल को अलविदा 2015 में, AWS Amazon का सबसे लाभदायक बिज़नेस यूनिट बन गया — उस रिटेल ऑपरेशन से भी ज़्यादा मुनाफ़ेवाला जिसने Amazon को शुरुआत में मानचित्र पर रखा था [4]। यह एक असली मोड़ था। आंतरिक अराजकता कम करने के लिए शुरू हुआ एक साइड प्रोजेक्ट अब बाकी सब को फ़ंड करने वाला इंजन बन चुका था।\n2016 तक, AWS राजस्व $12.2 बिलियन तक पहुँच गया [3]।\nप्लेटफ़ॉर्म परिपक्व होता है (2017–2022) इस समय तक AWS \u0026ldquo;क्लाउड कंप्यूट\u0026rdquo; नहीं रहा था और एंटरप्राइज़ के लिए एक पूर्ण ऑपरेटिंग वातावरण के करीब कुछ बन गया था। प्रमुख जोड़:\nAmazon SageMaker (2017) — एक मैनेज्ड ML प्लेटफ़ॉर्म जिसने शुरू से ट्रेनिंग इन्फ्रास्ट्रक्चर सेटअप की ज़रूरत खत्म की [5] AWS Fargate (2017) — सर्वरलेस कंटेनर; Lambda लेकिन Docker वर्कलोड के लिए Amazon EKS (2018) — मैनेज्ड Kubernetes, जब यह साफ हो गया कि इंजीनियर इसे EC2 पर चला ही रहे थे AWS Ground Station (2019) — मैनेज्ड सर्विस के रूप में सैटेलाइट संचार [3] रणनीति स्पष्ट हो गई: किसी कंपनी को जिस भी इन्फ्रास्ट्रक्चर की ज़रूरत हो उसे पहचानें और उसका मैनेज्ड वर्शन बनाएँ। डेटाबेस, क्यू, स्ट्रीमिंग, वीडियो ट्रांसकोडिंग, IoT, ML, ब्लॉकचेन, यहाँ तक कि क्वांटम कंप्यूटिंग सिमुलेशन भी। 2020 तक गिनती 175 सर्विसेज़ पार कर चुकी थी [3]। वे रुकने वाले नहीं थे।\nAI की ओर कदम (2023–अब) जेनरेटिव AI की लहर ने हर क्लाउड प्रोवाइडर को गति के मामले में अचानक पकड़ा, लेकिन AWS ने तेज़ी से कदम उठाए:\nAmazon Bedrock — फाउंडेशन मॉडल के लिए एक मैनेज्ड API लेयर: Anthropic का Claude, Meta का Llama, Mistral, और अन्य। बिना मॉडल इन्फ्रास्ट्रक्चर मैनेज किए AI ऐप बनाएँ [5] Amazon SageMaker AI (2024 रिडिज़ाइन) — एक एकीकृत डेटा और AI स्टूडियो के रूप में पुनर्निर्मित, जिसने मॉडल ट्रेनिंग वर्कफ़्लो को महीनों से घटाकर दिनों में ला दिया [5] Amazon Nova — AWS का खुद का फाउंडेशन मॉडल परिवार, re:Invent 2024 में घोषित [5] AWS का AI राजस्व रन रेट 2026 की शुरुआत में $15 बिलियन पार कर गया [9]। 20 साल के इन्फ्रास्ट्रक्चर निवेश का संचयी प्रभाव इन आंकड़ों में साफ दिख रहा है।\nआज यह कहाँ खड़ा है मेट्रिक 2026 आंकड़ा वार्षिक राजस्व (2025) $128.7 बिलियन [7] क्लाउड बाज़ार हिस्सेदारी ~32% [8] कुल सर्विसेज़ 200+ [3] वैश्विक क्षेत्र 36 [3] उपलब्धता क्षेत्र (Availability Zones) 100+ [3] सेवा प्राप्त देश 245 [3] 2006 से मूल्य कटौती 129 बार [3] Azure ~23% पर है और बढ़ रहा है। Google Cloud ~11% पर है [8]। AWS आगे है लेकिन अंतर पाँच साल पहले से कम हो गया है — Microsoft के OpenAI इंटीग्रेशन ने महत्वपूर्ण एंटरप्राइज़ वर्कलोड Azure की तरफ खींचे हैं, और यह प्रतिस्पर्धा और दिलचस्प होती जाएगी।\nइस यात्रा को पूरी तरह समझना मुश्किल है। 2003 का एक आंतरिक दस्तावेज़ जिसमें साझा APIs बनाने के लिए 57 लोगों की माँग की गई थी, वह एक ऐसा व्यवसाय बन गया जो अधिकांश देशों की GDP से अधिक राजस्व उत्पन्न करता है। और इसे बनाने का मूल कारण बस आंतरिक टीमों को काम दोहराने से रोकना था।\nसमाप्त\nस्रोत हमारी उत्पत्ति – Amazon Web Services AWS कैसे बना – TechCrunch Amazon Web Services की समयरेखा – Wikipedia AWS का उल्लेखनीय इतिहास – TechAhead AWS ने नई पीढ़ी का Amazon SageMaker लॉन्च किया – Amazon Press पहली AWS सर्विस क्या थी? – Peakscale AWS आँकड़े 2026: राजस्व और ऑपरेटिंग इनकम – ExpandedRamblings क्लाउड बाज़ार हिस्सेदारी 2026: AWS बनाम Azure बनाम Google – BusinessTats AWS at 20: Amazon के क्लाउड साम्राज्य के उदय की कहानी – GeekWire ","permalink":"https://cloudmato.com/hi/posts/aws-evolution-history/","title":"AWS कैसे एक सर्विस से 200+ तक पहुँचा"},{"content":"मैंने वर्षों में जितने भी ब्लॉग देखे हैं, वे ज़्यादातर WordPress पर चलते हैं — एक database, PHP, plugins, और हर दूसरे हफ़्ते security patches। मूल रूप से सिर्फ़ text publish करने वाली साइट के लिए बहुत सारे moving parts। Hugo इन सबके बिल्कुल विपरीत है। न database, न runtime। बस plain HTML files जो एक CDN से serve होती हैं, एक सेकंड से भी कम समय में generate होती हैं।\nHugo असल में क्या है — और यह इतना तेज़ क्यों है? Hugo Go में लिखा गया एक open-source static site generator है [1]। आप Markdown में content लिखते हैं, एक theme चुनते हैं, एक command चलाते हैं, और यह plain HTML, CSS, और JS का एक folder तैयार कर देता है। वही folder आपकी पूरी website है। Server पर कुछ भी नहीं चलता। न PHP, न Python, न कोई Node process जिसे जीवित रखना पड़े।\nयह speed सिर्फ़ marketing नहीं है। Hugo को 10,000 से ज़्यादा pages वाली sites को 10 सेकंड से कम में generate करते हुए benchmark किया गया है [2]। कुछ benchmarks में यह Jekyll जैसे alternatives से 100 गुना तक तेज़ पाया गया है [3]। इसकी वजह है Go — compiled, डिज़ाइन से ही concurrent, और Hugo इसका भरपूर उपयोग करता है।\nकोई runtime नहीं = कोई attack surface नहीं। कोई database नहीं जिसे breach किया जाए, कोई server-side code नहीं जिसे exploit किया जाए, कोई भूला हुआ plugin नहीं जिसे 2021 से security updates मिलना बंद हो गई हों [4]।\nइसे सेटअप करना Hugo install करें। macOS पर:\nbrew install hugo Ubuntu/Debian पर:\nsudo apt install hugo Verify करें:\nhugo version v0.158.0 या उसके बाद का version इस्तेमाल करें [1]। अगर आप SCSS-heavy themes के साथ काम करने की योजना बना रहे हैं, तो extended version install करें — इसमें Dart Sass built in आता है [2]।\nअपनी साइट बनाएं hugo new site my-site cd my-site git init Hugo तुरंत यह structure तैयार करता है:\nmy-site/ ├── archetypes/ ├── assets/ ├── content/ ├── layouts/ ├── static/ ├── themes/ └── hugo.toml content/ — आपके Markdown posts और pages themes/ — theme files यहाँ रहती हैं static/ — output में जैसे-का-तैसे copy होता है (favicon, images, fonts) hugo.toml — पूरी साइट की config अपनी पहली post लिखें hugo new content content/posts/hello-world.md फ़ाइल खोलें और आपको pre-filled front matter दिखेगा:\n+++ title = \u0026#34;Hello World\u0026#34; date = \u0026#34;2026-06-01T22:45:10+05:30\u0026#34; draft = true +++ जब publish करने के लिए तैयार हों, तो draft = false करें। Hugo production build के दौरान draft posts को चुपचाप skip कर देता है [1]।\nLocal में preview करें hugo server -D -D flag drafts को शामिल करता है। आपकी साइट http://localhost:1313 पर उपलब्ध है, save करते ही hot-reload होती है [1]।\nथीम — एक चुनें और ज़्यादा सोचना बंद करें Hugo themes gallery में 200 से ज़्यादा options हैं [5]। तीन जो जानने लायक हैं:\nथीम Stars किसके लिए सबसे अच्छा PaperMod 11,000+ Developer blogs, साफ़ reading Congo 1,300+ Personal sites, Tailwind-based Ananke 1,200+ सामान्य उपयोग, official starter PaperMod GitHub पर सबसे ज़्यादा stars वाली Hugo theme है [6]। तेज़, dark mode सपोर्ट करती है, built-in search, table of contents, multilingual support, multiple authors। मैं वहीं से शुरू करूँगा और जब तक वास्तव में ज़रूरत न हो, कुछ और नहीं देखूँगा।\nइसे git submodule के रूप में install करें:\ngit submodule add https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod इसे hugo.toml में set करें:\ntheme = \u0026#34;PaperMod\u0026#34; PaperMod, Congo, और Ananke सभी configuration-driven हैं, code-driven नहीं [6]। Customization hugo.toml params और front matter के ज़रिए होता है — theme update होने पर आपके बदलाव मिटते नहीं।\nकहाँ Deploy करें तीन वास्तव में मुफ़्त options जो Hugo के साथ अच्छी तरह काम करते हैं:\nPlatform मुफ़्त Bandwidth Edge CDN Auto Deploy सावधान रहें Cloudflare Pages Unlimited requests Global edge हाँ Workers पर बढ़ता ध्यान [8] GitHub Pages Unlimited (public repos) सीमित Via Actions कम features [1] Netlify 100 GB/month हाँ हाँ 2025 के अंत से credit billing [8] Cloudflare Pages वह जगह है जहाँ मैं कोई भी public-facing चीज़ रखूँगा। Cloudflare का global edge network इसका मतलब है कि आपका HTML visitors तक उनके पास के node से पहुँचता है [7]। Free tier bandwidth throttle नहीं करता। एक ईमानदार बात: Cloudflare तेज़ी से Pages की जगह अपने Workers product को push कर रहा है [8], इसलिए roadmap पर नज़र रखना उचित है।\nNetlify सेटअप करने में सबसे तेज़ है — एक GitHub repo connect करें, यह Hugo को auto-detect करता है, deploy करता है। लेकिन Netlify ने 2025 के अंत में credit-based billing में बदलाव कर लिया [8]। जब आप free allowance से ज़्यादा हो जाते हैं, तो वे आपकी साइट pause कर देते हैं। Cloudflare बस serving जारी रखता है।\nGitHub Pages ठीक काम करता है अगर आप पहले से GitHub ecosystem में हैं। कोई preview deployments नहीं, कम features — लेकिन अगर आपका repo वहाँ पहले से है तो कोई झंझट नहीं [1]।\nCloudflare Pages पर deploy करना पाँच steps में होता है:\nअपना Hugo repo GitHub या GitLab पर push करें Cloudflare Pages dashboard में repo connect करें Build command set करें: hugo --minify Output directory set करें: public Env variable add करें: HUGO_VERSION = 0.158.0 [7] main पर हर push automatically rebuild और deploy trigger करता है। कोई देखरेख नहीं।\nरोज़मर्रा की देखभाल यहीं पर static sites वास्तव में जीतती हैं। कोई server patch नहीं करना। कोई plugin updates नहीं। किसी PHP version के साथ compatible रहने की ज़रूरत नहीं। \u0026ldquo;आपका WordPress installation पुराना है\u0026rdquo; जैसी कोई चेतावनी नहीं।\nपूरा content workflow यह है:\nhugo new content content/posts/new-post.md # अपने editor में लिखें git add content/posts/new-post.md git commit -m \u0026#34;add: new post\u0026#34; git push main पर push करें। साइट सेकंडों में rebuild हो जाती है। बस [9]।\nnon-technical collaborators के लिए, Decap CMS Hugo के साथ integrate होता है और Git-backed browser-based editor प्रदान करता है [9]। Writers एक UI में content edit करते हैं, CMS Markdown को repo में commit करता है, Hugo build करता है। किसी को terminal छूने की ज़रूरत नहीं।\nHugo version upgrades hosting dashboard में एक env variable बदलने की बात है। कोई npm audit alerts नहीं, कोई dependency tree conflicts नहीं, कोई ecosystem drama नहीं।\nआख़िर Static क्यों? Static sites तब से हैं जब से web शुरू हुई। जब databases सस्ते हो गए और WordPress ने CMS को सबके लिए accessible बनाया तो ये fashion से बाहर हो गईं। वापस जाने के कारण:\nSpeed — CDN से pre-built HTML, request के समय render होने वाली किसी भी चीज़ से तेज़ load होती है [4] Security — कोई database नहीं, कोई server execution नहीं, कोई exploitable surface नहीं [4] Cost — अधिकांश personal और small business projects के लिए वास्तव में मुफ़्त hosting Portability — source git repo में Markdown files है; किसी भी host पर एक दोपहर में migrate करें Reliability — CDN पर एक static file को traffic load के तहत PHP server की तुलना में बंद करना बहुत मुश्किल है [3] Hugo एक और चीज़ जोड़ता है जो तब मायने रखती है जब आपके पास बहुत सारा content हो: build time। 1,000 pages की साइट एक सेकंड से भी कम में [3]। लिखते समय live reload, कोई प्रतीक्षा नहीं। बड़ी teams जो अक्सर content update करती हैं, slow builds से block नहीं होंगी।\nअगर आप एक blog, documentation site, portfolio, या marketing site चला रहे हैं जिसे real-time data की ज़रूरत नहीं है — तो इसके लिए dynamic server चलाने का कोई अच्छा कारण नहीं है।\nसमाप्त\nस्रोत Hugo Quick Start A Guide to Using Hugo in 2024 and 2025 — Strapi Why Hugo is the Best Static Blog Framework in 2025 — DEV Community The Resurgence of Static Sites — DillonBaird.io Hugo Themes Gallery Hugo PaperMod — GitHub Deploy a Hugo Site — Cloudflare Pages Docs Hugo Deployment: Netlify, Vercel, and Cloudflare Pages Comparison Hugo with Decap CMS: Git-Based Content Management Top Hugo Themes 2025 — Rost Glukhov ","permalink":"https://cloudmato.com/hi/posts/build-deploy-static-site-hugo/","title":"Hugo से Static Site बनाएं और Deploy करें"},{"content":"आप इसे ब्राउज़र टैब में देखते हैं। आप इसे सर्च रिज़ल्ट्स में साइट के नाम के पास देखते हैं। आप इसे किसी वेबसाइट का लोगो समझते हैं। तो इसे favicon क्यों कहते हैं? यह नाम टैब्स या लोगो से कोई संबंध नहीं रखता। और आप सही हैं — इसका कोई संबंध नहीं है। यह नाम उस चीज़ की विरासत है जिसके लिए यह आइकन मूल रूप से बनाया गया था, न कि जो यह आज करता है।\nयह कभी टैब्स के लिए नहीं था \u0026ldquo;Favicon\u0026rdquo; नाम दो शब्दों का संयोजन है: favorite + icon [1]। यानी वह आइकन जो आपके ब्राउज़र की favourites list में किसी वेबसाइट के पास दिखता है — जिसे अधिकांश लोग बुकमार्क्स कहते हैं।\nयही इस नाम के पीछे की पूरी कहानी है। यह एक बुकमार्क्स आइकन था। टैब आइकन नहीं। साइट लोगो नहीं। ब्राउज़र टैब में इसका उपयोग बहुत बाद में आया, और तब तक यह नाम अटक चुका था।\nएक डेवलपर, एक देर रात, एक चालाक अप्रूवल साल था 1999। ब्राउज़र वॉर्स पूरे जोरों पर थे। Microsoft, Internet Explorer 5 पर काम कर रहा था और Bharat Shyam नाम का एक डेवलपर Favorites फीचर पर काम कर रहा था [2]।\nउनका विचार सरल था: जब आप किसी साइट को बुकमार्क करें, तो URL के पास एक छोटा सा आइकन देखना सादे टेक्स्ट लिंक से बेहतर नहीं होगा? तो उन्होंने इसे बनाया — एक 16×16 पिक्सेल का आइकन, जो किसी वेबसाइट के सर्वर की root में रखी favicon.ico फ़ाइल से लोड होता था [3]।\nमज़ेदार बात यह है। Shyam को पता था कि यह addition सामान्य चैनलों से अप्रूव नहीं हो पाएगी, इसलिए उन्होंने देर शाम का इंतज़ार किया जब एक कम अनुभवी प्रोजेक्ट मैनेजर ड्यूटी पर था — junior PM Ray Sun। उन्होंने Sun को फीचर दिखाया और कोड check in करवा लिया [4]। इस तरह favicon.ico चुपचाप IE5 में शामिल हो गया, जो मार्च 1999 में रिलीज़ हुआ [5]।\nसच कहें तो, बहुत से अच्छे वेब फीचर्स शायद इसी तरह से पास हुए होंगे।\nफ़ाइल फॉर्मेट का चुनाव चूंकि IE5 Windows पर चलता था, Shyam ने .ico फॉर्मेट का उपयोग किया — एक Windows-native आइकन फॉर्मेट जिसे Microsoft पहले से पूरी तरह सपोर्ट करता था [2]। अपने वेब सर्वर की root में एक favicon.ico फ़ाइल डालें, और IE किसी साइट को user की favorites list में जोड़ने से पहले इसे अपने आप उठा लेता था। कोई HTML टैग की ज़रूरत नहीं। बस एक convention।\nयही कारण है कि root में favicon.ico 2026 में भी मौजूद है। ब्राउज़र अभी भी डिफ़ॉल्ट रूप से वहाँ देखते हैं, भले ही HTML अब आपको इसे स्पष्ट रूप से declare करने का तरीका देता है।\nW3C जल्दी शामिल हो गया उसी साल, W3C ने दिसंबर 1999 में HTML 4.01 specification में favicon support को शामिल कर लिया [6]। इसे declare करने का मानक तरीका था:\n\u0026lt;link rel=\u0026#34;shortcut icon\u0026#34; href=\u0026#34;/favicon.ico\u0026#34; type=\u0026#34;image/x-icon\u0026#34;\u0026gt; ध्यान दें shortcut icon — दो शब्द। \u0026ldquo;Shortcut\u0026rdquo; बुकमार्क्स के लिए Microsoft की terminology थी (वे Windows desktop पर \u0026ldquo;shortcuts\u0026rdquo; का उपयोग करते थे)। इसलिए HTML syntax में भी बुकमार्क्स की उत्पत्ति आगे चली। W3C ने अंततः स्पष्ट किया कि shortcut एक valid keyword नहीं है और rel=\u0026quot;icon\u0026quot; सही रूप है [7], लेकिन आप shortcut icon पूरे इंटरनेट पर अभी भी देखेंगे क्योंकि पुरानी आदतें जल्दी नहीं जातीं।\nयह ब्राउज़र टैब्स पर कब आया? यह वह हिस्सा है जो वास्तव में नाम को भ्रामक लगाता है।\nIE5 केवल favourites list में और जब आप किसी साइट पर होते थे तो address bar में favicons दिखाता था। ब्राउज़र टैब का उपयोग तब आया जब tabbed browsing 2000 के दशक की शुरुआत से मध्य तक मुख्यधारा में आई — Firefox, Opera, Safari सभी ने favicon को उठाया और इसे टैब पर ही रेंडर करने लगे [2]।\nउस समय, favicon अपने मूल संदर्भ से पूरी तरह बाहर निकल चुका था। अब यह हर विज़िट के लिए एक स्थायी visual identity बन गया था — बुकमार्क हो या न हो। लेकिन किसी ने इसका नाम नहीं बदला। \u0026ldquo;Favicon\u0026rdquo; चलता रहा, भले ही तब तक इसे \u0026ldquo;tab icon\u0026rdquo; या \u0026ldquo;site icon\u0026rdquo; कहना कहीं अधिक उचित होता।\nमोबाइल का विस्तार जब Apple ने 2007 में पहला iPhone लॉन्च किया, तो उन्होंने Apple Touch Icon नाम की चीज़ पेश की — एक उच्च रिज़ॉल्यूशन आइकन जो iOS home screen पर webpage save करने पर दिखता है [2]। यह बिल्कुल ऐप आइकन जैसा दिखता है।\nAndroid ने 2010 के आसपास इसका अनुसरण किया। फिर Progressive Web Apps आए, जिन्हें install scenarios के लिए पूरे manifest.json में आइकन की ज़रूरत होती है।\nतो अब एक वेबसाइट से यह अपेक्षा की जाती है कि वह बनाए रखे:\nLegacy browsers के लिए favicon.ico Modern browsers के लिए PNG favicon (आमतौर पर 32×32 या 96×96) Apple Touch Icons (वर्तमान iOS के लिए 180×180) PWAs के लिए Web App Manifest icons (192×192, 512×512) सामान्य भाषा में ये सभी \u0026ldquo;favicon\u0026rdquo; हैं। इनमें से कोई भी अब बुकमार्क्स आइकन नहीं है।\nक्या यह नाम भ्रामक है? कुछ हद तक, लेकिन वास्तव में नहीं — यह बस पुराना हो गया है।\nजब Bharat Shyam ने 1999 में \u0026ldquo;favicon\u0026rdquo; गढ़ा, तो नाम बिल्कुल सटीक था। यह शाब्दिक रूप से आपके favorites के लिए एक आइकन था। समस्या यह है कि आइकन का कार्य 25 वर्षों में बड़े पैमाने पर बढ़ा जबकि नाम 1999 में ही रुक गया। टेक में यह बहुत होता है — \u0026ldquo;wireless\u0026rdquo; का मतलब radio हुआ करता था, \u0026ldquo;desktop\u0026rdquo; का मतलब अभी भी आपका computer है भले ही फोन वही काम करते हों।\n\u0026ldquo;Favicon\u0026rdquo; नाम भ्रामक नहीं है, यह कालबाह्य है। फर्क है। कोई आपको भ्रमित करने की कोशिश नहीं कर रहा था — उपयोग का मामला बस मूल इरादे से बहुत आगे बढ़ गया।\nफॉर्मेट का विकास युग फॉर्मेट आकार कहाँ 1999 .ico 16×16 Favourites list 2000 का दशक .ico / .png 16×16, 32×32 Address bar, tabs 2007+ .png 57×57 – 180×180 iOS home screen 2010 का दशक .png 192×192, 512×512 Android, PWA अभी .svg Scalable सभी modern browsers SVG favicons आज सबसे अच्छा विकल्प हैं — एक फ़ाइल, असीमित रूप से scalable, बिना किसी pixel-hunting के retina screens पर काम करती है [2]। लेकिन root में .ico कहीं नहीं जा रहा। Browsers इसे ढूंढते रहते हैं।\nएक-फ़ाइल Convention जो अपने कारण से आगे निकल गई favicon.ico convention — web root में एक फ़ाइल डालें और browsers इसे अपने आप खोज लेते हैं — कभी औपचारिक रूप से standardised नहीं हुई। यह बस वही था जो IE5 ने किया, और बाकी सभी ने इसे copy किया [3]। आज भी, बड़ी संख्या में browsers किसी भी पेज पर जाने पर चुपचाप GET /favicon.ico request करते हैं, भले ही HTML में कोई \u0026lt;link rel=\u0026quot;icon\u0026quot;\u0026gt; declare न हो।\nयह 1999 की एक implementation detail है जिसे दुनिया का हर web server 2026 में भी handle करता है। काफी उल्लेखनीय है।\nसमाप्त\nस्रोत How We Got the Favicon - The History of the Web Favicon - Wikipedia A brief history of favicon - RealFaviconGenerator Inventing Favicon.ico - Take the First Favicon - Web Design Museum A Quick History of Favicon - Medium How to Add a Favicon to your Site - W3C ","permalink":"https://cloudmato.com/hi/posts/history-of-favicon-why-called-favicon/","title":"Favicon का इतिहास: इसे Favicon क्यों कहते हैं?"},{"content":"TypeScript अगस्त 2025 में GitHub पर सबसे ज्यादा उपयोग की जाने वाली भाषा बन गई — एक दशक से अधिक समय में पहली बार Python और JavaScript दोनों को पीछे छोड़ते हुए [4]। 78% पेशेवर डेवलपर्स अब TypeScript लिखते हैं [5]। और फिर भी, लगभग किसी भी पुराने कोडबेस, स्टार्टअप MVP, या त्वरित यूटिलिटी स्क्रिप्ट को खोलें और आपको अभी भी सादे .js फाइलें मिलेंगी। यह आलस्य नहीं है। इसके पीछे वास्तविक, संरचनात्मक कारण हैं।\nTypeScript वास्तव में क्या है? TypeScript, JavaScript है जिसमें types जोड़े गए हैं। Microsoft ने इसे एक असली समस्या को हल करने के लिए बनाया — बड़े JavaScript कोडबेस बहुत जल्दी अप्रबंधनीय हो जाते हैं। जब किसी कोडबेस में हजारों लाइनें और दर्जनों योगदानकर्ता हों, तो केवल call site पढ़कर यह नहीं जाना जा सकता कि कोई function क्या उम्मीद करता है [1]।\nमूल विचार है static typing। JavaScript में, आपको पता चलता है कि आपने number की जगह string पास किया — runtime पर, जब bug पहले से production में होता है। TypeScript इसे compile time पर पकड़ लेता है, कुछ भी चलने से पहले [2]।\n// TypeScript function add(a: number, b: number): number { return a + b; } add(5, \u0026#34;10\u0026#34;); // ❌ Error: Argument of type \u0026#39;string\u0026#39; is not assignable to parameter of type \u0026#39;number\u0026#39; // JavaScript function add(a, b) { return a + b; } add(5, \u0026#34;10\u0026#34;); // ✅ कोई error नहीं। \u0026#34;510\u0026#34; लौटाता है। debugging में शुभकामनाएं। दो code blocks में पूरी बात।\nएक महत्वपूर्ण बात: TypeScript एक अलग runtime नहीं है। Browser कभी .ts फाइल नहीं देखता। TypeScript सादे JavaScript में compile होता है। Runtime पर, यह सब JS ही होता है [1]।\nTypeScript वास्तव में क्या सही करता है उपयोगकर्ताओं तक पहुंचने से पहले errors यह सबसे बड़ी बात है। type mismatch, कोई missing property, गलत arguments के साथ call किया गया function — ये सभी build step के दौरान पकड़े जाते हैं, रात 2 बजे production error log में नहीं [2]।\nIDE की शक्तियां typed codebase में Autocomplete वास्तव में उपयोगी है। Definition पर jump करना काम करता है। किसी function का नाम बदलने से पूरी जगह orphan references नहीं बचते। JavaScript के साथ, आपका editor ज्यादातर अनुमान लगा रहा होता है [9]।\nस्व-दस्तावेज़ीकरण कोड interface User { id: number; name: string; email: string; isAdmin: boolean; } function getUser(id: number): Promise\u0026lt;User\u0026gt; { ... } आपको यह explain करने वाले comment की जरूरत नहीं कि यह function क्या करता है या क्या लौटाता है। Types बता देते हैं। 5+ डेवलपर्स की टीम में, यह बहुत मूल्यवान है [2]।\nआंकड़े इसका समर्थन करते हैं 2025 में TypeScript adoption ने active npm packages के 75% को पार किया [8] शीर्ष 1000 npm packages में से 85% अब TypeScript type definitions के साथ आती हैं [5] Developer satisfaction 84.1% पर है — किसी भी सर्वेक्षण की गई भाषा में सबसे अधिक [3] 2025 के एक academic study में पाया गया कि LLM-generated compilation errors में से 94% type-check failures थीं — यानी AI coding assistants TypeScript के साथ बेहतर output देते हैं [5] अंतिम बात दिलचस्प है। जैसे-जैसे AI अधिक code लिखता है, typed languages safety net के रूप में और भी मूल्यवान हो जाती हैं।\nतो फिर इतने सारे Apps अभी भी JavaScript क्यों उपयोग करते हैं? यह ईमानदार हिस्सा है। पाँच असली कारण हैं — बहाने नहीं।\n1. वेब का अधिकांश हिस्सा TypeScript के महत्वपूर्ण होने से पहले लिखा गया था TypeScript 2012 में जारी किया गया था। इसे गंभीर traction हासिल करने में वर्षों लगे। TypeScript के default बनने से पहले लाखों production apps JavaScript में बनाई गई थीं। एक काम करने वाले codebase को फिर से लिखना महंगा और जोखिम भरा है। Companies तब तक ऐसा नहीं करतीं जब तक कोई मजबूत business case न हो। इसलिए वे codebases JavaScript में रहते हैं — और JavaScript में ही maintain होते रहते हैं [10]।\n2. Build step एक वास्तविक लागत है JavaScript सीधे browser में चलती है। TypeScript नहीं। आपको एक compiler (tsc, या esbuild, या swc, या babel, या कुछ और), एक tsconfig.json, एक build pipeline, और कोई ऐसा व्यक्ति चाहिए जो समझे कि build क्यों टूटा [6]।\nएक quick internal tool या weekend project बनाने वाली team के लिए — यह overhead बेकार लगता है। और उस scale पर अक्सर होता भी है [7]।\n3. TypeScript के types वैकल्पिक और अपूर्ण हैं यहाँ कुछ ऐसा है जिसके बारे में लोग पर्याप्त बात नहीं करते: TypeScript का type system runtime safety की गारंटी नहीं देता। आप किसी भी चीज़ को any में cast कर सकते हैं। आप @ts-ignore उपयोग कर सकते हैं। External API responses unknown होते हैं जब तक आप TypeScript को नहीं बताते कि वे क्या हैं — और अगर आप झूठ बोलते हैं, TypeScript मान लेता है।\nconst data = await fetch(\u0026#39;/api/user\u0026#39;).then(r =\u0026gt; r.json()) as User; // TypeScript आप पर भरोसा करता है। अगर API कुछ अलग लौटाती है, तो भी crash होगा। उन teams के लिए जो strict mode enforce नहीं करतीं, TypeScript projects अतिरिक्त शोर वाली JavaScript बन सकती हैं [2]।\n4. सभी libraries में TypeScript support बेहतरीन नहीं है DefinitelyTyped पर @types/* packages मदद करते हैं, लेकिन वे volunteers द्वारा maintain किए जाते हैं और library updates के पीछे रहते हैं। अगर आप कोई niche library उपयोग कर रहे हैं, तो आप असली code लिखने से ज्यादा समय missing या गलत type definitions से लड़ने में बिता सकते हैं [6]।\n5. छोटी scripts को इसकी जरूरत नहीं एक 50-line Node.js script जो CSV पढ़ती है और S3 पर upload करती है। एक browser snippet जो class toggle करता है। एक serverless function जो एक email भेजती है। TypeScript का मूल्य project size और team size के साथ बढ़ता है। एक निश्चित threshold से नीचे, यह सिर्फ शोर है [7]।\nरेखा कहाँ है परिदृश्य JS या TS? Personal script / एकबारगी utility JavaScript अकेले का MVP, proof of concept JavaScript (या TS अगर पहले से setup हो) Team project, 3+ डेवलपर्स TypeScript लंबे समय का production app TypeScript Public npm library TypeScript Framework internals (जैसे Svelte compiler) कभी-कभी JSDoc-annotated JS [10] Svelte एक दिलचस्प मामला है। Svelte टीम ने वास्तव में 2023 में अपने compiler के source को TypeScript से JSDoc-annotated JavaScript में convert किया — इसलिए नहीं कि TypeScript बुरा है, बल्कि इसलिए कि इसने उनके development loop से build step को हटा दिया जबकि JSDoc के माध्यम से type hints बनाए रखे। Svelte अभी भी इसके साथ बनाए गए applications के लिए TypeScript को पूरी तरह support करता है [10]।\nTypeScript जीत रहा है — बस धीरे-धीरे migration काल्पनिक नहीं है। यह हो रहा है। 40% डेवलपर्स अब exclusively TypeScript में लिखते हैं, 2022 में 28% से बढ़कर [3]। Major frameworks by default TypeScript-first ship करते हैं — Next.js, Nuxt, SvelteKit, Angular [8]। इस बिंदु पर आप essentially TypeScript के बिना Angular नहीं लिख सकते।\nAI coding की लहर इसे तेज कर रही है। जब आपका AI assistant code generate करता है, तो आप चाहते हैं कि type system ship करने से पहले गलतियाँ पकड़े [5]।\nJavaScript अभी भी लंबे समय तक रहेगी — मौजूदा वेब खुद को rewrite नहीं करता। लेकिन किसी भी वास्तविक scale के नए projects के लिए, default बदल गया है। अब आपको TypeScript उपयोग न करने के लिए एक विशिष्ट कारण की जरूरत होगी, न कि इसे उपयोग करने के लिए।\nसमाप्त\nस्रोत TypeScript और JavaScript के बीच अंतर — GeeksforGeeks TypeScript बनाम JavaScript: अंतर और use cases — LogRocket Blog State of JavaScript 2025: TypeScript का वर्चस्व मजबूत — InfoQ TypeScript GitHub पर शीर्ष पर पहुँचा — InfoWorld TypeScript बनाम JavaScript: 73% Devs ने Switch किया [2026] — tech-insider.org TypeScript के नुकसान समझाए गए — FatCat Remote छोटे projects के लिए TypeScript उपयोग क्यों बंद करें? — DEV Community 2026 में TypeScript Tooling की स्थिति — PkgPulse TypeScript बनाम JavaScript — Strapi Blog बड़े projects TypeScript छोड़ रहे हैं… क्यों? — YouTube ","permalink":"https://cloudmato.com/hi/posts/typescript-vs-javascript-why-js-still-wont-die/","title":"TypeScript बेहतरीन है। तो फिर JavaScript अभी भी हर जगह क्यों है?"},{"content":"फ्रंटएंड डेवलपर और AI इंजीनियर के बीच की रेखा तेज़ी से धुंधली हो रही है। 2026 में, सबसे ज़्यादा माँग में रहने वाले वेब डेवलपर केवल सुंदर UI नहीं बना रहे—वे उन UI को सीधे बड़े भाषा मॉडल, वेक्टर डेटाबेस, और स्वायत्त एजेंट से जोड़ रहे हैं। अगर आप पहले से React, TypeScript, या Next.js जानते हैं, तो आप उस भविष्य के बहुत करीब हैं—शायद आप सोचते हैं उससे भी ज़्यादा।\nफ्रंटएंड डेवलपर्स को शुरू से ही बढ़त क्यों है आधुनिक AI एप्लिकेशन स्टैक TypeScript, React, और HTTP APIs पर चलता है—वही टूल्स जो आप पहले से हर दिन उपयोग करते हैं [1]। Next.js जैसे फ्रेमवर्क AI-संचालित UI बिल्डर्स का डिफ़ॉल्ट आउटपुट बन गए हैं, और Vercel AI SDK पहले से ही React इकोसिस्टम में एक प्रथम श्रेणी नागरिक है [2]। डेटा वैज्ञानिकों के विपरीत जिन्हें पहले डिप्लॉयमेंट और UI सीखना पड़ता है, आप पहले से ही प्रोडक्ट शिप करना जानते हैं। आपकी चुनौती यह नहीं है कि कैसे बनाएं—बल्कि यह है कि किन नए प्रिमिटिव्स से बनाएं।\nपहले दिन से आप जो मुख्य फायदे लाते हैं:\nकंपोनेंट थिंकिंग सीधे एजेंटिक टूल डिज़ाइन और मॉड्यूलर AI वर्कफ्लो पर लागू होती है API उपभोग (REST, GraphQL) स्वाभाविक रूप से LLM API कॉल और स्ट्रीमिंग रिस्पॉन्स में ट्रांसफर होता है स्टेट मैनेजमेंट कौशल सीधे मल्टी-टर्न कन्वर्सेशन मेमोरी पर लागू होते हैं TypeScript प्रोडक्शन AI एप्लिकेशन लेयर्स में प्रमुख भाषा है [3] आपका 6-चरणीय AI रोडमैप फ्रंटएंड डेवलपर से AI-सक्षम इंजीनियर तक की यात्रा सीखने की गति के आधार पर लगभग 6–12 महीने लेती है [4]। महत्वपूर्ण सिद्धांत: हर चरण में कुछ वास्तविक बनाएं। बिना शिप किए ट्यूटोरियल देखना AI सीखने में सबसे बड़ी समय की बर्बादी है [4]।\nचरण 1 — AI-संचालित डेव टूल्स अपनाएं (महीना 1) AI कोड की एक भी लाइन लिखने से पहले, हर दिन AI का उपयोग शुरू करें। यह इस बात के लिए सहज ज्ञान बनाता है कि मॉडल क्या कर सकते हैं और क्या नहीं—एक ऐसा सहज ज्ञान जो हर बाद के चरण में काम आता है [5]।\nअभी अपनाने के लिए टूल्स:\nGitHub Copilot – HTML, CSS, JavaScript, और React, Vue, Angular सहित सभी प्रमुख फ्रेमवर्क के लिए इनलाइन ऑटोकम्पलीट [5] Cursor – आपके IDE के अंदर संवादात्मक कोड एडिटिंग Vercel v0 – सादे टेक्स्ट विवरण से प्रोडक्शन-रेडी React + Tailwind कंपोनेंट उत्पन्न करें [5] Codeium – ऑटोकम्पलीट और कोड सुझावों के लिए सबसे मजबूत मुफ्त विकल्प [5] महत्वपूर्ण सावधानी: अपने पहले महीने में, AI सुझाव स्वीकार करने से पहले कंपोनेंट मैन्युअली लिखें। AI को बहुत जल्दी बड़े कोड ब्लॉक जेनरेट करने देना पैटर्न पहचान को रोकता है जो आपको बाद में एक बेहतर इंजीनियर और बेहतर प्रॉम्प्ट लेखक बनाता है [1]।\nचरण 2 — अपने ऐप्स में LLM इंटीग्रेट करें (महीने 1–3) यहीं पर आपके मौजूदा कौशल कंपाउंड होने लगते हैं। React या Next.js से सीधे LLM API कॉल करना सीखें।\nVercel AI SDK से शुरू करें। यह एक ओपन-सोर्स TypeScript टूलकिट है जो सभी प्रमुख प्रदाताओं—OpenAI, Anthropic, Google Gemini, और Mistral—में एक एकीकृत इंटरफ़ेस प्रदान करता है—इसलिए आप केवल दो लाइन कोड बदलकर मॉडल स्विच कर सकते हैं [2]। यह स्ट्रीमिंग, टूल कॉलिंग, और जेनरेटिव UI को आउट ऑफ द बॉक्स हैंडल करता है, जो इसे AI विकास में सबसे फ्रंटएंड-नेटिव प्रवेश बिंदु बनाता है [2]।\nप्रदाता पैकेज विशेषताएं Vercel AI SDK ai (npm) एकीकृत API, Next.js-नेटिव, स्ट्रीमिंग UI OpenAI openai (npm) सामान्य-उद्देश्य चैट और फंक्शन कॉलिंग Anthropic @anthropic-ai/sdk लंबा संदर्भ, जटिल तर्क Google Gemini @google/generative-ai मल्टीमोडल (टेक्स्ट + इमेज + ऑडियो) इस चरण में पक्के करने के मुख्य कौशल:\nUI में लाइव स्ट्रीमिंग रिस्पॉन्स स्कीमा वैलिडेशन के साथ संरचित JSON आउटपुट मैसेज हिस्ट्री के साथ मल्टी-टर्न कन्वर्सेशन बेसिक टूल/फंक्शन कॉलिंग Codecademy का AI-असिस्टेड फ्रंट-एंड डेवलपमेंट पाथ आपको AI कोडिंग एजेंट का उपयोग करके React ऐप्स बनाना सिखाता है और यह भी समझाता है कि ये टूल्स अंदर से कैसे काम करते हैं—इस चरण के लिए एक उपयोगी साथी [6]।\nचरण 3 — प्रॉम्प्ट इंजीनियरिंग में महारत हासिल करें (महीने 2–4) प्रॉम्प्ट इंजीनियरिंग अब AI विशेषज्ञता की छत नहीं है—यह ज़मीन है [7]। हर AI इंजीनियर को इसकी ज़रूरत है, और इसके बिना, हर आगे का चरण कठिन हो जाता है।\nआत्मसात करने की पाँच मुख्य तकनीकें:\nसिस्टम प्रॉम्प्ट – किसी भी यूज़र इनपुट से पहले मॉडल की पर्सोना, सीमाएं, और आउटपुट फॉर्मेट परिभाषित करें फ्यू-शॉट उदाहरण – व्यवहार को विश्वसनीय रूप से मार्गदर्शन करने के लिए 2–5 उदाहरण इनपुट/आउटपुट जोड़े दिखाएं चेन-ऑफ-थॉट (CoT) – मॉडल को अंतिम उत्तर देने से पहले चरण-दर-चरण तर्क करने का निर्देश दें संरचित आउटपुट – हर बार पार्स करने योग्य रिस्पॉन्स की गारंटी के लिए JSON स्कीमा या Zod वैलिडेशन का उपयोग करें तापमान नियंत्रण – उपयोग के मामले के आधार पर रचनात्मकता बनाम निश्चयवाद को ट्यून करें (क्रिएटिव कॉपी बनाम कोड जेनरेशन) इन तकनीकों का अभ्यास करते हुए एक छोटा वास्तविक प्रोजेक्ट बनाएं—एक कंटेंट जेनरेटर, एक स्मार्ट फॉर्म, एक कोड रिव्यूअर। सीखना तभी टिकता है जब आप साथ-साथ बनाते हैं [4]।\nचरण 4 — RAG सिस्टम बनाएं (महीने 3–6) रिट्रीवल-ऑगमेंटेड जेनरेशन (RAG) आपके AI ऐप को मॉडल के स्थिर ट्रेनिंग डेटा के बजाय आपके अपने डेटा—प्रोडक्ट डॉक्स, नॉलेज बेस, सपोर्ट टिकट—पर आधारित प्रश्नों का उत्तर देने देता है। यह 2026 के जॉब मार्केट में लगातार सबसे अधिक मूल्यवान कौशलों में से एक है [7]।\nफ्रंटएंड-फ्रेंडली वेक्टर डेटाबेस विकल्प:\nSupabase + pgvector – PostgreSQL-आधारित वेक्टर स्टोर; परिचित यदि आप पहले से Supabase उपयोग करते हैं Pinecone – पूरी तरह प्रबंधित, साफ REST API, न्यूनतम इन्फ्रास्ट्रक्चर Upstash Vector – सर्वरलेस और एज-कम्पैटिबल, Vercel डिप्लॉयमेंट के साथ अच्छी तरह जोड़ी बनाता है 2026 में कौशल बदलाव बेसिक RAG (एक बार खोजें, सारांश बनाएं) से एजेंटिक RAG (बार-बार खोजें, स्रोत सत्यापित करें, निष्कर्ष संयोजित करें) की ओर है [7]। अभी का बेसिक RAG चरण 5 की नींव है।\nचरण 5 — AI एजेंट और MCP प्रोटोकॉल (महीने 5–9) AI एजेंट ऐसे एप्लिकेशन हैं जहाँ मॉडल तय करता है कि कौन से टूल्स को कब और किस क्रम में कॉल करना है, न कि एक निश्चित निष्पादन पथ का पालन करना। यह 2026 में AI इंजीनियरिंग का सबसे तेज़ी से बढ़ने वाला क्षेत्र है [8]।\nबनाने के लिए मुख्य अवधारणाएं:\nटूल कॉलिंग – मॉडल को टाइप्ड फंक्शन (खोज, कैलकुलेटर, डेटाबेस क्वेरी, API कॉल) तक पहुंच दें एजेंटिक लूप – मॉडल एक टूल कॉल करता है, परिणाम देखता है, फिर अगला कदम तय करता है मल्टी-एजेंट समन्वय – एक साझा कार्य पर सहयोग करने वाले विशेष एजेंट MCP प्रोटोकॉल अब AI एजेंट को टूल्स और डेटा स्रोतों से जोड़ने का सार्वभौमिक मानक है। 2025 के अंत में Linux Foundation को दान किया गया, इसे महीनों के भीतर OpenAI, Google, Microsoft, और Amazon द्वारा तेज़ी से अपनाया गया [7]। फ्रंटएंड डेवलपर्स के लिए, MCP का मतलब है कि आपका Next.js ऐप एक मानकीकृत प्रोटोकॉल का उपयोग करके किसी भी LLM को संरचित टूल इंटरफ़ेस प्रदान कर सकता है—प्रति प्रदाता अब और कस्टम इंटीग्रेशन नहीं।\nFrontend Masters का Coding with AI पाथ पूर्ण एजेंटिक लूप, मॉडल ट्रेड-ऑफ, कौशल, हुक्स, और एजेंट टीम बनाने को कवर करता है—आज हायरिंग मैनेजर जो देखते हैं उसके साथ बिल्कुल संरेखित [9]।\nचरण 6 (वैकल्पिक) — Python और ML की नींव (महीने 6–12) यदि आपका लक्ष्य AI इंजीनियरिंग में गहराई से जाना है—मॉडल फाइन-ट्यून करना, बड़े पैमाने पर एम्बेडिंग के साथ काम करना, या एक समर्पित ML टीम में शामिल होना—तो Python अनिवार्य हो जाती है। यह AI इंजीनियरिंग और डेटा साइंस भूमिकाओं में लगभग 90% काम को कवर करती है [4]।\nPython समय कहाँ लगाएं:\nडेटा रैंगलिंग के लिए numpy और pandas ओपन-सोर्स मॉडल एक्सेस के लिए transformers (Hugging Face) प्रोडक्शन RAG और एजेंट पाइपलाइन ऑर्केस्ट्रेशन के लिए LangChain या LlamaIndex यह चरण उन फ्रंटएंड डेवलपर्स के लिए वैकल्पिक है जो एप्लिकेशन लेयर में रहना चाहते हैं। इसे छोड़ना आपको सीमित नहीं करता; 2026 में अधिकांश उच्च-मूल्य AI प्रोडक्ट कार्य TypeScript में है।\n2026 में शीर्ष लर्निंग प्लेटफॉर्म प्लेटफॉर्म कोर्स / पाथ किसके लिए सबसे अच्छा Frontend Masters Coding with AI एजेंट, Claude Code, LLM वर्कफ्लो Codecademy AI-Assisted Front-End Dev React + AI टूल्स शुरू से [6] DataCamp AI Learning Roadmap 2026 व्यापक AI फंडामेंटल और Python [4] Coursera GenAI for Front-End Developers वेब डेवलपर्स के लिए GenAI अवधारणाएं Dataquest AI Engineer Roadmap फुल स्टैक → AI इंजीनियर ट्रांजिशन [3] Capgemini Academy GenAI for Front-End Devs एथिक्स, Copilot, एंटरप्राइज़ AI उपयोग 2026 में नौकरी दिलाने वाले कौशल 2026 में AI-सक्षम फ्रंटएंड डेवलपर्स की स्क्रीनिंग करने वाले भर्तीकर्ता एक बहुत विशिष्ट चेकलिस्ट से काम कर रहे हैं [7] [8]:\nLLM API इंटीग्रेशन कम से कम एक प्रमुख प्रदाता (OpenAI, Anthropic, या Gemini) के साथ Vercel AI SDK या समकक्ष एकीकृत-इंटरफ़ेस टूलिंग प्रॉम्प्ट इंजीनियरिंग संरचित आउटपुट और फ्यू-शॉट तकनीकों के साथ RAG सिस्टम डिज़ाइन चंकिंग स्ट्रैटेजी और रि-रैंकिंग सहित एजेंट ऑर्केस्ट्रेशन टूल उपयोग और मल्टी-स्टेप एजेंटिक लूप के साथ MCP प्रोटोकॉल जागरूकता और व्यावहारिक कार्यान्वयन एवल साक्षरता – गुणवत्ता मापने के लिए मॉडल मूल्यांकन डिज़ाइन और चलाना सुरक्षा और गार्डरेल – एजेंट को स्कोप करना ताकि वे अनधिकृत कार्य न कर सकें आज बाज़ार में सबसे बड़ी कौशल कमी मॉडल ज्ञान या गणित नहीं है—यह एजेंटिक इंजीनियरिंग है: ऐसे AI एजेंट डिज़ाइन और संचालित करना जो प्रोडक्शन में विश्वसनीय रूप से टिके रहें [8]। वह एकल क्षमता ही उन डेवलपर्स को अलग करती है जिन्होंने ट्यूटोरियल देखे हैं उनसे जिन्होंने वास्तविक AI प्रोडक्ट शिप किए हैं।\nउन टूल्स से शुरू करें जो आप हर दिन उपयोग करते हैं, पहले महीने में कुछ छोटा शिप करें, और हर चरण को पिछले पर कंपाउंड होने दें। 2026 में React डेवलपर से प्रोडक्शन-रेडी AI इंजीनियर तक का रास्ता कभी इतना छोटा नहीं था—या इतना मूल्यवान।\nस्रोत Learn Frontend Development in 2026 | ASSIST Software AI SDK by Vercel – Introduction AI Engineer Roadmap 2026: Skills for Full-Stack Developers | Imaginary Cloud A Realistic Roadmap to Start an AI Career in 2026 | Towards Data Science 7 Best AI Tools for Frontend Development in 2026 | eesel AI AI-Assisted Front-End Development | Codecademy AI Developer Hiring 2026: Skills That Actually Matter | Digital Applied Agentic AI Skills Required for Engineers \u0026amp; Developers 2026 | NovelVista Coding with AI Learning Path | Frontend Masters ","permalink":"https://cloudmato.com/hi/posts/ai-learning-path-frontend-developers-2026/","title":"2026 में फ्रंटएंड डेवलपर्स के लिए AI सीखने का रोडमैप"},{"content":"JavaScript में पहले कोड को फ़ाइलों में विभाजित करने का कोई अंतर्निहित तरीका नहीं था — इस सीमा ने प्रतिस्पर्धी मॉड्यूल फॉर्मेट के एक पूरे इकोसिस्टम को जन्म दिया। आज, डेवलपर्स require(), import, .mjs, .cjs, AMD और UMD का सामना करते हैं, अक्सर एक ही प्रोजेक्ट में। यह गाइड हर मॉड्यूल सिस्टम को स्पष्ट करता है, बताता है कि प्रत्येक का उपयोग कब करना है, और आगे का स्पष्ट रास्ता दिखाता है।\nJavaScript को मॉड्यूल सिस्टम की आवश्यकता क्यों थी वेब के शुरुआती दिनों में, JavaScript एक स्क्रिप्टिंग भाषा थी जो सरल पेज इंटरैक्शन के लिए थी। जैसे-जैसे एप्लिकेशन बड़े होते गए, डेवलपर्स सब कुछ ग्लोबल वेरिएबल्स में भरने लगे — जिससे नामकरण टकराव और अप्रबंधनीय \u0026ldquo;स्पेगेटी\u0026rdquo; कोड पैदा हुआ [1]। समुदाय ने भाषा के बाहर मॉड्यूल पैटर्न का आविष्कार करके जवाब दिया: पहले प्राइवेट स्कोप बनाने के लिए Immediately Invoked Function Expressions (IIFEs), फिर AMD और CommonJS जैसे औपचारिक मॉड्यूल स्पेसिफिकेशन। केवल 2015 में ही JavaScript को ES6 स्पेसिफिकेशन के माध्यम से एक नेटिव मॉड्यूल सिस्टम मिला [6]।\nCommonJS (CJS) — Node.js का वर्कहॉर्स CommonJS को 2009 में सर्वर-साइड JavaScript के लिए मॉड्यूल सिस्टम के रूप में पेश किया गया था, और यह आज भी Node.js में डिफ़ॉल्ट मॉड्यूल फॉर्मेट बना हुआ है [3]।\nसिंटैक्स // Exporting const greet = (name) =\u0026gt; `Hello, ${name}!`; module.exports = { greet }; // Importing const { greet } = require(\u0026#39;./greet\u0026#39;); console.log(greet(\u0026#39;World\u0026#39;)); मुख्य विशेषताएं सिंक्रोनस लोडिंग — require() तब तक एक्जीक्यूशन को ब्लॉक करता है जब तक फ़ाइल पूरी तरह लोड नहीं हो जाती, जो सर्वर पर ठीक है लेकिन ब्राउज़र में समस्याजनक है [2]। स्वभाव से डायनामिक — आप रनटाइम पर if ब्लॉक, लूप्स, या फंक्शन के अंदर require() कॉल कर सकते हैं [1]। module.exports / exports — एक्सपोर्ट किया गया मान एक सामान्य JavaScript ऑब्जेक्ट है, जो रनटाइम पर असाइन होता है। कोई tree-shaking नहीं — क्योंकि एक्सपोर्ट रनटाइम पर निर्धारित होते हैं, बंडलर्स स्थैतिक रूप से यह निर्धारित नहीं कर सकते कि कौन से हिस्से अप्रयुक्त हैं [4]। CommonJS अभी भी सही विकल्प है जब मौजूदा Node.js कोडबेस को मेंटेन करना हो या उन पैकेजों के साथ काम करना हो जिन्होंने अभी ESM बिल्ड शिप नहीं किया है [2]।\nAMD — असिंक्रोनस मॉड्यूल डेफिनिशन AMD लगभग 2011 के आसपास विशेष रूप से ब्राउज़र परफॉर्मेंस को हल करने के लिए उभरा: CommonJS के विपरीत, यह डिपेंडेंसी को असिंक्रोनस रूप से लोड करता है ताकि पेज फ्रीज न हो [5]।\n// AMD define + require via RequireJS define([\u0026#39;dependency\u0026#39;], function(dep) { return { hello: () =\u0026gt; dep.greet() }; }); require([\u0026#39;myModule\u0026#39;], function(mod) { mod.hello(); }); AMD को RequireJS लोडर द्वारा लोकप्रिय बनाया गया था। हालांकि, ES Modules अब हर ब्राउज़र में नेटिव async लोडिंग प्रदान करते हैं, इसलिए नए प्रोजेक्टों के लिए AMD को काफी हद तक अप्रचलित माना जाता है [6]।\nUMD — यूनिवर्सल मॉड्यूल डेफिनिशन 2011 में, UMD एक कम्पैटिबिलिटी शिम के रूप में आया जो CommonJS (Node.js), AMD (ब्राउज़र), और सामान्य ग्लोबल स्क्रिप्ट के बीच की खाई को पाटने के लिए था [5]।\n(function(root, factory) { if (typeof define === \u0026#39;function\u0026#39; \u0026amp;\u0026amp; define.amd) { define([], factory); // AMD } else if (typeof module === \u0026#39;object\u0026#39; \u0026amp;\u0026amp; module.exports) { module.exports = factory(); // CommonJS } else { root.myLib = factory(); // Global variable } }(this, function() { return { version: \u0026#39;1.0\u0026#39; }; })); Lodash, Underscore.js, Backbone.js और Moment.js जैसी प्रमुख लाइब्रेरीज़ ने UMD को सार्वभौमिक रूप से उपभोग्य बनाने के लिए अपनाया [6]। आज, UMD व्यावहारिक रूप से अप्रचलित है क्योंकि ES Modules हर जगह नेटिव रूप से समर्थित हैं — लेकिन आप अभी भी npm पर पुराने पैकेजों में इसे देखेंगे।\nES Modules (ESM) — आधुनिक मानक ES2015 (ES6) में पेश किया गया और अब सभी आधुनिक ब्राउज़रों और Node.js ≥ 12 में नेटिव रूप से समर्थित, ESM JavaScript के लिए आधिकारिक, मानकीकृत मॉड्यूल सिस्टम है [4]।\nसिंटैक्स // Named exports export const add = (a, b) =\u0026gt; a + b; export const PI = 3.14159; // Default export export default class Calculator { /* ... */ } // Importing import Calculator, { add, PI } from \u0026#39;./math.js\u0026#39;; मुख्य विशेषताएं स्टैटिक एनालिसिस — import और export स्टेटमेंट टॉप लेवल पर होने चाहिए, जिससे Webpack और Rollup जैसे टूल tree-shaking (डेड कोड हटाना) कर सकते हैं [3]। असिंक्रोनस लोडिंग — ब्राउज़र या Node.js बिना ब्लॉक किए मॉड्यूल को फेच और पार्स करता है [1]। लाइव बाइंडिंग — इंपोर्ट किए गए मान लाइव रेफरेंस हैं, कॉपी नहीं, इसलिए एक्सपोर्टिंग मॉड्यूल में बदलाव इंपोर्टर में दिखते हैं [8]। टॉप-लेवल await — ESM फ़ाइलें async फंक्शन के बाहर await का उपयोग कर सकती हैं, एक ऐसी सुविधा जो CJS में नहीं है [2]। स्पष्ट फ़ाइल एक्सटेंशन — रिलेटिव इंपोर्ट में एक्सटेंशन शामिल होना चाहिए (जैसे, ./utils.js) [4]। डायनामिक import() — मांग पर लेज़ी लोडिंग import() ऑपरेटर (डायनामिक import) एक फंक्शन-जैसा एक्सप्रेशन है जो ES मॉड्यूल को असिंक्रोनस रूप से लोड करता है और एक Promise लौटाता है [7]। यह ESM और CJS दोनों संदर्भों में काम करता है।\n// Load a module only when the user clicks a button button.addEventListener(\u0026#39;click\u0026#39;, async () =\u0026gt; { const { Chart } = await import(\u0026#39;./chart.js\u0026#39;); new Chart(data).render(); }); सामान्य उपयोग के मामले कोड स्प्लिटिंग — केवल वही JavaScript शिप करें जो उपयोगकर्ता को अभी चाहिए कंडीशनल लोडिंग — केवल पुराने ब्राउज़रों में पॉलीफिल लोड करें रनटाइम पाथ कंस्ट्रक्शन — वेरिएबल से मॉड्यूल पाथ बनाएं CJS ↔ ESM ब्रिज — CommonJS कोड await import() का उपयोग करके ESM पैकेज इंपोर्ट कर सकता है [8] डायनामिक इंपोर्ट सभी आधुनिक ब्राउज़रों और Node.js में पूरी तरह समर्थित हैं [7]।\nफ़ाइल एक्सटेंशन: .js, .mjs और .cjs आप जो एक्सटेंशन चुनते हैं वह Node.js (और आपके बंडलर) को बताता है कौन सा मॉड्यूल सिस्टम उपयोग करना है [4][9]।\nएक्सटेंशन मॉड्यूल सिस्टम कब उपयोग करें .js package.json के \u0026quot;type\u0026quot; फ़ील्ड द्वारा निर्धारित डिफ़ॉल्ट; प्रोजेक्ट-वाइड सेटिंग का पालन करता है .mjs हमेशा ES Module package.json की परवाह किए बिना एक फ़ाइल को ESM बनाएं .cjs हमेशा CommonJS ESM-फर्स्ट प्रोजेक्ट में एक फ़ाइल को CJS बनाएं package.json का \u0026quot;type\u0026quot; फ़ील्ड // All .js files treated as ES Modules { \u0026#34;type\u0026#34;: \u0026#34;module\u0026#34; } // All .js files treated as CommonJS (default) { \u0026#34;type\u0026#34;: \u0026#34;commonjs\u0026#34; } package.json में \u0026quot;type\u0026quot;: \u0026quot;module\u0026quot; सेट करने से उस पैकेज की हर .js फ़ाइल ES मॉड्यूल बन जाती है [4]। आप \u0026quot;type\u0026quot; सेटिंग की परवाह किए बिना .mjs (ESM फोर्स) या .cjs (CJS फोर्स) एक्सटेंशन का उपयोग करके प्रति-फ़ाइल ओवरराइड कर सकते हैं [9]।\nCJS बनाम ESM — पूर्ण तुलना फ़ीचर CommonJS (CJS) ES Modules (ESM) सिंटैक्स require() / module.exports import / export लोडिंग सिंक्रोनस असिंक्रोनस कहाँ चलता है Node.js (नेटिव रूप से) Browser + Node.js Tree-shaking ❌ संभव नहीं ✅ समर्थित डायनामिक इंपोर्ट require() कहीं भी import() एक्सप्रेशन टॉप-लेवल await ❌ ✅ लाइव बाइंडिंग ❌ (लोड टाइम पर कॉपी) ✅ फ़ाइल एक्सटेंशन .cjs या .js .mjs या .js स्टेटस लीगेसी (अभी भी व्यापक रूप से उपयोग) आधुनिक मानक इंटरऑपरेबिलिटी: CJS और ESM का मिश्रण Node.js दोनों सिस्टमों को महत्वपूर्ण नियमों के साथ सह-अस्तित्व में रहने देता है [8]:\n✅ ESM CommonJS पैकेज को import कर सकता है — Node.js module.exports को डिफ़ॉल्ट एक्सपोर्ट के रूप में रैप करता है। ❌ CJS ESM फ़ाइल को require() नहीं कर सकता — यह ERR_REQUIRE_ESM त्रुटि फेंकता है। ✅ CJS डायनामिक await import() का उपयोग करके ESM लोड कर सकता है एक वर्कअराउंड के रूप में [8]। 2026 में आपको कौन सा मॉड्यूल सिस्टम उपयोग करना चाहिए? नए प्रोजेक्ट → ES Modules (package.json में \u0026quot;type\u0026quot;: \u0026quot;module\u0026quot;) का उपयोग करें। ESM मानक है, tree-shaking सक्षम करता है, और ब्राउज़र और Node.js दोनों में काम करता है [1][2]। मौजूदा Node.js कोडबेस → CommonJS अभी भी व्यावहारिक और अच्छी तरह से समर्थित है; धीरे-धीरे माइग्रेट करें। लाइब्रेरी लेखक → अधिकतम कम्पैटिबिलिटी के लिए package.json के \u0026quot;exports\u0026quot; फ़ील्ड के माध्यम से दोहरे पैकेज (CJS और ESM दोनों बिल्ड) शिप करें [3]। लीगेसी ब्राउज़र समर्थन → एक बंडलर (Vite, Webpack, Rollup) का उपयोग करें जो ESM को लक्ष्य फॉर्मेट में परिवर्तित करता है; AMD/UMD अब आवश्यक नहीं हैं [6]। JavaScript मॉड्यूल परिदृश्य एकत्रित हो गया है: नए कोड के लिए ESM स्पष्ट विजेता है, लेकिन उन पुरानी नींवों पर बने विशाल npm इकोसिस्टम को नेविगेट करने के लिए CJS (और यहां तक कि AMD/UMD) को समझना आवश्यक है।\nस्रोत JavaScript में CommonJS बनाम ES Modules — Syncfusion Blogs CommonJS बनाम ES Modules — Better Stack Community Node.js में CommonJS बनाम ES Modules — LogRocket Blog ECMAScript Modules — Node.js आधिकारिक दस्तावेज़ीकरण JavaScript में CJS, AMD, UMD और ESM क्या हैं? — DEV Community मॉड्यूल भूलभुलैया नेविगेट करना: JavaScript मॉड्यूल सिस्टम का इतिहास — Codilime import() — MDN Web Docs Node.js में CommonJS और ES Modules की गहरी जानकारी — AppSignal Blog .mjs, .cjs, .mts और .cts एक्सटेंशन क्या हैं? — Total TypeScript MJS और CJS को समझना — RGB Studios ","permalink":"https://cloudmato.com/hi/posts/javascript-module-systems-require-import-mjs/","title":"JavaScript मॉड्यूल सिस्टम: require, import, .mjs और अधिक"},{"content":"हर दिन आपका फ़ोन न्यूज़ अलर्ट, चैट मैसेज और राइड अपडेट से गुलज़ार रहता है — और यह सब तब होता है जब इनसे जुड़े ऐप्स बंद होते हैं। लेकिन किसी रिमोट सर्वर से आया मैसेज मिलीसेकंड में आपकी लॉक स्क्रीन तक कैसे पहुंचता है? और नहीं, आपका फ़ोन बार-बार यह नहीं पूछता कि \u0026ldquo;कुछ नया है क्या?\u0026rdquo; — इसका जवाब इससे कहीं ज़्यादा दिलचस्प है।\nबड़ा सवाल: क्या फ़ोन नोटिफिकेशन के लिए पोल करता है? संक्षिप्त उत्तर है नहीं। आधुनिक मोबाइल ऑपरेटिंग सिस्टम नए संदेशों की जांच के लिए बार-बार किसी सर्वर को पोल (पुल) नहीं करते [8]। इसके बजाय, iOS और Android दोनों Apple या Google द्वारा संचालित एक केंद्रीकृत गेटवे से एकल, दीर्घकालिक परसिस्टेंट कनेक्शन बनाए रखते हैं। जब कोई नोटिफिकेशन तैयार होती है, तो गेटवे उसे उस खुले चैनल के माध्यम से आपके डिवाइस पर पुश करता है [8]। इस मूलभूत पुश मॉडल का अर्थ है:\nकिसी भी ऐप को बैकग्राउंड में अपना पोलिंग लूप चलाने की ज़रूरत नहीं नेटवर्क और बैटरी का उपयोग काफ़ी कम हो जाता है डिवाइस चाहे कुछ भी कर रहा हो, नोटिफिकेशन लगभग तुरंत पहुंचती हैं तीन-पक्षीय आर्किटेक्चर दोनों प्लेटफ़ॉर्म एक ही उच्च-स्तरीय तीन-पक्षीय मॉडल साझा करते हैं [9]:\nआपके ऐप का बैकएंड सर्वर — कोई इवेंट (नया मैसेज, ऑर्डर भेजा गया, आदि) का पता लगाता है और नोटिफिकेशन पेलोड तैयार करता है प्लेटफ़ॉर्म पुश गेटवे — iPhone के लिए Apple Push Notification service (APNs), Android के लिए Firebase Cloud Messaging (FCM) उपयोगकर्ता का डिवाइस — OS के माध्यम से नोटिफिकेशन प्राप्त करता है और उसे दिखाता है रजिस्ट्रेशन के समय, ऐप OS से एक विशिष्ट डिवाइस टोकन मांगता है — एक क्रिप्टोग्राफ़िकली हस्ताक्षरित पहचानकर्ता जो गेटवे को बताता है कि कौन सा डिवाइस (और उस डिवाइस पर कौन सा ऐप) किसी दी गई नोटिफिकेशन को प्राप्त करे [1][4]। ऐप फिर इस टोकन को अपने बैकएंड पर भेजता है, जो इसे बाद के उपयोग के लिए स्टोर करता है।\nApple का APNs कैसे काम करता है (iPhone) डिवाइस रजिस्ट्रेशन और टोकन जब कोई iOS ऐप registerForRemoteNotifications() कॉल करता है, तो OS Apple के APNs सर्वर से संपर्क करता है और एक डिवाइस-विशिष्ट पुश टोकन प्राप्त करता है [1]। यह टोकन डिवाइस की पहचान और ऐप आइडेंटिफायर को एन्कोड करता है और iOS द्वारा जब भी यह बदलता है (जैसे, रिस्टोर के बाद) तो रिफ्रेश किया जाता है। टोकन फिर डेवलपर के सर्वर पर भेजा जाता है, जो इसे भविष्य की नोटिफिकेशन के लिए उपयोग करता है।\nपरसिस्टेंट TLS कनेक्शन iPhone Apple के APNs सर्वर से एक एकल, हमेशा-चालू, एन्क्रिप्टेड TCP कनेक्शन बनाए रखता है [2][3]। मुख्य तकनीकी विवरण:\nप्राथमिक पोर्ट: TCP 5223 — एक समर्पित APNs पोर्ट [3] फॉलबैक पोर्ट: TCP 443 (HTTPS) — प्रतिबंधित Wi-Fi नेटवर्क पर उपयोग किया जाता है [3] एन्क्रिप्शन: TLS (Transport Layer Security) पूरी तरह से Keepalive पैकेट: डिवाइस नियमित रूप से हल्के हार्टबीट पैकेट भेजता है ताकि सर्वर निष्क्रिय कनेक्शन को बंद न करे [3] क्योंकि यह कनेक्शन OS स्तर पर बनाए रखा जाता है — न कि किसी व्यक्तिगत ऐप द्वारा — यह तब भी बना रहता है जब आपके फ़ोन पर हर ऐप सस्पेंड या बंद हो। डिवाइस के सभी ऐप इस एकल पाइप का लाभ साझा करते हैं।\nनोटिफिकेशन डिलीवर करना जब आपके ऐप के बैकएंड के पास कुछ भेजने के लिए होता है, तो वह APNs के साथ प्रमाणित होता है (JWT या सर्टिफिकेट का उपयोग करके) और नोटिफिकेशन शीर्षक, बॉडी, बैज काउंट और कोई भी कस्टम डेटा वाला JSON पेलोड POST करता है [1]। APNs फिर इस पेलोड को परसिस्टेंट कनेक्शन के माध्यम से टार्गेट डिवाइस पर रूट करता है। iOS इसे प्राप्त करता है, संबंधित ऐप को संक्षेप में जगाता है (यदि आवश्यक हो), और नोटिफिकेशन दिखाता है।\niOS इंटेलिजेंस: स्मार्ट नोटिफिकेशन रैंकिंग iOS 26 ने Apple Intelligence-संचालित प्राथमिकता रैंकिंग पेश की, जो स्वचालित रूप से प्रासंगिक नोटिफिकेशन (डिलीवरी आना, मीटिंग शुरू होना, तुरंत रिप्लाई की ज़रूरत) को बढ़ावा देती है और सामान्य वाली को नीचे रखती है — बिना किसी डेवलपर कार्रवाई के सबसे महत्वपूर्ण अलर्ट स्टैक के शीर्ष पर दिखाती है [7]।\nAndroid का FCM कैसे काम करता है डिवाइस रजिस्ट्रेशन इसी तरह, Android पर, जब कोई ऐप पहली बार FirebaseMessaging.getInstance().getToken() कॉल करता है, तो डिवाइस Google के FCM इन्फ्रास्ट्रक्चर के साथ रजिस्टर होता है और एक रजिस्ट्रेशन टोकन प्राप्त करता है [4]। यह टोकन ऐप के बैकएंड को भेजा जाता है और बाद की टार्गेटिंग के लिए स्टोर किया जाता है।\nएक साझा परसिस्टेंट कनेक्शन FCM का सबसे महत्वपूर्ण डिज़ाइन सिद्धांत डिवाइस पर Google Play Services प्रक्रिया द्वारा बनाए रखा एकल साझा परसिस्टेंट कनेक्शन है [5]। FCM का उपयोग करने वाला हर ऐप — जो वस्तुतः Android पर हर ऐप है — अपनी पुश नोटिफिकेशन इस एक कनेक्शन के माध्यम से रूट करता है। लाभ महत्वपूर्ण हैं:\nबैटरी बचत: प्रत्येक ऐप को अपना बैकग्राउंड सॉकेट बनाए रखने की ज़रूरत नहीं [5] डेवलपर्स के लिए सरलता: ऐप्स को कनेक्शन लाइफसाइकिल को बिल्कुल भी मैनेज नहीं करना पड़ता विश्वसनीयता: Google का इन्फ्रास्ट्रक्चर रीकनेक्ट, रिट्राई और डिलीवरी रसीदें संभालता है मैसेज प्राथमिकता और Doze मोड Android का Doze मोड बैटरी बचाने के लिए जब डिवाइस निष्क्रिय और अनप्लग्ड हो तो बैकग्राउंड गतिविधि को आक्रामक रूप से प्रतिबंधित करता है [6]। FCM इसे दो अलग-अलग प्राथमिकता स्तरों के साथ संभालता है [5][6]:\nप्राथमिकता Doze में व्यवहार सामान्य उपयोग का मामला सामान्य बैच किया गया और अगले Doze रखरखाव विंडो पर डिलीवर किया गया न्यूज़लेटर, सोशल फ़ीड अपडेट उच्च Doze को बाईपास करता है; सोए हुए डिवाइस को तुरंत जगा सकता है [6] इनकमिंग कॉल, चैट मैसेज, अलार्म डेवलपर FCM पेलोड में प्राथमिकता सेट करते हैं। उच्च-प्राथमिकता वाले मैसेज केवल उपयोगकर्ता-दृश्यमान, समय-संवेदनशील अलर्ट के लिए हैं — इस प्राथमिकता का दुरुपयोग करने पर Google डिवाइस को जगाने की ऐप की क्षमता को थ्रोटल कर सकता है [5]।\nAndroid 16: AI-संचालित नोटिफिकेशन ऑर्गनाइज़र 2025 के मध्य में रिलीज़ हुए Android 16 ने एक Notification Organizer पेश किया जो आने वाली नोटिफिकेशन को स्वचालित रूप से वर्गीकृत करने और उपयोगकर्ता के हस्तक्षेप के बिना कम-प्राथमिकता वाली नोटिफिकेशन (जैसे प्रमोशन) को म्यूट करने के लिए ऑन-डिवाइस AI का उपयोग करता है [7]। यह iOS पर Apple Intelligence के दृष्टिकोण को दर्शाता है और दोनों प्लेटफ़ॉर्म के स्मार्ट, कम भारी नोटिफिकेशन अनुभवों की ओर एक अभिसरण का प्रतिनिधित्व करता है।\niOS बनाम Android: तुलनात्मक विश्लेषण विशेषता iOS (APNs) Android (FCM) गेटवे सेवा Apple Push Notification service Firebase Cloud Messaging कनेक्शन प्रोटोकॉल TLS/TCP पर प्रोप्राइटरी बाइनरी TLS पर HTTP/2 या XMPP प्राथमिक पोर्ट 5223 (फॉलबैक: 443) [3] 443 (HTTPS) कनेक्शन स्वामी iOS कर्नेल / सिस्टम डेमन Google Play Services प्रक्रिया अनुमति आवश्यक स्पष्ट ऑप्ट-इन डायलॉग आवश्यक [7] डिफ़ॉल्ट रूप से दी गई (Android 13+ में ऑप्ट-इन आवश्यक) वैश्विक ऑप्ट-इन दर ~56% [7] ~67% [7] प्राथमिकता स्तर सामान्य, समय-संवेदनशील, महत्वपूर्ण सामान्य, उच्च AI नोटिफिकेशन रैंकिंग Apple Intelligence (iOS 26+) Notification Organizer (Android 16+) Doze/कम-पावर बाईपास साइलेंट पुश + बैकग्राउंड फ़ेच APIs उच्च-प्राथमिकता FCM फ्लैग [6] सिर्फ पोल क्यों नहीं? पुश के पक्ष में तर्क केंद्रीकृत पुश गेटवे के अस्तित्व से पहले, ऐप्स को अपने पोलिंग लूप लागू करने होते थे — हर कुछ मिनट में किसी सर्वर से पूछने के लिए जागते थे \u0026ldquo;कुछ नया है?\u0026rdquo; लागत बहुत अधिक थी [8]:\nबैटरी ड्रेन: प्रत्येक पोलिंग साइकिल रेडियो को जगाती है, जो महंगा है नेटवर्क ओवरहेड: हज़ारों ऐप प्रत्येक स्वतंत्र HTTP अनुरोध करते हैं विलंब: एक नोटिफिकेशन पोलिंग अंतराल तक देर से आ सकती है स्केलेबिलिटी: बैकएंड सर्वर बड़े पैमाने पर निरंतर पोलिंग अनुरोधों को संभालते हैं परसिस्टेंट-कनेक्शन पुश मॉडल इन सभी को समाप्त कर देता है। प्रति डिवाइस एक खुला सॉकेट लाखों संभावित नोटिफिकेशन संभालता है। रेडियो केवल तब जागता है जब वास्तव में कुछ डिलीवर करना हो। और गेटवे क्यूइंग, विफल डिलीवरी को रिट्राई करने और पुरानी नोटिफिकेशन को एक्सपायर करने की सभी जटिलताओं को संभालता है [9]।\nनिष्कर्ष आपका फ़ोन कभी भी अंधाधुंध अलर्ट के लिए इंटरनेट को पोल नहीं करता। iPhone और Android दोनों एक परिष्कृत, बैटरी-सचेत दृष्टिकोण अपनाते हैं: Apple या Google के वैश्विक गेटवे से एकल OS-प्रबंधित परसिस्टेंट कनेक्शन चुपचाप बैकग्राउंड में बैठता है। जब दुनिया में कहीं भी कोई सर्वर आपके डिवाइस तक पहुंचना चाहता है, तो वह उस गेटवे पर एक मैसेज पोस्ट करता है, जो तुरंत खुले चैनल के माध्यम से इसे आपकी स्क्रीन पर पुश करता है। परिणाम बैटरी जीवन पर न्यूनतम प्रभाव के साथ लगभग वास्तविक-समय डिलीवरी है — हर बज़ और बैनर के पीछे छिपी एक वास्तविक इंजीनियरिंग उपलब्धि।\nस्रोत APNs के साथ अपने ऐप को रजिस्टर करना — Apple Developer Documentation Apple Push Notification Service: MDM में APNs कैसे काम करता है — Fleet क्या iOS एक स्थिर कनेक्शन बनाए रखता है? — Apple Developer Forums Firebase Cloud Messaging — आधिकारिक Firebase दस्तावेज़ीकरण Android पर उपयोगकर्ताओं तक FCM नोटिफिकेशन पहुंचाना सुनिश्चित करें — Firebase Blog, अप्रैल 2025 Doze और App Standby के लिए ऑप्टिमाइज़ करें — Android Developers iOS बनाम Android पर पुश नोटिफिकेशन: 2026 में ये कैसे काम करते हैं — MobiLoud मोबाइल के लिए Pull बनाम Push आर्किटेक्चर — Microsoft Mobile Engineering, Medium पुश नोटिफिकेशन डीप डाइव: APNs और FCM के लिए अंतिम तकनीकी गाइड — Spritle 50 मिलियन डिवाइस तक पुश नोटिफिकेशन स्केल करना — Design Gurus Substack ","permalink":"https://cloudmato.com/hi/posts/how-mobile-push-notifications-work-ios-android/","title":"मोबाइल पुश नोटिफिकेशन कैसे काम करते हैं: iOS और Android"},{"content":"भारत का सबसे भरोसेमंद परीक्षा बोर्ड CBSE मई 2026 में एक बड़े साइबर सुरक्षा घोटाले से हिल गया, जब एक 19 वर्षीय एथिकल हैकर ने इसके ऑन-स्क्रीन मार्किंग (OSM) मूल्यांकन प्रणाली में बिना किसी रोक-टोक के प्रवेश का लाइव प्रदर्शन किया — जिसमें प्रोडक्शन सर्वर तक शेल एक्सेस और एक असुरक्षित क्लाउड बकेट से छात्रों की उत्तर पुस्तिकाओं का मुफ्त डाउनलोड शामिल था [1][2]। इस उल्लंघन से अनुमानित 20 लाख कक्षा 12 के छात्रों का व्यक्तिगत और शैक्षणिक डेटा खतरे में पड़ गया [5]। यह लेख हैक की हर परत को उजागर करता है, समझाता है कि इसका छात्रों और परिवारों पर क्या असर पड़ा, और सरकार को दोबारा ऐसा होने से रोकने के लिए क्या करना चाहिए।\n2026 CBSE OSM उल्लंघन: क्या हुआ 22 मई 2026 को निसर्ग अधिकारी — एक 19 वर्षीय एथिकल हैकर और कक्षा 12 के छात्र — ने सोशल मीडिया पर CBSE के OnMark पोर्टल की गंभीर सुरक्षा खामियों का विस्तृत विवरण सार्वजनिक किया। यह वही थर्ड-पार्टी सिस्टम है जिसका उपयोग परीक्षक कक्षा 12 की उत्तर पुस्तिकाओं का डिजिटल मूल्यांकन करने के लिए करते हैं [2][3]। उनके खुलासे को विस्फोटक बनाने वाली बात सिर्फ कमज़ोरियाँ नहीं थीं, बल्कि समयरेखा भी थी: CBSE अधिकारी पहले यह इनकार कर चुके थे कि ऐसी कोई खामी मौजूद है, फिर भी अधिकारी ने CBSE के लाइव प्रोडक्शन सर्वर पर पूर्ण क्रिएट, रीड, अपडेट और डिलीट (CRUD) एक्सेस के साथ शेल एक्सेस का प्रदर्शन किया [1]। उन्होंने कई विश्वविद्यालयों में मूल्यांकन की जिम्मेदारी संभालने वाले एक अन्य OnMark सबडोमेन पर सुपर-एडमिन अधिकार भी हासिल किए [1]।\nयह पोर्टल एक निजी विक्रेता COEMPT Eduteck द्वारा CBSE के साथ अनुबंध के तहत संचालित किया जाता है। अधिकारी ने इस सिस्टम की सुरक्षा को \u0026ldquo;अत्यंत असुरक्षित\u0026rdquo; बताया [4] — एक ऐसी विशेषता जिसे CBSE का अपना बाद का ऑडिट भी ठीक से नकार नहीं सका।\nउजागर हुई कमज़ोरियाँ अधिकारी ने CBSE से जुड़े सिस्टम में कम से कम छह उच्च-गंभीरता वाली कमज़ोरियाँ चिन्हित कीं [3]। नीचे दी गई तालिका में उजागर हुई गंभीर खामियों का सारांश है:\nकमज़ोरी विवरण जोखिम स्तर हार्डकोडेड मास्टर पासवर्ड सार्वजनिक रूप से पठनीय कोड में एम्बेड एक सार्वभौमिक गुप्त पासवर्ड, प्रति-उपयोगकर्ता प्रमाणीकरण को बायपास करता है अत्यंत गंभीर ब्राउज़र में OTP दृश्यमान परीक्षकों को भेजे गए वन-टाइम पासवर्ड ब्राउज़र HTTP प्रतिक्रियाओं में दिखाई देते थे उच्च बिना सत्यापन के पासवर्ड रीसेट किसी भी परीक्षक के खाते का पासवर्ड बिना पहचान जाँच के रीसेट किया जा सकता था उच्च AWS S3 बकेट — कोई प्रमाणीकरण नहीं बकेट URL वाला कोई भी व्यक्ति उत्तर पुस्तिकाएं और प्रश्न पत्र डाउनलोड कर सकता था अत्यंत गंभीर SARAS पोर्टल पर MD5 पासवर्ड हैशिंग CBSE की स्कूल संबद्धता प्रणाली पर पुराना, आसानी से क्रैक करने योग्य हैश एल्गोरिदम उच्च एडमिन पासवर्ड \u0026ldquo;123456\u0026rdquo; CBSE के इकोसिस्टम से जुड़े एक प्रशासनिक पोर्टल ने कथित तौर पर यह तुच्छ पासवर्ड इस्तेमाल किया अत्यंत गंभीर स्रोत: [3][4][8][14]\nOnMark सिस्टम से जुड़े Amazon Web Services (AWS) S3 स्टोरेज बकेट ने कथित तौर पर किसी को भी 2026 बोर्ड परीक्षाओं की स्कैन की गई उत्तर पुस्तिकाएं और प्रश्न पत्र बिना किसी प्रमाणिकता के ब्राउज़ और डाउनलोड करने की अनुमति दी [4][15]। यह एक क्लासिक असुरक्षित क्लाउड कॉन्फ़िगरेशन है — आधुनिक IT में बड़े पैमाने पर डेटा उजागर होने के सबसे सामान्य और सबसे रोके जाने योग्य कारणों में से एक।\nछात्रों पर प्रभाव: कौन प्रभावित हुआ? इन कमज़ोरियों के वास्तविक परिणाम सीधे लाखों छात्रों पर पड़े:\nगोपनीयता उल्लंघन: स्कैन की गई उत्तर पुस्तिकाएं — जिनमें हस्तलेख, रोल नंबर और स्कूल विवरण शामिल हैं — कथित तौर पर ब्राउज़र और URL वाले किसी के लिए भी सुलभ थीं [15]। अंक हेरफेर का जोखिम: परीक्षकों का प्रतिरूपण करने और सुपर-एडमिन एक्सेस प्राप्त करने की क्षमता ने सैद्धांतिक रूप से अंकों में बदलाव की अनुमति दी, हालांकि CBSE का कहना है कि ऐसी कोई छेड़छाड़ की पुष्टि नहीं हुई [1][14]। वित्तीय धोखाधड़ी: पुनर्मूल्यांकन पोर्टल पर एक अलग दुर्भावनापूर्ण हमले के कारण शुल्क प्रदर्शन राशि ₹1 और ₹68,000 के बीच उतार-चढ़ाव करती रही, जिससे लगभग 50 छात्रों से अधिक शुल्क लिया गया [7]। परीक्षा की अखंडता प्रभावित: AWS बकेट में 2026 के प्रश्न पत्र कथित रूप से सुलभ होने के साथ, बोर्ड परीक्षा की निष्पक्षता पर ही सवाल उठ गया [4]। राजनीतिक विवाद: कांग्रेस नेता जयराम रमेश ने इसे \u0026ldquo;20 लाख छात्रों की गोपनीयता को खतरे में डालने वाला एक बड़ा डेटा लीक\u0026rdquo; बताते हुए सरकार से जवाबदेही की मांग की [5][6]। COEMPT Eduteck विवाद इस तूफान के केंद्र में है COEMPT Eduteck, वह निजी IT विक्रेता जो CBSE का OSM प्लेटफॉर्म संचालित करती है [17]। आलोचकों का आरोप है कि कई निविदा दौरों में बार-बार अनुरोध प्रस्ताव (RFP) में ऐसे बदलाव किए गए जो विक्रेता की पात्रता मानदंड को उसके पक्ष में बदलते प्रतीत होते हैं [17]। प्रमुख चिंताजनक बिंदु:\nरोबोटिक स्कैनिंग मशीनों की आवश्यकता — एक महत्वपूर्ण भौतिक सुरक्षा सुरक्षा उपाय — को कथित तौर पर तीसरे RFP में हटा दिया गया [6]। स्कैन की गई छवियों में प्रमाणित सुरक्षित स्कैनर के बजाय मोबाइल फोन कैमरे से कैप्चर किए जाने के संकेत मिले, जिससे भौतिक डेटा हैंडलिंग पर सवाल उठे [6]। कांग्रेस ने निविदा प्रक्रिया और विक्रेता के आचरण की जांच की औपचारिक मांग की [17]। CBSE ने यह बनाए रखा है कि चिन्हित कमज़ोरियों को \u0026ldquo;नियंत्रित कर लिया गया है,\u0026rdquo; और कुछ हैकिंग प्रदर्शनों को लाइव प्रोडक्शन सिस्टम के बजाय परीक्षण वातावरण के लिए जिम्मेदार ठहराया — एक दावा जिसे साइबर सुरक्षा शोधकर्ताओं ने विवादित किया है [3][10]।\nनकली DigiLocker: एक छिपा खतरा इस संकट को और बढ़ाते हुए, इलेक्ट्रॉनिक्स और सूचना प्रौद्योगिकी मंत्रालय (MeitY) ने CBSE विवाद की आड़ में चल रही एक नकली DigiLocker वेबसाइट के बारे में सार्वजनिक चेतावनी जारी की [9]। यह धोखाधड़ी पोर्टल:\nदिखने में आधिकारिक सरकारी DigiLocker इंटरफेस की नकल करता है। छात्रों को DigiLocker और CISCE सेवाएं प्रदान करने का दावा करता है। छात्रों की साख और व्यक्तिगत जानकारी चुराने के लिए बनाया गया है। बोर्ड परिणाम सत्यापित करने के लिए दौड़ रहे छात्र और अभिभावक फ़िशिंग के प्रमुख लक्ष्य हैं। MeitY उपयोगकर्ताओं से DigiLocker को केवल digilocker.gov.in के माध्यम से एक्सेस करने और CERT-In के आधिकारिक चैनलों के माध्यम से संदिग्ध साइटों की रिपोर्ट करने का आग्रह करता है [9]।\nअब तक की सरकारी प्रतिक्रिया सरकार की तात्कालिक प्रतिक्रिया ऊर्जावान रही है, हालांकि दीर्घकालिक अनुवर्ती कार्रवाई अभी देखनी बाकी है:\nIIT टास्क फोर्स तैनात: CBSE ने OnMark का ऑडिट करने और शेष कमज़ोरियों को मजबूत करने के लिए IIT मद्रास और IIT कानपुर के साइबर सुरक्षा विशेषज्ञों के साथ-साथ सरकारी एजेंसी के पेशेवरों को लाया [11]। कमज़ोरी नियंत्रण घोषित: CBSE ने कहा कि सभी \u0026ldquo;चिन्हनीय कमज़ोरियों\u0026rdquo; को नियंत्रित कर लिया गया है, अतिरिक्त जांच अभी जारी है [10]। DigiLocker बदलाव की घोषणा: शिक्षा मंत्रालय ने पुष्टि की कि अगले शैक्षणिक वर्ष से CBSE कक्षा 12 की उत्तर पुस्तिकाएं DigiLocker पर उपलब्ध होंगी, जिससे थर्ड-पार्टी विक्रेता पोर्टलों पर निर्भरता कम होगी [16]। राष्ट्रीय साइबर सुरक्षा रणनीति 2026 लॉन्च: यह व्यापक नीति ढांचा महत्वपूर्ण क्षेत्रों में तेज़ पहचान और प्रतिक्रिया के लिए CERT-In, राज्य पुलिस साइबर सेल और निजी क्षेत्र के हितधारकों के बीच समन्वय अनिवार्य करता है [13]। CERT-In का विस्तार: 2024-25 में, CERT-In ने 29.44 लाख से अधिक साइबर घटनाओं को संभाला, 1,530 अलर्ट, 390 कमज़ोरी सलाह जारी की, और सरकार तथा महत्वपूर्ण बुनियादी ढांचे में 9,700 से अधिक सुरक्षा ऑडिट किए [12]। क्या और किया जाना चाहिए: एक नीति रोडमैप प्रतिक्रियात्मक पैचिंग कोई रणनीति नहीं है। व्यवस्थित सुधार इस तरह दिखना चाहिए:\nअनिवार्य विक्रेता सुरक्षा मानक सरकारी शिक्षा डेटा संभालने वाले किसी भी EdTech विक्रेता को अनुबंध हस्ताक्षर से पहले और वार्षिक नवीनीकरण पर CERT-In-अनुमोदित थर्ड-पार्टी सुरक्षा ऑडिट पास करना होगा। सरकारी RFP में सुरक्षा आवश्यकताएं गैर-परक्राम्य, संस्करण-लॉक खंड होनी चाहिए — ऐसी वस्तुएं नहीं जिन्हें निविदा संशोधनों में चुपचाप कमज़ोर किया जा सके। सभी सरकारी शिक्षा पोर्टलों के लिए औपचारिक बग बाउंटी कार्यक्रम स्थापित किए जाने चाहिए, जो अधिकारी जैसे एथिकल हैकरों को सुरक्षित, कानूनी रूप से संरक्षित और आर्थिक रूप से पुरस्कृत प्रकटीकरण चैनल दें। क्लाउड कॉन्फ़िगरेशन प्रशासन सभी सरकार-से-जुड़े क्लाउड स्टोरेज (AWS S3, Azure Blob, GCP) को स्वचालित गलत-कॉन्फ़िगरेशन स्कैनिंग से गुजरना होगा — EU, USA और ऑस्ट्रेलिया में पहले से अनिवार्य एक मानक। डिजिटल व्यक्तिगत डेटा संरक्षण (DPDP) अधिनियम 2023 को सार्थक दंड के साथ लागू किया जाना चाहिए: लापरवाही से छात्र डेटा उजागर करने वाले विक्रेताओं को केवल सलाहकार नोटिस नहीं, वित्तीय दायित्व का सामना करना चाहिए। एक समर्पित Edu-CERT भारत को वित्तीय क्षेत्र के CERT-Fin के मॉडल पर एक क्षेत्रीय शिक्षा CERT (Edu-CERT) स्थापित करना चाहिए, जिसके पास समाचारपत्रों तक छात्र शिकायतें पहुंचने का इंतजार किए बिना वास्तविक समय में शिक्षा बुनियादी ढांचे के विक्रेताओं को स्वतंत्र रूप से ऑडिट करने, प्रतिक्रिया देने और दंडित करने का अधिकार हो। साइबर सुरक्षा प्रतिभा पाइपलाइन राष्ट्रीय साइबर सुरक्षा रणनीति 2026 का लक्ष्य पांच वर्षों में 5 लाख साइबर सुरक्षा पेशेवरों को प्रशिक्षित करना है [13]; इसका एक समर्पित हिस्सा विशेष रूप से edtech सुरक्षा और सरकारी पोर्टल ऑडिटिंग में लगाया जाना चाहिए। साइबर सुरक्षा को स्कूल और कॉलेज पाठ्यक्रमों में शामिल किया जाना चाहिए ताकि प्रशासकों और डेवलपर्स की अगली पीढ़ी शुरू से ही सुरक्षा-प्रथम सोच के साथ काम करे। छात्र और अभिभावक जागरूकता वार्षिक डिजिटल साक्षरता अभियान छात्रों, अभिभावकों और स्कूल प्रशासकों को आधिकारिक URL सत्यापित करने, फ़िशिंग पोर्टल पहचानने और आधिकारिक चैनलों के माध्यम से डेटा विसंगतियों की रिपोर्ट करने के बारे में शिक्षित करें [9]। CBSE को एक स्पष्ट सार्वजनिक घटना-प्रतिक्रिया प्रोटोकॉल प्रकाशित करना चाहिए ताकि छात्र जान सकें कि उल्लंघन का संदेह होते ही क्या करना है। CBSE संकट अंततः एक व्यवस्थागत खामी का लक्षण है: सार्वजनिक सेवाओं में भारत के तेज़ डिजिटल विस्तार के साथ सुरक्षा वास्तुकला में समतुल्य निवेश लगातार नहीं किया गया है। जैसे-जैसे परीक्षा परिणाम, पहचान और शैक्षणिक रिकॉर्ड डिजिटल प्रणालियों से और अधिक जुड़ते जाते हैं, दांव केवल ऊंचे होते जाते हैं — और सार्थक संरचनात्मक सुधार की खिड़की अभी है, अगली सुर्खी बनाने से पहले।\nस्रोत CBSE ऑनलाइन मार्किंग पोर्टल सुरक्षा खामियों से इनकार के बाद हैक — MediaNama एक 19 वर्षीय छात्र ने कैसे CBSE का OSM पोर्टल हैक किया — The Print CBSE ने किशोर हैकर के आरोपों के बाद OnMark पोर्टल में कमज़ोरियाँ स्वीकारीं — Careers360 \u0026lsquo;अत्यंत असुरक्षित\u0026rsquo;: एथिकल हैकर का आरोप, CBSE उत्तर पुस्तिकाएं सार्वजनिक रूप से सुलभ थीं — BusinessToday CBSE कक्षा 12 डेटा लीक: 20 लाख छात्रों की गोपनीयता खतरे में — Asianet Newsable 20 लाख छात्रों की गोपनीयता को खतरे में डालने वाला बड़ा डेटा लीक: कांग्रेस — ANI News CBSE पोर्टल पर दुर्भावनापूर्ण हमला, लगभग 50 छात्र प्रभावित — The Chenab Times \u0026lsquo;पासवर्ड था 123456\u0026rsquo;: छात्र ने CBSE-लिंक्ड सिस्टम में नई सुरक्षा चूक का आरोप लगाया — BusinessToday CBSE OSM विवाद के बीच सरकार ने नकली DigiLocker वेबसाइट के बारे में चेतावनी दी — Digit CBSE का कहना है OSM पोर्टल की \u0026lsquo;कमज़ोरियाँ नियंत्रित\u0026rsquo;, IIT टीमें तैनात — India TV News सुरक्षा चिंताओं के बाद CBSE ने IIT मद्रास और IIT कानपुर विशेषज्ञ तैनात किए — Swarajya Mag सरकार ने महत्वपूर्ण क्षेत्रों में साइबर सुरक्षा मजबूत की; CERT-In ने 9,700 से अधिक ऑडिट किए — PIB भारत ने राष्ट्रीय साइबर सुरक्षा रणनीति 2026 लॉन्च की — Education Post CBSE OSM विवाद समझाया: बोर्ड ने पोर्टल हैक के बाद सुरक्षा खामियाँ स्वीकारीं — Gulf News CBSE उत्तर पुस्तिका लीक विवाद: छात्रों ने AWS डेटा उल्लंघन का आरोप लगाया — OneIndia अगले वर्ष से CBSE कक्षा 12 की उत्तर पुस्तिकाएं DigiLocker पर — Careers360 कांग्रेस ने CBSE उत्तर पुस्तिका लीक पर चिंता जताई, मूल्यांकन ठेकेदार पर सवाल — The Statesman ","permalink":"https://cloudmato.com/hi/posts/cbse-portal-hacks-vulnerabilities-2026/","title":"CBSE पोर्टल हैक 2026: जोखिम, प्रभाव और सरकारी सुधार"},{"content":"क्लाउड कंप्यूटिंग दुनिया के सॉफ्टवेयर चलाने के तरीके को नया रूप दे रही है — वैश्विक बाजार 2026 में $1 ट्रिलियन के करीब पहुंचने की राह पर है [1], जो AI वर्कलोड, SaaS विस्तार, और एंटरप्राइज़ डिजिटल ट्रांसफॉर्मेशन द्वारा संचालित है। फिर भी अगर आप पहले से DigitalOcean Droplet या किसी समान VPS पर अपने ऐप्स तैनात करते हैं, तो आप सोच रहे होंगे: क्या मुझे वास्तव में कुछ बदलने की जरूरत है? यहाँ एक ईमानदार, व्यावहारिक जवाब दिया गया है।\nक्लाउड कंप्यूटिंग क्या है? क्लाउड कंप्यूटिंग इंटरनेट पर पे-एज़-यू-गो आधार पर कंप्यूटिंग संसाधनों — सर्वर, स्टोरेज, डेटाबेस, नेटवर्किंग, सॉफ्टवेयर, और एनालिटिक्स — की डिलीवरी है [1]। भौतिक हार्डवेयर खुद रखने के बजाय, आप किसी प्रदाता से क्षमता किराए पर लेते हैं और इसे कहीं से भी एक्सेस करते हैं। तीन प्रमुख खिलाड़ी हैं AWS (~33% बाजार हिस्सेदारी), Microsoft Azure (~23%), और Google Cloud (~12%), जो मिलकर वैश्विक क्लाउड इंफ्रास्ट्रक्चर बाजार के 60% से अधिक पर नियंत्रण रखते हैं [3]।\n\u0026ldquo;क्लाउड\u0026rdquo; शब्द अनिवार्य रूप से किसी और के कंप्यूटर, बड़े पैमाने पर प्रबंधित, आपको मांग पर उपलब्ध का संक्षिप्त रूप है [2]।\nतीन क्लाउड सेवा मॉडल सभी क्लाउड सेवाएं एक जैसी नहीं होतीं। प्रदाता अपनी सेवाओं को तीन अलग-अलग परतों में व्यवस्थित करते हैं [4][5]:\nIaaS — इंफ्रास्ट्रक्चर एज़ अ सर्विस IaaS आपको वर्चुअल मशीन, नेटवर्किंग, और स्टोरेज देता है जबकि प्रदाता भौतिक हार्डवेयर का स्वामित्व और रखरखाव करता है। आप अभी भी अपना OS, रनटाइम, और एप्लिकेशन इंस्टॉल और प्रबंधित करते हैं। AWS EC2, Azure Virtual Machines, और Google Compute Engine इसके प्रमुख उदाहरण हैं [5]।\nसॉफ्टवेयर स्टैक पर पूरा नियंत्रण OS पैचिंग और सुरक्षा हार्डनिंग की जिम्मेदारी आपकी DevOps विशेषज्ञता वाली टीमों के लिए सबसे उपयुक्त जिन्हें लचीलेपन की जरूरत है PaaS — प्लेटफॉर्म एज़ अ सर्विस PaaS, IaaS के ऊपर एक पूरी तरह से प्रबंधित रनटाइम जोड़ता है। आप कोड पुश करें; प्लेटफॉर्म डिप्लॉयमेंट, OS अपडेट, और स्केलिंग संभालता है। Heroku, Google App Engine, और Vercel लोकप्रिय PaaS विकल्प हैं [4]।\nडेवलपर्स सर्वर कॉन्फ़िगरेशन को पूरी तरह छोड़ देते हैं git push से प्रोडक्शन तक तेज़ कम परिचालन ओवरहेड — छोटी टीमों के लिए आदर्श SaaS — सॉफ्टवेयर एज़ अ सर्विस SaaS तैयार उत्पाद है: ब्राउज़र में उपयोग के लिए तैयार सॉफ्टवेयर, विक्रेता द्वारा पूरी तरह प्रबंधित। Gmail, Salesforce, Dropbox, और Slack रोजमर्रा के उदाहरण हैं [5]। इंस्टॉल करने, पैच करने, या स्केल करने के लिए कुछ नहीं है — प्रदाता सब कुछ करता है।\nक्लाउड कंप्यूटिंग के मुख्य फायदे क्लाउड को अपनाना तेज़ी से बढ़ा है क्योंकि यह उन समस्याओं को हल करता है जो एक पारंपरिक VPS बड़े पैमाने पर नहीं कर सकता [1][2]:\nलचीली स्केलेबिलिटी क्लाउड प्लेटफॉर्म सेकंडों में CPU, RAM, और स्टोरेज प्रोविज़न करते या जारी करते हैं — रीबूट की जरूरत नहीं। ऑटो-स्केलिंग ग्रुप ट्रैफिक उछाल का पता लगाते हैं और स्वचालित रूप से नए इंस्टेंस चालू करते हैं, फिर मांग कम होने पर हटा देते हैं [7]। किसी अप्रत्याशित वायरल क्षण या प्रोडक्ट लॉन्च को संभालने के लिए सर्वर साइजिंग का अनुमान लगाने की जरूरत नहीं। वास्तविक पे-एज़-यू-गो मूल्य निर्धारण आप कंप्यूट सेकंड, संग्रहीत GBs, और उपभोग की गई API कॉल के लिए बिल किए जाते हैं — कभी भी निष्क्रिय क्षमता के लिए नहीं [8]। स्टार्टअप लगभग शून्य इंफ्रास्ट्रक्चर खर्च के साथ शुरू हो सकते हैं और लागत को केवल राजस्व के साथ बढ़ने दे सकते हैं। सर्वरलेस फ़ंक्शन (AWS Lambda, Google Cloud Functions) इसे और आगे ले जाते हैं: अगर कोई आपके एंडपॉइंट को नहीं कॉल करता, तो आपका बिल शाब्दिक रूप से $0 है। बिल्ट-इन ग्लोबल डिस्ट्रीब्यूशन AWS 34+ भौगोलिक क्षेत्रों में काम करता है; Azure और Google Cloud समान फुटप्रिंट कवर करते हैं [2]। टोक्यो, फ्रैंकफर्ट, या साओ पाउलो में उपयोगकर्ताओं के करीब अपना ऐप तैनात करना एक कॉन्फ़िगरेशन बदलाव है, न कि हार्डवेयर खरीद का ऑर्डर। कंटेंट डिलीवरी नेटवर्क (CDN) और एज कैश प्रथम श्रेणी, प्रबंधित सेवाएं हैं। उच्च उपलब्धता और आपदा पुनर्प्राप्ति क्लाउड वर्कलोड कई अवेलेबिलिटी ज़ोन में चलते हैं — किसी क्षेत्र के भीतर भौतिक रूप से अलग डेटा सेंटर। अगर एक ज़ोन विफल होता है, तो ट्रैफिक स्वचालित रूप से बिना किसी मैन्युअल हस्तक्षेप के रीरूट हो जाता है [7][8]। उद्योग SLA 99.99% अपटाइम का वादा करती है — प्रति वर्ष 53 मिनट से कम डाउनटाइम। बिना अतिरिक्त लागत के एंटरप्राइज़-ग्रेड सुरक्षा हाइपरस्केलर DDoS शमन, हार्डवेयर-स्तर एन्क्रिप्शन, IAM, और अनुपालन प्रमाणपत्र (SOC 2, ISO 27001, HIPAA, GDPR) में अरबों का निवेश करते हैं [1][11]। 3-व्यक्ति स्टार्टअप को Fortune 500 कंपनी जैसी ही भौतिक सुरक्षा स्थिति मिलती है। प्रबंधित सेवाएं जो परेशानी खत्म करती हैं रिलेशनल डेटाबेस चाहिए? AWS RDS या Cloud SQL चालू करें — किसी DBA की जरूरत नहीं। मैसेज क्यू चाहिए? SQS या Pub/Sub का उपयोग करें — कोई RabbitMQ क्लस्टर संभालने की जरूरत नहीं। मशीन लर्निंग APIs, वीडियो ट्रांसकोडिंग, रीयल-टाइम एनालिटिक्स: सभी प्रबंधित, पे-पर-यूज़ सेवाओं के रूप में उपलब्ध [12]। VPS का मामला: जहाँ DigitalOcean अभी भी जीतता है ऊपर बताई गई हर चीज़ के बावजूद, एक साधारण VPS किसी भी तरह से पुराना नहीं पड़ा है। DigitalOcean, Linode (Akamai Cloud), और Hetzner एक बहुत वास्तविक, व्यावहारिक जगह पर काबिज हैं [6][9]।\nVPS एक एकल भौतिक होस्ट पर एक वर्चुअल मशीन है। आपको root एक्सेस, CPU और RAM का एक निश्चित हिस्सा, और एक अनुमानित मासिक बिल मिलता है — आमतौर पर एंट्री-लेवल Droplet के लिए $6–$24 [6][10]।\nVPS तब भी बेहतरीन समझ में आता है जब:\nट्रैफिक अनुमानित हो। एक पोर्टफोलियो साइट, स्थिर आगंतुकों वाला एक छोटा SaaS, या CI रनर को ऑटो-स्केलिंग की जरूरत नहीं। ऐसी क्षमता के लिए भुगतान करना जिसका आप कभी उपयोग नहीं करेंगे, शुद्ध ओवरहेड है [9]। आपको एक निश्चित मासिक बजट चाहिए। लूप में फंसे Lambda फ़ंक्शन या गलती से हुए S3 एग्रेस चार्ज से अप्रत्याशित बिल नहीं। फुल-स्टैक कंट्रोल मायने रखता है। Root SSH आपको कोई भी रनटाइम इंस्टॉल करने, कर्नेल पैरामीटर बदलने, और क्लाउड-विशिष्ट एब्स्ट्रैक्शन या वेंडर लॉक-इन से बचने देता है [6]। आप कई छोटे प्रोजेक्ट सस्ते में होस्ट करते हैं। एक $12/महीना Droplet Nginx वर्चुअल होस्ट या Docker कंटेनर का उपयोग करके दर्जनों कम-ट्रैफिक ऐप्स सर्व कर सकता है। आपके उपयोगकर्ता सभी एक ही क्षेत्र में हैं। एक नजदीकी VPS उन लेटेंसी-संवेदनशील वर्कलोड के लिए मल्टी-रीजन क्लाउड सेटअप से बेहतर प्रदर्शन कर सकता है जो भौगोलिक वितरण से लाभ नहीं उठाते। शोध लगातार दिखाता है कि स्थिर, अनुमानित वर्कलोड चलाने वाले व्यवसाय अक्सर क्लाउड प्लेटफॉर्म पर 40–60% अधिक भुगतान करते हैं समकक्ष VPS संसाधनों की तुलना में [8]। यह लागत अंतर वास्तविक है और इसे ईमानदारी से तौला जाना चाहिए।\nक्लाउड बनाम VPS: आमने-सामने तुलना विशेषता क्लाउड (AWS / Azure / GCP) VPS (DigitalOcean / Linode) स्केलेबिलिटी सेकंडों में ऑटो-स्केल मैन्युअल अपग्रेड आवश्यक अपटाइम SLA 99.99% (मल्टी-ज़ोन) ~99.9% (एकल सर्वर) मूल्य निर्धारण मॉडल पे-पर-यूज़ (परिवर्तनशील) निश्चित मासिक शुल्क वैश्विक क्षेत्र दुनिया भर में 30–40+ कम; प्रदाता के अनुसार अलग प्रबंधित सेवाएं डेटाबेस, AI, क्यू, CDN न्यूनतम; ज्यादातर DIY सुरक्षा टूलिंग बिल्ट-इन IAM, DDoS, अनुपालन प्रमाणपत्र बेसिक फ़ायरवॉल; स्व-प्रबंधित सीखने की अवस्था उच्च (सैकड़ों सेवाएं) कम; सीधा Linux/SSH सबसे उपयुक्त परिवर्तनशील लोड, माइक्रोसर्विस, AI स्थिर ऐप्स, डेव एनवायरनमेंट, साइड प्रोजेक्ट तो — क्या आपको अपना VPS छोड़ देना चाहिए? जरूरी नहीं। VPS को एक विश्वसनीय, किफायती अपार्टमेंट समझें — आपको किराया पता है, आप इसके हर कोने को नियंत्रित करते हैं, और जब आपकी जरूरतें स्थिर हों तो यह बिल्कुल उपयुक्त है। क्लाउड एक वैश्विक होटल चेन की तरह है: प्रति वर्ग फुट अधिक महंगा, लेकिन आप आज रात, किसी भी शहर में, शून्य नोटिस पर एक अलग कमरे के आकार के साथ चेक इन कर सकते हैं [11]।\nक्लाउड कंप्यूटिंग में अपग्रेड करें अगर:\nआपके एप्लिकेशन का ट्रैफिक अप्रत्याशित रूप से बढ़ता है। आपको मल्टी-रीजन रिडंडेंसी या ग्लोबल CDN डिलीवरी की जरूरत है। आप इंफ्रास्ट्रक्चर चलाए बिना प्रबंधित AI, ML, या डेटा पाइपलाइन सेवाएं चाहते हैं। आपकी टीम के पास सर्वर को पैच और मेनटेन करने की बैंडविड्थ नहीं है। अनुपालन आवश्यकताओं के लिए SOC 2, HIPAA, या GDPR प्रमाणपत्र की जरूरत है [1][11]। अपने VPS के साथ रहें अगर:\nट्रैफिक स्थिर और समझ में आने वाला है। आप एक पारदर्शी, निश्चित मासिक बिल चाहते हैं। आप साइड प्रोजेक्ट, डेव एनवायरनमेंट, या कम-ट्रैफिक क्लाइंट साइट बना रहे हैं। आपको क्लाउड वेंडर लॉक-इन के बिना root-लेवल कंट्रोल चाहिए। आपका ऐप ऑटो-स्केलिंग ओवरहेड को कभी उचित नहीं ठहराता [9][10]। कई टीमें अंततः हाइब्रिड दृष्टिकोण अपनाती हैं — प्रोडक्शन और बर्स्ट क्षमता के लिए क्लाउड हाइपरस्केलर, लागत-संवेदनशील, स्थिर वर्कलोड के लिए VPS। 2026 में एंटरप्राइज़ में मल्टी-क्लाउड और हाइब्रिड अपनाना 89% तक पहुंच गया [3], जो साबित करता है कि उद्योग एक या दूसरे को नहीं चुन रहा, बल्कि दोनों को रणनीतिक रूप से चुन रहा है। क्लाउड हर समस्या का जवाब नहीं है — लेकिन बढ़ते हुए एप्लिकेशन जो विश्वसनीयता, वैश्विक पहुंच, और डेवलपर वेग की मांग करते हैं, उनके लिए इसे हराना तेजी से मुश्किल होता जा रहा है।\nस्रोत Cloud Computing Guide 2026: Advantages, Disadvantages, and Real Business Impact Cloud Computing in 2026: Benefits, Business Impact, and Future Growth Cloud Market Share 2026: AWS vs Azure vs Google Revenue \u0026amp; Full Stats IaaS vs. PaaS vs. SaaS — Red Hat SaaS vs PaaS vs IaaS – Types of Cloud Computing – AWS What is a Virtual Private Server (VPS)? — Google Cloud Cloud vs. VPS Hosting: Pros, Cons and Key Differences — Cloudways VPS vs Cloud Hosting: Performance, Cost \u0026amp; Security Comparison for 2026 — HostMyCode VPS vs. Cloud Hosting: Key Differences, Pros \u0026amp; Cons — SiteGround Cloud Server vs VPS Hosting: Price Comparison 2026 — LetsCloud Cloud Hosting vs VPS vs Dedicated: Which Is Best for 2026? — SkyNet Hosting Cloud Computing: Types, Benefits \u0026amp; Use Cases Explained (2026) — Techimply ","permalink":"https://cloudmato.com/hi/posts/cloud-computing-vs-vps-hosting/","title":"क्लाउड कंप्यूटिंग बनाम VPS: फायदे और मुख्य अंतर"},{"content":"भारत दुनिया का दूसरा सबसे बड़ा स्मार्टफोन बाज़ार है — और साइबर अपराधियों द्वारा सबसे अधिक निशाना बनाए जाने वाले देशों में से एक। सिर्फ 2025 में, भारतीयों ने 28.15 लाख साइबर अपराध की शिकायतें दर्ज कीं और डिजिटल धोखाधड़ी में ₹22,495 करोड़ गंवाए [2]। यदि आप बैंकिंग, UPI भुगतान, या सिर्फ WhatsApp के लिए स्मार्टफोन का उपयोग करते हैं, तो आप एक लक्ष्य हैं। अगली स्कैम कॉल आने से पहले अपने फोन को सुरक्षित करने के लिए यह आपकी पूरी और सीधी गाइड है।\nसमस्या की व्यापकता संख्याएं एक भयावह तस्वीर पेश करती हैं। भारत में साइबर अपराध के मामले पिछले वर्ष की तुलना में 2025 में 24% बढ़ गए [2], और भारत सरकार को धोखाधड़ी से जुड़े 7.81 लाख से अधिक SIM कार्ड और 2,08,469 फोन IMEI ब्लॉक करने पड़े [3]। अकेले UPI धोखाधड़ी ने वित्त वर्ष 26 के पहले आठ महीनों में ₹805 करोड़ से अधिक का नुकसान किया — और यह केवल उन मामलों की गिनती है जो वास्तव में रिपोर्ट किए गए, क्योंकि अनुमानित 51% UPI धोखाधड़ी पीड़ित कभी शिकायत दर्ज नहीं कराते [1]।\nधोखाधड़ी यादृच्छिक नहीं है। स्कैमर्स संगठित ऑपरेशन चलाते हैं, AI वॉयस-क्लोनिंग, नकली सरकारी पोर्टल और विश्वासजनक डीपफेक वीडियो का उपयोग करके हर एक दिन आम लोगों से पैसे ऐंठते हैं।\nभारतीयों को निशाना बनाने वाले सबसे आम फोन स्कैम डिजिटल अरेस्ट और छद्मवेश स्कैम \u0026ldquo;डिजिटल अरेस्ट\u0026rdquo; भारत में सबसे तेजी से बढ़ने वाली मनोवैज्ञानिक धोखाधड़ी है [1]। एक कॉलर — अक्सर WhatsApp वीडियो के माध्यम से — CBI अधिकारी, सीमा शुल्क अधिकारी, या TRAI प्रतिनिधि के रूप में खुद को पेश करता है। वे दावा करते हैं कि आपका फोन नंबर मनी लॉन्ड्रिंग या ड्रग तस्करी से जुड़ा है और आपको एक नकली \u0026ldquo;डिजिटल अरेस्ट\u0026rdquo; में डाल देते हैं, मांग करते हैं कि आप तब तक कॉल पर रहें जब तक जुर्माना न भरें या बैंक क्रेडेंशियल साझा न करें [5]।\nमुख्य चेतावनी संकेत:\nकॉलर गोपनीयता की मांग करता है और घंटों कनेक्टेड रहने का आग्रह करता है वे आपसे \u0026ldquo;सुरक्षित सरकारी खाते\u0026rdquo; में पैसे ट्रांसफर करने को कहते हैं वे आधिकारिक दिखने वाली स्क्रीन पृष्ठभूमि और नकली ID कार्ड का उपयोग करते हैं वे फोन काटने पर तत्काल गिरफ्तारी की धमकी देते हैं वास्तविकता जांच: भारत में कोई भी सरकारी एजेंसी — न CBI, न ED, न TRAI, न पुलिस — फोन या वीडियो कॉल पर नागरिकों को गिरफ्तार नहीं करती [5]।\nUPI, OTP और भुगतान धोखाधड़ी धोखेबाज नकली भुगतान-अनुरोध QR कोड, नकली PhonePe/GPay स्क्रीन और बैंक SMS संदेशों के रूप में छिपाए गए फिशिंग लिंक भेजते हैं [7]। एक बार स्कैन या क्लिक करने पर, आपका OTP कैप्चर हो जाता है और मिनटों में आपका खाता खाली हो जाता है।\nसामान्य UPI हमले के तरीके:\nनकली कलेक्ट अनुरोध — आपको ₹1 का \u0026ldquo;परीक्षण\u0026rdquo; भुगतान अनुरोध मिलता है; इसे स्वीकार करने पर एक बड़ा डेबिट हो जाता है स्क्रीनशेयर स्कैम — एक नकली \u0026ldquo;बैंक सपोर्ट\u0026rdquo; एजेंट आपसे AnyDesk या TeamViewer इंस्टॉल करने को कहता है; वे रियल टाइम में आपका OTP देखते हैं [8] नकल ऐप्स — Play Store के बाहर से डाउनलोड किए गए PhonePe/GPay जैसे दिखने वाले APK जो आपके क्रेडेंशियल चुरा लेते हैं [7] eSIM हाईजैकिंग और SIM स्वैप धोखाधड़ी जैसे-जैसे भारत eSIM अपना रहा है, एक नया हमला उभरा है। धोखेबाज आपके टेलीकॉम ऑपरेटर को आपके रूप में कॉल करते हैं, उन्हें eSIM जारी करने के लिए मना लेते हैं, फिर आपके नंबर पर आने वाले हर OTP को इंटरसेप्ट करते हैं [6]। मिनटों में वे आपके बैंक खाते, ईमेल और UPI पर नियंत्रण पा लेते हैं। साउथ इंडियन बैंक चेतावनी देता है कि 2025-26 में eSIM स्कैम तेजी से बढ़ रहे हैं और पूरी चोरी दस मिनट से कम में पूरी हो सकती है [6]।\nस्कैमर्स से अपने फोन को कैसे मजबूत बनाएं अपने SIM कार्ड को सुरक्षित करें आपका मोबाइल नंबर आपकी पूरी डिजिटल जीवन की मास्टर कुंजी है। इसे उसी अनुसार सुरक्षित रखें।\nSIM PIN सेट करें (Android पर Settings → SIM card → SIM PIN; iPhone पर Settings → Cellular → SIM PIN)। कोई भी जो आपका फोन चुराता है, इस PIN के बिना कॉल नहीं कर सकता या OTP प्राप्त नहीं कर सकता [4]। अपने कैरियर के साथ SIM लॉक सक्षम करें — Airtel, Jio, या Vi को कॉल करें और पोर्ट-ब्लॉक या eSIM एक्टिवेशन फ्रीज की मांग करें ताकि कोई भी स्टोर में व्यक्तिगत रूप से आए बिना आपका नंबर पोर्ट या डुप्लीकेट न कर सके। sancharsaathi.gov.in पर अपने पंजीकृत SIM की जांच करें — भारत का आधिकारिक संचार साथी पोर्टल आपको अपने आधार के तहत पंजीकृत सभी SIM कार्ड देखने और किसी भी अपरिचित को तुरंत ब्लॉक करने की सुविधा देता है [3]। अपने UPI और बैंकिंग ऐप्स को सुरक्षित करें खतरा गलत व्यवहार सुरक्षित व्यवहार नकली कलेक्ट अनुरोध रिफंड समझकर स्वीकृत करना सभी आने वाले अनुरोध जो आपने शुरू नहीं किए, अस्वीकार करें स्क्रीन-शेयर की मांग \u0026ldquo;बैंक सपोर्ट\u0026rdquo; के लिए AnyDesk इंस्टॉल करना कॉल समाप्त करें; बैंक कभी रिमोट एक्सेस नहीं मांगते QR कोड भुगतान नाम जांचे बिना मर्चेंट QR स्कैन करना भुगतान से पहले मर्चेंट का नाम सत्यापित करें अज्ञात APK किसी लिंक से PhonePe डाउनलोड करना केवल Google Play / Apple App Store से डाउनलोड करें OTP अनुरोध \u0026ldquo;बैंक अधिकारी\u0026rdquo; से साझा करना OTP केवल आपका है — किसी से भी साझा न करें अभी लेने के लिए अतिरिक्त कदम:\nप्रत्येक UPI और बैंकिंग ऐप में बायोमेट्रिक लॉक (फिंगरप्रिंट/चेहरा) सक्षम करें [8]। अपने बैंक के ऐप में दैनिक UPI लेनदेन सीमा निर्धारित करें — अधिकांश ₹5,000 जितनी कम सीमा की अनुमति देते हैं। हर लेनदेन के लिए SMS/ईमेल अलर्ट चालू करें, चाहे कितना भी छोटा हो। उन वेबसाइटों से सहेजे गए कार्ड हटाएं जिनका आप नियमित रूप से उपयोग नहीं करते। अपनी डिवाइस सेटिंग्स को मजबूत करें अपना OS और ऐप्स अपडेट रखें। सुरक्षा पैच उन्हीं कमजोरियों को बंद करते हैं जिनका स्कैमर्स फायदा उठाते हैं [4]। किसी भी बैंकिंग या भुगतान कार्य के लिए सार्वजनिक Wi-Fi से कभी कनेक्ट न करें। इसके बजाय मोबाइल डेटा या एक विश्वसनीय VPN का उपयोग करें [4]। मासिक रूप से ऐप अनुमतियों की जांच करें। किसी भी ऐप से माइक्रोफोन, कैमरा और संपर्क एक्सेस रद्द करें जिसे वास्तव में इनकी जरूरत नहीं है। Google Play Protect (Android) सक्षम करें या उच्च जोखिम वाली स्थितियों के लिए Lockdown Mode (iPhone) उपलब्ध रखें। मजबूत, अनूठे पासवर्ड और एक प्रतिष्ठित पासवर्ड मैनेजर का उपयोग करें। सभी ईमेल और सोशल खातों पर दो-कारक प्रमाणीकरण (2FA) सक्षम करें [4]। APK साइड-लोड न करें। Android पर \u0026ldquo;अज्ञात ऐप्स इंस्टॉल करें\u0026rdquo; अनुमति अक्षम करें — अधिकांश बैंकिंग ट्रोजन इसी तरह आते हैं [7]। अगर आप पहले से ही स्कैम का शिकार हो चुके हैं तो क्या करें गति ही सब कुछ है। प्रत्येक मिनट जो आप प्रतीक्षा करते हैं, वह धोखेबाजों को पैसे हस्तांतरित करने का अधिक समय देता है।\nतुरंत 1930 पर कॉल करें — भारत की 24×7 राष्ट्रीय साइबर अपराध हेल्पलाइन धन हस्तांतरित होने से पहले प्राप्तकर्ता खाते को फ्रीज कर सकती है [1]। सभी लेनदेन ID, स्क्रीनशॉट और धोखेबाज के नंबर के साथ cybercrime.gov.in पर शिकायत दर्ज करें। अपने बैंक की धोखाधड़ी लाइन पर कॉल करें और तत्काल लेनदेन विवाद की मांग करें। राष्ट्रीय स्तर पर ब्लॉक करवाने के लिए संचार साथी के चक्षु पोर्टल पर फोन नंबर/WhatsApp खाते की रिपोर्ट करें [3]। जो खो गया उसे \u0026ldquo;वापस पाने\u0026rdquo; के लिए और पैसे ट्रांसफर न करें — अक्सर एक दूसरा स्कैमर मदद करने का प्रस्ताव देते हुए सामने आता है। सरकारी साधन जो हर भारतीय को बुकमार्क करने चाहिए भारत ने फोन धोखाधड़ी से लड़ने के लिए कई मुफ्त संसाधन बनाए हैं:\nसंसाधन उद्देश्य लिंक हेल्पलाइन 1930 साइबर धोखाधड़ी की रिपोर्ट करें, खाते फ्रीज करें 1930 पर कॉल करें साइबर अपराध पोर्टल औपचारिक FIR-स्तर की शिकायत दर्ज करें cybercrime.gov.in संचार साथी अपने SIM कार्ड प्रबंधित/ब्लॉक करें sancharsaathi.gov.in चक्षु (संचार साथी) स्पैम कॉल, SMS, WhatsApp धोखाधड़ी की रिपोर्ट करें sancharsaathi.gov.in/sfc साइबर फ्रॉड रिस्क इंडिकेटर RBI + सरकार रियल-टाइम लेनदेन निगरानी स्वचालित (कोई कार्रवाई आवश्यक नहीं) सरकार की I4C पहल ने लॉन्च के बाद से ₹8,031 करोड़ से अधिक की धोखाधड़ी वाली लेनदेन पहले ही ब्लॉक कर दी है [3]। ये सिस्टम काम करते हैं — लेकिन केवल तभी जब आप जल्दी रिपोर्ट करते हैं।\nस्वर्णिम नियम स्कैमर्स तात्कालिकता और डर पर निर्भर करते हैं। जिस क्षण एक कॉल घबराहट पैदा करे — \u0026ldquo;आपका नंबर ब्लॉक हो जाएगा,\u0026rdquo; \u0026ldquo;आप डिजिटल अरेस्ट में हैं,\u0026rdquo; \u0026ldquo;आपका बैंक खाता खतरे में है\u0026rdquo; — यही वह संकेत है जब आपको फोन काट देना चाहिए, सांस लेनी चाहिए, और जिस एजेंसी का नाटक किया जा रहा है उसके आधिकारिक नंबर पर कॉल करके स्वतंत्र रूप से सत्यापित करना चाहिए। कोई भी वैध संस्था आपको दोबारा जांचने के लिए दंडित नहीं करेगी।\nअपने फोन को सुरक्षित करना एक बार का काम नहीं है; यह एक साप्ताहिक आदत है। ऐप अनुमतियों की समीक्षा करने, पासवर्ड अपडेट करने, और अपरिचित SIM पंजीकरण के लिए sancharsaathi.gov.in की जांच करने के लिए मासिक रिमाइंडर सेट करें। स्कैमर्स लगातार हैं — आपकी सतर्कता भी होनी चाहिए।\nस्रोत भारत में डिजिटल धोखाधड़ी 2026: बढ़ते खतरे, सामान्य स्कैम और खुद को कैसे बचाएं भारत में साइबर अपराध 2025: 24% की वृद्धि, ₹22,495 करोड़ का नुकसान डिजिटल इंडिया में साइबर धोखाधड़ी पर रोक — प्रेस सूचना ब्यूरो भारत में 10 सामान्य मोबाइल फोन स्कैम और उनसे कैसे बचें डिजिटल अरेस्ट स्कैम से खुद को बचाएं: एक जरूरी गाइड भारत में eSIM धोखाधड़ी का उदय और आप इसके बारे में क्या कर सकते हैं UPI स्कैम 2026: हैकर्स OTP और नकली ऐप्स का उपयोग करके पैसे कैसे चुराते हैं UPI धोखाधड़ी: अपने खाते को कैसे सुरक्षित करें — पूरी गाइड ","permalink":"https://cloudmato.com/hi/posts/how-to-secure-your-phone-from-scams-india/","title":"भारत में अपने फोन को स्कैम से कैसे सुरक्षित करें (2026)"},{"content":"2026 में सही AI टूल चुनना कौन सा सबसे स्मार्ट है से कम और कौन सा आपके बजट में फिट बैठता है से अधिक संबंधित है। बाजार अब वास्तव में शक्तिशाली मुफ्त टियर से लेकर $300 प्रति माह पावर-यूजर सब्सक्रिप्शन तक फैला हुआ है — और उनके बीच का अंतर पहले से कहीं अधिक है। यहाँ $0 से $300/माह तक रैंक किए गए हर प्रमुख AI टूल की एक निश्चित, बजट-प्राथमिक गाइड है, ताकि आप अनुमान लगाना बंद कर सकें और चुनना शुरू कर सकें।\n2026 में AI मूल्य निर्धारण का परिदृश्य 2026 के AI बाजार की एक परिभाषित विशेषता $20/माह के स्तर पर मूल्य निर्धारण का अभिसरण है [1]। ChatGPT Plus, Claude Pro, Google Gemini AI Pro, Microsoft Copilot Pro, और Perplexity Pro सभी ने स्वतंत्र रूप से अपने मानक भुगतान टियर के लिए लगभग $20/माह पर आकर ठहरे हैं [2]। उस आधार के ऊपर और नीचे, कीमतें नाटकीय रूप से फैल जाती हैं — पूरी तरह से मुफ्त टियर से लेकर प्रति माह सैकड़ों डॉलर खर्च करने वाले एंटरप्राइज़ प्लान तक [3]।\nएक भी पैसा खर्च करने से पहले समझने के लिए तीन व्यापक श्रेणियां:\nसामान्य-उद्देश्य चैटबॉट (ChatGPT, Claude, Gemini, Copilot, Grok) — लेखन, शोध, कोडिंग और दैनिक Q\u0026amp;A के लिए सर्वश्रेष्ठ विशेष लेखन टूल (Jasper, Grammarly, Writesonic, Wordtune) — कंटेंट क्रिएटर और मार्केटर्स के लिए सर्वश्रेष्ठ छवि/मीडिया जेनरेटर (Midjourney) — दृश्य सामग्री निर्माण के लिए सर्वश्रेष्ठ टियर 1: मुफ्त AI टूल्स (आकस्मिक उपयोगकर्ताओं के लिए सर्वश्रेष्ठ) हर प्रमुख AI प्लेटफॉर्म अब एक सार्थक मुफ्त टियर प्रदान करता है — न केवल एक डेमो, बल्कि वास्तव में उपयोग योग्य एक्सेस [4]।\nटूल मुफ्त टियर मॉडल मुख्य सीमाएं ChatGPT GPT-5.3 प्रति 5 घंटे में 10 संदेश [5] Claude Claude 3.x दैनिक संदेश सीमा, कोई Projects नहीं Gemini Gemini 2.x सीमित प्रॉम्प्ट, कोई Advanced सुविधाएं नहीं Copilot GPT-4o आधारित असीमित बेसिक चैट, सीमित दैनिक बूस्ट Perplexity GPT-4o / Claude प्रति दिन सीमित Pro सर्च Grok Grok 3 X.com के माध्यम से, सीमित क्वेरी Meta AI Llama-आधारित मुफ्त, WhatsApp/Instagram में अंतर्निहित सर्वश्रेष्ठ मुफ्त विकल्प: शोध के लिए Perplexity (स्रोत उद्धृत करता है) और लंबे-फॉर्म लेखन के लिए Claude। दोनों अपने $0 मूल्य टैग से कहीं बेहतर प्रदर्शन करते हैं [4]।\nटियर 2: बजट प्लान — $7 से $19/माह $20/माह की प्रतिबद्धता के बिना अधिक वॉल्यूम की आवश्यकता वाले उपयोगकर्ताओं के लिए, कई ठोस विकल्प मौजूद हैं।\nलेखन और व्याकरण टूल्स Wordtune — $6.99/माह; मजबूत टोनल नियंत्रण के साथ वाक्यों को फिर से लिखता और पैराफ्रेज़ करता है [7] Grammarly Premium — $12/माह; लेखन गुणवत्ता जांच, टोन समायोजन, और 1,000 AI प्रॉम्प्ट प्रति माह [7] Writesonic — 200K शब्दों के लिए $12.67/माह से; असीमित शब्दों के लिए $16/माह, मजबूत SEO सुविधाएं [7] चैटबॉट अपग्रेड ChatGPT Go — $8/माह; मुफ्त से अधिक संदेश वॉल्यूम, लेकिन GPT-5.5 और Sora का अभाव [5] SuperGrok Lite — $10/माह; मार्च 2026 में लॉन्च, DeepSearch के साथ Grok में प्रवेश-स्तर की एक्सेस [8] Midjourney Basic — $10/माह; प्रति माह 200 फास्ट GPU छवि जेनरेशन [6] सर्वश्रेष्ठ बजट विकल्प: लेखकों के लिए $12/माह पर Grammarly Premium; उच्च-वॉल्यूम आउटपुट की जरूरत वाले कंटेंट मार्केटर्स के लिए $16/माह पर Writesonic Unlimited।\nटियर 3: मानक प्लान — $20 से $40/माह (सर्वोत्तम विकल्प) यहीं से अधिकांश उपयोगकर्ताओं को शुरू करना चाहिए। पांच सबसे बड़े AI प्लेटफॉर्म $20/माह पर एक साथ हैं, जो आपको एक ही कीमत पर मजबूत फीचर समानता देते हैं [2]।\nटूल कीमत सर्वश्रेष्ठ उपयोग विशेष सुविधा ChatGPT Plus $20/माह सर्वांगीण उपयोग GPT-5.5, Sora, Codex, Deep Research (10 रन) [5] Claude Pro $20/माह लेखन और कोडिंग सबसे लंबी कॉन्टेक्स्ट विंडो, बेहतरीन गद्य गुणवत्ता [3] Gemini AI Pro $19.99/माह Google Workspace उपयोगकर्ता Gmail, Docs, Drive के साथ एकीकृत [4] Copilot Pro $20/माह Microsoft 365 उपयोगकर्ता Word, Excel, Outlook, Teams में अंतर्निहित [2] Perplexity Pro $20/माह शोध और तथ्य-जांच रियल-टाइम वेब उद्धरण, मल्टी-मॉडल चयन [9] Grok SuperGrok $30/माह X उपयोगकर्ता, रियल-टाइम समाचार DeepSearch, Big Brain Mode, 128K कॉन्टेक्स्ट [8] Midjourney Standard $30/माह छवि जेनरेशन 15 फास्ट GPU घंटे + असीमित Relax मोड छवियां [6] $20 टियर में चुनाव ChatGPT Plus चुनें अगर आप सबसे व्यापक फीचर सेट और OpenAI के टूल्स इकोसिस्टम तक एक्सेस चाहते हैं [5] Claude Pro चुनें अगर लेखन गुणवत्ता, सूक्ष्मता और लंबे दस्तावेज़ आपकी प्राथमिकता हैं [3] Gemini AI Pro चुनें अगर आप पहले से Google Workspace में हैं — केवल एकीकरण ही लागत को उचित ठहराता है [4] Copilot Pro चुनें अगर आपका वर्कफ़्लो Microsoft 365 पर चलता है [2] Perplexity Pro चुनें अगर आप भारी शोध करते हैं और मनगढ़ंत तथ्यों से नफरत करते हैं [9] टियर 4: प्रो प्लान — $49 से $125/माह पावर यूजर और पेशेवर जिन्होंने मानक प्लान का अधिकतम उपयोग कर लिया है, वे यहाँ आते हैं [3]।\nविशेष लेखन प्लेटफॉर्म Jasper Creator — $49/माह; 50,000 शब्द/माह, ब्रांड वॉयस, एक यूजर सीट [10] Jasper Teams — $125/माह; असीमित शब्द, तीन यूजर सीट, सहयोग सुविधाएं [10] AI चैटबॉट पावर टियर ChatGPT Pro ($100/माह) — 9 अप्रैल 2026 को लॉन्च; 5× Plus उपयोग सीमाएं, GPT-5.5 Pro, पूर्ण Codex एक्सेस, डेवलपर्स के लिए आदर्श [5] Claude Max ($100/माह) — Anthropic का मिड-टियर Max प्लान; प्राथमिकता कतार के साथ 5× Claude Pro उपयोग [3] Google Gemini AI Ultra ($100/माह) — Google I/O 2026 के बाद पुनर्मूल्यांकन; Gemini 3.1 Ultra, Google One 2TB स्टोरेज, और YouTube Premium शामिल है [4] छवि जेनरेशन Midjourney Pro — $60/माह; 30 फास्ट GPU घंटे, स्टेल्थ मोड, 12 समवर्ती जॉब्स [6] सर्वश्रेष्ठ प्रो विकल्प: डेवलपर्स और पावर यूजर के लिए $100/माह पर ChatGPT Pro, या Claude Max अगर लेखन गुणवत्ता सबसे अधिक मायने रखती है [3][5]।\nटियर 5: अल्ट्रा और एंटरप्राइज़ प्लान — $120 से $300/माह ये प्लान मांग वाले वर्कलोड, टीमों, या विशिष्ट आवश्यकताओं वाले पेशेवरों के लिए हैं [8]।\nMidjourney Mega — $120/माह; 60 फास्ट GPU घंटे, अधिकतम समवर्ती जेनरेशन, प्राथमिकता कतार [6] ChatGPT Pro (पूर्ण) — $200/माह; सभी मॉडल तक वास्तव में असीमित एक्सेस, असीमित Sora वीडियो, शोध पूर्वावलोकन [5] Claude Max ($200 टियर) — $100 टियर से अधिक उपयोग सीमा; बड़े पैमाने पर सामग्री या कोड जेनरेशन करने वाली टीमों के लिए [3] Google Gemini AI Ultra — $249.99/माह (मूल मूल्य, पहले 3 महीनों के लिए $124.99 तक छूट); उच्चतम Gemini दर सीमाएं [4] Grok SuperGrok Heavy — $300/माह; अब तक जारी किया गया सबसे महंगा मुख्यधारा उपभोक्ता AI प्लान; Grok 4 Heavy एक्सेस, 256K कॉन्टेक्स्ट विंडो, और सभी सुविधाओं में अधिकतम दर सीमाएं प्रदान करता है [8] ईमानदार सलाह: जब तक आप AI आउटपुट के कारण पैसा नहीं कमा रहे एक पेशेवर हैं, $200–$300/माह टियर शायद ही कभी अपना औचित्य साबित करती है। OpenAI या Anthropic के $100/माह Pro टियर आधी कीमत पर 80–90% क्षमता प्रदान करते हैं [2]।\nत्वरित संदर्भ मूल्य तालिका: सभी टूल्स कीमत के अनुसार रैंक किए गए कीमत टूल प्लान का नाम $0 ChatGPT, Claude, Gemini, Copilot, Perplexity, Grok, Meta AI मुफ्त $6.99 Wordtune Starter $8 ChatGPT Go $10 SuperGrok, Midjourney Lite / Basic $12 Grammarly Premium $13–$16 Writesonic Individual / Unlimited $19.99 Google Gemini AI Pro $20 ChatGPT, Claude, Copilot, Perplexity Plus / Pro $30 Grok SuperGrok, Midjourney SuperGrok / Standard $40 X Premium+ के माध्यम से Grok X Premium+ $49 Jasper Creator $60 Midjourney Pro $100 ChatGPT, Claude, Gemini Pro / Max / Ultra $120 Midjourney Mega $125 Jasper Teams $200 ChatGPT, Claude Pro / Max $249.99 Google Gemini AI Ultra $300 Grok SuperGrok Heavy आपको कौन सा AI टूल चुनना चाहिए? \u0026ldquo;सर्वश्रेष्ठ\u0026rdquo; AI टूल वह है जो आपकी विशिष्ट समस्या को उस कीमत पर हल करे जिसका आपको पछतावा नहीं होगा। यहाँ त्वरित निर्णय गाइड है:\nबजट $0 है: Perplexity (शोध) या Claude (लेखन) से शुरू करें बजट ~$10–$16/माह है: चैट के लिए ChatGPT Go, लेखन गुणवत्ता के लिए Grammarly बजट ~$20/माह है: बहुमुखी प्रतिभा के लिए ChatGPT Plus; लेखन के लिए Claude Pro; Google उपयोगकर्ताओं के लिए Gemini AI Pro बजट ~$30/माह है: छवियों के लिए Midjourney Standard जोड़ें, या Grok SuperGrok अगर आपको रियल-टाइम X डेटा चाहिए बजट ~$100/माह है: भारी पेशेवर वर्कलोड के लिए ChatGPT Pro या Claude Max बजट $200+/माह है: इसे तभी विचार करें जब AI सीधे आपके लिए राजस्व उत्पन्न करे [2][3] 2026 में कोई एक टूल हर श्रेणी में हावी नहीं है — बाजार विशेषज्ञता में परिपक्व हो गया है [4]। सबसे समझदार रणनीति है मुफ्त से शुरू करना, उपयोग के मामले को सत्यापित करना, फिर एक-एक करके मूल्य निर्धारण टियर में आगे बढ़ना।\nस्रोत AI मूल्य निर्धारण तुलना: ChatGPT, Claude, Gemini, Copilot और अधिक के हर प्लान (2026) — AIViewer.ai AI मूल्य निर्धारण तुलना 2026: ChatGPT बनाम Claude बनाम Gemini — AIonX AI मूल्य निर्धारण तुलना 2026: ChatGPT बनाम Claude बनाम Perplexity बनाम Gemini — FindSkill.ai 2026 में सर्वश्रेष्ठ AI चैटबॉट सेवाएं तुलना: मूल्य निर्धारण, सुविधाएं और प्रदर्शन — TechTimes ChatGPT प्लान — OpenAI का आधिकारिक मूल्य निर्धारण पृष्ठ Midjourney मूल्य निर्धारण 2026: प्लान, लागत और Reddit का निर्णय — AI Tool Discovery AI टूल्स मूल्य निर्धारण तुलना 2026: हर प्लान, मूल्य के अनुसार रैंक किया गया — ComputerTech Grok मूल्य निर्धारण 2026: SuperGrok, X Premium+, Heavy और API लागत — FelloAI ChatGPT प्लान तुलना: मुफ्त बनाम Plus बनाम Pro बनाम Business बनाम Enterprise (2026) — IntuitionLabs Jasper मूल्य निर्धारण 2026 — G2 ","permalink":"https://cloudmato.com/hi/posts/best-ai-tools-2026-price-comparison/","title":"2026 के सर्वश्रेष्ठ AI टूल्स: हर प्लान कीमत के अनुसार रैंक किया गया"},{"content":"iPhone बनाम Android की बहस टेक जगत की सबसे पुरानी प्रतिस्पर्धाओं में से एक है — और 2026 में भी यह वास्तव में प्रतिस्पर्धी बनी हुई है। फिर भी, अपडेट की अवधि और कैमरा हार्डवेयर में Android के नाटकीय सुधार के बावजूद, iPhone कई महत्वपूर्ण पहलुओं में सार्थक और मापनीय बढ़त बनाए हुए है। चाहे आप पहली बार खरीदार हों या बदलाव पर विचार कर रहे हों, यहाँ छह ऐसे क्षेत्र हैं जहाँ iPhone लगातार आगे रहता है।\nसुरक्षा और प्राइवेसी: iPhone की सबसे स्थायी बढ़त जब आपके डेटा की सुरक्षा की बात आती है, तो iPhone एक संरचनात्मक बढ़त रखता है जो मार्केटिंग से परे है। Apple का App Tracking Transparency (ATT) फ्रेमवर्क, जो iOS 14.5 में पेश किया गया था और तब से बेहतर होता रहा है, डिफ़ॉल्ट रूप से थर्ड-पार्टी ऐड ट्रैकर्स को ब्लॉक करता है — Android उपयोगकर्ताओं को इसी तरह की सुरक्षा मैन्युअल रूप से कॉन्फ़िगर करनी पड़ती है [1]। 2025 की Privacy International रिपोर्ट ने iOS को स्टॉक Android से पंद्रह में से बारह प्राइवेसी मानदंडों पर आगे रखा, यह नोट करते हुए कि हालांकि 2020 के बाद से यह अंतर कम हुआ है, यह डिफ़ॉल्ट सेटिंग्स, डेटा रिटेंशन नीतियों और क्रॉस-सर्विस डेटा शेयरिंग पर बना हुआ है [2]।\nसुरक्षा के मोर्चे पर, आर्किटेक्चर मूलभूत रूप से भिन्न है:\niOS पैच सभी समर्थित iPhones पर एक साथ जारी होते हैं, जैसे ही कोई कमज़ोरी खोजी जाती है [3] Android पैच को पहले डिवाइस निर्माताओं और कैरियर्स से गुज़रना पड़ता है, जिससे नॉन-Pixel डिवाइसों के लिए हफ्तों या महीनों की भेद्यता बनती है [3] Apple का App Store कड़ी मैन्युअल समीक्षा प्रक्रिया लागू करता है, जिससे उपयोगकर्ताओं तक मैलवेयर पहुँचने का जोखिम काफी कम हो जाता है [4] Face ID, Secure Enclave हार्डवेयर, और एंड-टू-एंड iMessage एन्क्रिप्शन जैसी सुविधाएँ हर iPhone में बनी हुई हैं [1] Google की Pixel सीरीज़ ने अपने Titan M2 चिप और सक्रिय स्कैम-कॉल फ़िल्टरिंग के साथ सुरक्षा अंतर को काफी कम कर दिया है [2], लेकिन iPhone की प्राइवेसी डिफ़ॉल्ट उन उपयोगकर्ताओं के लिए सोने का मानक बनी हुई है जो अपने फ़ोन को sysadmin की तरह कॉन्फ़िगर नहीं करना चाहते।\nसॉफ़्टवेयर अपडेट जो वास्तव में आप तक पहुँचते हैं वर्षों से, Android की खंडित अपडेट डिलीवरी इसकी कमज़ोर कड़ी थी। हालांकि चीज़ें बेहतर हुई हैं — Google Pixel 9 और Samsung Galaxy S25 दोनों अब OS और सुरक्षा अपडेट के सात साल का वादा करते हैं [5] — iPhone का अपडेट मॉडल अभी भी प्रमुख व्यावहारिक फायदे रखता है।\nApple iOS अपडेट रिलीज़ के 24 घंटे के भीतर सभी समर्थित डिवाइसों तक पहुँचाता है, चाहे कैरियर, क्षेत्र या निर्माता कोई भी हो [6]। कोई बिचौलिया नहीं है। 2019 में खरीदा गया iPhone जो iOS 18 चला रहा है, उसी दिन वही सुरक्षा पैच प्राप्त करता है जो iPhone 16 Pro को मिलता है [1]।\nप्लेटफ़ॉर्म अपडेट वर्ष (फ्लैगशिप) एक साथ रोलआउट? बजट डिवाइस समर्थन Apple iPhone 6–7 साल ✅ हाँ ✅ हाँ (समान शेड्यूल) Google Pixel 7 साल ✅ हाँ ❌ सीमित Samsung Galaxy 7 साल (S-सीरीज़) ❌ क्रमिक ❌ 2–3 साल अन्य Android OEMs 1–3 साल ❌ क्रमिक ❌ 1–2 साल व्यावहारिक निहितार्थ: आज खरीदा गया एक मिड-रेंज iPhone उसी मूल्य बिंदु पर अपने Android समकक्ष की तुलना में वर्षों अधिक सुरक्षित और फीचर-करंट रहेगा [5]।\nApple इकोसिस्टम: एक नेटवर्क प्रभाव जो कोई Android ब्रांड नहीं दे सकता Apple की सबसे बड़ी दीर्घकालिक बढ़त कोई एकल डिवाइस नहीं है — यह अपने सभी हार्डवेयर में निर्बाध एकीकरण है। iPhone, iPad, Mac, Apple Watch, AirPods, और HomePod सभी ऐसी सुविधाओं के माध्यम से आसानी से संवाद करते हैं जो बस काम करती हैं [6]:\nAirDrop: किसी भी नज़दीकी Apple डिवाइस में तत्काल, एन्क्रिप्टेड फ़ाइल ट्रांसफर — कोई ऐप या अकाउंट आवश्यक नहीं Handoff: iPhone पर कोई दस्तावेज़, ईमेल या कॉल शुरू करें और बिना किसी रुकावट के Mac पर जारी रखें Universal Clipboard: अपने iPhone पर टेक्स्ट कॉपी करें, MacBook पर पेस्ट करें Continuity Camera: अपने iPhone को वायरलेस तरीके से उच्च-गुणवत्ता वाले Mac वेबकैम के रूप में उपयोग करें iMessage / FaceTime: एंड-टू-एंड एन्क्रिप्टेड मैसेजिंग और वीडियो कॉल जो सभी Apple डिवाइसों पर नेटिव रूप से काम करते हैं Samsung ने Galaxy डिवाइसों के साथ एक विश्वसनीय इकोसिस्टम बनाया है, लेकिन यह अन्य Android ब्रांड्स तक नहीं फैलता [6]। यदि आपके पास OnePlus फ़ोन और Lenovo लैपटॉप है, तो आपको इनमें से कोई भी एकीकरण नहीं मिलेगा। Apple का इकोसिस्टम काम करता है क्योंकि Apple हार्डवेयर और सॉफ़्टवेयर दोनों स्टैक को नियंत्रित करता है — एक बाधा जो iPhone के अधिकांश अन्य फायदों को भी समझाती है।\nबेहतर रीसेल वैल्यू: iPhones अपनी कीमत बनाए रखते हैं यदि स्वामित्व की कुल लागत आपके लिए महत्वपूर्ण है, तो iPhone की रीसेल वैल्यू का फायदा उल्लेखनीय है। औसतन, iPhones उपयोग के दो पूर्ण वर्षों के बाद अपने मूल मूल्य का 60–70% बनाए रखते हैं [7]। लंबे समय के दौरान तस्वीर तेज़ी से बदलती है:\nचार साल के बाद, iPhones अभी भी मूल मूल्य का लगभग 52.5% बनाए रखते हैं [7] फ्लैगशिप Android फ़ोन उसी अवधि में लगभग 21.1% तक गिर जाते हैं [7] बजट Android फ़ोन केवल 12.2% तक बनाए रखते हैं [7] iPhone 15 और 16 Pro मॉडल स्वामित्व के केवल एक वर्ष के बाद 70% से अधिक मूल्य बनाए रखने के लिए दिखाए गए हैं [8]। इसका मतलब है कि जब आप ट्रेड-इन या रीसेल पर वापस मिलने वाली राशि को ध्यान में रखते हैं, तो प्रीमियम iPhone और प्रीमियम Android डिवाइस के बीच वास्तविक लागत का अंतर स्टिकर मूल्य से काफी कम है।\nस्थिर प्रदर्शन और श्रेणी-अग्रणी वीडियो Apple iPhone की चिप और उसके ऑपरेटिंग सिस्टम दोनों को डिज़ाइन करता है, जो वर्टिकल इंटीग्रेशन का एक ऐसा स्तर है जिसे कोई भी Android OEM पूरी तरह दोहरा नहीं सकता। इसका परिणाम वह प्रदर्शन है जो वर्षों के उपयोग में भी सुचारू रहता है। 2026 बेंचमार्क परीक्षण में, iPhone 17 Pixel 10 पर 80.58 FPS की तुलना में औसत गेमिंग फ्रेम रेट 130.97 FPS प्राप्त करता है [1] — एक अंतर जो मोबाइल CPU और GPU आर्किटेक्चर में Apple Silicon की बढ़त को दर्शाता है।\nविशेष रूप से वीडियो क्रिएटर्स के लिए, iPhone Pro मॉडल उद्योग का मानक बने हुए हैं [9]:\nProRes रिकॉर्डिंग पेशेवर पोस्ट-प्रोडक्शन वर्कफ़्लो के लिए Log वीडियो कैप्चर सिनेमा-ग्रेड सॉफ़्टवेयर में लचीले कलर ग्रेडिंग के लिए Cinematic मोड स्वचालित रैक-फोकस शैलो डेप्थ-ऑफ-फील्ड वीडियो के लिए Action मोड बाहरी जिम्बल के बिना भारी स्थिर फुटेज के लिए iPhone Pro पर शूट किए गए ProRes फुटेज नियमित रूप से व्यावसायिक प्रोडक्शन और शॉर्ट फिल्मों में दिखते हैं [9] — एक रचनात्मक प्रमाण-पत्र जिसका कोई भी वर्तमान Android डिवाइस बड़े पैमाने पर दावा नहीं कर सकता।\nApp Store गुणवत्ता और डेवलपर प्राथमिकता डेवलपर नए ऐप्स और फीचर लॉन्च करते समय लगातार iOS को प्राथमिकता देते हैं [4]। कारण आंशिक रूप से आर्थिक हैं (iOS उपयोगकर्ता ऐप्स में अधिक खर्च करते हैं) और आंशिक रूप से तार्किक — Apple का एकीकृत हार्डवेयर Android के व्यापक डिवाइस विखंडन की तुलना में किसी ऐप को परीक्षण और अनुकूलित करना बहुत आसान बनाता है [4]।\nउपयोगकर्ताओं के लिए व्यावहारिक परिणाम:\nनए ऐप्स आमतौर पर पहले iOS पर लॉन्च होते हैं, अक्सर Android संस्करणों के आने से महीनों पहले Apple की कड़ी App Store समीक्षा प्रक्रिया उपयोगकर्ताओं तक पहुँचने से पहले निम्न-गुणवत्ता, असुरक्षित या भ्रामक ऐप्स को फ़िल्टर कर देती है [4] Apple का TestFlight बीटा प्लेटफ़ॉर्म उपयोगकर्ताओं को एक नियंत्रित वातावरण में पॉलिश्ड प्री-रिलीज़ सॉफ़्टवेयर तक जल्दी पहुँच देता है Xcode और SwiftUI जैसे टूल डेवलपर्स को एक तंग रूप से एकीकृत, सुसंगत विकास वातावरण देते हैं जो हर iPhone स्क्रीन आकार और सेंसर से साफ़ तरीके से मैप होता है [4] यह डेवलपर-फर्स्ट गतिशीलता का मतलब है कि iPhone उपयोगकर्ताओं को लगातार जल्दी उच्च-गुणवत्ता, अधिक स्थिर ऐप अनुभव मिलते हैं।\nनिष्कर्ष 2026 में Android वास्तव में उत्कृष्ट है — विशेष रूप से Pixel और Samsung Galaxy फ्लैगशिप। लेकिन प्राइवेसी डिफ़ॉल्ट, एक साथ सॉफ़्टवेयर अपडेट, इकोसिस्टम एकजुटता, रीसेल वैल्यू, स्थायी प्रदर्शन और डेवलपर माइंडशेयर में iPhone के फायदे मापनीय हैं, न कि केवल मार्केटिंग। उन उपयोगकर्ताओं के लिए जो एक ऐसा डिवाइस चाहते हैं जो अन्य Apple हार्डवेयर के साथ गहराई से काम करे, मैन्युअल कॉन्फ़िगरेशन के बिना सुरक्षित रहे, और समय के साथ अपना मूल्य बनाए रखे, iPhone एक मजबूत दीर्घकालिक निवेश बना हुआ है।\nस्रोत iPhone बनाम Android 2026: प्राइवेसी, प्रदर्शन और लागत 2026 में iPhone बनाम Android प्राइवेसी और सुरक्षा — Secrets of Privacy Android बनाम iOS: सुरक्षा तुलना 2026 — NordVPN Android बनाम iOS ऐप डेवलपमेंट: 2026 में कौन बेहतर है? — Shakuro 2026 में Android बनाम iOS सुरक्षा: क्या iPhone अभी भी सुरक्षित है? — MacObserver 2026 में Android बनाम iPhone इकोसिस्टम की तुलना — Swapper 2026 रीसेल वैल्यू रिपोर्ट: कौन से स्मार्टफ़ोन अपना मूल्य सबसे अच्छे से बनाए रखते हैं? — iGenius Phone Repair 2026 में कौन से सेलफ़ोन सबसे लंबे समय तक रीसेल वैल्यू बनाए रखते हैं? — ecoATM 2026 में iPhone Android से बेहतर क्यों है — 73inc ","permalink":"https://cloudmato.com/hi/posts/iphone-advantages-over-android/","title":"iPhone बनाम Android: iPhone चुनने के 6 प्रमुख फायदे"},{"content":"आप एक डेवलपर हैं जो लोकल सर्वर टेस्ट कर रहे हैं, या किसी इंटरनल कॉर्पोरेट टूल तक पहुँचने की कोशिश कर रहे हैं, और Chrome लाल रंग की \u0026ldquo;Your connection is not private\u0026rdquo; स्क्रीन दिखाकर दरवाज़ा बंद कर देता है। ब्राउज़र में एक छुपा हुआ रास्ता है: thisisunsafe टाइप करें। यह लेख बताता है कि यह ट्रिक वास्तव में क्या करती है, यह कहाँ से आई, इसे कब इस्तेमाल करना उचित है — और कब यह आपको गंभीर नुकसान पहुँचा सकती है।\n\u0026ldquo;thisisunsafe\u0026rdquo; क्या है? thisisunsafe Chromium-आधारित ब्राउज़रों — जिनमें Google Chrome और Microsoft Edge शामिल हैं — में बना एक गुप्त कीबोर्ड पासफ्रेज़ है, जो आपको SSL/TLS सर्टिफिकेट एरर पेज को ओवरराइड करने देता है [1]। जब Chrome किसी साइट को अमान्य, एक्सपायर्ड, या सेल्फ-साइन्ड सर्टिफिकेट की वजह से ब्लॉक करता है और NET::ERR_CERT_INVALID या NET::ERR_CERT_AUTHORITY_INVALID जैसी एरर दिखाता है, तो thisisunsafe टाइप करने पर (ब्राउज़र विंडो फोकस में होने पर, किसी टेक्स्ट फील्ड की जरूरत नहीं) चेतावनी तुरंत गायब हो जाती है और पेज लोड हो जाता है [2]।\nयह जादू अदृश्य है: कोई ऑन-स्क्रीन टेक्स्ट बॉक्स नहीं, कोई प्रॉम्प्ट नहीं। Chrome पृष्ठभूमि में सटीक कीप्रेस अनुक्रम को सुनता है। एक बार जब आप वाक्यांश पूरा कर लेते हैं, तो ब्लॉक हट जाता है और पेज लोड हो जाता है — हालाँकि एड्रेस बार में \u0026ldquo;Not Secure\u0026rdquo; इंडिकेटर एक स्थायी अनुस्मारक के रूप में दिखता रहता है [3]।\nमहत्वपूर्ण बात यह है कि यह बायपास डोमेन-स्कोप्ड और सेशन-सीमित है। https://dev.internal के लिए टाइप करने पर केवल उसी डोमेन को छूट मिलती है; किसी अन्य सर्टिफिकेट-एरर साइट के लिए दोबारा वाक्यांश दर्ज करना होगा [3]। यह कोई वैश्विक टॉगल नहीं है।\nChrome के SSL बायपास फ्रेज़ का बदलता इतिहास यह एस्केप हैच सालों से चुपचाप मौजूद है, लेकिन Chrome की टीम ने समय-समय पर कीवर्ड बदलकर इसे आकस्मिक रूप से खोजना जानबूझकर कठिन बना दिया है [4]:\ndanger — जब यह सुविधा पहली बार पेश की गई थी तब का मूल पासफ्रेज़। badidea — दिसंबर 2015 में danger की जगह आया, जब मूल वाक्यांश ऑनलाइन व्यापक रूप से फैल गया और एक आकस्मिक उपाय के रूप में दुरुपयोग किया जाने लगा [5]। thisisunsafe — वर्तमान वाक्यांश, जब badidea खुद बहुत प्रसिद्ध हो गया तब इसे लाया गया। आंतरिक रूप से Chrome इसे अपने Base64 प्रतिनिधित्व (dGhpc2lzdW5zYWZl) के रूप में संग्रहीत करता है ताकि इसे आकस्मिक खोज से छुपाया जा सके [4]। यह पैटर्न जानबूझकर है। Chrome के सोर्स कोड में टिप्पणियाँ स्पष्ट रूप से कहती हैं कि \u0026ldquo;HTTPS एरर गंभीर हैं और इन्हें नज़रअंदाज़ नहीं किया जाना चाहिए\u0026rdquo; [2]। हर नाम परिवर्तन Chrome का तरीका है यह सुनिश्चित करने का कि केवल वे उपयोगकर्ता जो वास्तव में बायपास की खोज करते हैं — न कि आम रोज़मर्रा के उपयोगकर्ता — ही इसे सक्रिय कर सकें।\nइसे कैसे उपयोग करें (चरण दर चरण) उस साइट पर जाएँ जो Chrome सर्टिफिकेट एरर पेज दिखा रही है। सुनिश्चित करें कि ब्राउज़र विंडो फोकस में है (पेज पर कहीं भी क्लिक करें, एड्रेस बार में नहीं)। thisisunsafe टाइप करें — सब लोअरकेस, कोई स्पेस नहीं, Enter की जरूरत नहीं। पेज अपने आप रीलोड हो जाएगा और चेतावनी को पार कर साइट लोड कर देगा [1]। Microsoft Edge (जो Chromium-आधारित भी है) पर भी यही पासफ्रेज़ बिल्कुल उसी तरह काम करता है [3]।\nडेवलपर्स के लिए वैध उपयोग के मामले यह बायपास विशिष्ट, नियंत्रित परिस्थितियों में एक वास्तविक उत्पादकता उपकरण है [6]:\nलोकल डेवलपमेंट सर्वर: https://localhost या https://192.168.x.x पर सेल्फ-साइन्ड सर्टिफिकेट Chrome की चेतावनी को ट्रिगर करेगा, भले ही आप सर्वर के मालिक हों। thisisunsafe आपको इसे जल्दी से पार करने देता है [2]। इंटरनल कॉर्पोरेट टूल: एंटरप्राइज़ इंट्रानेट कभी-कभी ऐसे प्राइवेट CA-साइन्ड सर्टिफिकेट पर चलते हैं जो Chrome के रूट स्टोर द्वारा विश्वसनीय नहीं होते। इन टूल्स तक पहुँचने वाले डेवलपर और सिसएडमिन हर मशीन को रीकॉन्फिगर करने की बजाय बायपास का उपयोग कर सकते हैं [3]। सुरक्षा अनुसंधान और प्रॉक्सी टूल: Burp Suite या OWASP ZAP जैसे टूल लोकल प्रॉक्सी के माध्यम से HTTPS ट्रैफिक को इंटरसेप्ट करते हैं, जिससे पेनेट्रेशन टेस्टिंग सेशन के दौरान बायपास की आवश्यकता वाली सर्टिफिकेट चेतावनियाँ उत्पन्न होती हैं [6]। स्टेटिक सूचनात्मक साइटें: एक रीड-ओनली, इनपुट-मुक्त पेज ब्राउज़ करना जहाँ कोई क्रेडेंशियल या व्यक्तिगत डेटा प्रसारित नहीं होता, उसका जोखिम प्रोफाइल बहुत कम होता है [3]। विशेष रूप से localhost पर काम करने वाले डेवलपर्स के लिए, एक बेहतर स्थायी समाधान मौजूद है: chrome://flags/ पर जाएँ, \u0026ldquo;Allow invalid certificates for resources loaded from localhost\u0026rdquo; सक्षम करें, और ब्राउज़र को फिर से लॉन्च करें [6]। इससे मैन्युअल बायपास की आवश्यकता पूरी तरह समाप्त हो जाती है।\nवास्तविक सुरक्षा जोखिम जिन्हें आप नज़रअंदाज़ नहीं कर सकते thisisunsafe बायपास ठीक इसीलिए मौजूद है क्योंकि SSL/TLS सर्टिफिकेट चेतावनियाँ मैन-इन-द-मिडल (MitM) हमलों से बचाती हैं — ऐसी स्थितियाँ जहाँ एक ही नेटवर्क पर हमलावर आपके कनेक्शन को इंटरसेप्ट करता है, सर्वर का रूप धारण करता है, और ट्रांसमिट हो रहे सभी डेटा को चुपचाप पढ़ता या बदलता है [7]। चेतावनी को बायपास करने से अंतर्निहित सर्टिफिकेट समस्या दूर नहीं होती; यह केवल Chrome को आगे बढ़ने का निर्देश देता है।\nअविश्वसनीय नेटवर्क पर बायपास करते समय ठोस जोखिम:\nक्रेडेंशियल चोरी: अविश्वसनीय कनेक्शन पर प्रसारित लॉगिन क्रेडेंशियल और सेशन कुकीज़ को हमलावर प्लेनटेक्स्ट में कैप्चर कर सकता है [3]। मैलवेयर इंजेक्शन: एक समझौता किया हुआ मध्यस्थ पेज सामग्री को संशोधित करके एक वैध डोमेन प्रतीत होने वाली जगह से दुर्भावनापूर्ण स्क्रिप्ट परोस सकता है [3]। अज्ञात इंटरसेप्शन: सेल्फ-साइन्ड सर्टिफिकेट कोई बाहरी CA सत्यापन प्रदान नहीं करते, जिससे वैध सर्वर और नकली सर्वर के बीच अंतर करना असंभव हो जाता है [7]। सुरक्षा फर्म EMA के शोध में पाया गया कि व्यापक इंटरनेट पर लगभग 80% TLS सर्टिफिकेट में कॉन्फिगरेशन कमज़ोरियाँ हैं जो उन्हें MitM वैक्टर के संपर्क में ला सकती हैं [8] — एक चेतावनीपूर्ण अनुस्मारक कि सर्टिफिकेट चेतावनियाँ झूठे अलार्म नहीं हैं जिन्हें लापरवाही से नज़रअंदाज़ किया जाए।\nजैसे-जैसे thisisunsafe की सार्वजनिक जागरूकता बढ़ी है, सुरक्षा शोधकर्ताओं ने सोशल इंजीनियरिंग जोखिम को भी चिह्नित किया है: एक दुर्भावनापूर्ण व्यक्ति किसी गैर-तकनीकी उपयोगकर्ता को यह वाक्यांश टाइप करने का निर्देश दे सकता है, जो मूल रूप से एक सुरक्षात्मक बाधा को ट्रोजन दरवाज़े में बदल देता है [3]।\n\u0026ldquo;thisisunsafe\u0026rdquo; के सुरक्षित विकल्प यदि आप नियमित रूप से thisisunsafe का सहारा लेते हैं, तो यह एक संकेत है कि अंतर्निहित सर्टिफिकेट समस्या को ठीक से हल किया जाना चाहिए:\nलोकल डेव के लिए एक विश्वसनीय CA इंस्टॉल करें: mkcert जैसे टूल सेकंडों में लोकल-ट्रस्टेड डेवलपमेंट सर्टिफिकेट बनाते हैं, जो चेतावनी को पूरी तरह समाप्त कर देते हैं। Let\u0026rsquo;s Encrypt का उपयोग करें: पब्लिक-फेसिंग साइटों के लिए मुफ्त, व्यापक रूप से विश्वसनीय सर्टिफिकेट, सेल्फ-साइन्ड सर्टिफिकेट की आवश्यकता को समाप्त करते हैं [2]। localhost के लिए Chrome flags: chrome://flags/#allow-insecure-localhost फ्लैग डेवलपर्स के लिए विशेष रूप से बनाया गया है और वैश्विक बायपास से अधिक सुरक्षित है [6]। सर्टिफिकेट ठीक करें: यदि चेतावनी आपके द्वारा प्रबंधित प्रोडक्शन साइट पर दिखती है, तो एक एक्सपायर्ड या गलत तरीके से कॉन्फिगर किया गया सर्टिफिकेट एक गंभीर समस्या है जिसे तुरंत हल किया जाना चाहिए — बायपास नहीं किया जाना चाहिए [9]। सार यह है: thisisunsafe डेवलपर वर्कफ्लो के एक सीमित समूह के लिए एक तेज़ उपकरण है। उस नियंत्रित संदर्भ के बाहर, यह एक ऐसे अलार्म को बंद करता है जो बहुत अच्छे कारण से मौजूद है।\nस्रोत thisisunsafe – Bypassing Chrome Security Warnings thisisunsafe – How to Bypass Chrome\u0026rsquo;s ERR_CERT_INVALID Warning The Hidden thisisunsafe Bypass: Unlocking Chrome \u0026amp; Edge\u0026rsquo;s Secret SSL Override Chrome\u0026rsquo;s SSL Bypass Cheatcode Bypassing HSTS or HPKP in Chrome Is a badidea Chrome: Bypass NET::ERR_CERT_INVALID for Development How SSL Certificates Help Prevent Man-in-the-Middle Attacks EMA Report Finds Nearly 80% of SSL/TLS Certificates Are Vulnerable to MitM Attacks Chrome Certificate/HSTS Error Bypass Mechanism: In-depth Analysis of \u0026rsquo;thisisunsafe\u0026rsquo; ","permalink":"https://cloudmato.com/hi/posts/thisisunsafe-chrome-ssl-bypass-explained/","title":"thisisunsafe: Chrome का गुप्त SSL बायपास समझाया गया"},{"content":"React फ्रंटएंड इकोसिस्टम में प्रमुख UI लाइब्रेरी बनी हुई है, और स्टार्टअप से लेकर FAANG कंपनियों तक के इंटरव्यूअर React-specific प्रश्नों से ज्ञान की गहराई मापते हैं [1]। यह गाइड सबसे अधिक पूछे जाने वाले प्रश्नों को कठिनाई के क्रम में प्रस्तुत करती है — बुनियादी प्रश्नों से लेकर विशेषज्ञ स्तर के आर्किटेक्चर और React 19 की आंतरिक कार्यप्रणाली तक — ताकि आप किसी भी फ्रंटएंड इंटरव्यू के लिए पूरी तरह तैयार हो सकें।\nशुरुआती स्तर: हर उम्मीदवार को पता होनी चाहिए ये मूल बातें 1. React क्या है, और यह किस समस्या का समाधान करता है? React Meta द्वारा रखरखाव की जाने वाली एक JavaScript लाइब्रेरी है जो composable यूज़र इंटरफेस बनाने के लिए उपयोग की जाती है। यह UI को एप्लिकेशन state के साथ sync में रखने की समस्या हल करता है — बदलावों को ट्रैक करके केवल प्रभावित DOM हिस्सों को अपडेट करता है [2]।\n2. JSX क्या है? JSX एक syntax extension है जो आपको JavaScript के अंदर HTML जैसा markup लिखने देता है। Babel जैसे टूल्स build time पर JSX को React.createElement() calls में कम्पाइल कर देते हैं [2]।\n3. Props और State में क्या अंतर है? Props read-only inputs हैं जो parent component से child को पास किए जाते हैं; state component के अंदर internally manage होने वाला mutable data है। जब state बदलती है, React component और उसके subtree को फिर से render करता है [3]।\n4. Virtual DOM क्या है? असली browser DOM को सीधे छूने के बजाय, React पहले UI के एक lightweight in-memory representation पर बदलाव लागू करता है। फिर यह नए virtual tree को पिछले से compare करता है और केवल न्यूनतम real DOM mutations करता है [7]।\n5. Controlled और Uncontrolled Components में क्या अंतर है? Controlled component में, form element की values React state द्वारा value और onChange के ज़रिए नियंत्रित होती हैं। Uncontrolled component में, DOM खुद value संभालता है और आप इसे ref के ज़रिए पढ़ते हैं [3]।\nमध्यवर्ती स्तर: Hooks, Lists, और Side Effects 6. React के मुख्य Hooks और उनका उद्देश्य बताएं। React Hooks — React 16.8 में पेश किए गए — ऐसे functions हैं जो functional components में state और lifecycle सुविधाएं देते हैं [1]:\nuseState – सरल local state manage करें useEffect – data fetching या subscriptions जैसे side effects चलाएं useContext – wrapper component के बिना context value उपयोग करें useRef – re-renders किए बिना mutable value को renders के पार बनाए रखें useReducer – explicit action types के साथ complex state transitions संभालें [2] 7. Lists में key props क्यों ज़रूरी हैं? Arrays render करते समय, React renders के बीच elements को match करने के लिए key का उपयोग करता है। Stable, unique keys से React items को efficiently move, insert, और remove कर सकता है। इनके बिना React items को unnecessarily unmount और remount कर सकता है — उनकी internal state खो देता है [1]।\n8. useEffect dependency array कैसे काम करता है? Empty array [] effect को mount पर एक बार चलाता है। Variables list करने से यह तब re-run होता है जब वे values बदलती हैं। Array छोड़ने से यह हर render के बाद चलता है। सामान्य bugs में stale closures और missing dependencies शामिल हैं [4]।\n9. React Context कब उपयोग करना चाहिए? Context global, low-frequency data के लिए आदर्श है जैसे authentication status, locale, या theme। हालाँकि, अगर data बार-बार बदलता है — जैसे form inputs — तो हर consumer हर बदलाव पर re-render होता है, जो performance को नुकसान पहुंचा सकता है [1]। Contexts को update frequency के अनुसार split करें और ज़रूरत पड़ने पर provider values को memoize करें।\n10. Code Splitting क्या है, और इसे कैसे implement करते हैं? Code splitting initial bundle size को on-demand JavaScript loading से कम करती है। React में, React.lazy को dynamic import() के साथ उपयोग करें और component को \u0026lt;Suspense fallback={…}\u0026gt; में wrap करें [2]।\nएडवांस्ड स्तर: Performance, Reconciliation, और Fiber 11. React का reconciliation algorithm कैसे काम करता है? Reconciliation वह प्रक्रिया है जिससे React state या props बदलने पर minimal DOM update calculate करता है। React एक नया virtual DOM tree बनाता है, उसे O(n) heuristic से पिछले से compare करता है (अलग-अलग types के elements अलग trees बनाते हैं), और फिर एक single synchronous pass में patch commit करता है [7]।\n12. React Fiber क्या है? React Fiber, React core algorithm का एक complete rewrite है जो incremental rendering को enable करने के लिए introduce किया गया। यह rendering को छोटे units of work में तोड़ता है, जिससे React in-progress renders को pause, prioritize, या abort कर सकता है — startTransition, useDeferredValue, और concurrent rendering model को शक्ति देता है [4]।\n13. useMemo बनाम useCallback — क्या अंतर है? useMemo एक computation के result को cache करता है; useCallback function reference को cache करता है। दोनों re-renders पर unnecessary काम से बचते हैं। हालाँकि, React 19 में React Compiler stable होने के साथ, अधिकांश components को अब इन्हें manually नहीं लिखना पड़ता — compiler build time पर auto-memoization inject करता है [1]। इन्हें तभी उपयोग करें जब profiling एक concrete bottleneck दिखाए [8]।\n14. Custom Hooks क्या हैं, और ये क्यों महत्वपूर्ण हैं? Custom hooks user-defined functions हैं जो use से शुरू होते हैं और component tree को बदले बिना components के बीच stateful logic extract और share करते हैं। सामान्य उदाहरणों में useFetch, useDebounce, और useLocalStorage शामिल हैं [3]।\n15. useReducer को useState पर कब प्राथमिकता दें? useReducer तब बेहतर होता है जब state के multiple sub-values हों या जब next state पिछले पर non-trivial तरीकों से निर्भर हो। यह transitions को explicit, auditable, और easily testable बनाता है — Redux जैसा ही pattern [5]।\n16. Render और Commit phases समझाएं। React का काम दो phases में बंटा है: render phase (reconciliation), जो interruptible है और pure functions चलाती है, और commit phase, जो resulting mutations को real DOM पर एक single synchronous pass में apply करती है। यह split ही concurrent mode को safe बनाती है — commit हमेशा atomic होता है [7]।\nविशेषज्ञ स्तर: React 19, Server Components, और Architecture 17. React Compiler क्या है? React Compiler एक build-time tool है जो React 19 के साथ stably ship हुआ है और component tree में automatically memoization logic inject करता है। यह बिना नए code में manual useMemo, useCallback, या React.memo calls के hand-optimized performance देता है [1]।\n18. React Server Components (RSC) क्या हैं? Server Components exclusively server पर render होते हैं और browser को कभी ship नहीं होते। ये directly databases और file systems access कर सकते हैं और Client Components के साथ seamlessly compose होते हैं। 2026 में किसी भी Next.js role के लिए, Server Component और Client Component में अंतर न जान पाना effectively disqualifying है [5]।\n19. useActionState समझाएं। useActionState एक action function और initial state accept करता है, [state, dispatchAction, isPending] return करता है। Action dispatch करने से isPending true होती है, function चलता है, और resolution पर state उसके return value से replace हो जाती है — जो पहले data, loading, और error के लिए तीन अलग useState calls की ज़रूरत थी [6]।\n20. useOptimistic क्या है? useOptimistic async action in-flight रहते state का एक optimistic version तुरंत render करता है, फिर action settle होने पर automatically real state पर वापस आ जाता है। यह likes, chat messages, या list reorders के लिए आदर्श है जहाँ network round-trip sluggish लगती है [6]।\n21. Large-scale React application को कैसे architect करते हैं? Senior प्रश्न syntax recall की बजाय architectural judgment probe करते हैं। मुख्य considerations में शामिल हैं: complexity के अनुपात में state management strategy चुनना (local state → Context → Zustand/Redux Toolkit), data-heavy server-rendered views के लिए RSC का लाभ उठाना, route-level code splitting लागू करना, memoization के लिए React Compiler पर भरोसा करना, और UI components और business logic के बीच clean separation enforce करना [5]।\n22. React में performance optimization कैसे करते हैं? Performance पहले एक measurement discipline है। React.memo या react-window जैसी virtualization libraries की ओर जाने से पहले React Profiler और bundle analysis tools से शुरुआत करें। Time to Interactive (TTI) benchmark करें ताकि पता चले किसी बदलाव ने वास्तव में असर किया या नहीं [9]।\nस्रोत Ex-interviewers के 100+ React इंटरव्यू प्रश्न (2026) – GreatFrontEnd 70+ React इंटरव्यू प्रश्न और उत्तर (2026) – InterviewBit React इंटरव्यू प्रश्न और उत्तर (2026) – Toptal 25 React इंटरव्यू प्रश्न 2026 – DEV Community 50+ Senior React Architect इंटरव्यू प्रश्न (2026) – Hirecta React 19 इंटरव्यू प्रश्न – CodifyNext Virtual DOM से परे: React का Fiber Architecture – Medium Advanced ReactJS इंटरव्यू प्रश्न 2026 – InterviewKickstart React Coding इंटरव्यू प्रश्न 2026 – Playcode Blog ","permalink":"https://cloudmato.com/hi/posts/react-interview-questions-beginner-to-expert/","title":"React इंटरव्यू प्रश्न: शुरुआत से विशेषज्ञ स्तर तक"},{"content":"लाखों लोग हर दिन Claude का उपयोग करते हैं — लेकिन एक महत्वपूर्ण अंतर है जो शुरुआती उपयोगकर्ताओं और डेवलपर्स दोनों को भ्रमित करता है: Claude.ai सब्सक्रिप्शन और Anthropic API key दो बिल्कुल अलग उत्पाद हैं, जिनकी कीमत, एक्सेस का तरीका और लक्षित दर्शक अलग-अलग हैं। यह समझना कि आपको वास्तव में किसकी ज़रूरत है, आपका पैसा बचा सकता है और \u0026ldquo;यह काम क्यों नहीं कर रहा?\u0026rdquo; जैसी निराशाजनक स्थितियों से बचा सकता है।\nClaude.ai सब्सक्रिप्शन क्या है? Claude.ai सब्सक्रिप्शन आपको वेब ऐप, डेस्कटॉप क्लाइंट और मोबाइल ऐप्स के ज़रिए Anthropic के conversational AI इंटरफेस तक पहुंच देता है [1]। इसे Netflix जैसी सेवा समझें — आप एक निश्चित मासिक शुल्क देते हैं और एक पॉलिश, उपयोगकर्ता-अनुकूल चैट अनुभव पाते हैं।\nAnthropic फिलहाल चार सब्सक्रिप्शन स्तर प्रदान करता है [2]:\nFree (मुफ्त) — सीमित दैनिक उपयोग, Claude के बेस मॉडल तक पहुंच। Pro ($20/माह) — Free से 5× अधिक उपयोग, पीक समय पर प्राथमिकता, extended reasoning मॉडल, Projects, Google Workspace इंटीग्रेशन, और टर्मिनल में Claude Code। Max ($100–$200/माह) — और भी अधिक उपयोग, उन power users के लिए जो पूरे दिन Claude में काम करते हैं। Team ($25/सीट/माह, न्यूनतम 5 सीट) — संगठनों के लिए सहयोग सुविधाएं, केंद्रीकृत बिलिंग और एडमिन नियंत्रण। Enterprise — SSO, बेहतर सुरक्षा और समर्पित सपोर्ट के साथ कस्टम मूल्य निर्धारण। सब्सक्रिप्शन knowledge workers के लिए डिज़ाइन किया गया है — लेखक, विश्लेषक, छात्र, शोधकर्ता, और वे सभी जिन्हें ब्राउज़र या डेस्कटॉप इंटरफेस के ज़रिए एक AI सोच-साझेदार की ज़रूरत है [3]।\nAnthropic API और API Key क्या है? Anthropic API एक बिल्कुल अलग उत्पाद है, जो उन डेवलपर्स और व्यवसायों के लिए है जो Claude की बुद्धिमत्ता को सीधे अपने एप्लिकेशन, स्क्रिप्ट या स्वचालित वर्कफ़्लो में एम्बेड करना चाहते हैं [4]। मासिक निश्चित शुल्क के बजाय, आप प्रति token भुगतान करते हैं — टेक्स्ट के छोटे-छोटे हिस्से जिन्हें Claude प्रोसेस करता है।\nएक्सेस Anthropic Console (platform.claude.com) के ज़रिए प्रबंधित होती है, जहाँ आप अकाउंट बनाते हैं, पेमेंट मेथड जोड़ते हैं और API key जनरेट करते हैं। सभी Claude API keys sk-ant- prefix से शुरू होती हैं और केवल एक बार — बनाते समय — दिखाई जाती हैं। अगर आपने डायलॉग बंद करने से पहले कॉपी नहीं की, तो आपको नई key बनानी होगी [5]।\nमई 2026 तक के वर्तमान API token दर [6]:\nमॉडल Input (प्रति 10 लाख token) Output (प्रति 10 लाख token) Claude Haiku 4.5 $1.00 $5.00 Claude Sonnet 4.6 $3.00 $15.00 Claude Opus 4.7 $5.00 $25.00 डेवलपर्स Prompt Caching (cached input की लागत 90% तक कम) और Batch API (असमकालिक कार्यों के लिए 50% सस्ता) का उपयोग करके लागत काफी कम कर सकते हैं [6]।\nसबसे ज़रूरी बात: ये दोनों एक-दूसरे की जगह इस्तेमाल नहीं हो सकते यही वह बात है जो अधिकांश नए उपयोगकर्ताओं को चौंका देती है: Claude.ai का पेड सब्सक्रिप्शन Claude API एक्सेस के साथ नहीं आता, और न ही इसका उल्टा [7]। Anthropic स्पष्ट रूप से पुष्टि करता है कि Pro, Max, Team और Enterprise plans केवल claude.ai चैट अनुभव को कवर करती हैं। अगर आप Console के ज़रिए programmatic API एक्सेस चाहते हैं, तो आपको अपनी बिलिंग के साथ एक अलग Console अकाउंट सेट अप करना होगा — भले ही आप पहले से Pro के लिए भुगतान कर रहे हों [7]।\nव्यवहार में इसका मतलब है:\nclaude.ai पर लॉगिन करके चैट करना → सब्सक्रिप्शन के माध्यम से बिल होता है। Python/Node.js कोड में sk-ant- key के साथ api.anthropic.com कॉल करना → Console API क्रेडिट बैलेंस के माध्यम से बिल होता है [4]। दोनों उत्पादों का wallet एक नहीं है।\nमूल्य निर्धारण का दर्शन: निश्चित शुल्क बनाम pay-per-token सब्सक्रिप्शन मॉडल अनुमानित, मानव-गति के उपयोग के लिए उपयुक्त है। आप जानते हैं कि हर महीने कितना खर्च होगा, और भारी conversational उपयोग (प्रतिदिन दर्जनों लंबी चैट) अक्सर समकक्ष API खर्च से कहीं अधिक मूल्य देता है [8]। mem0.ai के विश्लेषकों का अनुमान है कि Pro उपयोगकर्ता सामान्य चैट उपयोग में केवल $20/माह में लगभग $150 के API tokens के बराबर मूल्य प्राप्त कर सकते हैं [9]।\nAPI मॉडल परिवर्तनशील, प्रोग्रामेटिक workloads के लिए उपयुक्त है। यदि आप Sonnet 4.6 के ज़रिए प्रतिदिन 1 करोड़ tokens प्रोसेस कर रहे हैं, तो आप मानक दरों पर लगभग $90/दिन खर्च करेंगे — इस use case के लिए सब्सक्रिप्शन बिल्कुल काम नहीं आएगा [9]। लेकिन कम मात्रा के automations या कभी-कभी की स्क्रिप्ट के लिए, pay-as-you-go मॉडल का मतलब है कि जब आप उपयोग नहीं करते, आप कुछ नहीं देते।\nकिसे क्या चुनना चाहिए? Claude.ai सब्सक्रिप्शन चुनें अगर आप:\nमुख्य रूप से ब्राउज़र, डेस्कटॉप या मोबाइल ऐप के ज़रिए Claude का उपयोग करते हैं। मानव-नेतृत्व वाले लेखन, शोध, विश्लेषण या brainstorming के लिए Claude उपयोग करते हैं। tokens ट्रैक किए बिना एक अनुमानित मासिक बिल चाहते हैं। टर्मिनल में Claude Code को निश्चित शुल्क के अंतर्गत कवर करना चाहते हैं [10]। Anthropic API (API key के साथ) चुनें अगर आप:\nएक ऐप, चैटबॉट या स्वचालित pipeline बनाने वाले डेवलपर हैं। कोड से Claude को programmatically कॉल करने की ज़रूरत है (Python, Node.js, आदि)। CI/CD pipelines, headless automation या agent frameworks चलाते हैं। मॉडल, temperature और context window पर बारीक नियंत्रण चाहते हैं [3]। Anthropic API Key कैसे प्राप्त करें API के साथ शुरुआत करने में पाँच मिनट से कम समय लगता है [5]:\nplatform.claude.com पर जाएं और अपनी ईमेल या Google अकाउंट से साइन अप करें। Billing पर जाएं और क्रेडिट कार्ड जोड़ें (परीक्षण के लिए $10–$25 का शुरुआती क्रेडिट सामान्य है)। बाईं साइडबार में API Keys पर क्लिक करें, फिर Create Key पर। key को वर्णनात्मक नाम दें (जैसे my-app-production), फिर तुरंत कॉपी करें — Anthropic इस बिंदु के बाद पूरी key का मान संग्रहीत नहीं करता। अपने कोड में x-api-key header या Python और TypeScript के लिए Anthropic के आधिकारिक SDKs के ज़रिए key का उपयोग करें। अधिकांश solo डेवलपर्स के लिए, बड़े workloads के लिए प्रतिबद्ध होने से पहले एक छोटे क्रेडिट बैलेंस से शुरू करना और Console dashboard में उपयोग की निगरानी करना सबसे सुरक्षित तरीका है।\nस्रोत Pro plan क्या है? | Claude Help Center Plans \u0026amp; Pricing | Claude by Anthropic Claude, Claude API, और Claude Code: क्या अंतर है? API overview - Claude API Docs Claude API Key कैसे प्राप्त करें: पूरी गाइड (2026) Pricing - Claude API Docs मेरे पास पेड Claude सब्सक्रिप्शन है। API के लिए अलग भुगतान क्यों करना पड़ता है? Claude Pro बनाम API: आपके लिए क्या सही है? | Pine AI Claude Pricing: हर plan और API cost (मई 2026) Claude Pricing 2026: हर plan, API cost और optimization strategy ","permalink":"https://cloudmato.com/hi/posts/claude-subscription-vs-anthropic-api-key/","title":"Claude सब्सक्रिप्शन बनाम Anthropic API Key: मुख्य अंतर"},{"content":"MacBook देखने में आकर्षक, शक्तिशाली और बेहद लोकप्रिय हैं — लेकिन ये पूरी तरह बेदाग नहीं हैं। चाहे आप एक निराश Apple उपयोगकर्ता हों या दोनों प्लेटफ़ॉर्म के बीच चुनाव करने की सोच रहे हों, यह गाइड MacBook की सबसे आम समस्याओं और उन मुख्य क्षेत्रों को उजागर करती है जहाँ Windows लैपटॉप बाज़ी मार लेते हैं।\nMacBook की आम समस्याएं जो आपको पता होनी चाहिए अपनी लोकप्रियता के बावजूद, MacBook भी हर तकनीकी उत्पाद की तरह कई समस्याओं से ग्रस्त हैं। यहाँ वे सबसे सामान्य परेशानियां हैं जो उपयोगकर्ता सबसे अधिक रिपोर्ट करते हैं:\nओवरहीटिंग और थर्मल थ्रॉटलिंग\nIntel प्रोसेसर वाले कई MacBook Pro मॉडल वीडियो एडिटिंग या गेमिंग जैसे भारी कार्यों के दौरान अत्यधिक गर्म हो जाते थे। इससे सिस्टम गर्मी को नियंत्रित करने के लिए प्रदर्शन को धीमा कर देता था। नए Apple Silicon मॉडल पर भी ओवरहीटिंग की शिकायतें बनी रहती हैं। लैपटॉप का निचला हिस्सा काफी गर्म हो जाता है, Intel मॉडल पर पंखे तेज आवाज़ करते हैं, और सिस्टम सुस्त लग सकता है।\nतेज़ बैटरी ड्रेन\nतेज़ बैटरी खत्म होना MacBook की सबसे चिंताजनक समस्याओं में से एक है क्योंकि उपयोगकर्ता इन लैपटॉप पर पूरे दिन काम करते हैं। बैटरी अचानक तेज़ी से खत्म होने के कारण अक्सर डिस्प्ले की चमक, बैकग्राउंड ऐप्स या बैटरी का पुराना होना होता है। Apple के अनुसार, Mac नोटबुक की बैटरियां अपने अधिकतम चार्ज साइकिल — अधिकांश आधुनिक मॉडल के लिए 1,000 साइकिल — पर भी मूल क्षमता का 80% तक बनाए रखने के लिए डिज़ाइन की गई हैं।\nकनेक्टिविटी और Wi-Fi समस्याएं\nMacBook पर आम समस्याओं में Wi-Fi और Bluetooth कनेक्शन की अनियमितता, बैटरी ड्रेन, धीमा प्रदर्शन और सुस्त इंटरनेट ब्राउज़र शामिल हैं। MacBook उपयोगकर्ताओं को कभी-कभी Wi-Fi से जुड़ी समस्याएं होती हैं, जैसे बीच-बीच में कनेक्शन टूटना या कमज़ोर सिग्नल, खासकर macOS अपडेट के बाद।\nरहस्यमय स्टोरेज समस्याएं\nवास्तविक उपयोगकर्ता स्टोरेज से जुड़े हैरान करने वाले व्यवहार की रिपोर्ट करते रहते हैं। एक उपयोगकर्ता ने बताया कि बूट पर सिस्टम ने 380 GB स्टोरेज उपयोग और केवल ~100 GB शेष दिखाया — और कुछ मिनटों बाद 120 GB \u0026ldquo;System Data\u0026rdquo; को दिया गया, जिसे पुनः प्राप्त करने का कोई स्पष्ट रास्ता नहीं था।\nकीबोर्ड की खराबी\n2015 से 2019 के MacBook मॉडल में इस्तेमाल किया गया बटरफ्लाई कीबोर्ड अपनी डिज़ाइन खामियों के लिए बदनाम हो गया। धूल और मलबे के कारण keys आसानी से फंस जाती थीं, काम करना बंद कर देती थीं, या दोहरी टाइपिंग की समस्या आती थी। Apple ने अंततः प्रभावित कीबोर्ड के लिए मुफ्त मरम्मत कार्यक्रम शुरू किया और बाद के मॉडल में अधिक विश्वसनीय scissor मैकेनिज़्म पर वापस आया।\nडिस्प्ले समस्याएं (Flexgate)\n2016–2018 के कुछ MacBook Pro मॉडल \u0026ldquo;Flexgate\u0026rdquo; नामक डिस्प्ले समस्या से पीड़ित थे, जिसमें स्क्रीन की बैकलाइट विफल हो जाती थी, जिससे \u0026ldquo;stage light\u0026rdquo; प्रभाव या कमज़ोर केबल के कारण पूरी तरह डिस्प्ले खराब हो जाती थी।\nसमय के साथ धीमा प्रदर्शन\nMac की सबसे आम समस्याओं में से एक है MacBook का सुस्त महसूस होना। ऐप्स खुलने में अधिक समय लेने लगते हैं, बीचबॉल बार-बार दिखता है, और साधारण कार्य भी धीरे होने लगते हैं। यह आमतौर पर तब होता है जब स्टोरेज लगभग भर जाता है, स्टार्टअप पर बहुत सारे ऐप्स चलते हैं, या सिस्टम को लंबे समय से रीस्टार्ट नहीं किया गया है।\nजहाँ Windows लैपटॉप स्पष्ट रूप से बेहतर हैं 1. हार्डवेयर लचीलापन और अपग्रेड की सुविधा Mac को अपग्रेड करना लगभग असंभव है। मेमोरी और हार्ड ड्राइव आमतौर पर फैक्ट्री से मदरबोर्ड पर सोल्डर होते हैं, और खरीदते समय सही कॉन्फ़िगरेशन चुनना पड़ता है। दूसरी ओर, कई Windows PC — खासकर डेस्कटॉप और कुछ हाई-एंड लैपटॉप — उपयोगकर्ताओं को बाद में RAM, हार्ड ड्राइव और यहाँ तक कि ग्राफिक्स कार्ड बदलने की अनुमति देते हैं, जिससे प्रदर्शन सुधारना और डिवाइस की उम्र बढ़ाना आसान होता है।\n2. कीमत और पैसे की कीमत Apple के MacBook कई हाई-एंड Windows डिवाइस की तुलना में काफी महंगे हैं। Apple डिवाइस बिल्ड क्वालिटी, डिज़ाइन और सपोर्ट में बेहतर हैं, लेकिन बजट में कुछ ढूंढ रहे लोगों के लिए कीमतें बहुत अधिक हैं। Windows डिवाइस सस्ती हैं और हर प्रकार के उपयोगकर्ता की ज़रूरतें पूरी करती हैं — बजट ऑप्शन ढूंढने वाले छात्र से लेकर हाई-परफॉर्मिंग वर्कस्टेशन चाहने वाले पेशेवर ग्राफिक डिज़ाइनर तक।\n3. बेहतर गेमिंग प्रदर्शन चूंकि गेम्स मुख्य रूप से PC के लिए लिखे जाते हैं, इसलिए डेवलपर्स उन्हें बेहतर तरीके से चलाने के लिए पुरानी और परीक्षित विधियों का उपयोग करते हैं। Mac के लिए रिलीज़ करना डेवलपर्स और पब्लिशर्स के लिए अतिरिक्त खर्च उठाता है। Apple Silicon चिप्स अच्छा प्रदर्शन करती हैं, लेकिन macOS पर उपलब्ध गेम्स की संख्या Windows की तुलना में बहुत कम है, और कई गेम्स macOS के लिए ऑप्टिमाइज़ नहीं हैं।\n4. व्यापक सॉफ्टवेयर संगतता Windows सबसे लोकप्रिय डेस्कटॉप OS है, और इसकी व्यापक लोकप्रियता का अर्थ है कि सॉफ्टवेयर डेवलपर Windows-specific ऐप्स बनाने की ओर झुकते हैं। यह Windows को सॉफ्टवेयर के एक विशाल संग्रह के साथ संगत बनाता है जो macOS के साथ नहीं है। चाहे आप प्रोडक्टिविटी टूल, क्रिएटिव सॉफ्टवेयर, या niche एप्लिकेशन ढूंढ रहे हों, आपको Windows वर्शन मिलने की संभावना अधिक है।\n5. अधिक पोर्ट्स और बेहतर कनेक्टिविटी पोर्ट्स और कनेक्टिविटी के मामले में, MacBook एक minimalist दृष्टिकोण अपनाते हैं। Apple की स्लीक डिज़ाइन की तारीफ करते हुए भी, यह कुछ व्यावहारिक परेशानियों की ओर ले जा सकती है। अगर आपको बाहरी हार्ड ड्राइव, USB फ्लैश ड्राइव, प्रिंटर और अन्य डिवाइस जोड़ने हों, तो सीमित USB पोर्ट्स आपको विकल्पों की कमी महसूस करा सकते हैं। इसके विपरीत, अधिकांश Windows नोटबुक में अभी भी कम से कम एक USB Type-A सॉकेट होता है, जो रोज़मर्रा की ज़िंदगी में काफी उपयोगी है।\n6. टचस्क्रीन, 2-in-1 और फॉर्म फैक्टर विविधता Windows के साथ आपको MacBook की तुलना में डिज़ाइन और रंग में बहुत अधिक विकल्प मिलते हैं। Windows लैपटॉप टैबलेट, कन्वर्टिबल 2-in-1, दोहरी स्क्रीन वाले लैपटॉप और अन्य कई फॉर्म फैक्टर में आते हैं। MacBook केवल clamshell डिज़ाइन तक सीमित हैं, और केवल Windows लैपटॉप में टच और पेन-सक्षम डिस्प्ले होते हैं।\n7. अधिक शक्तिशाली डेवलपर टूल्स और हार्डवेयर विकल्प WSL2 (Windows Subsystem for Linux 2) के आने के साथ, Windows अब डेवलपर वातावरण में दूसरे दर्जे का नागरिक नहीं है — यह एक शक्तिशाली हाइब्रिड प्लेटफ़ॉर्म है। WSL2 आपको Ubuntu, Debian या अन्य distros को Windows के अंदर native apps की तरह चलाने देता है। उच्च GPU और हार्डवेयर लचीलापन का अर्थ है कि आप अपनी विशिष्ट ज़रूरतों के अनुसार मशीनें बना या अपग्रेड कर सकते हैं।\n8. कस्टमाइज़ेशन की स्वतंत्रता Windows उपयोगकर्ताओं को सबसे बड़ी सुविधा यह मिलती है कि वे built-in विकल्पों और third-party टूल्स का उपयोग करके अपने सिस्टम को मनचाहे तरीके से कस्टमाइज़ या अपग्रेड कर सकते हैं। जबकि Apple macOS को कसकर बंधा रखता है, Windows उपयोगकर्ता registries बदलकर और ऐप्स के ज़रिए system-level बदलाव करके अधिकांश पहलुओं को व्यक्तिगत बना सकते हैं।\nनिष्कर्ष Windows चुनें अगर आपको गेमिंग प्रदर्शन चाहिए, हार्डवेयर कस्टमाइज़ेशन पसंद है, सस्ती कीमतें चाहते हैं, या enterprise सॉफ्टवेयर का उपयोग करते हैं। वहीं, Mac लैपटॉप उन उपयोगकर्ताओं के लिए बेहतर हैं जो दक्षता, ecosystem की एकरूपता और बैटरी लाइफ चाहते हैं। अधिकांश रोज़मर्रा के उपयोगकर्ताओं, पेशेवरों और gamers के लिए, Windows 11 अपनी अनुकूलनशीलता, व्यापक सॉफ्टवेयर संगतता और HP, Dell और ASUS जैसे प्रसिद्ध ब्रांडों द्वारा दिए गए विशाल हार्डवेयर विकल्पों के कारण सबसे ऊपर है। MacBook एक परिष्कृत मशीन है — लेकिन अगर आपके लिए लचीलापन, मूल्य और शक्ति सबसे महत्वपूर्ण हैं, तो Windows एक समझदार विकल्प बना रहता है।\nस्रोत Apple MacBook की आम समस्याएं — Des3Tech MacBook की वे समस्याएं जो मरम्मत की ओर ले जाती हैं — TechToro 10 आम iMac और MacBook समस्याएं — Stellar Info 5 सबसे आम MacBook समस्याएं — BGR MacBook Pro 2024 स्टोरेज समस्याएं — Apple Community उपयोगकर्ताओं की 10 सबसे आम MacBook समस्याएं — TechTimes आम MacBook समस्याएं और उनके समाधान — Box.co.uk 9 कारण क्यों Windows अभी भी macOS से बेहतर है — XDA Developers Mac बनाम Windows — Vibetric Windows 11 बनाम macOS 2025 — Windows Forum ","permalink":"https://cloudmato.com/hi/posts/macbook-problems-where-windows-is-better/","title":"MacBook की समस्याएं और जहाँ Windows बेहतर है"},{"content":" cloudmato.com के बारे में cloudmato.com एक शोध-आधारित ब्लॉग है जहाँ हर लेख लाइव वेब स्रोतों के साथ लिखा जाता है — बिना भराव, बिना अनुमान।\nयह साइट वेब डेवलपमेंट, ब्राउज़र इंटरनल्स, नेटवर्किंग, सुरक्षा, डेटाबेस, डिस्ट्रिब्यूटेड सिस्टम्स, और उन AI टूल्स व मॉडल्स को कवर करती है जो सॉफ्टवेयर बनाने के तरीके को बदल रहे हैं।\nयह ब्लॉग क्यों? अच्छी तकनीकी लेखन दुर्लभ है। अधिकांश लेख या तो सतह को छूते हैं या मार्केटिंग कॉपी में जानकारी दबा देते हैं। cloudmato.com इसे काटने के लिए बना है — सरल भाषा, असली उदाहरण, उद्धृत स्रोत।\nकिन विषयों पर लेख मिलेंगे वेब डेवलपमेंट, फ्रंटएंड फ्रेमवर्क्स और ब्राउज़र DevTools नेटवर्किंग, HTTP, DNS और वेब सुरक्षा डेटाबेस, कैशिंग और डिस्ट्रिब्यूटेड सिस्टम्स AI टूल्स, LLM API और उनका सही उपयोग क्लाउड इंफ्रास्ट्रक्चर, DevOps और डेवलपर टूलिंग संपर्क करें कोई विषय सुझाना चाहते हैं? कुछ सुधार नज़र आया?\ncloudmato@gmail.com पर लिखें।\nइस साइट पर हर लेख उद्धृत वेब स्रोतों के साथ लिखा जाता है। स्रोतों के लिंक क्रमांकित संदर्भों के रूप में मिलेंगे।\n","permalink":"https://cloudmato.com/hi/pages/about/","title":"हमारे बारे में"}]