Firebase ನಲ್ಲಿ ಕಸ್ಟಮ್ ಇ-ಕಾಮರ್ಸ್ (Custom E-commerce on Firebase)

ನಾನು ಮೊದಲಿನಿಂದಲೇ (from scratch) ಒಂದು ಕಸ್ಟಮ್ ಇ-ಕಾಮರ್ಸ್ ಸೈಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ನಾನು ಸಿದ್ಧವಾಗಿರುವ (off-the-shelf) ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳನ್ನು ಬಳಸಲಿಲ್ಲ. ಬದಲಾಗಿ, Firebase Realtime Database ಮತ್ತು Netlify ಅನ್ನು ಬಳಸಿದೆ.

ಕ್ಲೈಂಟ್‌ಗೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸೆಟಪ್ ಅಗತ್ಯವಿತ್ತು. ಅವರಿಗೆ ಬೆಲೆ ವ್ಯತ್ಯಾಸಗಳೊಂದಿಗೆ (pricing variants) ಉತ್ಪನ್ನಗಳ ಕ್ಯಾಟಲಾಗ್ ಮತ್ತು ಅಡ್ಮಿನ್ ಪ್ಯಾನಲ್ ಬೇಕಾಗಿತ್ತು. ಅಲ್ಲದೆ, ಅವರ ಸೇಲ್ಸ್ ತಂಡವು ನೇರವಾಗಿ ಸೈಟ್‌ನಿಂದಲೇ ಆರ್ಡರ್‌ಗಳನ್ನು ಮಾಡುವಂತಾಗಬೇಕಿತ್ತು.

ಪ್ರಮುಖ ತಾಂತ್ರಿಕ ಸವಾಲುಗಳನ್ನು ನಾನು ಹೇಗೆ ಪರಿಹರಿಸಿದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ.

ಡೇಟಾ ಪ್ರತ್ಯೇಕತೆ (Data Separation)

ನಾನು ಇ-ಕಾಮರ್ಸ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಆಂತರಿಕ ನಿರ್ವಹಣಾ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿರಿಸಿದೆ. ಇದು ವಾಣಿಜ್ಯ ಡೇಟಾವು ಉದ್ಯೋಗಿಗಳ ಸಂಬಳ ಅಥವಾ ಬಜೆಟ್‌ನಂತಹ ಸೂಕ್ಷ್ಮ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಬೆರೆಯದಂತೆ ತಡೆಯುತ್ತದೆ.

ಬೆಲೆಗಾಗಿ ಡೇಟಾ ಮಾಡೆಲಿಂಗ್ (Data Modeling for Pricing)

ಬೆಲೆ ಯೋಜನೆಗಳು (Pricing plans) ಹೆಚ್ಚಾಗಿ ವಿವಿಧ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತವೆ. ನೀವು ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನದ ಒಳಗೆ ಯೋಜನೆಯ ಡೇಟಾವನ್ನು ಡೂಪ್ಲಿಕೇಟ್ ಮಾಡಿದರೆ, ಅಪ್‌ಡೇಟ್‌ಗಳು ತಲೆನೋವಾಗಿ ಪರಿಣಮಿಸುತ್ತವೆ.

  • ನಾನು ಎಲ್ಲಾ ಯೋಜನೆಗಳಿಗಾಗಿ ಒಂದು ಗ್ಲೋಬಲ್ ಆರ್ಕೈವ್ ಅನ್ನು ರಚಿಸಿದೆ.
  • ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನವು ಕೇವಲ ಪ್ಲಾನ್ ಐಡಿಗಳ (plan IDs) ಅರೇ ಅನ್ನು ಮಾತ್ರ ಹೊಂದಿರುತ್ತದೆ.
  • ಇದು ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾ ದೋಷಗಳನ್ನು ತಡೆಯುತ್ತದೆ.

ಅಟಾಮಿಕ್ ಆರ್ಡರ್ ನಂಬರಿಂಗ್ (Atomic Order Numbering)

ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಜನರು ಆರ್ಡರ್ ಮಾಡಿದಾಗ, ನೀವು 'ರೇಸ್ ಕಂಡೀಷನ್' (race condition) ಎದುರಿಸುತ್ತೀರಿ. ಇಬ್ಬರು ಬಳಕೆದಾರರು ಒಂದೇ ಕೊನೆಯ ಆರ್ಡರ್ ಸಂಖ್ಯೆಯನ್ನು ಓದಿದರೆ, ಒಂದು ಆರ್ಡರ್ ಅಳಿಸಿಹೋಗಬಹುದು (overwritten).

  • ಇದನ್ನು ಪರಿಹರಿಸಲು ನಾನು Firebase transactions ಬಳಸಿದೆ.
  • runTransaction ಫಂಕ್ಷನ್ ಅನೇಕ ಏಕಕಾಲಿಕ ಬಳಕೆದಾರರಿದ್ದರೂ ಸಹ ಸಂಖ್ಯೆಯು ಸರಿಯಾಗಿ ಹೆಚ್ಚಾಗುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
  • ಇದು ಪ್ರತಿಯೊಂದು ಆರ್ಡರ್ ವಿಶಿಷ್ಟ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿರುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಸುರಕ್ಷಿತ ಅಡ್ಮಿನ್ ಪ್ರವೇಶ (Secure Admin Access)

ನಾನು ಸೋರ್ಸ್ ಕೋಡ್‌ನಲ್ಲಿ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಇಷ್ಟಪಡಲಿಲ್ಲ. ನಾನು MD5 ನಂತಹ ಸರಳ ಹ್ಯಾಶ್‌ಗಳನ್ನು ಸಹ ಬಳಸಲಿಲ್ಲ.

  • ನಾನು Web Crypto API ಮೂಲಕ PBKDF2 ಅನ್ನು ಬಳಸಿದೆ.
  • ಇದು ಹ್ಯಾಶ್‌ಗೆ ಸಾವಿರಾರು ಇಟರೇಶನ್‌ಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ.
  • ಇದು ಹ್ಯಾಕರ್‌ಗಳಿಗೆ ಬ್ರೂಟ್-ಫೋರ್ಸ್ ಅಟ್ಯಾಕ್‌ಗಳನ್ನು (brute-force attacks) ಮಾಡುವುದು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ.
  • ನಾನು ಕೋಡ್‌ನಲ್ಲಿ ಕೇವಲ ಸಾಲ್ಟ್ (salt) ಮತ್ತು ಹ್ಯಾಶ್ ಅನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸುತ್ತೇನೆ.

'Zero' ಬಗ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದು (Correcting the 'Zero' Bug)

ಬೆಲೆ 0 ಇರುವ ಉತ್ಪನ್ನಗಳು "price to be defined" ಎಂದು ತೋರಿಸುವ ಒಂದು ಬಗ್ ಅನ್ನು ನಾನು ಕಂಡುಕೊಂಡೆ.

  • JavaScript 0 ಅನ್ನು "falsy" ಎಂದು ಪರಿಗಣಿಸುವುದರಿಂದ ಇದು ಸಂಭವಿಸಿತು.
  • ನಾನು ನನ್ನ ಲಾಜಿಕ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ಇದನ್ನು ಸರಿಪಡಿಸಿದೆ.
  • "price || null" ಬಳಸುವ ಬದಲಿಗೆ, ನಾನು "price != null" ಅನ್ನು ಬಳಸಿದೆ.
  • ಇದು ಸಿಸ್ಟಮ್ 0 ಅನ್ನು ಮಾನ್ಯವಾದ ಸಂಖ್ಯೆಯಾಗಿ ಗುರುತಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.

CSP ಕಾನ್ಫಿಗರೇಶನ್ (CSP Configuration)

Firebase ಡೈನಾಮಿಕ್ ಸಬ್‌ಡೊಮೇನ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. Content Security Policy (CSP) ಗಾಗಿ ಬಳಸುವ ಸಾಮಾನ್ಯ HTML meta ಟ್ಯಾಗ್ ಈ ವೈಲ್ಡ್‌ಕಾರ್ಡ್‌ಗಳನ್ನು (wildcards) ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

  • ನಾನು CSP ಅನ್ನು HTML ನಿಂದ Netlify HTTP ಹೆಡರ್ಸ್‌ಗೆ ವರ್ಗಾಯಿಸಿದೆ.
  • ಇದು Firebase ಸೇವೆಗಳು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲು ವೈಲ್ಡ್‌ಕಾರ್ಡ್‌ಗಳನ್ನು ಬಳಸಲು ನನಗೆ ಅನುಮತಿಸಿತು.

ಕಸ್ಟಮ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಕೇವಲ ಕೋಡ್ ಬರೆಯುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬಯಸುತ್ತದೆ. ಇದು ಪ್ರೊಡಕ್ಷನ್ ವೈಫಲ್ಯಗಳನ್ನು ತಡೆಯುವ ವಾಸ್ತುಶಿಲ್ಪದ ಆಯ್ಕೆಗಳನ್ನು (architectural choices) ಮಾಡುವುದನ್ನು ಬಯಸುತ್ತದೆ.

ಮೂಲ: https://dev.to/androve2k/custom-e-commerce-on-firebase-catalog-atomic-orders-and-admin-panel-42ec