ನೈಜ-ಸಮಯದ ಸಹಯೋಗವು (Real-time collaboration) ತೆರೆ ಎಳೆಯುವವರೆಗೆ ಅತಿ ಸುಲಭವಾಗಿ ಕಾಣಿಸುತ್ತದೆ. ಒಬ್ಬ ವ್ಯಕ್ತಿ ಟೈಪ್ ಮಾಡುತ್ತಾನೆ. ಇನ್ನೊಬ್ಬರು ಮೂರು ಪ್ಯಾರಾಗಳು ಮೇಲಿರುವ ಒಂದು ಸಾಲನ್ನು ಅಳಿಸುತ್ತಾರೆ. ಮೂರನೆಯವರು Stack Overflow ನಿಂದ ಒಂದು ಸ್ನಿಪ್ಪೆಟ್ ಅನ್ನು ಪೇಸ್ಟ್ ಮಾಡುತ್ತಾರೆ. ಯಾವುದೋ ಒಂದು ರೀತಿಯಲ್ಲಿ ಆ ದಾಖಲೆಯು ಒಂದೇ, ಸುಸಂಬದ್ಧ ಸ್ಥಿತಿಗೆ ತಲುಪುತ್ತದೆ. WebSockets ಅಥವಾ distributed state ಬಗ್ಗೆ ಯಾವುದೇ ಪೂರ್ವ ಅನುಭವವಿಲ್ಲದೆ, ಅಂತಹ ಸುಗಮತೆಯನ್ನು ಮೊದಲಿನಿಂದම ನಿರ್ಮಿಸುವುದು ಅಜಾಗರೂಕತೆಯಂತೆ ಕೇಳಿಸಬಹುದು. ಆದರೆ ನಿಜವಾಗಿ ಕಲಿಯಲು ಇದು ಸರಿಯಾದ ಮಾರ್ಗವೂ ಹೌದು.
ಈ ಯೋಜನೆಯು ಶೂನ್ಯದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಯಾವುದೇ ಎರವಲು ಪಡೆದ boilerplate ಇಲ್ಲ. ಕಠಿಣ ಭಾಗಗಳನ್ನು ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳ ಮಾಂಟೇಜ್ನಲ್ಲಿ ಬಿಟ್ಟುಬಿಡುವ ಯಾವುದೇ ಸುಂದರವಾದ YouTube ವಾಕ್ಥ್ರೂಗಳು ಇಲ್ಲ. ಇದರ ಗುರಿಯೆಂದರೆ, ಅನೇಕ ಬಳಕೆದಾರರು ಏಕಕಾಲದಲ್ಲಿ ಒಂದೇ ಫೈಲ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡಬಹುದಾದ ಮತ್ತು ಒಬ್ಬರ ಬದಲಾವಣೆಗಳನ್ನು ಹಾಗೂ ಒಬ್ಬರ ಕರ್ಸರ್ (cursor) ಅನ್ನು ಮತ್ತೊಬ್ಬರು ನಡೆಯುತ್ತಿರುವಾಗಲೇ ನೋಡಬಹುದಾದ ಒಂದು ಸಹಯೋಗದ ಕೋಡ್ ಎಡಿಟರ್ (collaborative code editor) ತಯಾರಿಸುವುದು. ಅಲ್ಲಿಗೆ ತಲುಪಲು transport layers, consistency models ಮತ್ತು ದಾಖಲೆಯನ್ನು ಹಾಳು ಮಾಡದೆಯೇ ಏಕಕಾಲಿಕ ಎಡಿಟ್ಗಳನ್ನು (concurrent edits) ವಿಲೀನಗೊಳಿಸುವ ಕಠಿಣ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬೇಕಾಗುತ್ತದೆ.
"Real-Time" ಎಂದರೆ ನಿಜವಾಗಿ ಏನು?
ಹೆಚ್ಚಿನ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ಗಳು request-response cycles ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ನೀವು ಒಂದು ಫಾರ್ಮ್ ಅನ್ನು ಸಬ್ಮಿಟ್ ಮಾಡುತ್ತೀರಿ, ಸರ್ವರ್ ಅದನ್ನು ಉಳಿಸುತ್ತದೆ, ನಂತರ ನೀವು ಪುಟವನ್ನು ರಿಫ್ರೆಶ್ ಮಾಡುತ್ತೀರಿ. ನೈಜ-ಸಮಯದ ಸಹಯೋಗವು ಈ ನಿಯಮವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮುರಿಯುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಕೀ-ಸ್ಟ್ರೋಕ್ (keystroke) ಕೂಡ ಒಂದು ಘಟನೆಯಾಗಿದ್ದು, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಮಿಲಿಸೆಕೆಂಡುಗಳಲ್ಲಿ ಇತರ ಎಲ್ಲಾ ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ತಲುಪಬೇಕು ಮತ್ತು ಅರ್ಥವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಕ್ರಮದಲ್ಲಿ ಬರಬೇಕು.
WebSockets ಇಲ್ಲಿ ಸ್ಪಷ್ಟವಾದ transport ಆಯ್ಕೆಯಾಗಿದೆ ಏಕೆಂದರೆ ಅವು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವೆ ನಿರಂತರವಾದ, full-duplex ಸಂಪರ್ಕವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತವೆ. ಪ್ರತಿ ಕೆಲವು ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ "ಏನಾದರೂ ಹೊಸದಿದೆಯೇ?" ಎಂದು ಕೇಳುವ ಮೂಲಕ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ವ್ಯರ್ಥ ಮಾಡುವ HTTP polling ನಂತಲ್ಲದೆ, WebSocket ತೆರೆದೆಯೇ ಇರುತ್ತದೆ. ಬಳಕೆದಾರ A ಸೆಮಿಕೋಲನ್ ಟೈಪ್ ಮಾಡಿದಾಗ, ಆ ಅಕ್ಷರವು ಒಂದು ಸಂದೇಶವಾಗಿ ಸಾಕೆಟ್ ಮೂಲಕ ಕೇಂದ್ರ ಸರ್ವರ್ಗೆ ಪ್ರಯಾಣಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಬಳಕೆದಾರ B ಮತ್ತು C ಗೆ ಹರಡುತ್ತದೆ. ಆ ಭಾಗವು ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳವಾಗಿದೆ.
ಕಠಿಣವಾದ ಭಾಗವೆಂದರೆ B ಮತ್ತು C ಏಕಕಾಲದಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದು. ಎರಡೂ ಬದಲಾವಣೆಗಳು ಏಕಕಾಲದಲ್ಲಿ ಸರ್ವರ್ಗೆ ತಲುಪಿದರೆ, ಯಾವುದು ಗೆಲ್ಲುತ್ತದೆ? ನೀವು ಕೇವಲ ಸಂದೇಶಗಳನ್ನು ಅವು ಬಂದ ಕ್ರಮದಲ್ಲಿ ಪ್ರಸಾರ ಮಾಡಿದರೆ, ಅಕ್ಷರಗಳು ಕಣ್ಮರೆಯಾಗುವ ಅಥವಾ ಪಠ್ಯವು ಗೊಂದಲಮಯವಾಗುವ ಅಪಾಯವಿರುತ್ತದೆ. Naive last-write-wins ತಂತ್ರಗಳು ವಿಫಲವಾಗುತ್ತವೆ ಏಕೆಂದರೆ ಅವು ಉದ್ದೇಶವನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ. ನಾನು ಮೊದಲ ಸಾಲಿನ ಆರಂಭದಲ್ಲಿ "hello" ಎಂದು ಟೈಪ್ ಮಾಡುವಾಗ ನೀವು ಮೊದಲ ಸಾಲಿನ ಆರಂಭದಲ್ಲಿ "world" ಎಂದು ಟೈಪ್ ಮಾಡಿದರೆ, ಫಲಿತಾಂಶವು ನಮ್ಮಲ್ಲಿ ಒಬ್ಬರನ್ನು ಅಳಿಸಿಹಾಕುವ ಸಂಘರ್ಷವಾಗಬಾರದು. ಅದು ನಿರ್ಣಾಯಕವಾಗಿ (deterministically) ಆಯ್ಕೆಯಾದ "helloworld" ಅಥವಾ "worldhello" ಆಗಿರಬೇಕು. ಅದನ್ನು ಸಾಧಿಸಲು ದಾಖಲೆಯ ರಚನೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಸಿಂಕ್ರೊನೈಸೇಶನ್ (synchronization) ತಂತ್ರದ ಅಗತ್ಯವಿದೆ.
ಶೂನ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸುವುದು ಏಕೆ ಮುಖ್ಯ?
ಈ ಸಂಕೀರ್ಣತೆಯನ್ನು ಮರೆಮಾಚುವ ಅತ್ಯುತ್ತಮ ಫ್ರೇಮ್ವರ್ಕ್ಗಳಿವೆ. Yjs, Automerge ಮತ್ತು Socket.IO ಇವು ನೋವನ್ನು ಕಡಿಮೆ ಮಾಡಿ ಒಂದು ಮಧ್ಯಾಹ್ನದೊಳಗೆ ಕೆಲಸ ಮಾಡುವ ಪ್ರೊಟೊಟೈಪ್ ಅನ್ನು ನೀಡಬಲ್ಲವು. ಆದರೆ ಅವುಗಳ ಅಡಿಯಲ್ಲಿರುವ ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು (primitives) ಅರ್ಥಮಾಡಿಕೊಳ್ಳದೆ ಅವುಗಳನ್ನು ಬಳಸುವುದು, ಉಪಕರಣಗಳನ್ನು ಓದಲು ತಿಳಿಯದೆಯೇ ವಿಮಾನವನ್ನು ಆಟೋಪಿಲಟ್ನಲ್ಲಿ ಹಾರಿಸುವಂತೆ ಇರುತ್ತದೆ. ಅನಿಶ್ಚಿತತೆ (turbulence) ಎದುರಾದಾಗ—ಮತ್ತು distributed systems ನಲ್ಲಿ ಅದು ಯಾವಾಗಲೂ ಎದುರಾಗುತ್ತದೆ—ಸಮಸ್ಯೆಯು ನಿಮ್ಮ ನೆಟ್ವರ್ಕ್ ಲೇಯರ್ನಲ್ಲಿದೆಯೇ, ನಿಮ್ಮ ಸಂಘರ್ಷ ಪರಿಹಾರದಲ್ಲಿದೆಯೇ (conflict resolution) ಅಥವಾ ನಿಮ್ಮ ಡೇಟಾ ಮಾಡೆಲ್ನಲ್ಲಿದೆಯೇ ಎಂದು ನಿಮಗೆ ತಿಳಿಯಬೇಕಾಗುತ್ತದೆ.
ಇಲ್ಲಿನ ಬದ್ಧತೆಯೆಂದರೆ ಲೈಬ್ರರಿಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗುವ ಮೊದಲು ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಕಲಿಯುವುದು. ಅಂದರೆ ಈ ಕೆಳಗಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಸ್ವತಃ ಯೋಚಿಸಿ ತಿಳಿಯುವುದು:
- ಟೈಪ್ ಮಾಡುವ ಮಧ್ಯದಲ್ಲೇ ಕ್ಲೈಂಟ್ ಡಿಸ್ಕನೆಕ್ಟ್ ಆಗಿ ಹತ್ತು ಸೆಕೆಂಡುಗಳ ನಂತರ ಮರುಸಂಪರ್ಕಗೊಂಡಾಗ
- ಇಬ್ಬರು ಬಳಕೆದಾರರು ಏಕಕಾಲದಲ್ಲಿ ಒಂದೇ ಕರ್ಸರ್ ಸ್ಥಾನದಲ್ಲಿ ಪಠ್ಯವನ್ನು ಸೇರಿಸಿದಾಗ
- ಒಬ್ಬ ಬಳಕೆದಾರರು ಮತ್ತೊಬ್ಬ ಬಳಕೆದಾರರು ಸಕ್ರಿಯವಾಗಿ ಎಡಿಟ್ ಮಾಡುತ್ತಿರುವ ಒಂದು ಬ್ಲಾಕ್ ಅನ್ನು ಅಳಿಸಿದಾಗ
- ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗಿ ಹೊಸ ನೋಡ್ (node) ದಾಖಲೆಯ ಸ್ಥಿತಿಯನ್ನು ಮೊದಲಿನಿಂದಲೇ ಮರುನಿರ್ಮಿಸಬೇಕಾದಾಗ
ಈ ಸಮಸ್ಯೆಗಳಿಗೆ Operational Transformation (OT) ಮತ್ತು Conflict-free Replicated Data Types (CRDTs) ಎಂಬ ಎರಡು ಪ್ರಮುಖ ಪರಿಹಾರಗಳಿವೆ. Google Docs ತನ್ನ ಆರಂಭಿಕ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು OT ಮೇಲೆ ನಿರ್ಮಿಸಿತು, ಇದು ಆಪರೇಷನ್ಗಳನ್ನು ಅನ್ವಯಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು ಪರಸ್ಪರ ರೂಪಾಂತರಿಸಲು ಕೇಂದ್ರ ಸರ್ವರ್ ಅನ್ನು ಬಯಸುತ್ತದೆ. ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, CRDTs ಗಳನ್ನು ಏಕಕಾಲಿಕ ಅಪ್ಡೇಟ್ಗಳನ್ನು ಯಾವುದೇ ಸಮನ್ವಯವಿಲ್ಲದೆ ಸ್ಥಳೀಯವಾಗಿ ವಿಲೀನಗೊಳಿಸುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಇದು ಅವುಗಳನ್ನು peer-to-peer ಅಥವಾ edge-based ಸೆಟಪ್ಗಳಿಗೆ ಆಕರ್ಷಕವಾಗಿಸುತ್ತದೆ. ಇವುಗಳ ನಡುವೆ ಅಥವಾ ಹೈಬ್ರಿಡ್ ವಿಧಾನಗಳನ್ನು ಆರಿಸಿಕೊಳ್ಳಲು ಮೆಮೊರಿ ಬಳಕೆ, ಕನ್ವರ್ಜೆನ್ಸ್ ಗ್ಯಾರಂಟಿಗಳು (convergence guarantees) ಮತ್ತು ಅನುಷ್ಠಾನದ ಸಂಕೀರ್ಣತೆಯಲ್ಲಿನ ಅವುಗಳ ಹೊಂದಾಣಿಕೆಗಳನ್ನು (trade-offs) ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿದೆ. ಕೇವಲ ಅವುಗಳ ಬಗ್ಗೆ ಓದುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ; ಅವು ಎಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ ಎಂದು ನೋಡಲು Naive ಮತ್ತು Refined ಎರಡೂ ಆವೃತ್ತಿಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು ಯೋಜನೆಯಾಗಿದೆ.
ಮರುನಿರ್ಮಾಣಗಳು, ತಪ್ಪುಗಳು ಮತ್ತು ಅಂತ್ಯವಿಲ್ಲದ ದಾರಿಗಳು
ನಿರೀಕ್ಷೆಗಳನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ರೂಪಿಸಲಾಗಿದೆ. ಯಾವುದೂ ಕೆಲಸ ಮಾಡದ ಸಮಯಗಳು ಇರುತ್ತವೆ. ಮೊದಲ ಪ್ರಯತ್ನವು ಪಠ್ಯ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ರತಿನಿಧಿಸಲು ಸರಳ JSON patches ಅನ್ನು ಬಳಸಬಹುದು, ಆದರೆ JSON ಗೆ "ಪ್ಯಾರಾಗ್ರಾಫ್ನಲ್ಲಿ ಇಂಡೆಕ್ಸ್ 5" ಎಂಬ ಪರಿಕಲ್ಪನೆ ಇಲ್ಲದಿರುವುದು ತಿಳಿಯಬಹುದು. ಇದರಿಂದಾಗಿ ಒಂದೇ ಇಂಡೆಕ್ಸ್ನಲ್ಲಿ ನಡೆಯುವ ಎರಡು ಏಕಕಾಲಿಕ ಸೇರ್ಪಡೆಗಳು (insertions) ವಿಲೀನಗೊಳ್ಳುವ ಬದಲು ಒಂದನ್ನೊಂದು ಅಳಿಸಿಹಾಕುತ್ತವೆ. ಎರಡನೇ ಪ್ರಯತ್ನವು ಒಂದು ಕಸ್ಟಮ್ ಲೀನಿಯರ್ ಹಿಸ್ಟರಿ ಲಾಗ್ ಅನ್ನು ನಿರ್ಮಿಸಬಹುದು, ಆದರೆ ಡಾಕ್ಯುಮೆಂಟ್ ಬೆಳೆದಂತೆ ಆ ಲಾಗ್ ಅನ್ನು ಮರುಪ್ರದರ್ಶಿಸುವುದು (replaying) Big O ನೈಟ್ಮೇರ್ ಆಗಿ ಪರಿಣಮಿಸುತ್ತದೆ ಎಂದು ಅರಿವಾಗಬಹುದು. ಮೂರನೇ ಪ್ರಯತ್ನವು WebSockets ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ (locally) ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡಬಹುದು, ಆದರೆ ಪ್ಯಾಕೆಟ್ ಲಾಸ್ ಮತ್ತು ಬದಲಾಗುವ ವಿಳಂಬದ (latency) ಕಾರಣದಿಂದಾಗಿ ನೈಜ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಅದು ವಿಫಲವಾಗಬಹುದು.
ಆ ಘರ್ಷಣೆಯೇ (friction) ಮುಖ್ಯ ಉದ್ದೇಶ. ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ರೆಪೊಸಿಟರಿಯನ್ನು ಕಾಪಿ ಮಾಡುವುದರಿಂದ, ಕ್ಯೂ (queue) ಏಕೆ ಆ ನಿರ್ದಿಷ್ಟ ಕ್ರಮದಲ್ಲಿ ಫ್ಲಶ್ ಆಗುತ್ತದೆ ಅಥವಾ ಸರ್ವರ್ ಏಕೆ ವರ್ಷನ್ ವೆಕ್ಟರ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬ ತನಿಖೆಯನ್ನು ನೀವು ಕೈಬಿಡುತ್ತೀರಿ. ಒಂದೇ ಘಟಕವನ್ನು (component) ಮೂರು ಬಾರಿ ಮರುನಿರ್ಮಿಸುವುದು ನಿಧಾನಗತಿಯ ಪ್ರಕ್ರಿಯೆಯಾಗಬಹುದು, ಆದರೆ ಇದು ಫ್ರೇಮ್ವರ್ಕ್ ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಲಾಜಿಕ್ ಏನನ್ನು ನಿರ್ವಹಿಸಬೇಕು ಎಂಬ ನಡುವಿನ ಗಡಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಲವಂತ ಮಾಡುತ್ತದೆ.
ಈ ಪ್ರಕ್ರಿಯೆಯ ದಾಖಲಾತಿಯು ಕೇವಲ ಯಶಸ್ಸಿನ ಕಥೆಗಳಾಗಿರುವುದಿಲ್ಲ. ಇದರಲ್ಲಿ ತಪ್ಪು ದಾರಿಗಳೂ ಇರುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಪ್ರೆಸೆನ್ಸ್ ಅವೇರ್ನೆಸ್ (presence awareness) ನಿರ್ಮಿಸುವುದು—ಯಾರು ಆನ್ಲೈನ್ನಲ್ಲಿದ್ದಾರೆ ಮತ್ತು ಅವರ ಕರ್ಸರ್ ಎಲ್ಲಿದೆ ಎಂದು ತಿಳಿಯುವುದು—ಇದು ಕೇವಲ ಸೌಂದರ್ಯಾತ್ಮಕ ವೈಶಿಷ್ಟ್ಯದಂತೆ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಅದು ಪಠ್ಯದಂತೆಯೇ ಅದೇ ಕನ್ಸಿಸ್ಟೆನ್ಸಿ ಮಾಡೆಲ್ (consistency model) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿಯುವವರೆಗೆ. ಬಳಕೆದಾರ A, ಬಳಕೆದಾರ B ನ ಕರ್ಸರ್ ಅನ್ನು ಕಾಲಂ 10 ರಲ್ಲಿ ನೋಡಿದರೆ, ನಂತರ ಬಳಕೆದಾರ B ನಾಲ್ಕು ಅಕ್ಷರಗಳನ್ನು ಸೇರಿಸಿದರೆ, ಆ ಕರ್ಸರ್ ಎಲ್ಲಿಗೆ ಚಲಿಸುತ್ತದೆ? ಡಾಕ್ಯುಮೆಂಟ್ ಟೋಪೋಲಜಿ (document topology) ಬಗ್ಗೆ ಹಂಚಿಕೆಯ ತಿಳುವಳಿಕೆ ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರೆಸೆನ್ಸ್ ಡೇಟಾ ವಾಸ್ತವದಿಂದ ದೂರ ಸರಿಯುತ್ತದೆ. ಇದನ್ನು ಪರಿಹರಿಸಲು ಕರ್ಸರ್ ಸ್ಥಾನವನ್ನು ಕೇವಲ ಅದರ ಸಂಖ್ಯಾತ್ಮಕ ಇಂಡೆಕ್ಸ್ (numerical index) ಗೆ ಮಾತ್ರವಲ್ಲದೆ, ಅಡಿಪಾಯದ ಡೇಟಾ ಸ್ಟ್ರಕ್ಚರ್ನ ಐಡೆಂಟಿಟಿ (identity) ಗೆ ಜೋಡಿಸಬೇಕಾಗುತ್ತದೆ. ಇವುಗಳಂತಹ ವಿವರಗಳನ್ನು ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಕೇವಲ ಮೇಲ್ಪದರದಲ್ಲಿ ಮಾತ್ರ ಚರ್ಚಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಅವು ಬೇಸರ ತರಿಸುವಂತಿವೆ ಹೊರತು ಅಪ್ರಮುಖವಾದವುಗಳಲ್ಲ.
ಮುಂದೆ ಏನು?
ತಕ್ಷಣದ ರೋಡ್ಮ್ಯಾಪ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸರಳವಾಗಿದೆ. ಮೊದಲ ಮೈಲಿಗಲ್ಲುಗಳು ಹೀಗಿರುತ್ತವೆ:
- ಕ್ಯಾರೆಕ್ಟರ್ ಇವೆಂಟ್ಗಳನ್ನು ಎಕೋ (echo) ಮಾಡುವ ಒಂದು ರೊ (raw) WebSocket ಸರ್ವರ್, ಇದರಿಂದ ವಿಳಂಬ (latency) ಮತ್ತು ಕನೆಕ್ಷನ್ ಲೈಫ್ಸೈಕಲ್ ಅನ್ನು ನೇರವಾಗಿ ಅನುಭವಿಸಬಹುದು
- ಕನ್ಕರನ್ಸಿ (concurrency) ಅಡಿಯಲ್ಲಿ ಸರಳವಾದ ಇನ್ಸರ್ಶನ್ ಆರ್ಡರಿಂಗ್ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಒಂದು ಸರಳ ಸ್ಟ್ರಿಂಗ್ ಬಫರ್
- ಆರ್ಡರ್ಡ್ ಸೀಕ್ವೆನ್ಸ್ಗಳಿಗಾಗಿ ಮೊದಲಿನಿಂದಲೇ ನಿರ್ಮಿಸಿದ CRDT, ಅದು ಎಷ್ಟೇ ಅಸಮರ್ಥವಾಗಿದ್ದರೂ ಸಹ, ಕಮ್ಯುಟೇಟಿವ್ ಪ್ರಾಪರ್ಟಿ (commutative property) ಅನ್ನು ಕಾರ್ಯರೂಪದಲ್ಲಿ ನೋಡಲು
- ಎಡಿಟರ್ನ ಇಂಪೆರೇಟಿವ್ API ಮತ್ತು ಆಪರೇಷನಲ್ ಹಿಸ್ಟರಿಯ ಫಂಕ್ಷನಲ್ ಸ್ವರೂಪದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಎದುರಿಸಲು, CodeMirror ಅಥವಾ Monaco ನಂತಹ ನೈಜ ಕೋಡ್ ಎಡಿಟರ್ನೊಂದಿಗೆ ಕ್ರಮೇಣ ಸಂಯೋಜನೆ (integration)
ಪ್ರತಿ ಹಂತವು ಬರೆದ ತರ್ಕದೊಂದಿಗೆ (rationale) ಬರುತ್ತದೆ. ಈ ವಿಧಾನ ಏಕೆ ಮತ್ತು ಆ ವಿಧಾನ ಏಕೆ ಅಲ್ಲ? ಯಾವ ಕಲ್ಪನೆಗಳು ತಪ್ಪೆಂದು ಸಾಬೀತಾದವು? ಯಾವ ಅಬ್ಸ್ಟ್ರಾಕ್ಷನ್ ಸೋರಿಕೆಯಾಯಿತು (leaked)?
ನೈಜ ಕಲಿಕೆ
WebSockets ಅಥವಾ CRDTಗಳಲ್ಲಿ ಅನುಭವವಿಲ್ಲದೆ ಇಂತಹ ಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಭಯಾನಕವಾಗಿರಬಹುದು, ಆದರೆ ಪರಿಣತಿ ಎನ್ನುವುದು ಹೆಚ್ಚಾಗಿ ಉತ್ತಮ ಲೇಬಲ್ಗಳೊಂದಿಗೆ ಪುನರಾವರ್ತಿತ ಗೊಂದಲವಾಗಿರುತ್ತದೆ. ಉದ್ದೇಶವು ವೇಗವಾಗಿ ಮುಗಿಸುವುದಲ್ಲ. ಬದಲಾಗಿ, ಪ್ರತಿಯೊಂದು ಪದರವನ್ನು ಕೇವಲ ಭರವಸೆಯ ಮೇಲೆ ಆಮದು ಮಾಡಿಕೊಳ್ಳುವ ಬದಲು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಮಿಸುವುದರಿಂದ, ಅದರ ವರ್ತನೆಯನ್ನು ಮುನ್ಸೂಚಿಸಬಹುದು (predictable) ಎಂಬ ವ್ಯವಸ್ಥೆಯನ್ನು ರೂಪಿಸುವುದು.
ನೀವು ಈ ಹಿಂದೆ ಸಹಯೋಗದ ಸಾಫ್ಟ್ವೇರ್ (collaborative software)—ಅದು ಪಠ್ಯ ಎಡಿಟರ್ ಆಗಿರಲಿ, ಡಿಸೈನ್ ಟೂಲ್ ಆಗಿರಲಿ ಅಥವಾ ಗೇಮ್ ಸ್ಟೇಟ್ ಸಿಂಕ್ ಇಂಜಿನ್ ಆಗಿರಲಿ—ನಿರ್ಮಿಸಿದ್ದರೆ, ನಿಮ್ಮನ್ನು ಅಚ್ಚರಿಗೊಳಿಸಿದ ವೈಫಲ್ಯದ ವಿಧಾನಗಳನ್ನು (failure modes) ಹಂಚಿಕೊಳ್ಳಿ. ನೀವು ಕೂಡ ಈ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಕಲಿಯುತ್ತಿದ್ದರೆ, ನಮ್ಮೊಂದಿಗೆ ಕೈಜೋಡಿಸಿ. ಕೋಡ್ ನಿಧಾನವಾಗಿ ಬರುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಪದೇ ಪದೇ ಮರುಬರೆಯಲಾಗುವುದು. ದಿನ 0 ಈಗ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.