ಇಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು REST ಸತ್ತಿದೆಯೇ ಅಥವಾ gRPC ಉಳಿದ ಎಲ್ಲವನ್ನೂ ಅಪ್ರಸ್ತುತಗೊಳಿಸಿದೆಯೇ ಎಂದು ವಾದಿಸಲು ಇಡೀ ಮಧ್ಯಾಹ್ನವನ್ನೇ ವ್ಯರ್ಥ ಮಾಡುತ್ತವೆ. ಆ ವಾದವು ಮುಖ್ಯ ವಿಷಯವನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನೀವು ಅತ್ಯುತ್ತಮ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಆರಿಸುತ್ತಿಲ್ಲ. ನೀವು ಸರಿಯಾದ ಗಡಿ (boundary) ಅನ್ನು ಆರಿಸುತ್ತಿದ್ದೀರಿ. ನಿಮ್ಮ Kubernetes ಕ್ಲಸ್ಟರ್ನ ಒಳಗೆ ಅದ್ಭುತವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಪ್ರೋಟೋಕಾಲ್, ನೀವು ಅದನ್ನು ಸಾವಿರಾರು ಬಾಹ್ಯ (external) ಡೆವಲಪರ್ಗಳಿಗೆ ನೀಡಿದಾಗ ಅಸಹಾಯಕವಾಗಬಹುದು. ನಿಮ್ಮ ಮೊಬೈಲ್ ಆಪ್ನ ಅಮೂಲ್ಯವಾದ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಅನ್ನು ಉಳಿಸುವ ಪ್ರೋಟೋಕಾಲ್, ನೀವು ಅದನ್ನು ಅನಿಯಮಿತ ಸಾರ್ವಜನಿಕ ಕ್ವೇರಿಗಳಿಗೆ (public queries) ತೆರೆದರೆ ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯವನ್ನು (infrastructure) ದಿವಾಳization ಮಾಡಬಹುದು. ಈ ನಿರ್ಧಾರವನ್ನು ತಂತ್ರಜ್ಞಾನದ ಜನಪ್ರಿಯತಾ ಸ್ಪರ್ಧೆಯಂತೆ ಪರಿಗಣಿಸಿದರೆ, ನೀವು ನಿಮ್ಮ ತಂಡದ ಪ್ರತಿಯೊಬ್ಬ ಪ್ರಸ್ತುತ ಸದಸ್ಯರಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುವ ವಾಸ್ತುಶಿಲ್ಪದ ಸಾಲವನ್ನು (architectural debt) ಸೃಷ್ಟಿಸುತ್ತೀರಿ.
ಗಡಿ ತತ್ವ (The Boundary Principle)
ವಾಸ್ತುಶಿಲ್ಪವು (Architecture) ವಿನಿಮಯದ (trade-offs) ಬಗ್ಗೆ ಇರುತ್ತದೆ, ಚಾಂಪಿಯನ್ಗಳ ಬಗ್ಗೆ ಅಲ್ಲ. ಸರಿಯಾದ ಪ್ರಶ್ನೆಯು ಎಂದಿಗೂ "ಯಾವುದು ವೇಗವಾಗಿದೆ?" ಅಥವಾ "ಯಾವುದು ಹೊಸದು?" ಎಂದಲ್ಲ. ಬದಲಾಗಿ "ವೈರ್ನ (wire) ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಕುಳಿತಿರುವವರು ಯಾರು ಮತ್ತು ಅವರು ಏನನ್ನು ನಿಯಂತ್ರಿಸುತ್ತಾರೆ?" ಎಂದಿರಬೇಕು. ಪ್ರೋಟೋಕಾಲ್ಗಳು ಗಡಿ ವಸ್ತುಗಳು (boundary objects). ತಪ್ಪು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಆರಿಸುವುದು ನಿಮ್ಮನ್ನು ನಿಧಾನಗೊಳಿಸುವುದು ಮಾತ್ರವಲ್ಲ; ಅದು ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ವರ್ಷಗಟ್ಟಲೆ ತಪ್ಪುಗಳನ್ನು ಬಿತ್ತುತ್ತದೆ.
ಸಾರ್ವಜನಿಕ APIಗಳು: REST ಎಂಬುದು ಬೋರಿಂಗ್ ಅಲ್ಲ, ಅದು ಜವಾಬ್ದಾರಿಯುತವಾಗಿದೆ
ನಿಮ್ಮ ಗ್ರಾಹಕರು ನೀವು ಎಂದೂ ಭೇಟಿಯಾಗದ ಬಾಹ್ಯ ಡೆವಲಪರ್ ಆಗಿದ್ದಾಗ, ನಿಮ್ಮ API ಕೇವಲ ಒಂದು ಇಂಟರ್ಫೇಸ್ ಅಲ್ಲ, ಅದು ಒಂದು ಉತ್ಪನ್ನ (product). ಆ ಡೆವಲಪರ್ ಬೆಳಗಿನ ಎರಡು ಗಂಟೆಗೆ ಕೇವಲ curl ಮತ್ತು Postman collection ಬಳಸಿ ಡೆಬಗ್ ಮಾಡುತ್ತಿರುತ್ತಾರೆ. ಅವರು ತಮ್ಮ ಮೊದಲ ಯಶಸ್ವಿ ಕರಲ್ ಮಾಡುವ ಮೊದಲು ಕಸ್ಟಮ್ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಯನ್ನು ಇನ್ಸ್ಟಾಲ್ ಮಾಡಬೇಕಾದರೆ ಅಥವಾ ಸ್ಕೀಮಾ ಭಾಷೆಯನ್ನು ಕಲಿಯಬೇಕಾದರೆ, ನೀವು ಈಗಾಗಲೇ ಅವರನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೀರಿ ಎಂದರ್ಥ.
REST ಇಲ್ಲಿ ಉಳಿದುಕೊಂಡಿದೆ ಏಕೆಂದರೆ ಅದು ವೆಬ್ನ ಅಡಿಪಾಯವಾಗಿದೆ. HTTP ವಿಧಾನಗಳು, ಸ್ಟೇಟಸ್ ಕೋಡ್ಗಳು ಮತ್ತು JSON ಸಾಮಾನ್ಯ ಭಾಷೆಗಳಾಗಿವೆ. ಕ್ಯಾಷಿಂಗ್ (Caching) ಎಂಬುದು ನಂತರದ ಆಲೋಚನೆಯಲ್ಲ; ಅದು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೂಲಸೌಕರ್ಯವಾಗಿದೆ. ಬ್ರೌಸರ್ಗಳು, CDNs ಮತ್ತು ಎಡ್ಜ್ ಕ್ಯಾಶೆಗಳು Cache-Control ಹೆಡರ್ಗಳು ಮತ್ತು ETag ವ್ಯಾಲಿಡೇಶನ್ ಅನ್ನು ನೈಸರ್ಗಿಕವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತವೆ. ನೀವು ಕೇವಲ ಒಂದು CDN ಹಿಂದೆ REST API ಅನ್ನು ಇರಿಸಿ, ಕ್ಯಾಷಿಂಗ್ ಲಾಜಿಕ್ನ ಒಂದೇ ಒಂದು ಸಾಲನ್ನು ಬರೆಯದೆ ತಕ್ಷಣದ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಉಳಿತಾಯವನ್ನು ಪಡೆಯಬಹುದು. ಸಾರ್ವಜನಿಕ ಟ್ರಾಫಿಕ್ ಅನಿರೀಕ್ಷಿತವಾಗಿದ್ದಾಗ ಮತ್ತು ನಿಮ್ಮ ಕ್ಲೌಡ್ನಿಂದ ಹೊರಹೋಗುವ ಪ್ರತಿ ಗಿಗಾಬೈಟ್ಗೂ ನೀವು ಹಣ ಪಾವತಿಸುತ್ತಿದ್ದಾಗ ಇದು ಬಹಳ ಮುಖ್ಯವಾಗುತ್ತದೆ.
ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, GraphQL ಸಾರ್ವಜನಿಕ ಗಡಿಗೆ ಭಾರೀ ತೆರಿಗೆಯನ್ನು (heavy tax) ತರುತ್ತದೆ. ಸಾರ್ವಜನಿಕ GraphQL ಎಂಡ್ಪಾಯಿಂಟ್ಗಳು ಕೇವಲ ಒಂದು ಅಜಾಗರೂಕ ಅಥವಾ ದುರುದ್ದೇಶಪೂರಿತ ಕ್ವೇರಿಯು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡದಂತೆ ತಡೆಯಲು ಕ್ವೇರಿ ಕಾಸ್ಟ್ ಅನಾಲಿಸಿಸ್ (query cost analysis), ಡೆಪ್ತ್ ಲಿಮಿಟಿಂಗ್ (depth limiting) ಮತ್ತು ಕಾಂಪ್ಲೆಕ್ಸಿಟಿ ಸ್ಕೋರಿಂಗ್ ಅಗತ್ಯವಿರುತ್ತದೆ. ನೀವು ಕೇವಲ ಒಂದು API ಅನ್ನು ಕಳುಹಿಸುತ್ತಿಲ್ಲ; ನೀವು ಒಂದು ಕ್ವೇರಿ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಇಂಜಿನ್, ರೇಟ್-ಲಿಮಿಟಿಂಗ್ ಸ್ಟ್ರಾಟಜಿ ಮತ್ತು ಕಂಪ್ಯೂಟ್ ಬಿಲ್ಲಿಂಗ್ ಮಾಡೆಲ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ. ದೊಡ್ಡ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳಷ್ಟು ಕಾರ್ಯಾಚರಣಾ ಸಾಮರ್ಥ್ಯ (operational muscle) ನಿಮ್ಮಲ್ಲಿಲ್ಲದಿದ್ದರೆ, ಸಾರ್ವಜನಿಕ ಬಳಕೆಗೆ ಅಂತಹ ಓವರ್ಹೆಡ್ (overhead) ಅಜಾಗರೂಕತೆಯಾಗಿದೆ. REST ಡಿಫಾಲ್ಟ್ ಆಗಿಯೇ ಗಾರ್ಡ್ರೈಲ್ಗಳನ್ನು (guardrails) ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಎಂಡ್ಪಾಯಿಂಟ್ ಒಂದು ಕೆಲಸವನ್ನು ಮಾತ್ರ ಮಾಡುತ್ತದೆ. ಗ್ರಾಹಕರು ನೀವು ನೀಡುವದ್ದನ್ನು ಮಾತ್ರ ಪಡೆಯುತ್ತಾರೆ, ಅವರು ಕಲ್ಪಿಸಿಕೊಳ್ಳುವ ಯಾವುದನ್ನೋ ಅಲ್ಲ.
ಆಂತರಿಕ ಸೇವೆಗಳು: ಸಂಪೂರ್ಣ ಪೈಪ್ಲೈನ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಿ (Internal Services: Own the Whole Pipe)
ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ಒಳಗೆ, ಸಂಭಾಷಣೆಯೇ ಬದಲಾಗುತ್ತದೆ. ನೀವು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಎರಡನ್ನೂ ನಿಯಂತ್ರಿಸುತ್ತೀರಿ. ಕರಲ್ ಚೈನ್ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಸೇವೆಗೆ ತಂತ್ರಜ್ಞಾನ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ನೀವು ನಿರ್ಧರಿಸಬಹುದು. ಇಲ್ಲಿಯೇ gRPC ತನ್ನ ಮೌಲ್ಯವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
ಮೊದಲನೆಯದಾಗಿ, JSON ಅನ್ನು ಪವಿತ್ರ ಎಂದು ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. Protocol Buffers, JSON ಗಿಂತ ಸುಮಾರು ಮೂರು ಪಟ್ಟು ವೇಗವಾಗಿ ಸೀರಿಯಲೈಸ್ (serialize) ಮಾಡುತ್ತದೆ. ಫಾರ್ಮ್ಯಾಟ್ ಬೈನರಿ ಆಗಿರುವುದರಿಂದ ಪೇಲೋಡ್ಗಳು (payloads) ಚಿಕ್ಕದಾಗಿರುತ್ತವೆ. ಕಾರ್ಯನಿರತ ಆಂತರಿಕ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ, ಆ ಮಿಲಿಸೆಕೆಂಡ್ಗಳು ಮತ್ತು ಮೆಗಾಬೈಟ್ಗಳು ನಿಜವಾದ ಹಣವಾಗಿ ಮತ್ತು ಕಡಿಮೆ ಟೇಲ್ ಲೇಟೆನ್ಸಿಯಾಗಿ (tail latency) ಪರಿಣಮಿಸುತ್ತವೆ. ಮುಖ್ಯವಾಗಿ, Protobuf ನಿಮಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ ಒಪ್ಪಂದವನ್ನು (strict contract) ನೀಡುತ್ತದೆ. ನೀವು ಫೀಲ್ಡ್ ಟೈಪ್ ಅನ್ನು ಬದಲಾಯಿಸಿದಾಗ ಅಥವಾ ಮೆಸೇಜ್ ಅನ್ನು ಮರುನಾಮಕರಣ ಮಾಡಿದಾಗ, ಅದು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಬೆಳಗಿನ ಮೂರು ಗಂಟೆಗೆ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸೇವೆಗಳು ಪಾರ್ಸ್ ಎಕ್ಸೆಪ್ಶನ್ಗಳನ್ನು ಎಸೆಯುವಾಗ ಸಂಭವಿಸುವುದಿಲ್ಲ, ಬದಲಾಗಿ ಕಂಪೈಲ್ ಸಮಯದಲ್ಲಿಯೇ ಸಂಭವಿಸುತ್ತದೆ.
gRPC, HTTP/2 ಮೇಲೆ ಚಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಹೆಡರ್ ಕಂಪ್ರೆಷನ್, ಮಲ್ಟಿಪ್ಲೆಕ್ಸಡ್ ಸ್ಟ್ರೀಮ್ಗಳು ಮತ್ತು ನೈಜ ಸ್ಟ್ರೀಮಿಂಗ್ ಸೆಮ್ಯಾಂಟಿಕ್ಸ್ ಅನ್ನು ಪಡೆಯುತ್ತೀರಿ. ನೀವು ಸೇವೆಗಳ ನಡುವೆ ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ (high-throughput) ಇವೆಂಟ್ಗಳನ್ನು ವರ್ಗಾಯಿಸುತ್ತಿದ್ದರೆ ಅಥವಾ ರಿಯಲ್-ಟೈಮ್ ಅಪ್ಡೇಟ್ಗಳನ್ನು ನೀಡುತ್ತಿದ್ದರೆ, ಸರ್ವರ್-ಸೈಡ್ ಮತ್ತು ಬೈಡೈರೆಕ್ಷನಲ್ ಸ್ಟ್ರೀಮಿಂಗ್ ನೈಸರ್ಗಿಕ ವೈಶಿಷ್ಟ್ಯಗಳಾಗಿವೆ, ಅವು ಕೇವಲ ರಿಕ್ವೆಸ್ಟ್-ರೆಸ್ಪಾನ್ಸ್ ಫ್ರೇಮ್ವರ್ಕ್ ಮೇಲೆ ಅಂಟಿಸಲಾದ ವರ್ಕೌಂಡ್ಸ್ (workarounds) ಅಲ್ಲ.
ಇಲ್ಲಿ ಒಂದು ಕಠಿಣ ಸವಾಲಿದೆ: gRPC ಅನ್ನು ನೇರವಾಗಿ ಬ್ರೌಸರ್ನತ್ತ ಇರಿಸಬೇಡಿ. ಬ್ರೌಸರ್ ನೆಟ್ವರ್ಕಿಂಗ್ ಮಾಡೆಲ್ಗಳು gRPC ನಿರೀಕ್ಷಿಸುವ ರೀತಿಯಲ್ಲಿ HTTP/2 ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಬ್ರೌಸರ್ ಬ್ಯಾಕೆಂಡ್ ಜೊತೆಗೆ ಮಾತನಾಡಲು ನೀವು grpc-web ಮತ್ತು Envoy ನಂತಹ ಪ್ರೊಕ್ಸಿಯನ್ನು ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್ನಲ್ಲಿ ಅಳವಡಿಸಬೇಕಾಗುತ್ತದೆ. ಇದು ಬಗ್ ಅಲ್ಲ; ಇದು ಒಂದು ಗಡಿ ಸಂಕೇತ (boundary signal). gRPC ಅನ್ನು ನಿಮ್ಮ ಫೈರ್ವಾಲ್ ಹಿಂದೆ, ಪರಸ್ಪರ ನಂಬುವ ಸೇವೆಗಳ ನಡುವೆ ಇರಿಸಿ ಮತ್ತು ಅದರ ಡೆಬಗ್ ಮಾಡಿಕೆಯ ಸಂಕೀರ್ಣತೆಯನ್ನು ವೇಗದ ಬೆಲೆಯಾಗಿ ಪರಿಗಣಿಸಿ. ಬೈನರಿ ಪೇಲೋಡ್ಗಳು JSON ನಂತೆ ಲಾಗ್ ಫೈಲ್ನಲ್ಲಿ ಸುಲಭವಾಗಿ ಓದಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ಸಂಕೀರ್ಣ UIಗಳು ಮತ್ತು ಮೊಬೈಲ್: GraphQL ನ ವಿಶೇಷತೆ (Complex UIs and Mobile: GraphQL's Niche)
ಆಧುನಿಕ ಮೊಬೈಲ್ ಸ್ಕ್ರೀನ್ಗಳು ವಿವಿಧ ಭಾಗಗಳ ಸಮ್ಮಿಶ್ರಣವಾಗಿವೆ. ಒಂದು ವ್ಯೂಗೆ ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ ಬೇಕಾಗಬಹುದು,