ഒപ്പ്ടിസ്ട്രീം (Optistream) തങ്ങളുടെ ആയിരത്തോളം പബ്ലിക് പേജുകളുടെ SEO നഷ്ടപ്പെടുത്താതെ തന്നെ പന്ത്രണ്ട് കസ്റ്റം വേർഡ്പ്രസ്സ് (WordPress) പ്ലഗിനുകളെ ഒരൊറ്റ കോഡ്ബേസിലേക്ക് സംയോജിപ്പിച്ചു.
ഈ സംയോജനം പ്രധാനപ്പെട്ടത് എന്തുകൊണ്ട്
ഒരു സാധാരണ വേർഡ്പ്രസ്സ് സൈറ്റിൽ കുറച്ച് പ്ലഗിനുകൾ ഉണ്ടാകാറുണ്ട്; എന്നാൽ വലിയ സൈറ്റുകൾ വയറുകൾ നിറഞ്ഞ ഒരു വർക്ക്ഷോപ്പ് പോലെയായിരിക്കും, ഓരോന്നും പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും അവയിൽ നിന്ന് ഒന്നിനെ വേർപെടുത്തുക എന്നത് പ്രയാസകരമാണ്. സ്ട്രീമർ പ്രൊഫൈലുകൾ, ഇ-സ്പോർട്സ് ടീമുകൾ, ഗെയിം ഡാറ്റ എന്നിവ കൈകാര്യം ചെയ്യുന്ന പന്ത്രണ്ട് പ്രത്യേക പ്ലഗിനുകളാണ് ഒപ്പ്ടിസ്ട്രീം സൈറ്റിൽ പ്രവർത്തിച്ചിരുന്നത്. ഈ പ്ലഗിനുകൾ ആയിരത്തോളം ഇൻഡെക്സബിൾ (indexable) പേജുകൾ നിർമ്മിച്ചിരുന്നു. ആ URL-കൾ മാറ്റമില്ലാതെ നിലനിർത്തുക എന്നത് അനിവാര്യമായിരുന്നു—ഏതൊരു മാറ്റവും മൈഗ്രേഷൻ പരാജയപ്പെടാൻ കാരണമായേനെ.
പഴയ സംവിധാനം എങ്ങനെയായിരുന്നു
പന്ത്രണ്ട് പ്ലഗിനുകളും അവയുടെ ഓരോ ഫോൾഡറുകളിലായി നിലനിന്നിരുന്നു, അവ ഓരോന്നും സ്വന്തം കസ്റ്റം പോസ്റ്റ് ടൈപ്പ് രജിസ്റ്റർ ചെയ്യുകയും വേർഡ്പ്രസ്സിൽ വ്യത്യസ്ത പോയിന്റുകളിൽ ഹുക്ക് (hook) ചെയ്യുകയും ചെയ്തിരുന്നു. ഇതിലൂടെ പ്രശ്നങ്ങൾ വർദ്ധിച്ചു:
- ഹുക്കുകളും (Hooks) അസറ്റുകളും ചിതറിക്കിടന്നിരുന്നതിനാൽ ഏത് കോഡ് എപ്പോൾ പ്രവർത്തിക്കുന്നു എന്ന് പ്രവചിക്കുന്നത് പ്രയാസമായിരുന്നു.
- റൂട്ടിംഗ് ലോജിക് (Routing logic) പല പ്രത്യേക ഫയലുകളിലായിരുന്നതിനാൽ, ഒരു സിംഗിൾ URL പല പ്ലഗിനുകളെയും ബാധിച്ചേക്കാമായിരുന്നു.
- CSS ഫയലുകൾ പ്രവചനാതീതമായ ക്രമത്തിൽ ലോഡ് ചെയ്യപ്പെടുന്നത് സ്റ്റൈൽ സംഘർഷങ്ങൾക്ക് (style clashes) കാരണമായി.
- ഡീബഗ്ഗിംഗിനായി പന്ത്രണ്ട് വ്യത്യസ്ത ഡയറക്ടറികൾ തുറക്കേണ്ടി വരുന്നത് ഏതൊരു ഡെവലപ്പറെയും സംബന്ധിച്ചിടത്തോളം സമയം നഷ്ടപ്പെടുത്തുന്ന കാര്യമായിരുന്നു.
ഫയലുകളുടെ എണ്ണം കുറയ്ക്കുക എന്നതായിരുന്നില്ല ലക്ഷ്യം; മറിച്ച് മുഴുവൻ സിസ്റ്റത്തിനും ഒരൊറ്റ ലൈഫ്സൈക്കിളും (lifecycle) ഡിപെൻഡൻസികൾ (dependencies) നിയന്ത്രിക്കാൻ ഒരൊറ്റ സ്ഥലവും നൽകുക എന്നതായിരുന്നു.
മൈഗ്രേഷൻ എങ്ങനെയാണ് ആസൂത്രണം ചെയ്തത്
പബ്ലിക് ഇന്റർഫേസ്—അതായത് URL-കൾ, ടെംപ്ലേറ്റുകൾ, മെറ്റാ ഡാറ്റ എന്നിവയെ ലംഘിക്കാൻ കഴിയാത്ത ഒരു കരാറായി ടീം കണക്കാക്കി. ഫ്രണ്ട് എൻഡിൽ (front end) സംഭവിക്കുന്ന ഏതൊരു മാറ്റവും പരാജയമായി കണക്കാക്കും. ഈ നിയമം മുൻനിർത്തി, ഓരോ ഘട്ടത്തിന് ശേഷവും പരിശോധിക്കേണ്ട ഒരു ചെക്ക്ലിസ്റ്റ് അവർ തയ്യാറാക്കി.
1. പബ്ലിക് കോൺട്രാക്റ്റുകൾ പട്ടികപ്പെടുത്തുക
ഓരോ URL പാത്തും അതിന്റെ പോസ്റ്റ് ടൈപ്പ്, റീറൈറ്റ് സ്ലഗ് (rewrite slug), ടെംപ്ലേറ്റ് ഫയൽ, അത് ആശ്രയിച്ചിരിക്കുന്ന മെറ്റാ കീകൾ (meta keys) എന്നിവ സഹിതം രേഖപ്പെടുത്തി. ഈ സ്പ്രെഡ്ഷീറ്റ് ഒരു നിയമപുസ്തകമായി മാറി: ഒരു മോഡ്യൂൾ മാറ്റിയതിന് ശേഷം ഒരു URL മാറിയാൽ, മൈഗ്രേഷൻ റോളബാക്ക് (rollback) ചെയ്യും.
2. ലളിതമായ ഒരു ലോഡർ നിർമ്മിക്കുക
വളരെ ചെറിയ ഒരു ബൂട്ട്സ്ട്രാപ്പ് (bootstrap) ഫയൽ നിർമ്മിച്ചു. പഴയ ഓരോ പ്ലഗിനും ഇപ്പോൾ പ്രവചിക്കാവുന്ന ഒരു ഫംഗ്ഷൻ പേര് വഴി ഒരു "കണ്ടന്റ് ഡൊമെയ്ൻ" (content domain) രജിസ്റ്റർ ചെയ്യുന്നു. ഈ ലോഡർ സങ്കീർണ്ണമായതൊന്നും ചെയ്യുന്നില്ല—ആവശ്യമുള്ളപ്പോൾ ശരിയായ മോഡ്യൂളിനെ വേർഡ്പ്രസ്സിലേക്ക് കൊണ്ടുവരാൻ മാത്രം മതിയാകും. ലളിതമായ രീതി പരാജയങ്ങൾ പെട്ടെന്ന് തിരിച്ചറിയാൻ സഹായിക്കുന്നു.
3. ഡാറ്റ സംരക്ഷിക്കുക
മെറ്റാ കീകൾ മാറ്റുന്നത് ഒരു കോഡ് മാറ്റത്തെ ഡാറ്റ മൈഗ്രേഷനായി മാറ്റി അനാവശ്യ റിസ്ക് ഉണ്ടാക്കുമായിരുന്നു. പഴയ കീകൾ മാറ്റമില്ലാതെ നിലനിർത്തി; പുതിയ ഹെൽപ്പർ ഫംഗ്ഷനുകൾ അവയെ പൊതിഞ്ഞു (wrap), ഇത് ഡാറ്റാബേസ് സ്കീമയെ (database schema) സുസ്ഥിരമായി നിലനിർത്തി.
4. CSS ഉടമസ്ഥാവകാശം പരിഹരിക്കുക
മൂന്ന് നടപടികളിലൂടെ സ്റ്റൈലിംഗ് സംഘർഷങ്ങൾ പരിഹരിച്ചു:
- മോഡ്യൂൾ CSS ഫയലുകൾ ഉയർന്ന മുൻഗണനയോടെ (high priority) എൻക്യൂ (enqueue) ചെയ്യുന്നു, അതിനാൽ അവ അവസാനമായി ലോഡ് ചെയ്യപ്പെടുന്നു.
- എല്ലാ സെലക്ടറുകളും ഓരോ മോഡ്യൂളിനും പ്രത്യേകമായ ഒരു റാപ്പർ ക്ലാസ്സിനുള്ളിൽ (wrapper class) പരിമിതപ്പെടുത്തി (scoped).
- ഒരു സ്റ്റൈൽഷീറ്റ് മാറുമ്പോൾ ബ്രൗസർ കാഷെകൾ (browser caches) ഒഴിവാക്കാൻ എൻക്യൂ ചെയ്യുമ്പോൾ
filemtime()ഉപയോഗിക്കുന്നു.
5. സുരക്ഷിതമായ ഒരു ലൂപ്പ് ഉപയോഗിക്കുക
ഓരോ മോഡ്യൂളായിട്ടാണ് മൈഗ്രേഷൻ മുന്നോട്ട് പോയത്. ഒരു മോഡ്യൂൾ മാറ്റിയ ശേഷം, അടുത്തതിലേക്ക് കടക്കുന്നതിന് മുമ്പ് ടീം പോസ്റ്റ്-ടൈപ്പ് രജിസ്ട്രേഷൻ, റൂട്ടിംഗ്, മൊബൈൽ ലേഔട്ട് എന്നിവ പരിശോധിച്ചു. പഴയ പ്ലഗിനുകൾ ഇൻസ്റ്റാൾ ചെയ്ത നിലയിൽ തന്നെ ഉണ്ടെങ്കിലും അവ ഇൻആക്റ്റീവ് (inactive) ആയിരുന്നു, ഇത് പെട്ടെന്ന് റോളബാക്ക് ചെയ്യാൻ സഹായിച്ചു.
പ്രൊഡക്ഷൻ ചെക്ക്ലിസ്റ്റ്
ഓരോ മോഡ്യൂൾ മാറ്റത്തിന് ശേഷവും ടീം ഇവ പരിശോധിച്ചു:
- എല്ലാ കണ്ടന്റ്-ടൈപ്പ് URL-കളും 200 HTTP സ്റ്റാറ്റസ് നൽകുന്നുണ്ടെന്ന് ഉറപ്പാക്കി.
- കാനോണിക്കൽ (canonical) URL ഹെഡർ ഒറിജിനൽ URL-മായി പൊരുത്തപ്പെടുന്നുണ്ടെന്ന് ഉറപ്പാക്കി.
- പേജ് ടൈറ്റിലുകളും മെറ്റാ ഡിസ്ക്രിപ്ഷനുകളും മാറ്റമില്ലാതെ തുടരുന്നു.
- എല്ലാ ചിത്രങ്ങളും ബ്രോക്കൺ ലിങ്കുകൾ ഇല്ലാതെ ലോഡ് ആകുന്നു.
- മൊബൈൽ സ്ക്രീനുകളിൽ ഹോറിസോണ്ടൽ ഓവർഫ്ലോ (horizontal overflow) കാണുന്നില്ല.
- ബ്രൗസർ കൺസോളിൽ ജാവാസ്ക്രിപ്റ്റ് അല്ലെങ്കിൽ CSS എററുകൾ ഒന്നുമില്ല.
ചെക്ക്ലിസ്റ്റ് പൂർണ്ണമായും വിജയിച്ചതിന് ശേഷം മാത്രമാണ് ടീം പഴയ പ്ലഗിൻ സ്ഥിരമായി ഡിആക്റ്റിവേറ്റ് ചെയ്തത്.
പുതിയ പ്ലഗിൻ നൽകുന്ന ഫലം
ലഭിച്ച ഒരൊറ്റ പ്ലഗിൻ കോഡ്ബേസ് കുറയ്ക്കുന്നില്ല; അത് അതിരുകളെ (boundaries) വ്യക്തമാക്കുക മാത്രമാണ് ചെയ്യുന്നത്. പന്ത്രണ്ട് പ്രവർത്തന മേഖലകളും ഇപ്പോൾ ഒരൊറ്റ ലൈഫ്സൈക്കിളും, ഒരൊറ്റ ഹുക്കുകളും, ഡിപെൻഡൻസികൾ നിയന്ത്രിക്കാൻ ഒരൊറ്റ സ്ഥലവും പങ്കിടുന്നു. പുതിയ പ്ലഗിൻ സിസ്റ്റത്തെ ചെറുതാക്കിയില്ല, പകരം അതിന്റെ അതിരുകളെ വ്യക്തമാക്കി. കുറഞ്ഞ പ്ലഗിനുകൾ ഉണ്ടാകുന്നതിനേക്കാൾ ഉപകാരപ്രദമാണ് ഇത് എന്ന് തെളിഞ്ഞു.
റിസ്കുകളും പ്രതിവാദങ്ങളും
അച്ചടക്കമുള്ള ഒരു കോൺട്രാക്റ്റ്-ഫസ്റ്റ് (contract-first) സമീപനവും ഘട്ടം ഘട്ടമായുള്ള റോൾഔട്ടും (rollout) റിസ്കുകൾ നിയന്ത്രിക്കാൻ സഹായിക്കുമെന്ന് ഒപ്പ്ടിസ്ട്രീം കേസ് കാണിച്ചുതരുന്നു.
അടുത്തതായി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
സമാനമായ ഒരു സംയോജനമാണ് നിങ്ങൾ ആലോചിക്കുന്നതെങ്കിൽ, ഈ രണ്ട് കാര്യങ്ങളിൽ നിന്ന് തുടങ്ങുക:
- URL സ്ഥിരത – ഒരു വരി കോഡ് എഴുതുന്നതിന് മുമ്പ് എല്ലാ പബ്ലിക് പാത്തുകളും മാപ്പ് ചെയ്യുക.
- ഡാറ്റ സ്ഥിരത – ഒരു ഫുൾ മൈഗ്രേഷന് തയ്യാറല്ലെങ്കിൽ ഡാറ്റാബേസ് ഫീൽഡുകളുടെ പേര് മാറ്റുന്നത് ഒഴിവാക്കുക.
അതിനുശേഷം, ഒരു ചെറിയ ലോഡർ നിർമ്മിക്കുക, CSS സ്കോപ്പ് ചെയ്യുക, കൃത്യമായ ഒരു പ്രൊഡക്ഷൻ ചെക്ക്ലിസ്റ്റ് ഉപയോഗിച്ചുകൊണ്ട് ഓരോ മോഡ്യൂളായി മാറ്റുക.