സബ്സ്ക്രിപ്ഷനുകൾ ഇല്ലാതെ ലൈവ് വെബ്സൈറ്റ് സന്ദർശകരെ ട്രാക്ക് ചെയ്യാം
ഒരു ക്ലയന്റിന് തങ്ങളുടെ വെബ്സൈറ്റിൽ തത്സമയം (real time) ആരെല്ലാം ഉണ്ടെന്ന് കാണണമെന്ന് ആഗ്രഹമുണ്ടായിരുന്നു.
അവർക്ക് Tidio വിഡ്ജറ്റ് ഇഷ്ടപ്പെട്ടെങ്കിലും സബ്സ്ക്രിപ്ഷനായി പണം നൽകാൻ അവർ ആഗ്രഹിച്ചില്ല.
ഈ വെല്ലുവിളിക്ക് രണ്ട് ഭാഗങ്ങളുണ്ടായിരുന്നു:
- സൈറ്റ് വ്യത്യസ്ത ഹോസ്റ്റിംഗിൽ WordPress ആണ് ഉപയോഗിച്ചിരുന്നത്.
- എനിക്ക് Firebase നേരിട്ട് WordPress സെറ്റപ്പിലേക്ക് ചേർക്കാൻ കഴിഞ്ഞില്ല.
ഞാൻ Firebase ഉപയോഗിച്ച് ഒരു എക്സ്റ്റേണൽ ട്രാക്കർ നിർമ്മിച്ചു. അത് എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത് എന്ന് നോക്കാം.
പരിഹാരം
ഞാൻ WordPress ഹെഡറിൽ ഒരു സിംഗിൾ സ്ക്രിപ്റ്റ് ടാഗ് ഉപയോഗിച്ചു. ഈ സ്ക്രിപ്റ്റ് ഒരു സ്വതന്ത്രമായ Firebase പ്രോജക്റ്റുമായി ബന്ധിപ്പിക്കുന്നു.
• Live Presence: ഞാൻ Firebase Realtime Database-ഉം onDisconnect() ഫങ്ക്ഷനും ഉപയോഗിച്ചു. ഉപയോക്താവ് അവരുടെ ടാബ് അടയ്ക്കുകയോ കണക്ഷൻ നഷ്ടപ്പെടുകയോ ചെയ്യുമ്പോൾ ഇത് അവരെ "online" ലിസ്റ്റിൽ നിന്ന് സ്വയമേവ നീക്കം ചെയ്യുന്നു.
• Visitor History: Firestore-ലേക്ക് ഡാറ്റ എഴുതാൻ ഞാൻ ഒരു Netlify Function ഉപയോഗിച്ചു. ഇത് സെർവർ സൈഡ് IP ജിയോലൊക്കേഷൻ (IP geolocation) സാധ്യമാക്കുന്നു.
• Security: ഞാൻ അനോനിമസ് ഓതന്റിക്കേഷൻ (anonymous authentication) ഉപയോഗിച്ചു. സന്ദർശകർക്ക് അവരുടെ സ്വന്തം സെഷൻ നോഡിലേക്ക് മാത്രമേ ഡാറ്റ എഴുതാൻ കഴിയൂ. അഡ്മിന് മാത്രമേ മുഴുവൻ ലിസ്റ്റും വായിക്കാൻ കഴിയൂ.
സാങ്കേതിക തടസ്സങ്ങൾ
ഇത് നിർമ്മിക്കുന്നത് അത്ര എളുപ്പമായിരുന്നില്ല. എനിക്ക് മൂന്ന് പ്രധാന സാങ്കേതിക തടസ്സങ്ങൾ നേരിടേണ്ടി വന്നു.
1. കാഷിംഗ് കെണി (The Caching Trap)
ഹിസ്റ്ററിയിൽ സീറോ സെഷനുകൾ മാത്രമാണ് കാണിച്ചത്. ട്രാക്കർ സ്ക്രിപ്റ്റിന് ഒരു വർഷത്തെ കാഷ് പോളിസി (cache policy) ഉണ്ടെന്ന് ഞാൻ കണ്ടെത്തി. സന്ദർശകർ സ്ക്രിപ്റ്റിന്റെ പഴയ പതിപ്പ് തന്നെ ഉപയോഗിച്ചുകൊണ്ടിരിക്കുകയായിരുന്നു.
- പരിഹാരം: ഞാൻ ട്രാക്കർ സ്ക്രിപ്റ്റിനായി അഞ്ച് മിനിറ്റ് കാഷ് പോളിസി നിശ്ചയിച്ചു.
2. വ്യാജ CORS എറർ (The Fake CORS Error)
ബ്രൗസർ ഒരു CORS എറർ കാണിച്ചു. ഡൊമെയ്ൻ വൈറ്റ്ലിസ്റ്റ് (domain whitelist) പ്രശ്നമാണെന്നാണ് ഞാൻ കരുതിയത്. എന്നാൽ ഒരു ലളിതമായ curl ടെസ്റ്റ് ചെയ്തപ്പോൾ സെർവർ കൃത്യമായി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് മനസ്സിലായി.
സത്യം മറ്റൊന്നായിരുന്നു. സെർവർ യഥാർത്ഥത്തിൽ ക്രാഷ് (crash) ആകുകയായിരുന്നു.
Node.js-ൽ, നിങ്ങൾ ഒരു 204 സ്റ്റാറ്റസ് കോഡ് ഉപയോഗിക്കുകയാണെങ്കിൽ, ബോഡി (body) ആയി ഒരു ശൂന്യമായ സ്ട്രിംഗ് (empty string) ഉപയോഗിക്കാൻ കഴിയില്ല. പകരം null ഉപയോഗിക്കണം. CORS ഹെഡറുകൾ അയക്കുന്നതിന് മുമ്പ് തന്നെ ആ ശൂന്യമായ സ്ട്രിംഗ് സെർവറിനെ ക്രാഷ് ആക്കി. ഹെഡറുകൾ ഒന്നും കാണാത്തതിനാൽ ബ്രൗസർ ഇതൊരു CORS പ്രശ്നമാണെന്ന് കരുതി.
- പരിഹാരം: റെസ്പോൺസ് ബോഡി
''എന്നതിൽ നിന്ന്nullഎന്നാക്കി മാറ്റി.
3. ഡാറ്റാ വിടവ് (The Missing Data Gap)
"Today" അല്ലെങ്കിൽ "Last 7 Days" ഫിൽട്ടറുകൾ ഉപയോഗിച്ചപ്പോൾ ഒന്നും ലഭിച്ചില്ല. ചില ഉപയോക്താക്കളുടെ ലൊക്കേഷൻ "Unknown" എന്ന് കാണിച്ചു. ആദ്യത്തെ പേജ് ലോഡ് ചെയ്യുമ്പോൾ മാത്രമാണ് ഞാൻ ടൈംസ്റ്റാമ്പും (timestamp) ലൊക്കേഷനും കണക്കാക്കിയത് എന്നതുകൊണ്ടാണ് ഇത് സംഭവിച്ചത്. ഒരു ഉപയോക്താവിന്റെ ബ്രൗസറിൽ പഴയൊരു സെഷൻ ഉണ്ടെങ്കിൽ, സെർവർക്ക് "start" ഇവന്റ് നഷ്ടപ്പെടും.
- പരിഹാരം: ഞാൻ ഈ കണക്കുകൂട്ടൽ ഐഡംപോറ്റന്റ് (idempotent) ആക്കി മാറ്റി. ഇപ്പോൾ ഓരോ ഇവന്റിനും സ്ക്രിപ്റ്റ് ഈ മൂല്യങ്ങൾ വീണ്ടും കണക്കാക്കുന്നു.
പ്രധാന പാഠങ്ങൾ
• ബ്രൗസറിലെ ഒരു CORS എറർ എല്ലായ്പ്പോഴും കോൺഫിഗറേഷൻ പ്രശ്നമാകണമെന്നില്ല. അത് ഒരു സെർവർ ക്രാഷിനെ മറച്ചുവെച്ചേക്കാം. എപ്പോഴും നിങ്ങളുടെ സെർവർ ലോഗുകൾ പരിശോധിക്കുക.
• ഒരു curl POST ടെസ്റ്റ് ബ്രൗസറിനെ പരിശോധിക്കുന്നില്ല. ബ്രൗസറുകൾ ആദ്യം ഒരു OPTIONS preflight റിക്വസ്റ്റ് അയക്കുന്നു. നിങ്ങളുടെ ടെസ്റ്റ് കൃത്യമാകണമെങ്കിൽ ഇതിനെക്കൂടി ഉൾപ്പെടുത്തണം.
• 204 പോലുള്ള "no content" HTTP സ്റ്റാറ്റസുകൾക്കായി null ഉപയോഗിക്കുക. ശൂന്യമായ സ്ട്രിംഗുകൾ (empty strings) ഉപയോഗിക്കരുത്.