GraphQL Video Discovery API तयार करणे
जेव्हा आमचा व्हिडिओ डेटाबेस लाखो रेकॉर्ड्सपर्यंत वाढला, तेव्हा आमचा API अडथळा (bottleneck) बनला.
ट्रेंडिंग व्हिडिओ, चॅनेल तपशील, टॅग्स, व्ह्यू काउंट आणि शिफारसी (recommendations) दाखवण्यासाठी एकाच स्क्रीनला पाच वेगवेगळ्या REST कॉल्सची गरज पडत होती. संथ कनेक्शन असलेल्या मोबाईल वापरकर्त्यांना फक्त एक पेज लोड करण्यासाठी ३० विनंत्या (requests) पाठवाव्या लागत होत्या.
GraphQL हे सोडवते. क्लायंट एकाच विनंतीमध्ये त्याला नेमके काय हवे आहे तेच विचारतो.
मी Strawberry आणि FastAPI वापरून प्रोडक्शन व्हिडिओ डिस्कव्हरी API तयार केला. मी ते कसे केले ते खाली दिले आहे.
Why Strawberry?
मी Graphene आणि Ariadne तपासून पाहिले, पण खालील कारणांमुळे Strawberry विजयी ठरले:
• Type hints हेच स्कीमा (schema) आहेत. तुम्ही Python कोड लिहिता आणि Strawberry GraphQL प्रकार (types) तयार करते. यासाठी कोणत्याही मॅन्युअल सिंक्रोनाइझेशनची गरज नसते. • हे async-native आहे. यामुळे API इव्हेंट लूपला ब्लॉक न करता अनेक विनंत्या हाताळू शकते. • FastAPI integration अत्यंत सुलभ आहे. GraphQL एंडपॉइंट अस्तित्वात असलेल्या REST रूट्सच्या अगदी शेजारीच असतो. • Built-in DataLoader. हे टूल N+1 समस्या थेट (out of the box) सोडवते.
The Data Stack
डेटा एका PHP साइटद्वारे व्यवस्थापित केलेल्या SQLite डेटाबेसमध्ये असतो. जलद फुल-टेक्स्ट सर्चसाठी मी SQLite FTS5 वापरतो.
Python सर्व्हिस हा डेटाबेस 'read-only' लेअर म्हणून वाचते. यामुळे माहितीचा केवळ एकच स्रोत (source of truth) असल्याची खात्री मिळते.
सर्चचा अनुभव चांगला करण्यासाठी, मी FTS5 रिलिव्हन्स स्कोअर आणि लोकप्रियतेचे संकेत (popularity signal) यांचे मिश्रण करतो. यामुळे एखादा एकच व्हायरल व्हिडिओ इतर सर्व सर्च रिझल्ट्सना झाकून टाकत नाही.
Solving the N+1 Problem
GraphQL मधील एक सामान्य अडथळा म्हणजे N+1 समस्या. जर तुम्ही २० व्हिडिओ फेच केले आणि नंतर प्रत्येक व्हिडिओसाठी चॅनेल फेच केले, तर एक साधी (naive) API २१ डेटाबेस क्वेरीज रन करेल.
DataLoader बॅचिंगद्वारे (batching) हे सुधारते. ते एकाच वेळी सर्व चॅनेल आयडी गोळा करते आणि ते सर्व मिळवण्यासाठी एकच क्वेरी रन करते. यामुळे आमचा क्वेरी वेळ ४०ms वरून ५ms पेक्षा कमी झाला.
Key Design Choices
• Opaque IDs: मी आयडीसाठी स्ट्रिंग्स वापरतो. यामुळे क्लायंट ॲप्समध्ये बिघाड न होता भविष्यातील बदल करणे शक्य होते. • Intentional Nullability: कोणते फील्ड्स रिकामे असू शकतात हे मी परिभाषित करतो. यामुळे क्लायंट क्रॅश न होता गहाळ डेटा हाताळण्यास मदत होते. • Read-only Schema: GraphQL API 'writes' हाताळत नाही. यामुळे सुरक्षेच्या अनेक समस्या दूर होतात. • Edge Caching: GraphQL बाय डीफॉल्ट POST वापरते, ज्याचे कॅशिंग करणे कठीण असते. Cloudflare द्वारे कॅशिंग करण्यास परवानगी देण्यासाठी मी Automatic Persisted Queries (APQ) वापरतो.
जर तुम्हाला खूप जास्त कस्टम एंडपॉइंट्स किंवा जटिल क्वेरी पॅरामीटर्समुळे त्रास होत असेल, तर हा स्टॅक एक उत्तम पर्याय आहे.