Movimento 0deps: ലോക്കൽ ഡിപെൻഡൻസികളും മാറ്റമില്ലാത്ത കരാറുകളും (Immutable Contracts)
സോഫ്റ്റ്വെയർ ഡെവലപ്പർമാർ പലപ്പോഴും നൂറുകണക്കിന് എക്സ്റ്റേണൽ ലൈബ്രറികൾ ഇൻസ്റ്റാൾ ചെയ്യാറുണ്ട്. ആധുനിക ഫ്രെയിംവർക്കുകൾ ആയിരക്കണക്കിന് ട്രാൻസിറ്റീവ് ഡിപെൻഡൻസികളെ (transitive dependencies) ആശ്രയിക്കുന്നു. ഇതിനർത്ഥം നിങ്ങളുടെ ആപ്ലിക്കേഷൻ അപരിചിതരുടെ കോഡ് പ്രവർത്തിപ്പിക്കുന്നു എന്നാണ്.
ഇത് ഒരു സോഫ്റ്റ്വെയർ സപ്ലൈ ചെയിൻ റിസ്ക് (software supply chain risk) സൃഷ്ടിക്കുന്നു.
ഓരോ ഡിപെൻഡൻസിയും നിങ്ങളുടെ അറ്റാക്ക് സർഫേസ് (attack surface) വർദ്ധിപ്പിക്കുന്നു. ഇത് താഴെ പറയുന്നവയ്ക്ക് കാരണമായേക്കാം:
- സുരക്ഷാ പിഴവുകൾ ഉണ്ടാക്കാം.
- സപ്ലൈ ചെയിൻ ആക്രമണങ്ങളുടെ ലക്ഷ്യസ്ഥാനമാകാം.
- മെയിന്റനർമാർ ഉപേക്ഷിച്ചേക്കാം.
- അതിന്റെ പബ്ലിക് API മാറ്റം വരുത്തിയേക്കാം.
- ബാക്ക്വേർഡ് കംപാറ്റിബിലിറ്റി (backward compatibility) തകരാറിലാക്കാം.
0deps ചലനം ഒരു ലളിതമായ ചോദ്യം ചോദിക്കുന്നു: നിങ്ങളുടെ ആപ്ലിക്കേഷൻ നിങ്ങൾ നിയന്ത്രിക്കുന്ന കോഡിൽ മാത്രം ആശ്രയിച്ചാൽ എങ്ങനെയുണ്ടാകും?
0deps മോഡലിൽ, ആവശ്യമായ ഡിപെൻഡൻസികൾ നിങ്ങളുടെ പ്രോജക്റ്റ് റിപ്പോസിറ്ററിയിലേക്ക് നേരിട്ട് ഉൾപ്പെടുത്തുന്നു. ബിൽഡുകൾക്കിടയിൽ അവ ഡൈനാമിക് ആയി ഡൗൺലോഡ് ചെയ്യുന്നത് നിങ്ങൾ നിർത്തുന്നു. ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കാൻ ആവശ്യമായതെല്ലാം തുടക്കം മുതൽ തന്നെ റിപ്പോസിറ്ററിയിൽ തന്നെ ഉണ്ടാകും.
ഈ സമീപനം ഇവ നൽകുന്നു:
- പുനരാവർത്തിക്കാവുന്ന ബിൽഡുകൾ (Reproducible builds).
- എക്സ്റ്റേണൽ രജിസ്ട്രികളോടുള്ള ആശ്രയത്വം കുറയ്ക്കുന്നു.
- കേന്ദ്രീകൃതമായ സുരക്ഷാ ഓഡിറ്റുകൾ.
- ഉയർന്ന പ്രവചനക്ഷമത (Predictability).
കോഡ് സ്റ്റാറ്റിക് ആയി സൂക്ഷിക്കുക എന്നതല്ല ഇതിന്റെ പ്രധാന തത്വം. ബഗുകൾ പരിഹരിക്കാനും സുരക്ഷ മെച്ചപ്പെടുത്താനും ഇംപ്ലിമെന്റേഷനുകളും അൽഗോരിതങ്ങളും വികസിച്ചുകൊണ്ടിരിക്കണം. എന്നാൽ പബ്ലിക് കോൺട്രാക്റ്റ് (public contract) സ്ഥിരമായി നിലനിൽക്കുന്നു.
ഓരോ ലൈബ്രറിയും ശ്രദ്ധാപൂർവ്വം രൂപകൽപ്പന ചെയ്ത ഒരു ഇന്റർഫേസ് പ്രദാനം ചെയ്യുന്നു. ഉദാഹരണങ്ങൾ ഇവയാണ്:
authenticate()createSession()verifyPasskey()
ഈ ഫംഗ്ഷനുകൾ ഒരു കരാർ (contract) നിർവചിക്കുന്നു. ഈ കരാർ ഒരിക്കലും മാറുന്നില്ല. നിങ്ങൾക്ക് ഇതിന് പിന്നിലെ കോഡ് വീണ്ടും എഴുതാനോ അല്ലെങ്കിൽ ലൈബ്രറി പൂർണ്ണമായും മാറ്റാനോ കഴിയും. നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ബാക്കി ഭാഗങ്ങൾ ഈ മാറ്റം ശ്രദ്ധിക്കില്ല.
ഒരു സുരക്ഷാ വീഴ്ച (vulnerability) ഉണ്ടാകുമ്പോൾ, നിങ്ങൾ സാധാരണയായി രണ്ട് പ്രശ്നങ്ങൾ നേരിടുന്നു:
- പിഴവ് പരിഹരിക്കുക.
- അപ്ഡേറ്റ് നിങ്ങളുടെ ആപ്പിനെ ബാധിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.
ഒരു 0deps ആർക്കിടെക്ചറിൽ, രണ്ടാമത്തെ പ്രശ്നം ഇല്ലാതാകുന്നു. പബ്ലിക് API മാറ്റമില്ലാതെ നിലനിൽക്കുമ്പോൾ നിങ്ങൾക്ക് ഇന്റേണൽ ഇംപ്ലിമെന്റേഷൻ അപ്ഡേറ്റ് ചെയ്യാം. കോഡിൽ മാറ്റം വരുത്താതെ തന്നെ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ പ്രവർത്തിച്ചുകൊണ്ടേയിരിക്കും.
ഒരു ഇന്റേണൽ അഡാപ്റ്റർ (internal adapter) ഉപയോഗിച്ച് നിങ്ങൾ എക്സ്റ്റേണൽ ഇന്റഗ്രേഷനുകളെ വേർതിരിക്കുന്നു: Application -> Public Interface -> Adapter -> Implementation
നാളെ ഒരു ലൈബ്രറി ഇല്ലാതായാൽ, നിങ്ങൾ അഡാപ്റ്റർ മാത്രം മാറ്റിയാൽ മതി. നിങ്ങളുടെ ആപ്പിന്റെ മറ്റ് ഭാഗങ്ങൾ ഒന്നും തകരാറിലാകില്ല.
0deps സോഫ്റ്റ്വെയറിനെ പൂർണ്ണമാക്കുന്നില്ല. ഇത് സപ്ലൈ ചെയിൻ റിസ്കുകൾ കുറയ്ക്കുന്നു. മാലീഷ്യസ് പാക്കേജുകൾ (malicious packages), രജിസ്ട്രി കോംപ്രമൈസുകൾ (registry compromises), ഡിപെൻഡൻസി കൺഫ്യൂഷൻ (dependency confusion) തുടങ്ങിയ പ്രശ്നങ്ങൾ ഇത് തടയുന്നു.
പ്രോജക്റ്റുകൾ പതിറ്റാണ്ടുകളോളം നീണ്ടുനിൽക്കുന്നു. ലൈബ്രറികളും ഫ്രെയിംവർക്കുകളും മാറിക്കൊണ്ടിരിക്കും. ഇക്കോസിസ്റ്റം എങ്ങനെയൊക്കെ മാറിയാലും, 0deps ഉപയോഗിക്കുന്നതിലൂടെ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഒരേ സ്ഥിര