Firebase-இல் ஒரு தனிப்பயனாக்கப்பட்ட (Custom) இ-காமர்ஸ் தளம்

நான் ஒரு தனிப்பயனாக்கப்பட்ட இ-காமர்ஸ் தளத்தை ஆரம்பத்திலிருந்து உருவாக்கினேன். நான் தயாராகக் கிடைக்கும் தளங்களைப் (off-the-shelf platforms) பயன்படுத்தவில்லை. அதற்குப் பதிலாக, Firebase Realtime Database மற்றும் Netlify ஆகியவற்றைப் பயன்படுத்தினேன்.

வாடிக்கையாளருக்கு ஒரு குறிப்பிட்ட அமைப்பு தேவைப்பட்டது. அவர்களுக்கு விலைப் மாற்றங்களுடன் கூடிய ஒரு தயாரிப்புப் பட்டியல் (product catalog) மற்றும் ஒரு நிர்வாகக் குழு (admin panel) தேவைப்பட்டது. மேலும், அவர்களின் விற்பனை குழு நேரடியாகத் தளத்திலிருந்து ஆர்டர்களைச் செய்ய வேண்டியிருந்தது.

முக்கியத் தொழில்நுட்ப சவால்களை நான் எவ்வாறு தீர்த்தேன் என்பது இதோ.

தரவுப் பிரிப்பு (Data Separation)

இ-காமர்ஸ் தரவுத்தளத்தை (database) உள் நிர்வாகத் தரவுத்தளத்திலிருந்து தனித்துப் பிரித்து வைத்தேன். இது வணிகத் தரவுகள், ஊழியர்களின் சம்பளம் அல்லது பட்ஜெட் போன்ற முக்கியமான கோப்புகளுடன் கலப்பதைத் தடுக்கிறது.

விலையிடலுக்கான தரவு மாதிரி (Data Modeling for Pricing)

விலையிடல் திட்டங்கள் (Pricing plans) பெரும்பாலும் வெவ்வேறு தயாரிப்புகளில் மீண்டும் மீண்டும் வரும். ஒவ்வொரு தயாரிப்பிற்குள்ளும் திட்டத் தரவை நகலெடுத்தால், அவற்றை மேம்படுத்துவது (updates) மிகவும் கடினமாகிவிடும்.

• அனைத்துத் திட்டங்களுக்கும் ஒரு உலகளாவிய ஆவணக் களஞ்சியத்தை (global archive) உருவாக்கினேன்.
• ஒவ்வொரு தயாரிப்பும் திட்ட ஐடிகளின் (plan IDs) ஒரு வரிசையை (array) மட்டுமே கொண்டிருக்கும்.
• இது மேம்படுத்தல்களை விரைவுபடுத்துவதோடு தரவுப் பிழைகளையும் தடுக்கிறது.

அணுக்கமான ஆர்டர் எண் முறை (Atomic Order Numbering)

ஒரே நேரத்தில் பல நபர்கள் ஆர்டர் செய்யும்போது, 'race condition' என்ற சிக்கல் ஏற்படும். இரண்டு பயனர்கள் ஒரே கடைசி ஆர்டர் எண்ணைப் படித்தால், ஒரு ஆர்டர் மற்றொன்றால் மாற்றப்படும் (overwritten).

• இதைத் தீர்க்க Firebase transactions-ஐப் பயன்படுத்தினேன்.
• runTransaction செயல்பாடு, ஒரே நேரத்தில் பல பயனர்கள் இருந்தாலும், எண் சரியாக அதிகரிப்பதை உறுதி செய்கிறது.
• இது ஒவ்வொரு ஆர்டருக்கும் ஒரு தனித்துவமான எண் இருப்பதை உறுதி செய்கிறது.

பாதுகாப்பான நிர்வாக அணுகல் (Secure Admin Access)

நான் கடவுச்சொற்களை மூலக் குறியீட்டில் (source code) சேமிக்க விரும்பவில்லை. MD5 போன்ற எளிய ஹாஷ்களையும் (hashes) நான் தவிர்த்தேன்.

• Web Crypto API மூலம் PBKDF2-ஐப் பயன்படுத்தினேன்.
• இது ஹாஷிற்கு ஆயிரக்கணக்கான முறைகளை (iterations)ச் செய்கிறது.
• இது ஹேக்கர்களுக்கு 'brute-force' தாக்குதல்களை மிகவும் கடினமாக்குகிறது.
• நான் குறியீட்டில் salt மற்றும் hash ஆகியவற்றை மட்டுமே சேமிக்கிறேன்.

'பூஜ்ஜியம்' பிழையைச் சரிசெய்தல் (Correcting the 'Zero' Bug)

விலை 0 ஆக இருக்கும் தயாரிப்புகள் "விலை பின்னர் அறிவிக்கப்படும்" (price to be defined) என்று காட்டுவது போன்ற ஒரு பிழையைக் கண்டறிந்தேன்.

• JavaScript 0-வை "falsy" எனக் கருதுவதால் இது நடந்தது.
• எனது தர்க்கத்தை (logic) மாற்றுவதன் மூலம் இதைச் சரிசெய்தேன்.
• "price || null" என்பதற்குப் பதிலாக, "price != null" என்பதைப் பயன்படுத்தினேன்.
• இது கணினி 0-வை ஒரு சரியான எண்ணாக அங்கீகரிப்பதை உறுதி செய்கிறது.

CSP கட்டமைப்பு (CSP Configuration)

Firebase மாறும் துணைடொமைன்களை (dynamic subdomains) பயன்படுத்துகிறது. Content Security Policy (CSP)-க்கான ஒரு சாதாரண HTML meta tag இந்த வைல்ட்கார்டுகளை (wildcards) கையாள முடியாது.

• நான் CSP-யை HTML-லிருந்து Netlify HTTP headers-க்கு மாற்றினேன்.
• இது Firebase சேவைகள் சரியாகச் செயல்பட வைல்ட்கார்டுகளைப் பயன்படுத்த எனக்கு அனுமதித்தது.

தனிப்பயனாக்கப்பட்ட அமைப்புகளை உருவாக்குவதற்கு வெறும் குறியீடு எழுதுவது மட்டும் போதாது. உற்பத்திச் சிக்கல்களைத் (production failures) தவிர்க்கும் கட்டமைப்புத் தேர்வுகளை (architectural choices) எடுப்பதும் அவசியம்.

மூலம்: https://dev.to/androve2k/custom-e-commerce-on-firebase-catalog-atomic-orders-and-admin-panel-42ec