ToolBox Image — हमने ToolBox Image को पूरी तरह से आपके ब्राउज़र में चलने के लिए क्यों बनाया

ज़्यादातर मुफ्त ऑनलाइन इमेज टूल एक ही तरह से काम करते हैं: आप एक फ़ाइल उनके सर्वर पर अपलोड करते हैं, सर्वर उसे प्रोसेस करता है, और आप रिज़ल्ट डाउनलोड करते हैं। यह मॉडल बनाने में आसान है, लेकिन इसके छिपे हुए खर्च हैं — आपकी गोपनीयता, उनके सर्वर के बिल, और फ़ाइल साइज़ और थ्रूपुट पर सीमाएँ।

ToolBox Image एक अलग तरीका अपनाता है। पूरा एप्लिकेशन — डिकोडिंग, एन्कोडिंग, कंप्रेशन, रीज़ाइज़िंग, फ़ॉर्मेट कन्वर्ज़न — आपके ब्राउज़र में चलता है। अपलोड करने के लिए कोई सर्वर नहीं है। आपकी इमेज आपके डिवाइस से कभी बाहर नहीं जाती। यह आर्किटेक्चर एक जानबूझकर किया गया चुनाव था, और इसने उत्पाद के बारे में हमारे हर फैसले को आकार दिया।

ब्राउज़र-फर्स्ट तरीका क्यों?

सबसे सीधा विकल्प पारंपरिक सर्वर-साइड आर्किटेक्चर है। आप एक इमेज अपलोड करते हैं, सर्वर उसे ImageMagick या Sharp जैसे टूल से प्रोसेस करता है, और रिज़ल्ट वापस भेजता है। यह काम करता है, लेकिन यह कई ऐसी समस्याएँ पैदा करता है जिन्हें हल करना मुश्किल है:

• गोपनीयता। उपयोगकर्ताओं को भरोसा करना होगा कि आप उनकी इमेज को स्टोर, विश्लेषण या लीक नहीं करेंगे। संवेदनशील दस्तावेज़ों के लिए — मेडिकल इमेज, डिज़ाइन मॉकअप, निजी फ़ोटो — यह भरोसा जीतना मुश्किल है।
• लागत। हर कंप्रेशन आपके इंफ्रास्ट्रक्चर पर चलता है। आप जितना सफल होंगे, उतना अधिक भुगतान करेंगे। यह फ़ाइल साइज़ को सीमित करने, कतारें जोड़ने या भुगतान विकल्प लाने का दबाव बनाता है।
• विलंबता। धीमे कनेक्शन पर 100 MB फ़ाइल अपलोड करने में प्रोसेसिंग शुरू होने से पहले मिनटों लग जाते हैं। खराब कनेक्टिविटी वाले क्षेत्रों के उपयोगकर्ताओं के लिए, यह टूल प्रभावी रूप से बेकार है।
• स्केल। एक सर्वर दर्जनों समवर्ती कंप्रेशन संभाल सकता है। लेकिन हज़ारों का क्या? आपको ऑटो-स्केलिंग ग्रुप, लोड बैलेंसर, CDN अपलोड एंडपॉइंट चाहिए — ये सब जटिलता और लागत बढ़ाते हैं।

ब्राउज़र-फर्स्ट मॉडल यह सब एक साथ हल करता है। प्रोसेसिंग मुफ्त है (उपयोगकर्ता के CPU साइकिल), निजी है (कोई डेटा डिवाइस से बाहर नहीं जाता), और असीम रूप से स्केलेबल है (हर उपयोगकर्ता अपना हार्डवेयर लाता है)।

इसे काम करना: WebAssembly और Web Workers

दस साल पहले, ब्राउज़र में इमेज कोडेक चलाना असंभव था। आज, WebAssembly हमें C और Rust लाइब्रेरीज़ को सीधे एक ऐसे फ़ॉर्मेट में कंपाइल करने देता है जिसे ब्राउज़र लगभग नेटिव स्पीड पर चला सकता है। हम Mozilla के mozJPEG, Google के libwebp, और libaom AVIF एन्कोडर — सभी C में लिखे गए — को WebAssembly में कंपाइल करते हैं। ब्राउज़र उन्हें उतनी ही कुशलता से चलाता है जैसे वे नेटिव रूप से इंस्टॉल हों।

लेकिन बड़े बैचों के लिए सिंगल-थ्रेडेड एन्कोडिंग धीमी है। यहाँ Web Workers काम आते हैं। हर वर्कर एक अलग CPU कोर पर चलता है, और हम उतने वर्कर बनाते हैं जितने कोर डिवाइस में हैं। 8 कोर वाले आधुनिक लैपटॉप पर, इसका मतलब है 8 इमेज एक साथ कंप्रेस हो रही हैं। 200 फ़ोटो का बैच जो एक थ्रेड पर मिनट लेता, वह सेकंड्स में पूरा होता है।

हमने क्या छोड़ा

ब्राउज़र-फर्स्ट तरीका मुफ्त नहीं है। सबसे बड़ी समझौता मेमोरी है। ब्राउज़र टैब डिवाइस की RAM तक पहुँच सकता है, लेकिन एक टैब का क्रैश होना क्योंकि इमेज उपलब्ध मेमोरी से अधिक हो गई — यह एक बुरा अनुभव है। हम सुरक्षित सीमा में रहने के लिए अलग-अलग फ़ाइलों को 100 MB और बैचों को 200 फ़ाइलों तक सीमित करते हैं।

हमने सर्वर-साइड फीचर्स जैसे पर्मानेंट स्टोरेज, ईमेल डिलीवरी और एनालिटिक्स भी छोड़े। कंप्रेस की गई इमेज का कोई डेटाबेस नहीं, कोई ईमेल न्यूज़लेटर नहीं, कोई ट्रैकिंग नहीं कि उपयोगकर्ता कौन से फ़ॉर्मेट पसंद करते हैं। यह हमारे गोपनीयता रुख के अनुरूप है, लेकिन इसका मतलब है कि हम "हाल की कंप्रेशन" या "सत्रों के बीच सहेजे गए प्रीसेट" जैसी सुविधाएँ नहीं दे सकते।

आगे क्या

ब्राउज़र प्रदर्शन-संवेदनशील अनुप्रयोगों के लिए एक वैध रनटाइम बन रहा है। जैसे-जैसे WebAssembly को गार्बेज कलेक्शन, थ्रेडिंग और SIMD सपोर्ट मिलता है, एप्लिकेशन स्टैक का अधिक हिस्सा क्लाइंट-साइड जा सकता है। हम और तेज़ पिक्सेल प्रोसेसिंग के लिए WebGPU और सहज फ़ोल्डर एकीकरण के लिए File System Access API की खोज कर रहे हैं।

अभी के लिए, कंप्रेसर लाइव है और हर दिन हज़ारों इमेज प्रोसेस कर रहा है — ये सभी वहीं रह रही हैं जहाँ उन्हें रहना चाहिए।