Membina API Penemuan Video GraphQL
Apabila pangkalan data video kami berkembang kepada ratusan ribu rekod, API kami menjadi penghalang (bottleneck).
Satu skrin memerlukan lima panggilan REST yang berbeza untuk memaparkan video trending, butiran saluran, tag, jumlah tontonan, dan cadangan. Pengguna mudah alih dengan sambungan perlahan terpaksa menghantar 30 permintaan hanya untuk memuatkan satu halaman.
GraphQL menyelesaikan masalah ini. Klien meminta tepat apa yang diperlukannya dalam satu permintaan.
Saya membina API penemuan video pengeluaran menggunakan Strawberry dan FastAPI. Berikut adalah cara saya melakukannya.
Mengapa Strawberry?
Saya telah menguji Graphene dan Ariadne, tetapi Strawberry menang kerana sebab-sebab berikut:
• Petunjuk jenis (type hints) adalah skema tersebut. Anda menulis kod Python, dan Strawberry membina jenis GraphQL. Tiada penyelarasan manual diperlukan. • Ia adalah asli-asinkron (async-native). Ini membolehkan API mengendalikan banyak permintaan tanpa menyekat gelung acara (event loop). • Integrasi FastAPI adalah lancar. Titik akhir (endpoint) GraphQL terletak bersebelahan dengan laluan REST sedia ada. • DataLoader terbina dalam. Alat ini menyelesaikan masalah N+1 secara terus.
Timbunan Data
Data disimpan dalam pangkalan data SQLite yang diuruskan oleh laman web PHP. Saya menggunakan SQLite FTS5 untuk carian teks penuh yang pantas.
Perkhidmatan Python membaca pangkalan data ini sebagai lapisan baca-sahaja. Ini memastikan hanya terdapat satu sumber kebenaran (source of truth).
Untuk menjadikan carian terasa lancar, saya menggabungkan skor relevansi FTS5 dengan isyarat populariti. Ini menghalang satu video tular daripada menenggelamkan semua hasil carian yang lain.
Menyelesaikan Masalah N+1
Perangkap biasa dalam GraphQL ialah masalah N+1. Jika anda mengambil 20 video dan kemudian mengambil saluran bagi setiap satu, API yang naif akan menjalankan 21 pertanyaan pangkalan data.
DataLoader membaiki ini dengan melakukan pemprosesan berkelompok (batching). Ia mengumpul semua ID saluran dalam satu kitaran dan menjalankan satu pertanyaan tunggal untuk mengambil kesemuanya. Ini mengurangkan masa pertanyaan kami daripada 40ms kepada bawah 5ms.
Pilihan Reka Bentuk Utama
• ID Opaque: Saya menggunakan rentetan (strings) untuk ID. Ini membolehkan perubahan pada masa hadapan tanpa merosakkan aplikasi klien. • Kebolehan Null yang Sengaja (Intentional Nullability): Saya menentukan medan mana yang boleh kosong. Ini membantu klien mengendalikan data yang hilang tanpa menyebabkan kegagalan (crashing). • Skema Baca-sahaja: API GraphQL tidak mengendalikan penulisan. Ini menghapuskan banyak kerumitan keselamatan. • Pengekalan Tepi (Edge Caching): GraphQL menggunakan POST secara lalai, yang sukar untuk disimpan dalam cache. Saya menggunakan Automatic Persisted Queries (APQ) untuk membolehkan pengekalan cache melalui Cloudflare.
Jika anda bergelut dengan terlalu banyak titik akhir tersuai atau parameter pertanyaan yang kompleks, timbunan ini adalah pilihan yang mantap.