𝗦𝗶𝗺𝗽𝗹𝗲 𝗟𝗶𝘃𝗲 𝗖𝗵𝗮𝘁 𝗔𝗹𝗺𝗼𝘀𝘁 𝗦𝗮𝗻𝗸 𝗧𝗵𝗶𝘀 𝗥𝗲𝗹𝗲𝗮𝘀𝗲
ಒಂದು ಸಾಮಾನ್ಯ ಲೈವ್ ಚಾಟ್ ವ್ಯವಸ್ಥೆಯು ನನ್ನ ಇತ್ತೀಚಿನ ಬಿಡುಗಡೆಯನ್ನು ಬಹುತೇಕ ಹಾಳು ಮಾಡಿತ್ತು.
ಇದು ಕೇಳಲು ಸರಳವಾಗಿ ಕಾಣುತ್ತದೆ. ಹತ್ತಿರದ ಬಳಕೆದಾರರನ್ನು ತೋರಿಸುವುದು ಮತ್ತು ಅವರು ಮಾತನಾಡಲು ಅವಕಾಶ ನೀಡುವುದು. ಆದರೆ ತಾಂತ್ರಿಕ ವಾಸ್ತವವು ತುಂಬಾ ಕಠಿಣವಾಗಿದೆ. ನಾನು ಲೈವ್ ಚಾಟ್ ಅನ್ನು ಜಿಯೋಲೊಕೇಶನ್ (geolocation) ಮತ್ತು ರೇಟಿಂಗ್ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಬೇಕಾಯಿತು. ಇದು ಒಳಗಿನ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅಪಾರ ಸಂಕೀರ್ಣತೆಯನ್ನು ಸೃಷ್ಟಿಸಿತು.
ಆರ್ಕಿಟೆಕ್ಚರ್ (The Architecture):
• ಫ್ರಂಟ್ ಎಂಡ್ (Frontend): React ಮತ್ತು TypeScript. • ಬ್ಯಾಕ್ ಎಂಡ್ (Backend): Express ಮತ್ತು WebSockets ನೊಂದಿಗೆ Node.js. • ಡೇಟಾಬೇಸ್ (Database): ಬಳಕೆದಾರರು ಮತ್ತು ರೇಟಿಂಗ್ಗಳಿಗಾಗಿ PostgreSQL. • ಕ್ಯಾಶ್ (Cache): ಸಕ್ರಿಯ ಸೆಷನ್ಗಳು ಮತ್ತು ಪ್ರೆಸೆನ್ಸ್ (presence) ಗಾಗಿ Redis.
ಜಿಯೋಲೊಕೇಶನ್ ಸಮಸ್ಯೆ (The Geolocation Problem)
ಸ್ಥಳದ ಆಧಾರದ ಮೇಲೆ ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿಸುವುದು ಸುಲಭವಲ್ಲ. ನಾನು ಅನೇಕ ಎಡ್ಜ್ ಕೇಸ್ಗಳನ್ನು (edge cases) ನಿರ್ವಹಿಸಬೇಕಾಯಿತು:
- ಅಕ್ಷಾಂಶ (latitude) ಮತ್ತು ರೇಖಾಂಶವನ್ನು (longitude) ಸಂಗ್ರಹಿಸುವುದು.
- ದೂರವನ್ನು ವಿಚಾರಣೆ ಮಾಡಲು (query) Postgres ಎಕ್ಸ್ಟೆನ್ಶನ್ಗಳನ್ನು ಬಳಸುವುದು.
- ಲೊಕೇಶನ್ ಅನುಮತಿಯನ್ನು ನಿರಾಕರಿಸುವ ಬಳಕೆದಾರರನ್ನು ನಿರ್ವಹಿಸುವುದು.
- ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತೆರೆಯದೆ ಬಳಕೆದಾರರು ಚಲಿಸಿದಾಗ ಹಳೆಯ ಡೇಟಾವನ್ನು (stale data) ನಿರ್ವಹಿಸುವುದು.
ನಾನು ಇದನ್ನು ಮತ್ತೆ ಮಾಡಬೇಕಾದರೆ, ಲೊಕೇಶನ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಮತ್ತು ಮ್ಯಾಚಿಂಗ್ ಅನ್ನು ಬೇರೆ ಬೇರೆ ಸೇವೆಗಳಾಗಿ (services) ವಿಂಗಡಿಸುತ್ತಿದ್ದೆ.
ಲೈವ್ ಚಾಟ್ನ ವಾಸ್ತವ (The Live Chat Reality)
WebSockets ನೈಜ-ಸಮಯದ (real-time) ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ತರುತ್ತದೆ, ಆದರೆ ಅವು ಗೊಂದಲವನ್ನೂ ತರುತ್ತವೆ. ವಿವಿಧ ಸರ್ವರ್ಗಳ ಮೂಲಕ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಲು ನಾನು Redis pub/sub ಅನ್ನು ಬಳಸಿದೆ.
ಅತ್ಯಂತ ಕಠಿಣ ಭಾಗಗಳು ಇವುಗಳಾಗಿದ್ದವು:
- ಬಳಕೆದಾರರು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಡಿಸ್ಕನೆಕ್ಟ್ ಆದಾಗ ಕನೆಕ್ಷನ್ಗಳನ್ನು ಕ್ಲೀನ್ ಅಪ್ ಮಾಡುವುದು.
- ಬಳಕೆದಾರರು ಬಿಟ್ಟುಹೋದ ರೂಮ್ಗಳಿಗೆ ಸಂದೇಶಗಳು ಹೋಗದಂತೆ ತಡೆಯುವುದು.
- ಗೋಸ್ಟ್ ಸೆಷನ್ಗಳನ್ನು (ghost sessions) ಸೃಷ್ಟಿಸದೆ ಮರುಸಂಪರ್ಕಗಳನ್ನು (reconnects) ನಿರ್ವಹಿಸುವುದು.
ಸರಳ ಫ್ಲಾಗ್ಗಳನ್ನು (flags) ಬಳಸುವ ಬದಲು ಔಪಚಾರಿಕ ಸ್ಟೇಟ್ ಮೆಷಿನ್ (state machine) ಬಳಸುವುದು ಉತ್ತಮ ಎಂದು ನಾನು ಕಲಿತೆ.
ರೇಟಿಂಗ್ ವ್ಯವಸ್ಥೆ (The Rating System)
ರೇಟಿಂಗ್ ವ್ಯವಸ್ಥೆಯನ್ನು ನೀವು ನಿರ್ಮಿಸುವವರೆಗೆ ಅದು ಅತ್ಯಂತ ಸರಳವಾಗಿ ಕಾಣುತ್ತದೆ. ನಾನು ಇವುಗಳನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕಾಯಿತು:
- ಬಳಕೆದಾರರು ಒಂದೇ ಸೆಷನ್ಗೆ ಎರಡು ಬಾರಿ ರೇಟಿಂಗ್ ನೀಡಲು ಸಾಧ್ಯವಾಗಬಾರದು.
- ಪ್ರೊಫೈಲ್ ವೀಕ್ಷಣೆಗಳಿಗಾಗಿ ರೇಟಿಂಗ್ಗಳು ವೇಗವಾಗಿ ಒಟ್ಟುಗೂಡಿಸಬೇಕು (aggregate).
- ಅಪ್ಲಿಕೇಶನ್ನಾದ್ಯಂತ ಡೇಟಾ ಸ್ಥಿರವಾಗಿರಬೇಕು.
ಡೂಪ್ಲಿಕೇಟ್ಗಳನ್ನು ತಡೆಯಲು ನಾನು ಸೆಷನ್ ಐಡಿಗಳ ಮೇಲೆ ಯೂನಿಕ್ ಕನ್ಸ್ಟ್ರೇಂಟ್ಗಳನ್ನು (unique constraints) ಬಳಸಿದೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು (performance) ಉಳಿಸಲು ಸರಾಸರಿಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡಿದೆ.
ಕಲಿತ ಪಾಠಗಳು (Lessons Learned)
ನಾನು ಇಂದು ಇದನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಿದರೆ, ಮೂರು ವಿಷಯಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತೇನೆ:
- ಮ್ಯಾಚಿಂಗ್ ಮತ್ತು ಚಾಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಮಾಡ್ಯೂಲ್ಗಳಾಗಿ ವಿಂಗಡಿಸುವುದು.
- WebSocket ಕನೆಕ್ಷನ್ ಸ್ಟೇಟ್ಗಳಿಗಾಗಿ ಸ್ಪಷ್ಟ ಮಾದರಿಗೀಕರಣವನ್ನು (explicit modeling) ಬಳಸುವುದು.
- ಮೊದಲ ದಿನದಿಂದಲೇ ಚಾಟ್ ಮತ್ತು ಮ್ಯಾಚಿಂಗ್ಗಾಗಿ ಉತ್ತಮ ಲಾಗ್ಗಳು (logs) ಮತ್ತು ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಸೇರಿಸುವುದು.
ಸಾಫ್ಟ್ವೇರ್ ನಿರ್ಮಾಣ ಮಾಡುವುದು ಸಣ್ಣ ನಿರ್ಧಾರಗಳ ಸರಣಿಯಾಗಿದೆ. ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯು ಸ್ವಚ್ಛವಾಗಿದೆಯೇ ಅಥವಾ ದುರ್ಬಲವಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ಈ ನಿರ್ಧಾರಗಳೇ ನಿರ್ಧರಿಸುತ್ತವೆ.
ನೀವು ಲೈವ್ ಚಾಟ್ ಅಥವಾ ಮ್ಯಾಚಿಂಗ್ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಿದ್ದೀರಾ? ನೀವು ಏನನ್ನು ವಿಭಿನ್ನವಾಗಿ ಮಾಡುತ್ತಿದ್ದಿರಿ?
ಮೂಲ: https://dev.to/jaeger974/simple-live-chat-almost-sank-this-release-2pn7