Pengantar Hasura GraphQL Engine untuk API Dinamis dengan PostgreSQL

Secara umum, selama beberapa tahun terakhir, REST API telah dikritik karena tidak fleksibel saat berhadapan dengan persyaratan teknologi yang berubah dengan cepat. Dalam retrospeksi, banyak yang percaya GraphQL diciptakan untuk mengatasi kebutuhan akan fleksibilitas dan efisiensi tambahan dalam pengembangan API. Dengan demikian, mengurangi kekurangan REST API. Sebagai hasil dari transisi Facebook dari aplikasi HTML5 ke pengaturan yang lebih kuat dan asli, GraphQL telah meningkat popularitas dan adopsinya selama lima tahun terakhir dengan alasan yang bagus. Di blog ini, kita akan mempelajari fenomena GraphQL, PostgreSQL dan kemudian mengenalkan mesin Hasura GraphQL secara menyeluruh. Singkatnya, hubungan dan ekosistem sistem Hasura GraphQL engine-PostgreSQL.

GraphQL: Pemberontakan Facebook

Sementara banyak yang percaya bahwa GraphQL dibuat sebagai pemberontakan terhadap REST API, ini bisa jadi lebih jauh dari kebenaran. Ironisnya, itu dibuat hanya untuk melayani kebutuhan internal di Facebook. Awalnya direkayasa dan bersumber terbuka oleh Tim Facebook, GraphQL sering disalahartikan sebagai teknologi basis data. Pada dasarnya, terlepas dari kesalahpahaman, GraphQL secara teknis adalah bahasa kueri untuk API dan bukan database. Akibatnya, ini mengurangi kerumitan pembuatan API, mengabstraksi semua permintaan ke satu titik akhir. Tidak seperti REST API tradisional, GraphQL bersifat deklaratif, artinya apa pun yang diminta akan dikembalikan. Meskipun untuk mendapatkan sedikit lebih banyak konteks, kita harus mundur selangkah dan mengunjungi kembali REST API.

Arsitektur REST

Biasanya, API adalah aturan, rutinitas, atau protokol yang menentukan bagaimana komponen perangkat lunak harus berinteraksi. Representational State Transfer (REST) ​​pada dasarnya adalah arsitektur desain API yang biasanya digunakan dalam implementasi layanan web di mana semuanya dianggap sebagai 'sumber daya'. Sayangnya, metodologi RESTful secara konsisten terbatas pada penanganan sumber daya tunggal. Oleh karena itu, jika data diperlukan dan berasal dari dua atau lebih sumber daya, misalnya, pos dan pengguna, perjalanan multi-putar ke server akan diperlukan untuk mengumpulkan semua yang diperlukan. Selain itu, REST menghadapi masalah dengan pengambilan 'over' dan 'under'. Semua ini tidak ideal, terutama dengan munculnya lebih banyak aplikasi berbasis data yang menangani kumpulan data besar yang menggabungkan sumber daya terkait. Yang bisa menjelaskan kesulitan yang dihadapi Facebook.

Dengan demikian, perlu adanya arsitektur API yang akan mengambil pendekatan yang lebih fleksibel dan progresif.

Penciptaan Alternatif

Atau, GraphQL tidak memikirkan data dalam hal URL sumber daya, kunci sekunder, atau tabel tetapi dalam hal grafik objek dan model yang menggunakan NSObjects atau JSON. Secara khusus, GraphQL tidak memerlukan titik akhir khusus per kasus penggunaan karena kemampuan dan kasus penggunaan yang berbeda dapat direpresentasikan dalam satu "Grafik". Dengan menggunakan bahasa kueri GraphQL, Anda dapat menjelaskan dengan tepat seperti apa seharusnya respons tersebut sehingga tidak diperlukan perjalanan pulang pergi server tambahan. Sebagai bahasa kueri lapisan aplikasi, ini dirancang untuk menafsirkan string dari server/klien dan mengembalikan data itu dalam format yang stabil, dapat dimengerti, dan dapat diprediksi. Ini hanyalah alat untuk mengkonsolidasikan data dengan lebih baik.

Kesederhanaan, Stabilitas dan Efisiensi.

Kebenarannya adalah tidak semua proyek memerlukan GraphQL meskipun skemanya telah didefinisikan dengan baik, jadi kami tahu pasti bahwa kami tidak akan mengambil terlalu banyak. Padahal, jika kita memiliki produk perusahaan yang mengandalkan data dari berbagai sumber, misalnya MySQL, Postgres, dan API lainnya, maka GraphQL adalah pilihan yang lebih baik. GraphQL bangga akan kesederhanaannya terutama dalam hal pengambilan data karena data dikumpulkan di bawah titik akhir atau panggilan yang sama. Pada dasarnya, karena klien mendapatkan apa yang sebenarnya mereka butuhkan, ini secara efektif mengurangi ukuran setiap permintaan yang dibuat oleh klien sehingga menghasilkan aplikasi berkinerja tinggi. Karena GraphQL menyatukan data yang membutuhkan banyak titik akhir, GraphQL memudahkan pengambilan berulang yang kompleks, sehingga efisiensi kueri lebih baik. Akibatnya, dengan kesederhanaannya, muncul lebih banyak stabilitas back-end, perencanaan, konstruksi, pelaksanaan, dan operasi lanjutan dari waktu ke waktu.

Keuntungan dari GraphQL

Singkatnya, GraphQL memungkinkan ekstraksi data dengan kueri yang mudah dimengerti, memungkinkan pengembangan aplikasi yang ringan dan cepat karena data diakses lebih langsung daripada melalui server. Selain itu, memungkinkan pengambilan beberapa sumber daya dengan satu permintaan tanpa menggunakan beberapa URL atau rantai sumber daya, sementara menggunakan satu titik akhir untuk semua data. Ingat, data didefinisikan di server dengan skema berbasis grafik, jadi dikirim sebagai paket daripada melalui beberapa panggilan. Hal ini memungkinkan peningkatan operasional dalam menggabungkan respons API selama pengembangan API.

Hal ini, pada gilirannya, mengurangi beban tim pengembangan front-end, memfasilitasi pembuatan versi API, menyederhanakan pemeliharaan, dan menghemat permintaan transfer data. Selain itu, ini memungkinkan lebih banyak prediktabilitas saat menerima data, mendukung pengambilan data deklaratif dan mengurangi pengambilan berlebihan dan pengambilan yang kurang. Pada dasarnya, pengambilan berlebihan terjadi ketika klien mengunduh lebih banyak informasi daripada yang sebenarnya diperlukan dalam aplikasi, sementara pengambilan yang kurang menyiratkan bahwa titik akhir tertentu belum memberikan informasi yang cukup sehingga mengharuskan klien untuk membuat permintaan tambahan untuk mengambil apa yang dibutuhkannya.

Secara teknis, GraphQL adalah pembungkus yang dapat didefinisikan yang berarti Anda tidak harus sepenuhnya mengganti sistem REST. Pada dasarnya, ini berarti GraphQL kompatibel dengan sistem yang kompatibel dengan REST-centric API. Selain itu, GraphQL memungkinkan pengembangan front dan back-end yang mulus dan independen. Ini karena begitu skema didefinisikan dengan baik, tim yang bekerja di front-end dan back-end sama-sama menyadari struktur data yang pasti. Semua manfaat ini dipandang menguntungkan oleh banyak insinyur full-stack. Terakhir, GraphQL memiliki kapasitas luar biasa untuk introspeksi dan dokumentasi diri secara menyeluruh.

Kasus Penggunaan GraphQL dalam pengembangan API

Dianggap sangat kuat, GraphQL digunakan oleh pengembang Full-stack yang mencari keterbacaan yang stabil dengan kecepatan dan pengindeksan yang cepat. Secara khusus, GraphQL berguna dalam pengembangan API yang membutuhkan throughput data yang tinggi. Faktanya, ini meminimalkan jumlah data yang diperlukan untuk transfer melalui jaringan. Ini sangat bermanfaat bagi pengguna seluler, perangkat berdaya rendah, dan jaringan yang tidak rapi. Itulah salah satu alasan awal Facebook merekayasa GraphQL. Berlawanan dengan kepercayaan, GraphQL tidak hanya berlaku di database kompleks yang besar, dapat membuat database yang relatif sederhana dengan efisiensi yang lebih besar.

Selain itu, ini dapat diterapkan pada berbagai kerangka kerja dan platform front-end yang unik, menyediakan lanskap heterogen yang dipelihara dengan satu API agar sesuai dengan semua kebutuhan pengguna. Selain itu, ini memfasilitasi pengembangan fitur yang cepat karena secara dramatis meningkatkan kecepatan fitur untuk tim pengembang full-stack. Hal ini dilakukan dengan mengurangi komunikasi yang diperlukan antar tim saat mengembangkan fitur baru karena pengembang front-end dapat membuat permintaan API, misalnya, untuk memperkenalkan fitur baru atau mengubah yang sudah ada tanpa harus menunggu pengembang back-end mengirimkannya. Ringkasan GraphQL cepat ini seharusnya sudah cukup untuk saat ini saat kita masuk ke pengenalan mesin Hasura GraphQL. Meskipun mari kita sentuh PostgreSQL untuk sedikit lebih banyak konteks.

Apa itu PostgreSQL?

Sebagai sistem manajemen basis data relasional berbasis komunitas yang gratis, PostgreSQL tidak dimiliki oleh satu perusahaan pun. Dianggap sebagai RDBMS yang paling kuat dan konsisten secara internal, Postgres ditulis dalam C, dan mendukung sejumlah bahasa pemrograman, seperti C/C++, JavaScript, Java, Python, R, Go, Lisp, .Net dll. Semakin disukai di antara kebanyakan pengembang full-stack, PostgreSQL lebih kaya fitur daripada saudaranya MySQL, mendapatkan popularitas karena fitur, skalabilitas, dan kinerjanya. PostgreSQL populer di proyek-proyek di mana persyaratan berkisar pada prosedur yang kompleks, desain yang rumit, integrasi yang dipesan lebih dahulu, dan integritas data.

Keuntungan Postgres untuk pengembang Full-Stack

Secara umum, fitur seperti pencarian teks lengkap, kolom JSON, replikasi logis, memberikan Postgres keunggulan di MySQL. Ini optimal untuk tuntutan kinerja database komersial yang khas sambil memungkinkan konsolidasi beberapa sistem database menjadi satu dengan biaya overhead dan biaya yang lebih sedikit. Selain itu, fitur-fiturnya yang lebih baru untuk Penyimpanan Nilai Kunci (tipe kolom JSON / JSONB) menjadikannya alternatif yang cocok untuk basis data NoSQL. Selain itu, ia mendukung pengelompokan atau arsitektur master-slave, membuatnya sangat cocok untuk lingkungan seperti cloud. Selain itu, ekstensi pembungkus data asing yang populer memungkinkan permintaan sumber eksternal langsung dari dalam PostgreSQL bila diperlukan. Secara khusus, ini paling cocok untuk sistem yang membutuhkan eksekusi kueri kompleks, pergudangan data, dan analisis data dinamis.

Faktanya, PostgreSQL lebih baik mendukung fitur-fitur tertentu yang tidak dimiliki MySQL. Misalnya, periksa batasan, tipe data yang kaya (seperti array, peta, JSON), Dukungan geospasial yang lebih kaya (PostGIS), dan dukungan teks lengkap yang lebih kaya. Selain itu, ini mendukung pembuatan indeks tanpa pemblokiran, Indeks parsial, Ekspresi tabel umum, dan fungsi analitik yang lebih dinamis. Meskipun demikian, PostgreSQL menawarkan dukungan SLL asli untuk koneksi untuk enkripsi komunikasi klien/server, serta peningkatan bawaan bernama SE-PostgreSQL yang menyediakan kontrol akses tambahan berdasarkan kebijakan SELinux.

Dengan banyak fitur kaya untuk produk kelas perusahaan, PostgreSQL cocok untuk sistem besar di mana data memerlukan otentikasi dan kecepatan baca/tulis sangat penting untuk keberhasilan proyek. Selain itu, ia juga mendukung beberapa peningkat kinerja yang biasanya tersedia dalam solusi eksklusif. Seperti termasuk: konkurensi tanpa kunci baca, server SQL, dan dukungan data Geospasial untuk menyebutkan beberapa.

Keuntungan utama lain dari arsitektur Postgres adalah ekstensibilitasnya yang unik. Hal ini memungkinkan pengguna untuk menambahkan fitur seperti tipe data, metode akses indeks, bahasa pemrograman server, pembungkus data asing (FDW) dan ekstensi yang dapat dimuat tanpa mengubah kode sistem inti. Ini memanfaatkan arsitektur prosesor multi-core modern sehingga memungkinkan kinerjanya tumbuh hampir secara linier seiring dengan meningkatnya jumlah core. Ini penting Umumnya, fitur seperti pencarian teks lengkap, kolom JSON, replikasi logis, memberikan Postgres keunggulan di MySQL. Ini optimal untuk tuntutan kinerja database komersial yang khas sambil memungkinkan konsolidasi beberapa sistem database menjadi satu dengan biaya overhead dan biaya yang lebih sedikit. Selain itu, fitur-fiturnya yang lebih baru untuk Penyimpanan Nilai Kunci (tipe kolom JSON / JSONB) menjadikannya alternatif yang cocok untuk basis data NoSQL. Selain itu, ia mendukung pengelompokan atau arsitektur master-slave, membuatnya sangat cocok untuk lingkungan seperti cloud. Selain itu, ekstensi pembungkus data asing yang populer memungkinkan permintaan sumber eksternal langsung dari dalam PostgreSQL bila diperlukan. Secara khusus, ini paling cocok untuk sistem yang membutuhkan eksekusi kueri kompleks, pergudangan data, dan analisis data dinamis.

Kekurangan PostgreSQL

Secara umum, jika Anda menyukai standar ANSI SQL, pertimbangkan PostgreSQL, meskipun jika Anda lebih menyukai standar ODBC, maka pilihlah MySQL. Sayangnya, Postgres terkadang gagal dalam kinerja dengan lingkungan produksi "selalu aktif". Kerugian tambahan dengan Postgres adalah kenyataan bahwa replikasinya diimplementasikan pada tingkat mesin penyimpanan. Ini membuatnya lebih mahal daripada replikasi MySQL, yang lebih matang dan diimplementasikan pada "tingkat mesin kueri".

Pengantar mesin Hasura GraphQL

Karena kita telah membahas secara singkat pengembangan GraphQL API dan PostgreSQL, kita seharusnya memiliki konteks yang cukup untuk pengenalan mesin Hasura GraphQL. Pada dasarnya, Hasura hanyalah mesin GraphQL untuk PostgreSQL RDBMS, menyediakan cara yang disederhanakan untuk bootstrap dan mengelola pengembangan GraphQL API. Dalam retrospeksi, Hasura saat ini adalah satu-satunya solusi yang tersedia yang secara instan menambahkan GraphQL-as-a-Service ke aplikasi berbasis PostgreSQL yang ada. Pada dasarnya, melewati tugas penulisan kode backend yang memakan waktu yang memproses GraphQL.

Hasura Sederhana

Mari luangkan waktu sebentar untuk menyederhanakan Hasura lebih jauh. Pada dasarnya, API adalah antarmuka yang memungkinkan Anda untuk meminta informasi (kueri), dan karenanya merespons dengan mengirimkan data JSON atau XML. Basis data itu biasanya di-host dan diambil dari server. Di sinilah Hasura masuk untuk menyederhanakan banyak hal. Di belakang, mesin Hasura GraphQL adalah server yang menangani kueri GraphQL Anda melalui database Postgres. Ini secara efektif mengurangi waktu yang dibutuhkan aplikasi Anda untuk siap produksi sehingga Anda dapat membuat, melihat, dan memodifikasi tabel database Anda dengan mudah hanya dalam beberapa klik. Akibatnya, ini memungkinkan pengembang tumpukan penuh untuk membangun aplikasi GraphQL yang dapat diskalakan di PostgreSQL dalam waktu yang lebih singkat. Ini menghemat minggu pengembang pengkodean di muka dan dapat mencegah bug kebocoran data yang bermasalah dari membuatnya ke produksi.

Masalah apa yang dipecahkan Hasura dalam pengembangan API?

Secara umum, Hasura menyederhanakan manajemen siklus hidup API selama penggunaan produksi skala besar terutama untuk API yang kompleks. Di atas segalanya, GraphQL Engine menarik pengembang full-stack yang memiliki backlog dengan proyek pengembangan API perusahaan menggunakan database PostgreSQL yang ada. Idealnya, karena GraphQL memungkinkan siklus pengembangan API secepat kilat, Hasura menyediakan cara yang disederhanakan bagi organisasi untuk secara bertahap berpindah ke GraphQL, tanpa memengaruhi aplikasi, database, atau pengguna yang ada. Selain ringan dan kinerjanya yang tinggi, mesin ini dilengkapi dengan UI admin, memungkinkan Anda menjelajahi GraphQL API dan mengelola skema database dan data Anda secara visual.

Kelebihan Hasura

Pertama, Hasura memiliki model yang solid dan stabil untuk mengelola perubahan basis data atau “migrasi”. Ini menguntungkan karena manajemen skema basis data seringkali rumit. Misalnya, tugas-tugas seperti; pelacakan perubahan dari waktu ke waktu dan mengaitkan perubahan skema dengan peningkatan API (manajemen skema). Selain itu, pekerjaan rutin seperti memelihara skrip yang dapat menyebarkan database baru atau memutar kembali perubahan dapat terbukti membosankan dan menyebabkan bug yang sulit didiagnosis atau pemadaman. Sebagai catatan positif, komponen migrasi basis data Hasura adalah SQL biasa, sehingga portabel di luar perangkat Hasura. Secara keseluruhan, Hasura memiliki fitur manajemen skema yang hebat dan Anda tidak perlu menulis kode untuk menangani koneksi soket web.

Kedua, mesin Hasura GraphQL memudahkan untuk mengambil data yang diperlukan dengan satu kueri. Ini dilakukan dengan memungkinkan Anda untuk menambahkan tampilan sebagai hubungan ke tabel atau tampilan lainnya. Selain itu, ini memungkinkan penulisan resolver khusus dengan skema-stitching dan integrasi fungsi tanpa server atau API layanan mikro yang dipicu pada peristiwa basis data. Ini bisa berguna dan memfasilitasi pembuatan aplikasi 3faktor. Faktanya, Hasura adalah mesin yang sangat ringan. Dalam retrospeksi, ini hanya menghabiskan hingga 50MB RAM bahkan saat melayani lebih dari 1000 permintaan/per detik. Pengembalian investasi yang brilian!

Secara khusus, Hasura lebih lanjut memfasilitasi otorisasi dan autentikasi tingkat data API dengan baik. Ini memungkinkan koneksi ke penyedia otentikasi pilihan baik melalui webhook, JWT, Auth0 atau implementasi khusus. Dan dengan demikian, spesifikasi peran untuk pengguna, menentukan siapa yang dapat mengakses data yang berbeda, misalnya, admin, pengguna anonim, dll. Umumnya, sistem kontrol akses granularnya didasarkan pada struktur tabel database yang mirip dengan skema GraphQL. Selain itu, aturan izin khusus ditentukan secara ketat berdasarkan operasi dan nilai database.

Terakhir, Hasura secara brilian mendukung paging yang efisien dengan model offset/limit sederhana seperti SQL. Misalnya, ia menggunakan model kontrol akses untuk membatasi jumlah baris yang dikembalikan untuk kueri tertentu. Modelnya memungkinkan penyetelan batas berdasarkan peran. Misalnya, pengguna yang menerapkan tingkat permintaan yang jauh lebih tinggi dibatasi pada batas baris yang lebih kecil. Ini menghindari penekanan pada database dan mesin GraphQL. Selain itu, Hasura tidak membatasi Anda hanya pada GraphQL. Anda masih dapat menjalankan REST atau layanan mikro non-GraphQL lainnya terhadap tabel Postgres yang dikelola Hasura. Ini dimungkinkan dengan jahitan skema otomatis Hasura. Hal ini memungkinkan penggabungan layanan GraphQL non-Hasura dan back-end untuk satu skema terpadu, menggabungkan API baru yang dikelola Hasura dengan API dan data lama.

Kasus Penggunaan Hasura

Cocok untuk lingkungan berkinerja tinggi, Hasura Engine menawarkan kecepatan sambil mengotomatiskan implementasi GraphQL-Postgres pada database yang ada. Akibatnya, ini memberi perusahaan yang sudah menggunakan Postgres cara yang tidak terlalu menegangkan dan bertahap untuk pindah ke GraphQL dengan menautkan tabel yang ada ke dalam "grafik". Hasura secara efisien menangani penggabungan skema yang memungkinkan Anda menerapkan logika bisnis khusus dengan mudah. Dengan skema GraphQL Jarak Jauh, Hasura dapat dimanfaatkan sebagai gerbang untuk logika bisnis khusus yang memungkinkan Anda menulis ke server GraphQL dalam bahasa favorit Anda, kemudian memaparkan data ke satu titik akhir. Selain itu, Hasura memiliki sintaks yang bagus untuk kueri dan mutasi dengan kueri langsung bawaan yang disebut langganan di GraphQL.

Beberapa Keterbatasan Hasura

Sayangnya, model sistem kontrol akses Hasura tidak akan sepenuhnya berfungsi untuk setiap aplikasi. Misalnya, itu tidak sepenuhnya mendukung otorisasi akses API pada tingkat parameter input individual. Belum lagi fakta bahwa itu terbatas pada database Postgres yang membutuhkan migrasi dalam banyak kasus. Meskipun dapat diabaikan, pesan kesalahan yang dikembalikan GraphQL API untuk permintaan yang salah formatnya cukup tidak ramah di Hasura. Jika tidak, hanya sedikit yang tidak dapat dilakukan Hasura seperti yang telah kita lihat dalam pengantar Hasura GraphQL Engine ini.

Kesimpulan

Kesimpulannya, seiring pertumbuhan GraphQL, pada dasarnya akan semakin menyederhanakan pengembangan API di dalam perusahaan untuk dibangun pada skala web. Dengan adopsi GraphQL yang cepat dalam skala luas di berbagai industri, Hasura memiliki potensi untuk lebih mengotomatiskan pembuatan dan pengelolaan API dengan teknologi pilihan standar industri, GraphQL dan Postgres. Hasura menyederhanakan pembuatan CRUD (Buat, baca, perbarui, dan hapus) backend GraphQL. Lebih penting lagi, Hasura sejauh ini merupakan pilihan terbaik dan satu-satunya jika Anda memulai dari awal dengan API dan Postgres yang berpusat pada GraphQL, tanpa menulis kode backend. Untuk setiap pertanyaan atau konsultasi tentang kemungkinan perusahaan GraphQL dan Hasura, jangan ragu untuk menghubungi kami. Itu saja untuk pengenalan kami tentang Hasura GraphQL Engine.