ஒரு GraphQL Video Discovery API-ஐ உருவாக்குதல்
எங்களது வீடியோ தரவுத்தளம் (database) பல லட்சம் பதிவுகளாக வளர்ந்தபோது, எங்களது API ஒரு தடையாகவும் (bottleneck) மாறியது.
டிரெண்டிங் வீடியோக்கள், சேனல் விவரங்கள், டேக்ஸ் (tags), பார் கவுண்ட்ஸ் (view counts) மற்றும் பரிந்துரைகளைக் காண்பிக்க ஒரு திரைக்கு ஐந்து வெவ்வேறு REST அழைப்புகள் (calls) தேவைப்பட்டன. மெதுவான இணையத் தொடர்பைப் பயன்படுத்தும் மொபைல் பயனர்கள், ஒரு பக்கத்தை ஏற்றவே 30 கோரிக்கைகளை (requests) அனுப்ப வேண்டியிருந்தது.
GraphQL இதைத் தீர்க்கிறது. கிளையண்ட் தனக்குத் தேவையானதை மட்டும் ஒரே கோரிக்கையில் கேட்டுப் பெறலாம்.
நான் Strawberry மற்றும் FastAPI ஆகியவற்றைப் பயன்படுத்தி ஒரு புரொடக்ஷன் வீடியோ டிஸ்கவரி API-ஐ உருவாக்கினேன். நான் அதை எப்படிச் செய்தேன் என்பது இதோ.
ஏன் Strawberry?
நான் Graphene மற்றும் Ariadne ஆகியவற்றைச் சோதித்தேன், ஆனால் பின்வரும் காரணங்களுக்காக Strawberry வெற்றி பெற்றது:
• Type hints-களே ஸ்கீமா (schema) ஆகும். நீங்கள் Python குறியீட்டை எழுதினால், Strawberry தானாகவே GraphQL வகைகளை (types) உருவாக்கிவிடும். இதற்குத் தனித்தனியாகச் சரிசெய்ய (manual syncing) வேண்டிய அவசியமில்லை. • இது async-native வகையைச் சேர்ந்தது. இது event loop-ஐத் தடுக்காமல், API பல கோரிக்கைகளைக் கையாள அனுமதிக்கிறது. • FastAPI ஒருங்கிணைப்பு மிகவும் எளிதானது (seamless). GraphQL endpoint ஏற்கனவே உள்ள REST ரூட்களுக்கு (routes) அருகிலேயே அமையும். • இதில் DataLoader ஏற்கனவே உள்ளது. இந்தத் கருவி N+1 சிக்கலைத் தானாகவே தீர்க்கிறது.
தரவு அடுக்கு (The Data Stack)
தரவுகள் ஒரு PHP தளத்தால் நிர்வகிக்கப்படும் SQLite தரவுத்தளத்தில் உள்ளன. வேகமான முழு-உரைத் தேடலுக்கு (full-text search) நான் SQLite FTS5-ஐப் பயன்படுத்துகிறேன்.
Python சேவை இந்தத் தரவுத்தளத்தை ஒரு 'read-only' அடுக்காகப் படிக்கிறது. இது தரவுகளின் நம்பகத்தன்மையை (one source of truth) உறுதி செய்கிறது.
தேடல் அனுபவம் சிறப்பாக இருக்க, நான் FTS5 பொருத்த மதிப்புகளை (relevance scores) ஒரு பிரபலத் தரத்துடன் (popularity signal) இணைக்கிறேன். இது ஒரு வைரல் வீடியோ மற்ற அனைத்துத் தேடல் முடிவுகளையும் மறைப்பதைத் தடுக்கிறது.
N+1 சிக்கலைத் தீர்த்தல்
GraphQL-இல் உள்ள ஒரு பொதுவான சிக்கல் N+1 சிக்கலாகும். நீங்கள் 20 வீடியோக்களைப் பெற்று, பின்னர் ஒவ்வொன்றிற்கும் சேனல் விவரங்களைப் பெற்றால், ஒரு சாதாரண API 21 தரவுத்தளக் கோரிக்கைகளை (queries) இயக்கும்.
DataLoader இதை 'batching' முறையில் சரிசெய்கிறது. இது அனைத்து சேனல் ஐடிகளையும் (channel IDs) ஒரே நேரத்தில் சேகரித்து, அவற்றைப் பெற ஒரே ஒரு கோரிக்கையை மட்டும் இயக்கும். இது எங்களது கோரிக்கை நேரத்தை 40ms-லிருந்து 5ms-க்கும் குறைவாகக் குறைத்தது.
முக்கிய வடிவமைப்புத் தெரிவுகள் (Key Design Choices)
• Opaque IDs: நான் ஐடிகளுக்கு (IDs) சரங்களைப் (strings) பயன்படுத்துகிறேன். இது கிளையண்ட் செயலிகளைப் பாதிக்காமல் எதிர்கால மாற்றங்களைச் செய்ய அனுமதிக்கிறது. • Intentional Nullability: எந்தெந்தத் புலங்கள் (fields) காலியாக இருக்கலாம் என்பதை நான் வரையறுக்கிறேன். இது தரவுகள் இல்லாதபோது கிளையண்ட் செயலிகள் செயலிழக்காமல் (crash) இருக்க உதவுகிறது. • Read-only Schema: GraphQL API எழுதுதல் (writes) பணிகளைக் கையாளுவதில்லை. இது பல பாதுகாப்புச் சிக்கல்களைத் தவிர்க்கிறது. • Edge Caching: GraphQL இயல்பாகவே POST முறையைப் பயன்படுத்துகிறது, இதை cache செய்வது கடினம். Cloudflare மூலம் caching செய்ய நான் Automatic Persisted Queries (APQ)-ஐப் பயன்படுத்துகிறேன்.
நீங்கள் அதிகப்படியான தனிப்பயன் எண்ட்பாயிண்ட்கள் (custom endpoints) அல்லது சிக்கலான கோரிக்கை அளவுருக்களால் (query parameters) சிரமப்பட்டால், இந்தத் தொழில்நுட்ப அடுக்கு (stack) ஒரு சிறந்த தேர்வாகும்.