Smashing Podcast Episode 31 Dengan Eve Porcello: Apa Itu GraphQL?

Dalam episode ini, kita berbicara tentang GraphQL. Apa itu, dan bagaimana cara mengatasi beberapa masalah API yang umum? Saya berbicara dengan ahli Eve Porcello untuk mencari tahu.

Tampilkan Catatan

• Malam di Twitter
• Perusahaan Hawa, Moon Highway
• Belajar GraphQL dari O'Reilly
• Temukan Jalan Anda Melalui The GraphQL Wilderness - Lokakarya GraphQL Eve diluncurkan awal 2021

Update mingguan

• Cara Menggunakan MDX yang Disimpan Dalam Sanity Di Situs Web Next.js
  ditulis oleh Jason Lenstorf
• Membangun Chatbot yang Diaktifkan NLP Percakapan Menggunakan Dialogflow Google
  ditulis oleh Nwani Victory
• Pertimbangan Etis Dalam Penelitian UX: Kebutuhan Untuk Pelatihan Dan Tinjauan
  ditulis oleh Victor Yocco
• Membuat Situs Web Lebih Mudah Untuk Dibicarakan
  ditulis oleh Frederick O'Brien
• Cara Mendesain UI Sederhana Saat Anda Memiliki Solusi Kompleks
  ditulis oleh Suzanne Scacca

Salinan

Drew McLellan: Dia adalah seorang insinyur perangkat lunak, instruktur, penulis, dan salah satu pendiri perusahaan pengembangan kurikulum dan pelatihan, Moon Highway. Karirnya mulai menulis spesifikasi teknis dan membuat desain UX untuk proyek web. Sejak memulai Moon Highway pada 2012, dia membuat konten video untuk egghead.io dan LinkedIn Learning, dan telah ikut menulis buku Learning React dan Learning GraphQL untuk O'Reilly's Media.

Drew: Dia juga sering menjadi pembicara konferensi, dan telah mempresentasikan di konferensi termasuk React Rally, GraphQL Summit, dan OSCON. Jadi kita tahu dia ahli dalam GraphQL, tapi tahukah Anda dia pernah mengajar beruang kutub bermain catur? Teman-temanku yang hebat, tolong sambut Eve Porcello.

Drew: Hai Hawa, apa kabar?

Eve Porcello: Saya hebat.

Drew: Seperti yang saya sebutkan di sana, Anda adalah seorang pendidik dalam hal-hal seperti JavaScript dan React, tetapi saya ingin berbicara dengan Anda hari ini tentang salah satu bidang spesialis Anda yang lain, GraphQL. Banyak dari kita akan pernah mendengar tentang GraphQL dalam beberapa kapasitas, tetapi mungkin tidak sepenuhnya yakin apa itu, atau apa fungsinya, dan khususnya, masalah seperti apa yang dipecahkannya di tumpukan web.

Drew: Jadi siapkan panggung untuk kami, jika Anda mau, jika saya seorang pengembang front-end, di mana GraphQL masuk ke ekosistem dan fungsi apa yang dijalankannya untuk saya?

Hawa: Ya. GraphQL cocok antara ujung depan dan ujung belakang. Ini semacam hidup di tengah-tengah antara keduanya dan memberikan banyak manfaat bagi pengembang front-end dan pengembang back-end.

Eve: Jika Anda seorang pengembang front end, Anda dapat menentukan semua persyaratan data front end Anda. Jadi, jika Anda memiliki daftar besar komponen React, misalnya, Anda dapat menulis kueri. Dan itu akan menentukan semua bidang yang Anda perlukan untuk mengisi data untuk halaman itu.

Eve: Sekarang dengan bagian backend, itu benar-benar milik sendiri, karena kami dapat mengumpulkan banyak data dari banyak sumber yang berbeda. Jadi kami memiliki data di REST API, dan database, dan semua tempat yang berbeda ini. Dan GraphQL memberi kita lapisan orkestrasi kecil yang bagus ini untuk benar-benar memahami kekacauan di mana semua data kita berada. Jadi ini benar-benar berguna untuk jenis semua orang di seluruh tumpukan.

Drew: Jadi pada dasarnya ini adalah teknologi berbasis API, bukan? Itu berada di antara ujung depan dan ujung belakang Anda dan menyediakan semacam API, apakah itu benar?

Hawa: Ya, itu benar sekali. Tepat.

Drew: Saya pikir, selama dekade terakhir, standar emas untuk API adalah istirahat. Jadi, jika Anda memiliki aplikasi sisi klien dan Anda perlu mengisinya dengan data dari backend, Anda akan membangun titik akhir REST API dan Anda akan menanyakannya. Jadi di mana model itu jatuh? Dan kapan kita membutuhkan GraphQL untuk masuk dan menyelesaikannya untuk kita?

Eve: Nah, masalah yang GraphQL benar-benar membantu kami, jenis masalah emas, solusi emas, saya kira, yang disediakan GraphQL adalah bahwa dengan REST kami mengambil banyak data secara berlebihan. Jadi jika saya memiliki pengguna slash atau produk slash, itu akan mengembalikan semua data saya setiap kali saya mencapai rute.

Eve: Dengan GraphQL, kita bisa sedikit lebih memilih data apa yang kita inginkan. Jadi jika saya hanya membutuhkan empat bidang dari objek yang memiliki seratus, saya akan dapat benar-benar menentukan bidang tersebut dan tidak perlu memuat data ke dalam, atau memuat semua data itu, saya harus katakan, ke perangkat Anda, karena itu banyak kerja keras ekstra, terutama untuk ponsel Anda.

Drew: Saya telah melihat dan bekerja dengan REST API di masa lalu yang memiliki bidang opsional di mana Anda dapat meneruskan daftar data yang Anda inginkan kembali, atau Anda dapat menambah apa yang kembali dengan hal-hal tambahan. Jadi saya kira itu mengidentifikasi masalah ini, bukan? Artinya, Anda tidak selalu ingin data yang sama kembali setiap saat. Jadi, apakah GraphQL memformalkan pendekatan yang memungkinkan ujung depan menentukan apa yang akan dikembalikan oleh backend, dalam hal data?

Hawa: Ya, persis. Jadi kueri Anda kemudian menjadi bagaimana Anda bertanya, bagaimana Anda memfilter, bagaimana Anda memahami segala jenis informasi dari mana saja.

Eve: Saya juga berpikir penting untuk dicatat bahwa kita tidak harus merobohkan semua REST API agar dapat bekerja dengan GraphQL dengan benar-benar berhasil. Banyak implementasi GraphQL paling sukses yang pernah saya lihat di luar sana, ini membungkus REST API. Dan kueri GraphQL benar-benar memberi Anda cara untuk memikirkan data apa yang Anda butuhkan. Dan mungkin sebagian data Anda berasal dari pengguna dan produk kami, contoh, sebagian data berasal dari REST, sebagian berasal dari database.

Drew: Saya kira skenario yang umum adalah, Anda mungkin memiliki titik akhir di situs web Anda yang mengembalikan informasi tentang pengguna untuk menampilkan header. Ini mungkin memberi Anda nama pengguna dan avatar mereka. Dan Anda menyisihkannya di setiap halaman dan mengisi data, tetapi kemudian Anda menemukan tempat lain di aplikasi Anda, Anda perlu menampilkan nama lengkapnya.

Drew: Jadi Anda menambahkannya ke titik akhir dan itu mulai mengembalikannya. Dan kemudian Anda melakukan bagian manajemen akun Anda, dan Anda perlu seperti alamat surat mereka. Jadi itu akan dikembalikan oleh titik akhir itu juga.

Drew: Dan sebelum Anda menyadarinya, titik akhir itu mengembalikan seluruh muatan berat yang menghabiskan banyak biaya di bagian belakang untuk disatukan, dan tentu saja banyak untuk diunduh.

Drew: Dan itu telah disingkirkan di setiap halaman hanya untuk menampilkan avatar. Jadi saya rasa itu adalah jenis masalah yang tumbuh dari waktu ke waktu, yang sangat mudah untuk jatuh ke dalam, terutama di tim besar, GraphQL, itu di atas masalah itu. Ia tahu bagaimana menyelesaikannya, dan ia dirancang untuk menyelesaikannya.

Hawa: Tepat sekali. Dan ya, saya pikir seluruh gagasan tentang Skema GraphQL, menurut saya benar-benar, agak jarang dibicarakan daripada bagian bahasa kueri GraphQL. Tapi saya benar-benar merasa bahwa Skema secara khusus memberi kita sistem tipe yang bagus untuk API ini.

Eve: Jadi siapa pun di tim, manajer, pengembang front-end, pengembang back-end, siapa saja yang benar-benar berurusan dengan data dapat berkumpul, menyatukan data apa yang sebenarnya ingin kami sajikan di API ini, dan kemudian semua orang tahu sumber apa itu kebenarannya adalah, mereka dapat membangun bagian aplikasi mereka sendiri berdasarkan itu.

Eve: Jadi ada beberapa manajemen skema rumit yang muncul dengan itu juga. Namun sejauh beralih dari layanan mikro kembali ke monolit, kami seperti melakukan itu, tetapi tetap mendapatkan semua manfaat yang kami suka dari layanan mikro.

Drew: Dan apakah saya memahami dengan benar bahwa cara khas menyiapkan sistem GraphQL adalah bahwa pada dasarnya Anda akan memiliki satu rute, yang merupakan titik akhir tempat Anda mengirim semua pertanyaan sehingga Anda tidak harus… Seringkali salah satu dari hal yang paling sulit adalah mencari tahu apa yang harus diberi nama, dan jalur apa yang seharusnya menjadi tujuan kueri khusus ini. Ini mengembalikan pengguna dan produk, haruskah itu memotong pengguna sesuatu, atau memotong produk sesuatu?

Drew: Dengan GraphQL Anda hanya memiliki satu titik akhir yang baru saja Anda jalankan pertanyaan Anda dan Anda mendapatkan kembali respons yang sesuai.

Hawa: Tepat sekali. Ya. Ini adalah titik akhir tunggal. Saya kira, Anda masih menghadapi masalah penamaan karena Anda menamai semua yang ada di Skema. Tapi sejauh, saya merasa seperti banyak perusahaan yang telah membuat taruhan besar pada layanan mikro, semua orang seperti, titik akhir apa yang kita miliki? Dimana mereka? Bagaimana mereka didokumentasikan? Dan dengan GraphQL, kami memiliki satu tempat, satu jenis kamus untuk mencari apa pun yang ingin kami ketahui tentang cara kerja API.

Drew: Jadi, saya sangat akrab dengan bahasa kueri lainnya, seperti SQL adalah contoh nyata dari bahasa kueri yang akan diketahui banyak pengembang web. Dan kueri di dalamnya berbentuk hampir seperti perintah. Ini string teks, bukan, Pilih ini dari itu, di mana, apa pun. Format apa yang diambil kueri dengan GraphQL?

Eve: Ini masih merupakan rangkaian teknologi, tetapi tidak menentukan dari mana logika itu berasal. Dan banyak logika dipindahkan kembali ke server. Jadi server GraphQL, GraphQL API benar-benar bertanggung jawab untuk mengatakan, "Dapatkan data ini dari tempatnya, filter berdasarkan parameter ini."

Eve: Tapi dalam bahasa query, ini sangat berorientasi pada bidang. Jadi kami hanya menambahkan bidang untuk apa pun yang ingin kami ambil. Kami juga dapat menempatkan filter pada kueri tersebut. Tapi saya pikir itu sedikit kurang langsung tentang dari mana informasi itu berasal. Banyak fungsi yang dibangun ke dalam server.

Drew: Jadi Anda dapat mencampur dan mencocokkan dalam kueri. Anda dapat membuat permintaan yang mengembalikan banyak jenis data yang berbeda dalam satu permintaan. Apakah itu benar?

Hawa: Ya, itu benar sekali. Jadi, Anda dapat mengirim kueri untuk bidang sebanyak yang diizinkan oleh server Anda, dan mengembalikan semua jenis data bersarang. Tapi begitulah cara kerjanya, kami menghubungkan berbagai jenis bidang. Jadi saya kira kita akan mendaur ulang pengguna dan ide produk saya, tetapi pengguna mungkin memiliki bidang produk yang mengembalikan daftar produk. Semua itu terkait dengan jenis lain juga. Jadi, sedalam yang kami inginkan untuk kueri, kami bisa.

Drew: Jadi, apakah itu berarti mengambil data untuk tampilan umum di aplikasi web Anda yang mungkin memiliki banyak hal yang terjadi, bahwa Anda cukup membuat satu permintaan ke backend dan menyelesaikan semuanya sekaligus tanpa perlu membuat yang berbeda kueri ke titik akhir yang berbeda, karena semuanya hanya satu hal?

Hawa: Ya. Itulah keseluruhan tujuannya, hanya satu kueri, tentukan setiap bidang yang Anda inginkan, lalu kembalikan dalam satu respons.

Drew: Dan kuerinya berbasis JSON, benar?

Eve: Kueri itu sendiri adalah string teks, tetapi biasanya mengembalikan data JSON. Jadi jika saya memiliki bidang, maka respons JSON saya sama persis, dan jadi sangat jelas apa yang Anda dapatkan saat mengirim kueri itu, karena respons data terlihat persis sama.

Drew: Banyak kueri yang sepertinya hampir seperti objek kosong, seperti pelanggan atau produk. Apakah ada cara untuk menentukan kueri yang lebih kompleks di mana logika bisnis dikendalikan di backend? Katakanlah saya ingin mendapatkan daftar tim untuk pengguna, tetapi hanya jika pengguna itu adalah admin tim dan di mana rencana tim belum kedaluwarsa, dan segala macam kendala nyata yang kita hadapi dalam pengembangan aplikasi web sehari-hari. Bisakah itu dicapai dengan GraphQL?

Hawa: Tentu saja. Jadi itulah hal yang sangat menarik dan kuat tentang GraphQL adalah, Anda dapat memindahkan banyak logika itu ke server. Jika Anda memiliki kueri yang kompleks, beberapa tipe pengguna yang sangat spesifik yang ingin Anda dapatkan, yang perlu Anda lakukan dalam Skema adalah mengatakan, "Dapatkan pengguna yang rumit", dan kemudian di server, akan ada fungsi di mana Anda dapat menulis semua logika dalam bahasa apa pun yang Anda inginkan. JavaScript adalah jenis bahasa implementasi GraphQL yang paling populer, tetapi Anda tidak harus menggunakannya sama sekali. Jadi Python, Go, C++, apa pun yang ingin Anda gunakan, Anda dapat membangun server GraphQL dengan itu. Tapi ya, Anda dapat mendefinisikan kueri sekompleks yang Anda inginkan.

Drew: Dan saya rasa itu memungkinkan Anda untuk merangkum banyak logika bisnis kemudian dalam jenis objek baru. Apakah itu adil? Anda tahu, Anda mengatur pengguna yang rumit dan kemudian Anda tidak perlu memikirkan apa itu pengguna yang rumit, tetapi Anda dapat terus menggunakan pengguna yang rumit itu dan mengetahui bahwa logika bisnis diimplementasikan pada itu. Apakah itu benar?

Hawa: Itu benar sekali. Jadi saya pikir ini sangat bagus untuk orang-orang front-end karena mereka dapat mulai membuat prototipe berdasarkan itu. Dan kemudian tim backend dapat mengimplementasikan fungsi-fungsi tersebut untuk membuatnya berfungsi. Dan kemudian ada semacam pemahaman bersama untuk apa tipe itu sebenarnya dan siapa mereka, dan, "Apa bidang pada tipe itu?" Dan semuanya dapat ditangani oleh di mana pun di tumpukan GraphQL bekerja. Dan itulah mengapa itu bukan teknologi ujung depan atau ujung belakang. Ini benar-benar baik, dan tidak keduanya.

Drew: Kedengarannya seperti memformalkan API dan hubungan antara front end dan backend, jadi semua orang mendapatkan antarmuka terstandarisasi yang dapat diprediksi.

Hawa: Tepat sekali.

Drew: Yang saya kira dalam organisasi di mana ujung depan dan ujung belakang dimiliki oleh tim yang berbeda, yang sama sekali tidak biasa, saya kira pendekatan ini juga memungkinkan perubahan dilakukan, katakanlah, di ujung depan, mungkin memerlukan perbedaan data, tanpa memerlukan seseorang yang bekerja di backend untuk membuat perubahan yang sesuai dengan itu. Anda masih memiliki API yang dapat disesuaikan hampir tanpa batas ini tanpa memerlukan pekerjaan apa pun untuk mengubahnya jika Anda memerlukan data baru.

Hawa: Ya, tepat sekali.

Drew: Jadi, apakah server GraphQL bertanggung jawab untuk memformat respons, atau apakah Anda perlu melakukannya di logika sisi server Anda?

Eve: Jadi server GraphQL mendefinisikan dua hal. Ini mendefinisikan Skema itu sendiri yang hidup di server, dan kemudian mendefinisikan fungsi resolver. Itu adalah fungsi yang pergi mendapatkan data dari mana pun itu. Jadi jika saya memiliki REST API yang saya bungkus dengan GraphQL, resolver akan mengambil dari API itu, mengubah data sesuai kebutuhan, dan kemudian mengembalikannya ke klien dalam fungsi itu. Anda dapat menggunakan fungsi database apa pun yang Anda inginkan di server itu juga. Jadi jika Anda memiliki data di banyak tempat yang berbeda, ini adalah tempat kohesif yang sangat bagus untuk memasukkan semua data itu dan untuk merancang semua logika di sekitar, “Dari mana data itu datang? Bagaimana kita ingin mengubahnya?”

Drew: Klien berkata, "Saya ingin pengguna yang kompleks", server menerimanya dalam kueri dan dapat berkata, "Benar, saya akan mencari resolver pengguna yang kompleks." Apakah itu benar?

Hawa: Mm-hmm (mengiyakan).

Drew: Yang merupakan fungsinya, dan kemudian Anda menulis logika Anda bahwa tim backend Anda, atau siapa pun yang menulis logika di dalam fungsi itu, untuk melakukan apa pun yang diperlukan untuk mengembalikan pengguna yang kompleks.

Hawa: Ya, persis.

Drew: Jadi itu bisa memanggil API lain, bisa menanyakan database, bisa mencari barang di cache, atau apa saja.

Hawa: Hampir semua hal. Dan kemudian, selama pengembalian dari fungsi itu sesuai dengan persyaratan Skema, cocok dengan bidang apa, jenis apa, yang dikembalikan ke sana, maka semuanya akan bekerja dengan baik dan harmonis.

Drew: Saya kira itu memberi Anda format respons yang konsisten di seluruh API Anda hanya secara default. Anda tidak perlu mendesain seperti apa tampilannya. Anda hanya mendapatkan hasil yang konsisten.

Hawa: Ya, persis.

Drew: Saya pikir itu bisa menjadi kemenangan yang sangat besar, karena sangat sulit untuk mempertahankan konsistensi di berbagai titik akhir API, terutama di tim yang lebih besar. Orang yang berbeda mengerjakan hal yang berbeda. Kecuali Anda memiliki tata kelola yang cukup ketat, itu bisa menjadi sangat kompleks dengan sangat cepat, bukan?

Hawa: Ya, tentu saja. Dan saya pikir Skema hanyalah dokumen kecil yang bagus untuk menggambarkan semuanya. Anda mendapatkan manfaat otomatis untuk dapat melihat semua bidang dalam Skema itu setiap kali Anda mencoba mengirim kueri ke sana, karena Anda dapat mengirim kueri introspeksi dan ada segala macam alat yang bagus untuk itu, seperti GraphQL dan GraphQL Playground, alat kecil yang dapat Anda gunakan untuk berinteraksi dengan data API.

Eve: Tapi juga, jika Anda pernah bermain-main dengan Postman, suka melakukan ping ke REST API, banyak di antaranya, dokumentasinya tidak benar-benar ada atau sulit ditemukan, atau semacamnya. GraphQL benar-benar memberi Anda lapisan kohesif yang bagus untuk menggambarkan segala sesuatu yang mungkin menjadi bagian dari API itu.

Drew: Secara praktis, bagaimana cara kerja di sisi server? Maksud saya, saya kira Anda perlu menjalankan layanan GraphQL sebagai bagian dari infrastruktur Anda, tetapi seperti apa bentuknya? Apakah seluruh server berjalan pada portnya sendiri? Atau apakah itu seperti perpustakaan yang Anda integrasikan ke Express atau Apache yang ada atau apa pun dengan rute yang memutuskan ke layanan itu? Bagaimana Anda menerapkannya?

Eve: Ya, ini adalah server yang sebenarnya. Jadi jenis implementasi GraphQL yang paling populer adalah server Node.js. Ketika GraphQL sebagai spesifikasi dirilis, tim merilis implementasi referensi ini dalam JavaScript, semacam server Node yang berfungsi sebagai pedoman untuk semua yang lain yang telah muncul. Tapi ya, Anda dapat menjalankan server ini pada instance mereka sendiri. Anda dapat menempatkannya di Lambda. Jadi ada Apollo Server Express, ada Apollo Server Lambda; segala macam jenis implementasi yang dapat Anda gunakan untuk benar-benar menjalankan hal ini.

Drew: Jadi Anda menyebutkan secara singkat sebelum konsep Skema yang dimiliki server.

Hawa: Ya.

Drew: Itu memberi Anda kemampuan untuk mendeskripsikan tipe Anda lebih ketat dari sekadar, Anda tahu, memetakan nama ke resolver. Ada lebih banyak yang terlibat di sana, bukan?

Hawa: Ya. Ada bahasa lengkap. Jadi saya telah mereferensikan spesifikasi dan saya tidak menjelaskan apa itu. GraphQL sendiri merupakan spec yang menjelaskan bahasa query dan bahasa definisi Schema. Jadi ia memiliki sintaks sendiri. Ini memiliki aturan sendiri untuk mendefinisikan jenis ini.

Eve: Saat Anda menggunakan bahasa definisi Skema, pada dasarnya Anda menggunakan semua fitur bahasa itu untuk dipikirkan, apa saja tipe yang merupakan bagian dari API? Ini juga tempat Anda menentukan kueri, mutasi, yang merupakan kata kerja, seperti tindakan, membuat login akun, hal-hal seperti itu. Dan bahkan langganan GraphQL, yang merupakan hal keren lainnya, GraphQL waktu nyata yang dapat Anda tentukan di dalam Skema.

Eve: Jadi ya, Skema itu sangat penting. Dan menurut saya ini memberi kita penegakan jenis yang bagus di seluruh aplikasi Stack lengkap kami, karena segera setelah Anda mulai menyimpang dari bidang tersebut dan dari jenis tersebut, Anda mulai melihat kesalahan, yang, dalam hal ini, bagus, karena Anda 'mengikuti aturan Skema.

Drew: Apakah ada persilangan antara itu dan TypeScript? Apakah ada semacam sinergi antara keduanya di sana?

Hawa: Tentu saja. Jadi, jika Anda adalah orang yang banyak berbicara tentang GraphQL, terkadang orang akan memberi tahu Anda bahwa itu buruk, dan mereka akan mendatangi Anda secara terbuka, ketika Anda bisa melakukannya, dan berbicara tentang bagaimana GraphQL tidak baik. Tetapi sering kali mereka melewatkan hal-hal keren yang Anda dapatkan dari tipe. Sejauh sinergi dengan TypeScript berjalan, tentu saja, Anda dapat membuat tipe secara otomatis untuk aplikasi ujung depan Anda menggunakan tipe dari Skema. Jadi itu adalah kemenangan besar karena Anda tidak hanya dapat membuatnya untuk pertama kali, yang memberi Anda interoperabilitas yang hebat dengan aplikasi ujung depan Anda, tetapi juga, seiring perubahan, Anda dapat membuat ulang tipe dan kemudian membangun untuk mencerminkan perubahan tersebut. Jadi ya, saya pikir hal-hal itu sangat cocok bersama karena tipe mulai menjadi semacam aturan de facto.

Eve: … menjadi semacam aturan de facto dalam JavaScript, mereka cocok bersama.

Drew: Tampaknya menjadi semacam tema yang sedang berlangsung dengan cara TypeScript telah dirancang ... itu bukan TypeScript, maaf. GraphQL telah dirancang bahwa ada banyak tentang memformalkan interaksi antara ujung depan dan ujung belakang. Dan itu datang sebagai solusi di antara konsistensi yang adil dan formalisasi dari apa yang sejauh ini merupakan pengalaman yang cukup suka berkelahi dengan istirahat bagi banyak orang. Satu hal yang harus selalu kami ingat saat menulis aplikasi sisi klien adalah bahwa kode tersebut dapat diperiksa dan berpotensi dimodifikasi. Dan memiliki API di mana klien hanya dapat meminta data bisa berbahaya. Sekarang, jika Anda dapat menentukan bidang apa yang Anda inginkan, mungkin itu bisa berbahaya. Di mana dalam keseluruhan tumpukan, Anda akan berurusan dengan otorisasi pengguna dan memastikan bahwa aturan bisnis di sekitar data Anda ditegakkan?

Eve: Anda akan menangani itu semua di server. Jadi, itu bisa terjadi dalam berbagai cara. Anda tidak harus menggunakan salah satu strategi, tetapi resolver Anda akan menangani otorisasi Anda. Jadi itu bisa berarti membungkus REST API yang sudah ada, seperti layanan seperti Auth0 atau sesuatu yang Anda buat sendiri. Itu bisa berarti berinteraksi dengan OAuth, seperti GitHub atau login Facebook atau Google, hal-hal semacam itu yang melibatkan jenis token yang lewat bolak-balik dengan resolver. Tetapi seringkali itu akan dibangun langsung ke dalam Skema. Jadi Skema akan mengatakan, saya tidak tahu, kami akan membuat mutasi login. Dan kemudian saya mengirim mutasi itu dengan kredensial saya dan kemudian di server, semua kredensial itu diverifikasi. Jadi klien tidak perlu terlalu khawatir, mungkin sedikit melewati token dan hal-hal seperti itu. Tetapi sebagian besar hanya dibangun ke dalam server.

Drew: Jadi intinya, itu tidak benar-benar berubah dibandingkan dengan cara kami membangun titik akhir istirahat saat ini. Istirahat sebagai teknologi, yah, itu tidak benar-benar berurusan dengan otorisasi dan kami memiliki middleware dan hal-hal di server yang menanganinya. Dan itu sama saja dengan GraphQL. Anda hanya berurusan dengan itu. Apakah ada konvensi di komunitas GraphQL untuk melakukan itu? Apakah ada pendekatan umum atau ada di semua tempat untuk bagaimana orang memilih untuk mengimplementasikannya?

Eve: Sejujurnya ada di mana-mana. Saya pikir sering kali Anda akan melihat orang-orang membangun ke dalam Skema dan maksud saya, mewakili tipe-tipe itu dan pengguna yang berwenang versus pengguna biasa yang membangun tipe-tipe itu ke dalam Skema itu sendiri. Tetapi Anda juga akan melihat banyak orang menggunakan solusi pihak ketiga. Saya menyebutkan Auth0. Banyak orang akan mengalihkan otorisasi mereka ke perusahaan yang lebih fokus padanya, terutama perusahaan kecil, startup, hal-hal seperti itu. Tetapi Anda juga akan melihat perusahaan yang lebih besar mulai menciptakan solusi untuk ini. Jadi AWS, Amazon memiliki AppSync, yang merupakan cita rasa GraphQL mereka, dan mereka memiliki daftar penulis yang dibangun langsung ke AppSync. Dan itu agak keren hanya untuk dapat, saya tidak tahu, tidak perlu khawatir tentang semua hal itu atau setidaknya menyediakan antarmuka untuk bekerja dengan itu. Jadi banyak alat ekosistem ini, saya pikir otorisasi adalah topik besar di GraphQL. Mereka telah melihat jenis kebutuhan, permintaan akan solusi autentikasi, dan pendekatan standar untuk menangani autentikasi pada grafik.

Drew: Saya kira hampir tidak ada, implementasi di luar sana yang tidak memerlukan semacam otorisasi. Jadi ya, itu akan menjadi persyaratan yang cukup umum. Kami semua semakin banyak membangun aplikasi berkomponen, terutama ketika kami menggunakan hal-hal React dan View dan apa pun yang Anda miliki. Dan prinsip kopling longgar meninggalkan kita dengan banyak komponen yang tidak perlu tahu apa lagi yang berjalan pada halaman di sekitar mereka. Apakah ada bahaya sebagai akibatnya, Anda bisa berakhir dengan banyak komponen yang menanyakan data yang sama dan membuat banyak permintaan? Atau apakah itu hanya masalah arsitektur di aplikasi Anda yang perlu Anda pecahkan untuk itu? Apakah ada semacam solusi yang baik untuk menangani itu?

Eve: Yah, saya pikir karena GraphQL sebagian besar, bukan 100% dari solusi, tetapi hampir setiap permintaan GraphQL dikirim melalui HTTP. Jadi jika Anda ingin melacak di mana beberapa permintaan itu terjadi, itu mungkin masalah yang cukup umum bagi orang-orang yang menggunakan data lainnya untuk aplikasi mereka. Jadi ada beberapa alat seperti Paulo Client Dev Tools dan Urkel Dev Tools untuk pengembang front end yang seperti, “Apa yang terjadi? Pertanyaan mana yang ada di halaman ini?” Itu memberi Anda wawasan yang sangat jelas tentang apa yang terjadi. Ada semacam beberapa aliran pemikiran dengan itu. Apakah kami membuat satu kueri yang sangat besar untuk semua data halaman? Atau apakah kami membuat kueri yang lebih kecil untuk memuat data untuk berbagai bagian aplikasi? Keduanya seperti yang Anda bayangkan, mereka memiliki kekurangannya sendiri, hanya karena jika Anda memiliki pertanyaan besar, Anda menunggu lebih banyak bidang.

Eve: Jika Anda memiliki kueri yang lebih kecil, mungkin ada bentrokan antara data yang Anda perlukan. Tapi saya pikir, dan tidak terlalu menyinggung, tapi saya sudah di sana. Jadi ada sesuatu yang disebut Deferred Directive yang datang ke spesifikasi GraphQL dan Deferred Directive akan membantu dengan jenis pemuatan konten sekunder. Jadi katakanlah Anda memiliki beberapa konten di bagian atas halaman, konten super penting yang ingin Anda muat terlebih dahulu. Jika Anda menambahkan itu ke kueri Anda dan kemudian setiap bidang berikutnya mendapatkan arahan yang ditangguhkan untuk itu. Itu hanya penghias kecil yang akan Anda tambahkan ke bidang, yang kemudian akan berkata, "Baiklah, muat data penting dulu, lalu tahan dan muat data kedua." Dan itu memberi Anda ini, ini adalah tampilan jenis streaming data ke ujung depan Anda, sehingga ada kinerja yang dirasakan, ada interaktivitas. Orang-orang langsung melihat data versus menunggu setiap bidang memuat halaman, yang ya, itu bisa menjadi masalah.

Drew: Ya. Saya kira itu memungkinkan Anda untuk merancang halaman di mana segala sesuatu ... kami tidak suka berbicara terlalu banyak tentang viewport, tetapi itu adalah segalanya di paro atas, Anda dapat memprioritaskan, memuat itu dan kemudian memuat secara sekunder dalam segala hal lebih lanjut turun. Jadi, kami telah berbicara banyak tentang kueri data. Salah satu tugas utama API adalah mengirimkan data baru dan yang dimodifikasi kembali ke server untuk kegigihan. Anda menyebutkan secara singkat mutasi sebelumnya. Itu istilah yang digunakan GraphQL untuk menulis data kembali ke server?

Hawa: Tepat sekali. Jadi, segala jenis perubahan yang ingin kami buat pada data, apa pun yang ingin kami tulis kembali ke server, itu adalah mutasi, dan itu semua seperti kueri, mereka diberi nama operasi yang hidup di server. Jadi, Anda dapat memikirkan tentang semua hal yang kami ingin agar dapat dilakukan oleh pengguna kami? Mewakili mereka yang bermutasi. Dan sekali lagi di server, tulis semua fungsi yang membuat hal itu berfungsi.

Drew: Dan apakah itu sesederhana meminta data? Memanggil mutasi semudah itu?

Hawa: Ya. Itu bagian dari bahasa kueri. Itu terlihat sangat identik. Satu-satunya perbedaan adalah, yah, saya kira kueri menggunakan filter. Jadi mutasi mengambil apa yang tampak seperti filter dalam kueri itu sendiri. Tetapi mereka bertanggung jawab untuk benar-benar mengubah data. Email dan kata sandi mungkin dikirim dengan mutasi, dan kemudian server mengumpulkannya dan kemudian menggunakannya untuk memberi otorisasi kepada pengguna.

Drew: Jadi, sama seperti sebelumnya, Anda membuat resolver di backend untuk menanganinya dan melakukan apa pun yang perlu dilakukan. Satu kejadian umum saat menulis data adalah Anda ingin mengkomit perubahan Anda dan kemudian melakukan kueri ulang untuk mendapatkan jenis status saat ini. Apakah GraphQL memiliki alur kerja yang baik untuk itu?

Hawa: Itu semacam hidup dalam mutasi itu sendiri. Jadi, sering kali saat membuat Skema Anda, Anda akan membuat operasi mutasi. Saya akan tetap dengan log-in, menerima email dan kata sandi. Dan mutasi itu sendiri mengembalikan sesuatu. Jadi itu bisa mengembalikan sesuatu yang sederhana seperti Boolean, ini berjalan dengan baik, atau ini berjalan buruk, atau itu bisa mengembalikan tipe yang sebenarnya. Jadi seringkali Anda akan melihat mutasi seperti mutasi masuk, mungkin itu mengembalikan pengguna. Jadi Anda mendapatkan semua informasi tentang pengguna setelah mereka masuk. Atau Anda dapat membuat jenis objek khusus yang memberi Anda pengguna itu ditambah jam berapa pengguna masuk, dan mungkin sedikit lebih banyak metadata tentang transaksi itu di objek yang dikembalikan . Jadi sekali lagi, terserah Anda untuk mendesainnya, tetapi pola itu benar-benar dimasukkan ke dalam GraphQL.

Drew: Ini semua terdengar sangat bagus, tetapi setiap pilihan teknis melibatkan pertukaran. Apa kerugian menggunakan GraphQL? Apakah ada skenario di mana itu akan menjadi pilihan yang sangat buruk?

Eve: Saya pikir tempat di mana GraphQL mungkin berjuang adalah membuat peta satu-ke-satu dari-

Eve: … perjuangan adalah membuat peta satu-ke-satu dari data tabular. Jadi katakanlah Anda memiliki, saya tidak tahu, memikirkan tabel database dengan segala macam bidang yang berbeda dan, saya tidak tahu, ribuan bidang pada tipe tertentu, hal-hal seperti itu, tipe data itu dapat direpresentasikan dengan baik dengan GraphQL, tetapi kadang-kadang ketika Anda menjalankan proses untuk menghasilkan Skema pada data itu, Anda memiliki, dalam Skema, masalah yang sama yang Anda miliki di database, yang mungkin terlalu banyak data yang melampaui apa yang klien sebenarnya membutuhkan. Jadi saya pikir tempat-tempat itu berpotensi menjadi masalah. Saya telah berbicara dengan orang-orang yang memiliki Skema yang dibuat secara otomatis berdasarkan data mereka dan itu menjadi Skema sejuta baris atau sesuatu seperti itu, hanya ribuan dan ribuan baris kode Skema. Dan di situlah menjadi sedikit rumit, seperti seberapa berguna ini sebagai dokumen yang dapat dibaca manusia?

Hawa: Ya. Jadi, situasi apa pun di mana Anda berurusan dengan klien, itu sangat cocok sejauh memodelkan setiap jenis data yang berbeda, itu menjadi sedikit rumit jika sumber data Anda terlalu besar.

Drew: Jadi kedengarannya seperti di mana pun Anda akan dengan hati-hati menyusun respons di bidang dan melakukannya lebih banyak dengan tangan, Anda bisa mendapatkan hasil yang sangat kuat. Tetapi jika Anda menghasilkan barang secara otomatis karena Anda baru saja mendapatkan Skema besar, maka mungkin itu menjadi sedikit berat.

Hawa: Ya. Dan saya pikir orang-orang mendengarkan dan tidak setuju dengan saya tentang itu karena ada alat yang bagus untuk itu juga. Tapi saya pikir tempat di mana GraphQL benar-benar bersinar adalah langkah mengabstraksi logika ke server, memberi pengembang ujung depan kebebasan untuk menentukan komponen mereka atau persyaratan data ujung depan mereka, dan benar-benar mengelola Skema sebagai sebuah tim.

Drew: Apakah ada sesuatu yang dibangun ke dalam bahasa kueri untuk menangani paginasi hasil, atau apakah itu tergantung pada implementasi khusus sesuai kebutuhan?

Hawa: Ya. Pagination, Anda akan membangun terlebih dahulu ke dalam Skema, sehingga Anda dapat menentukan pagination untuk itu. Ada banyak pedoman yang muncul di masyarakat. Contoh yang baik untuk dilihat apakah Anda baru mengenal GraphQL atau tidak, saya selalu melihat ini, adalah API GitHub GraphQL. Mereka pada dasarnya telah membuat ulang API mereka untuk v4 dari API yang menghadap publik mereka menggunakan GraphQL. Jadi itu adalah tempat yang bagus untuk melihat bagaimana perusahaan besar sebenarnya menggunakan ini dalam skala besar. Banyak orang menjalankan API besar, tetapi mereka tidak mempublikasikannya ke semua orang. Jadi pagination dibangun ke dalam API itu dengan sangat baik dan Anda dapat mengembalikan, saya tidak tahu, 50 repositori pertama yang pernah Anda buat, atau Anda juga dapat menggunakan pagination berbasis kursor untuk mengembalikan catatan berdasarkan ide dalam data Anda. Jadi paginasi berbasis kursor dan jenis paginasi posisional seperti catatan pertama dan terakhir, biasanya begitulah cara orang mendekatinya, tetapi ada banyak teknik.

Drew: Apakah ada gotcha besar yang harus kita ketahui saat menggunakan GraphQL? Katakanlah saya akan menerapkan instalasi GraphQL baru untuk organisasi saya, selanjutnya kami akan membangun semua titik akhir API baru kami menggunakan GraphQL. Apa yang harus saya ketahui? Apakah ada sesuatu yang mengintai di semak-semak?

Eve: Bersembunyi di semak-semak, selalu dengan teknologi, kan? Saya pikir salah satu hal yang tidak dibangun ke dalam GraphQL, tetapi dapat diimplementasikan tanpa terlalu banyak kerumitan adalah keamanan API. Jadi misalnya, Anda menyebutkan jika saya memiliki pertanyaan besar, kami membicarakannya dengan otorisasi, tetapi juga menakutkan untuk membuka API di mana seseorang dapat mengirim kueri bersarang besar, teman dari teman, teman dari teman, teman dari teman , ke bawah dan ke bawah rantai. Dan kemudian pada dasarnya Anda mengizinkan orang untuk DDoS Anda dengan kueri besar ini. So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. Sangat.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. Apakah Anda memiliki kata-kata perpisahan?

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. I appreciate it.