മാച്ച് ദിവസം തുടങ്ങുന്നത് വരെ എന്റെ ഫുട്ബോൾ ആപ്പ് കൃത്യമായി പ്രവർത്തിച്ചു

𝗠𝘆 𝗙𝗼𝗼𝘁𝗯𝗮𝗹𝗹 𝗔𝗽𝗽 𝗪𝗼𝗿𝗸𝗲𝗱 𝗣𝗲𝗿𝗳𝗲𝗰𝘁𝗹𝘆 𝗨𝗻𝘁𝗶𝗹 𝗠𝗮𝘁𝗰𝗵𝗱𝗮𝘆 𝗦𝘁𝗮𝗿𝘁𝗲𝗱

ഒരു ഫുട്ബോൾ ആപ്പ് നിർമ്മിക്കുന്നത് ആദ്യം എളുപ്പമാണെന്ന് തോന്നി.

മത്സരങ്ങളുടെ വിവരങ്ങൾ ശേഖരിക്കാനും (fetch), ടീമുകളെ കാണിക്കാനും, സ്കോറുകൾ കാണിക്കാനും, ഓരോ കുറച്ച് സെക്കൻഡിലും പുതുക്കാനും (refresh) ഞാൻ പ്ലാൻ ചെയ്തു. ടെസ്റ്റിംഗ് സമയത്ത് ഇത് നന്നായി പ്രവർത്തിച്ചു. ഞാൻ രണ്ട് ടാബുകളും കുറച്ച് സാമ്പിൾ മത്സരങ്ങളും ഉപയോഗിച്ചു. എല്ലാം ശരിയായിരുന്നു.

പിന്നീട് ആദ്യത്തെ തിരക്കുള്ള മത്സരദിവസം എത്തി.

നൂറുകണക്കിന് ഉപയോക്താക്കൾ ഒരേസമയം ആപ്പ് തുറന്നു. റിക്വസ്റ്റുകൾ പരസ്പരം കൂട്ടിമുട്ടി (overlapped). ചില സ്കോറുകൾ പിന്നോട്ട് മാറുന്നതായി തോന്നി. ഓരോ സന്ദർശകനും ആപ്പ് ഒരേ ഡാറ്റ തന്നെ പ്രത്യേകം പ്രത്യേകം ശേഖരിക്കുകയായിരുന്നു.

ഒരു ലൈവ് ആപ്പ് എന്നത് ഒരു API-യുമായി ബന്ധിപ്പിച്ചിട്ടുള്ള വെബ്സൈറ്റ് മാത്രമല്ലെന്ന് ഞാൻ മനസ്സിലാക്കി. അതൊരു ഡാറ്റാ സിൻക്രണൈസേഷൻ സിസ്റ്റം (data synchronization system) ആണ്.

ഞാൻ ചെയ്ത തെറ്റുകളും അവ എങ്ങനെ പരിഹരിച്ചുവെന്നും താഴെ നൽകുന്നു:

• ക്ലയന്റ് സൈഡ് പോളിംഗ് (client-side polling) മാത്രം ഒഴിവാക്കുക എന്റെ ആദ്യ പതിപ്പിൽ ഓരോ ബ്രൗസറും ഓരോ അഞ്ച് സെക്കൻഡിലും ഡാറ്റ ആവശ്യപ്പെട്ടിരുന്നു. 1 ഉപയോക്താവ് = മിനിറ്റിൽ 12 റിക്വസ്റ്റുകൾ. 1,000 ഉപയോക്താക്കൾ = മിനിറ്റിൽ 12,000 റിക്വസ്റ്റുകൾ. മിക്ക റിക്വസ്റ്റുകളും ഒരേ ഡാറ്റ തന്നെയായിരുന്നു ആവശ്യപ്പെട്ടത്.

• സെർവർ സൈഡ് റിക്വസ്റ്റുകൾ ഉപയോഗിക്കുക ഞാൻ API കോളുകൾ സെർവറിലേക്ക് മാറ്റി. ഇത് നിങ്ങൾക്ക് താഴെ പറയുന്നവയിൽ നിയന്ത്രണം നൽകുന്നു: • API credentials • Caching • Rate limiting • Error handling • Response formatting

ക്ലയന്റ് സൈഡ് കോഡിൽ ഒരിക്കലും കീകൾ (keys) ഉപയോഗിക്കരുത്. ആരെങ്കിലും നിങ്ങളുടെ കീ മോഷ്ടിച്ചാൽ അത് സുരക്ഷിതമല്ലെന്ന് മാത്രമല്ല, വലിയ നഷ്ടവും ഉണ്ടാക്കും.

• ഒരു മാപ്പിംഗ് ലെയർ (mapping layer) നിർമ്മിക്കുക ഞാൻ API-യിൽ നിന്നുള്ള ഡാറ്റ നേരിട്ട് എന്റെ കമ്പോണന്റുകളിലേക്ക് (components) നൽകുന്നത് നിർത്തി. ഡാറ്റാ പ്രൊവൈഡർ ഒരു ഫീൽഡിന്റെ പേര് മാറ്റിയാൽ എന്റെ UI തകരാറിലാകുമായിരുന്നു. ഇപ്പോൾ, ഞാൻ പ്രൊവൈഡർ നൽകുന്ന ഡാറ്റയെ ആദ്യം എന്റെ തന്നെ ആന്തരിക ഫോർമാറ്റിലേക്ക് മാപ്പിംഗ് ചെയ്യുന്നു. ഇത് എന്റെ UI സ്ഥിരതയുള്ളതാക്കുന്നു.

• വേഗതയ്ക്കായി സെർവർ കമ്പോണന്റുകൾ (Server Components) ഉപയോഗിക്കുക ഒരു ലോഡിംഗ് സ്ക്രീൻ കാണിക്കുന്നതിന് പകരം, ഞാൻ ആദ്യത്തെ മത്സരങ്ങൾ സെർവറിൽ തന്നെ ലോഡ് ചെയ്യുന്നു. ഉപയോക്താവിന് ഉടൻ തന്നെ ഉള്ളടക്കം കാണാൻ സാധിക്കുന്നു.

• സ്മാർട്ട് പോളിംഗ് (smart polling) നടപ്പിലാക്കുക ലൈവ് മത്സരങ്ങൾ ഇല്ലെങ്കിൽ ആപ്പ് പുതുക്കേണ്ടതില്ല. മത്സരങ്ങൾ അവസാനിക്കുമ്പോൾ പോളിംഗ് നിർത്താനുള്ള ഒരു സംവിധാനം ഞാൻ ചേർത്തു. ഇത് സെർവർ റിസോഴ്സുകൾ വലിയ തോതിൽ ലാഭിക്കുന്നു.

• റേസ് കണ്ടീഷനുകൾ (race conditions) പരിഹരിക്കുക ചിലപ്പോൾ റിക്വസ്റ്റ് A വരുന്നതിന് മുമ്പ് റിക്വസ്റ്റ് B വരാം. ഇത് സ്കോറുകൾ പിന്നോട്ട് മാറുന്നതായി തോന്നിപ്പിക്കുന്നു. പുതിയ റിക്വസ്റ്റുകൾ തുടങ്ങുന്നതിന് മുമ്പ് പഴയവ റദ്ദാക്കാൻ ഞാൻ ഒരു AbortController ഉപയോഗിക്കുന്നു.

• പിശകുകൾ (errors) കൃത്യമായി കൈകാര്യം ചെയ്യുക ഡാറ്റ പുതുക്കുന്നത് പരാജയപ്പെട്ടാൽ, ഒരു ശൂന്യമായ സ്ക്രീൻ കാണിക്കരുത്. അവസാനമായി വിജയകരമായി ലഭിച്ച ഡാറ്റ തന്നെ കാണിക്കുക. സ്കോർ കാണാത്തതിനേക്കാൾ നല്ലത് പതിനഞ്ച് സെക്കൻഡ് പഴക്കമുള്ള സ്കോർ കാണിക്കുന്നതാണ്.

ഒരു ഡെമോയ്ക്ക് ഡാറ്റ കാണിച്ചാൽ മാത്രം മതി. എന്നാൽ ഒരു യഥാർത്ഥ ഉൽപ്പന്നം (product) കാഷിംഗ് (caching), സുരക്ഷ (security), സ്റ്റേറ്റ് (state) എന്നിവ കൃത്യമായി കൈകാര്യം ചെയ്യണം.

നിങ്ങൾ എപ്പോഴെങ്കിലും ഒരു ലൈവ് ആപ്പ് നിർമ്മിച്ചിട്ടുണ്ടോ? യഥാർത്ഥ ഉപയോക്താക്കൾ എത്തിയപ്പോൾ എന്താണ് തകരാറിലായത്?

സ്രോതസ്സ്: https://dev.to/mihailove123/my-football-app-worked-perfectly-until-matchday-started-3i59