एक GraphQL वीडियो डिस्कवरी API बनाना
जब हमारा वीडियो डेटाबेस लाखों रिकॉर्ड्स तक बढ़ गया, तो हमारा API एक बाधा (bottleneck) बन गया।
एक ही स्क्रीन पर ट्रेंडिंग वीडियो, चैनल विवरण, टैग, व्यू काउंट और सिफारिशें (recommendations) दिखाने के लिए पांच अलग-अलग REST कॉल्स की आवश्यकता होती थी। धीमे कनेक्शन वाले मोबाइल उपयोगकर्ताओं को केवल एक पेज लोड करने के लिए 30 अनुरोध (requests) भेजने पड़ते थे।
GraphQL इसे हल करता है। क्लाइंट एक ही अनुरोध में ठीक वही मांगता है जिसकी उसे आवश्यकता है।
मैंने Strawberry और FastAPI का उपयोग करके एक प्रोडक्शन वीडियो डिस्कवरी API बनाया। यहाँ बताया गया है कि मैंने इसे कैसे किया।
Strawberry ही क्यों?
मैंने Graphene और Ariadne का परीक्षण किया, लेकिन Strawberry इन कारणों से जीत गया:
• Type hints ही स्कीमा हैं। आप Python कोड लिखते हैं, और Strawberry GraphQL types बनाता है। इसमें किसी मैन्युअल सिंकिंग की आवश्यकता नहीं होती है। • यह async-native है। यह API को event loop को ब्लॉक किए बिना कई अनुरोधों को संभालने की अनुमति देता है। • FastAPI के साथ integration सहज है। GraphQL endpoint मौजूदा REST routes के ठीक बगल में रहता है। • Built-in DataLoader। यह टूल N+1 समस्या को सीधे तौर पर हल करता है।
डेटा स्टैक
डेटा एक SQLite डेटाबेस में रहता है जिसे एक PHP साइट द्वारा प्रबंधित किया जाता है। मैं तेज़ full-text search के लिए SQLite FTS5 का उपयोग करता हूँ।
Python service इस डेटाबेस को एक read-only layer के रूप में पढ़ती है। यह सुनिश्चित करता है कि सत्य का केवल एक ही स्रोत (source of truth) हो।
सर्च को बेहतर बनाने के लिए, मैं FTS5 relevance scores को popularity signal के साथ मिलाता हूँ। यह किसी एक वायरल वीडियो को अन्य सभी सर्च परिणामों पर हावी होने से रोकता है।
N+1 समस्या का समाधान
GraphQL में एक आम समस्या N+1 समस्या है। यदि आप 20 वीडियो प्राप्त करते हैं और फिर प्रत्येक के लिए चैनल प्राप्त करते हैं, तो एक साधारण API 21 डेटाबेस क्वेरी चलाएगा।
DataLoader बैचिंग (batching) के माध्यम से इसे ठीक करता है। यह एक ही बार में सभी channel IDs को इकट्ठा करता है और उन सभी को प्राप्त करने के लिए एक एकल क्वेरी चलाता है। इससे हमारा क्वेरी समय 40ms से घटकर 5ms से भी कम हो गया।
मुख्य डिज़ाइन विकल्प
• Opaque IDs: मैं IDs के लिए strings का उपयोग करता हूँ। यह क्लाइंट ऐप्स को तोड़े बिना भविष्य के बदलावों की अनुमति देता है। • Intentional Nullability: मैं परिभाषित करता हूँ कि कौन से fields खाली हो सकते हैं। यह क्लाइंट्स को क्रैश हुए बिना गायब डेटा को संभालने में मदद करता है। • Read-only Schema: GraphQL API writes को हैंडल नहीं करता है। इससे कई सुरक्षा संबंधी सिरदर्द दूर हो जाते हैं। • Edge Caching: GraphQL डिफ़ॉल्ट रूप से POST का उपयोग करता है, जिसे कैश करना कठिन होता है। मैं Cloudflare के माध्यम से कैशिंग की अनुमति देने के लिए Automatic Persisted Queries (APQ) का उपयोग करता हूँ।
यदि आप बहुत अधिक कस्टम endpoints या जटिल query parameters से जूझ रहे हैं, तो यह स्टैक एक बेहतरीन विकल्प है।