Moviento 0deps: स्थानिक डिपेंडन्सीज आणि सुरक्षा
सॉफ्टवेअर डेव्हलपर्स बहुतेक प्रकल्पांमध्ये शेकडो बाह्य लायब्ररी (external libraries) इन्स्टॉल करतात. आधुनिक फ्रेमवर्क्स हजारो ट्रान्झिटिव्ह डिपेंडन्सीजवर (transitive dependencies) अवलंबून असतात. याचा अर्थ असा की तुमचे ॲप्लिकेशन शेकडो अज्ञात व्यक्तींनी लिहिलेला कोड चालवते.
ही परिसंस्था (ecosystem) डेव्हलपमेंटचा वेग वाढवते. परंतु, यामुळे पुरवठा साखळीतील (supply chain) मोठ्या जोखमी देखील निर्माण होतात.
0deps चळवळ एक साधा प्रश्न विचारते: जर तुमचे ॲप्लिकेशन फक्त तोच कोड चालवत असेल ज्यावर तुमचे प्रत्यक्ष नियंत्रण आहे, तर काय होईल?
प्रत्येक डिपेंडन्सी एक नवीन अटॅक सरफेस (attack surface) तयार करते. एखादी डिपेंडन्सी:
- सुरक्षा त्रुटी (security flaws) निर्माण करू शकते.
- सप्लाय चेन अटॅक्सचे लक्ष्य बनू शकते.
- तिच्या निर्मात्याकडून सोडून दिली जाऊ शकते.
- तिची पब्लिक API बदलू शकते.
- बॅकवर्ड सुसंगतता (backward compatibility) बिघडू शकते.
0deps मॉडेलमध्ये, तुम्ही सर्व आवश्यक डिपेंडन्सीज थेट तुमच्या प्रोजेक्ट रिपॉझिटरीमध्ये (repository) हलवता. तुम्ही बिल्ड टाइम दरम्यान डायनॅमिकली पॅकेजेस डाउनलोड करणे थांबवता. ॲप चालवण्यासाठी आवश्यक असलेली सर्व सामग्री तुम्ही क्लोन केल्याच्या क्षणापासून रिपॉझिटरीमध्येच राहते.
हा दृष्टिकोन खालील गोष्टी प्रदान करतो:
- रिप्रॉड्युसिबल बिल्ड्स (Reproducible builds).
- बाह्य पॅकेज रजिस्ट्रीजवरील कमी अवलंबित्व.
- केंद्रीकृत सुरक्षा ऑडिट्स (Centralized security audits).
- अंदाज लावण्यायोग्य (Predictable) परिणाम.
ध्येय कोड स्थिर (static) करणे हे नाही. बग्स सुधारण्यासाठी आणि सुरक्षित राहण्यासाठी इम्प्लिमेंटेशन्स आणि अल्गोरिदम विकसित होणे आवश्यक आहे. ध्येय फक्त 'पब्लिक कॉन्ट्रॅक्ट' (public contract) स्थिर ठेवणे हे आहे.
प्रत्येक लायब्ररी एक विशिष्ट इंटरफेस (interface) प्रदान करते. उदाहरणार्थ:
authenticate()createSession()verifyPasskey()
ही फंक्शन्स एक कॉन्ट्रॅक्ट तयार करतात. तुम्ही मूळ कोड पुन्हा लिहिला तरी ते कॉन्ट्रॅक्ट सारखेच राहते. तुम्ही तुमच्या ॲप्लिकेशनचे इतर भाग बिघडवल्याशिवाय लायब्ररी बदलू शकता किंवा प्रोटोकॉल्स बदलू शकता.
जेव्हा एखादी असुरक्षितता (vulnerability) समोर येते, तेव्हा तुम्हाला सहसा दोन समस्यांचा सामना करावा लागतो:
- बग फिक्स करणे.
- अपडेटमुळे तुमचे ॲप बिघडते का, हे तपासणे.
0deps आर्किटेक्चरमध्ये, दुसरी समस्या नाहीशी होते. तुम्ही इंटरफेसच्या मागे असलेले इम्प्लिमेंटेशन अपडेट करता. पब्लिक API तशीच राहते. तुमच्या ॲप्लिकेशनमध्ये कोणताही कोड बदल न करता ते काम करत राहते.
बाह्य कोड अंतर्गत अडॅप्टर्सच्या (internal adapters) मागे वेगळा करून, तुम्ही दीर्घकालीन जोखीम कमी करता. जर एखादी लायब्ररी उद्या गायब झाली, तर तुम्हाला फक्त अडॅप्टर अपडेट करावा लागेल.
0deps ओपन सोर्सच्या विरोधात नाही. ते तुम्ही त्याचा वापर कसा करता हे बदलते. लायब्ररी डायनॅमिक बाह्य लिंक्सऐवजी एकात्मिक घटक (integrated components) बनतात.
यामुळे असे सॉफ्टवेअर तयार होते जे अंदाज लावण्यायोग्य (predictable), लवचिक (resilient) आणि देखभाल करण्यास सोपे असते. इम्प्लिमेंटेशन्स विकसित होतात, पण कॉन्ट्रॅक्ट स्थिर राहते.