எனது கால்பந்து செயலி போட்டி நாள் தொடங்கும் வரை மிகச்சரியாகச் செயல்பட்டது

ஒரு கால்பந்து செயலியை உருவாக்குவது முதலில் எளிதாகத் தோன்றியது.

போட்டிகளைப் பெறுதல் (fetch), அணிகளைக் காட்டுதல், ஸ்கோர்களைக் காட்டுதல் மற்றும் ஒவ்வொரு சில வினாடிகளுக்கும் புதுப்பித்தல் (refresh) ஆகியவற்றைச் செய்யத் திட்டமிட்டேன். சோதனை முயற்சியின் போது இது நன்றாகச் செயல்பட்டது. நான் இரண்டு டேப்கள் (tabs) மற்றும் சில மாதிரிப் போட்டிகளைப் பயன்படுத்தினேன். அனைத்தும் சரியாகத் தெரிந்தன.

பிறகு, முதல் பரபரப்பான போட்டி நாள் வந்தது.

நூற்றுக்கணக்கான பயனர்கள் ஒரே நேரத்தில் செயலியைத் திறந்தனர். கோரிக்கைகள் (Requests) ஒன்றன் மேல் ஒன்று மோதின. சில ஸ்கோர்கள் பின்னோக்கி நகர்வது போல் தோன்றியது. ஒவ்வொரு பார்வையாளருக்கும் செயலி தனித்தனியாக அதே தரவை (data) எடுத்தது.

ஒரு நேரலைச் செயலி (live app) என்பது வெறும் API உடன் இணைக்கப்பட்ட இணையதளம் மட்டுமல்ல என்பதை நான் கற்றுக்கொண்டேன். அது ஒரு தரவு ஒத்திசைவு அமைப்பு (data synchronization system).

நான் செய்த தவறுகள் மற்றும் அவற்றை நான் எவ்வாறு சரி செய்தேன் என்பது இங்கே:

  • கிளையண்ட்-சைடு (client-side) பாலிங் முறையைத் தவிர்க்கவும் எனது முதல் பதிப்பில், ஒவ்வொரு உலாவியும் (browser) ஒவ்வொரு ஐந்து வினாடிகளுக்கும் தரவைக் கோரியது. 1 பயனர் = நிமிடத்திற்கு 12 கோரிக்கைகள். 1,000 பயனர்கள் = நிமிடத்திற்கு 12,000 கோரிக்கைகள். பெரும்பாலான கோரிக்கைகள் துல்லியமாக ஒரே தரவையே கேட்டன.

  • சர்வர்-சைடு (server-side) கோரிக்கைகளைப் பயன்படுத்தவும் நான் API அழைப்புகளை (calls) சர்வருக்கு மாற்றினேன். இது உங்களுக்குக் கீழ்க்கண்டவற்றைக் கட்டுப்படுத்த வழிவகை செய்கிறது: • API சான்றுகள் (credentials) • கேச்சிங் (Caching) • ரேட் லிமிட்டிங் (Rate limiting) • பிழை கையாளுதல் (Error handling) • பதிலளிக்கும் முறை (Response formatting)

கிளையண்ட்-சைடு குறியீட்டில் (code) ஒருபோதும் கீய்களை (keys) பயன்படுத்தாதீர்கள். யாராவது உங்கள் கீயைத் திருடிவிட்டால் அது பாதுகாப்பற்றது மற்றும் செலவு மிக்கது.

  • ஒரு மேப்பிங் லேயரை (mapping layer) உருவாக்கவும் நான் மூல API தரவை (raw API data) நேரடியாக எனது கூறுகளுக்கு (components) அனுப்புவதை நிறுத்தினேன். தரவு வழங்குநர் (provider) ஒரு புலத்தின் (field) பெயரை மாற்றினால், எனது UI உடைந்துவிடும். இப்போது, நான் வழங்குநரின் தரவை முதலில் எனது சொந்த உள் வடிவத்திற்கு (internal format) மாற்றுகிறேன். இது எனது UI-ஐ நிலையாக வைக்கிறது.

  • வேகத்திற்காக சர்வர் கூறுகளைப் (Server Components) பயன்படுத்தவும் ஒரு லோடிங் திரையைக் (loading screen) காட்டுவதற்குப் பதிலாக, ஆரம்பப் போட்டிகளை நான் சர்வரிலேயே ஏற்றுகிறேன். பயனர் உடனடியாக உள்ளடக்கத்தைப் பார்க்க முடிகிறது.

  • புத்திசாலித்தனமான பாலிங் முறையைச் செயல்படுத்தவும் நேரலை போட்டிகள் எதுவும் இல்லையென்றால் செயலி புதுப்பிக்கப்படக் கூடாது. போட்டிகள் முடிந்ததும் பாலிங்கை நிறுத்துவதற்கான ஒரு சரிபார்ப்பைச் சேர்த்தேன். இது சர்வர் வளங்களை (server resources) பெருமளவில் சேமிக்கிறது.

  • ரேஸ் கண்டிஷன்களைச் (race conditions) சரிசெய்யவும் சில நேரங்களில் கோரிக்கை B, கோரிக்கை A-க்கு முன்பே திரும்பும். இது ஸ்கோர்கள் பின்னோக்கி நகர்வது போல் தோற்றமளிக்கச் செய்கிறது. புதிய கோரிக்கைகளைத் தொடங்குவதற்கு முன் பழைய கோரிக்கைகளை ரத்து செய்ய நான் AbortController-ஐப் பயன்படுத்துகிறேன்.

  • பிழைகளைச் சிறப்பாகக் கையாளவும் புதுப்பித்தல் தோல்வியடைந்தால், வெற்றுத் திரையைக் காட்டாதீர்கள். கடைசியாக வெற்றிகரமாகப் பெறப்பட்ட தரவை அப்படியே வைத்திருக்கவும். பதினைந்து வினாடி பழைய ஸ்கோர் இருப்பது ஸ்கோர் இல்லாமலிருப்பதை விட சிறந்தது.

ஒரு டெமோ (demo) தரவைக் காட்டினால் போதுமானது. ஆனால் ஒரு உண்மையான தயாரிப்பு (product) கேச்சிங், பாதுகாப்பு மற்றும் ஸ்டேட் (state) ஆகியவற்றைக் கையாள வேண்டும்.

நீங்கள் ஒரு நேரலை செயலியை உருவாக்கியிருக்கிறீர்களா? உண்மையான பயனர்கள் வந்தபோது எது உடைந்தது?

ஆதாரம்: https://dev.to/mihailove123/my-football-app-worked-perfectly-until-matchday-started-3i59