Server GraphQL code-first
Skema GraphQL mendefinisikan kontrak untuk sebuah layanan GraphQL, dengan mengekspor sekumpulan tipe, field, dan mutasi yang dapat dijalankan terhadap layanan tersebut. Saat membuat layanan GraphQL, kita dapat memilih antara:
- menjadikan skema sebagai sumber kebenaran, dan membiarkan seluruh kode implementasi kita mengikuti definisinya
- menjadikan kode kita sebagai sumber kebenaran, dan menjadikan skema sebagai artefak yang dihasilkan dari kode
Dalam kedua kasus tersebut kita akan memiliki layanan GraphQL yang berfungsi penuh, namun, tergantung pada pendekatan yang kita gunakan, kita mungkin dapat mencapai lebih banyak atau lebih sedikit fitur, dengan lebih mudah atau lebih sulit, di masa mendatang. Kedua pendekatan ini disebut, masing-masing, "schema-first" (lebih tepat disebut "SDL-first") dan "code-first".
Gato GraphQL menggunakan pendekatan code-first. Mari kita lihat alasannya.
Mengapa Gato GraphQL menggunakan code-first
Dalam pendekatan code-first, kita mulai dengan membuat kode resolver, kemudian, dari kode sebagai sumber kebenaran tunggal, skema dihasilkan sebagai artefak. Oleh karena itu, skema dibuat dengan menjalankan sebuah skrip, bukan dibuat secara manual seperti pada SDL-first. Karena code-first juga memiliki skema, ia tidak melewatkan hal penting apa pun yang disediakan oleh SDL-first.
Namun, code-first memang menyediakan fitur penting yang tidak dimiliki SDL-first: kemampuan untuk menyediakan skema dinamis, yang dapat mengubah bentuk dan atributnya tergantung pada konteks, dan diatur melalui kode pada waktu berjalan. Memang, semua fitur hebat yang ditawarkan oleh Gato GraphQL merupakan konsekuensi langsung dari penerapan code-first-nya.
Keuntungan code-first
Skema dinamis memberikan semua manfaat yang tercantum di bawah ini, di antara manfaat lainnya:
Sumber kebenaran untuk skema adalah superset dari yang diperlukan oleh GraphQL. Properti tambahan (seperti field global, koneksi global, direktif global, dan fragmen yang dipersistensikan) sudah dapat digunakan dalam API kita tanpa harus menunggu properti tersebut ditambahkan ke spesifikasi GraphQL, jika pun itu pernah terjadi.
Karena sumber kebenaran tidak terikat pada skema, kita juga dapat menghasilkan skema apa pun untuk sistem lain: GraphQL hanyalah salah satu targetnya. Misalnya, ia dapat menghasilkan JSON-schema untuk layanan REST dari sumber kebenaran yang sama.
API dapat bersifat publik/privat secara bersamaan, tergantung pada apakah pengguna sudah masuk atau belum dan pada peran pengguna yang masuk, atau menawarkan lebih banyak atau lebih sedikit field tergantung pada beberapa properti lain, seperti apakah pengguna telah membayar untuk keanggotaan PRO.
Tipe tidak mengetahui terlebih dahulu field apa yang akan mereka selesaikan. Sebaliknya, resolver field melampirkan dirinya ke resolver tipe menggunakan pola publish-subscribe, dan resolver field dapat menggantikan resolver field lainnya. Fitur ini membuat API sangat dapat diperluas, memungkinkan kita memiliki kode umum untuk API kita, dan menyesuaikannya di tingkat aplikasi untuk klien atau proyek tertentu.
Sebuah field dapat diproses tidak hanya oleh satu, tetapi oleh banyak resolver field: setiap resolver field dalam rantai dapat memutuskan, pada waktu berjalan, apakah akan memproses field tersebut atau tidak berdasarkan beberapa properti, atau meneruskannya ke sepanjang rantai. Misalnya, resolver field khusus dapat digunakan hanya jika argumen field "source: testing" diteruskan, memungkinkan pengujian di beberapa situs dalam produksi sebelum rilis umum; strategi yang sama juga memungkinkan pemberian perbaikan bug cepat untuk klien atau lingkungan tertentu tanpa mengambil risiko efek samping yang tidak diinginkan di tempat lain.
Tipe dan antarmuka dapat secara otomatis diberi namespace untuk menghindari tabrakan dari pihak ketiga.