GraphQL dan Arsitektur Layanan Mikro

Saya mencoba memahami di mana GraphQL paling cocok untuk digunakan dalam arsitektur Microservice.

Ada beberapa perdebatan tentang hanya memiliki 1 skema GraphQL yang berfungsi sebagai API Gateway proksi permintaan ke layanan microser yang ditargetkan dan memaksa respons mereka. Layanan Microsoft masih akan menggunakan protokol REST / Thrift untuk pemikiran komunikasi.

Pendekatan lain adalah sebaliknya memiliki beberapa skema GraphQL satu per microservice. Memiliki server API Gateway yang lebih kecil yang merutekan permintaan ke layanan microser yang ditargetkan dengan semua informasi permintaan + permintaan GraphQL.

Pendekatan 1

Memiliki 1 Skema GraphQL sebagai Gateway API akan memiliki kelemahan di mana setiap kali Anda mengubah input / output kontrak layanan mikro Anda, kami harus mengubah Skema GraphQL sesuai di Sisi Gateway API.

Pendekatan 2

Jika menggunakan Multiple GraphQL Schema per microservices, masuk akal karena GraphQL memberlakukan definisi skema, dan konsumen perlu menghormati input / output yang diberikan dari microservice.

Pertanyaan

• Apakah Anda menemukan GraphQL cocok untuk mendesain arsitektur microservice?

• Bagaimana Anda merancang Gateway API dengan kemungkinan implementasi GraphQL?

Jelas mendekati # 1.

Membuat klien Anda berbicara dengan beberapa layanan GraphQL (seperti dalam pendekatan # 2) sepenuhnya mengalahkan tujuan menggunakan GraphQL di tempat pertama, yaitu untuk menyediakan skema seluruh data aplikasi Anda untuk memungkinkan mengambilnya dalam satu perjalanan pulang pergi.

Memiliki arsitektur apa-apa yang dibagikan mungkin tampak masuk akal dari perspektif layanan-mikro, tetapi untuk kode sisi-klien Anda, ini adalah mimpi buruk absolut, karena setiap kali Anda mengubah salah satu dari layanan-mikro Anda, Anda harus memperbarui semua klien Anda. Anda pasti akan menyesalinya.

GraphQL dan layanan microser sangat cocok, karena GraphQL menyembunyikan fakta bahwa Anda memiliki arsitektur layanan microser dari klien. Dari perspektif backend, Anda ingin membagi semuanya menjadi layanan microser, tetapi dari perspektif frontend, Anda ingin semua data Anda berasal dari satu API. Menggunakan GraphQL adalah cara terbaik yang saya tahu yang memungkinkan Anda melakukan keduanya. Ini memungkinkan Anda membagi backend menjadi layanan microser, sambil tetap menyediakan API tunggal untuk semua aplikasi Anda, dan memungkinkan penggabungan data dari berbagai layanan.

Jika Anda tidak ingin menggunakan REST untuk layanan microser Anda, Anda tentu saja dapat masing-masing memiliki Graph Graph API sendiri, tetapi Anda masih harus memiliki gateway API. Alasan orang menggunakan gateway API adalah untuk membuatnya lebih mudah untuk memanggil layanan microser dari aplikasi klien, bukan karena cocok dengan pola layanan microser.

Lihat artikel di sini , yang mengatakan bagaimana dan mengapa pendekatan # 1 bekerja lebih baik. Lihat juga gambar di bawah ini yang diambil dari artikel yang saya sebutkan:

Salah satu manfaat utama memiliki segala sesuatu di belakang satu titik akhir adalah bahwa data dapat disalurkan lebih efektif daripada jika setiap permintaan memiliki layanannya sendiri. Meskipun ini adalah nilai GraphQL yang sering disebut-sebut, pengurangan kompleksitas dan creep layanan, struktur data yang dihasilkan juga memungkinkan kepemilikan data untuk didefinisikan dengan sangat baik, dan dengan jelas digambarkan.

Manfaat lain dari mengadopsi GraphQL adalah kenyataan bahwa Anda secara mendasar dapat menegaskan kontrol yang lebih besar atas proses pemuatan data. Karena proses untuk pemuat data masuk ke titik akhir sendiri, Anda dapat memenuhi permintaan sebagian, sepenuhnya, atau dengan peringatan, dan dengan demikian mengontrol dengan cara yang sangat terperinci bagaimana data ditransfer.

Artikel berikut menjelaskan dua manfaat ini bersama yang lain dengan sangat baik: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

Untuk pendekatan # 2, sebenarnya itulah yang saya pilih, karena jauh lebih mudah daripada mempertahankan gateway API yang mengganggu secara manual. Dengan cara ini Anda dapat mengembangkan layanan Anda secara mandiri. Jadikan hidup lebih mudah: P

Ada beberapa alat yang bagus untuk menggabungkan skema menjadi satu, misalnya graphql-weaver dan graphql-tools apollo , saya menggunakan graphql-weaver, mudah digunakan dan bekerja dengan baik.

Pada pertengahan 2019 solusi untuk Pendekatan 1 sekarang memiliki nama " Skema Federasi " yang diciptakan oleh orang-orang Apollo (Sebelumnya ini sering disebut sebagai jahitan GraphQL). Mereka juga mengusulkan modul @apollo/federationdan @apollo/gatewayuntuk ini.

TAMBAH: Harap dicatat bahwa dengan Skema Federasi Anda tidak dapat memodifikasi skema di tingkat gateway. Jadi untuk setiap bit yang Anda butuhkan dalam skema Anda, Anda harus memiliki layanan terpisah.

Pada 2019 cara terbaik adalah menulis microservises yang mengimplementasikan spesifikasi gerbang apollo dan kemudian merekatkan bersama layanan ini menggunakan gateway berikut pendekatan # 1. Cara tercepat untuk membangun gateway adalah gambar buruh pelabuhan seperti ini. Kemudian gunakan susun buruh pelabuhan untuk memulai semua layanan secara bersamaan:

version: '3'

services:
    service1:
        build: service1
    service2:
        build: service2
    gateway:
        ports:
            - 80:80
        image: xmorse/apollo-federation-gateway
        environment: 
            - CACHE_MAX_AGE=5
            - "FORWARD_HEADERS=Authorization, X-Custom-Header" # default is Authorization, pass '' to reset
            - URL_0=http://service1
            - URL_1=http://service2

Cara dijelaskan dalam pertanyaan ini, saya percaya bahwa menggunakan gateway API khusus sebagai layanan orkestrasi dapat membuat banyak akal untuk aplikasi yang berfokus pada perusahaan yang kompleks. GraphQL bisa menjadi pilihan teknologi yang bagus untuk layanan orkestrasi itu, setidaknya sejauh yang ditanyakan. Keuntungan dari pendekatan pertama Anda (satu skema untuk semua layanan microsoft) adalah kemampuan untuk menyatukan data dari beberapa layanan microsoft dalam satu permintaan. Itu mungkin, atau mungkin tidak, sangat penting tergantung pada situasi Anda. Jika GUI meminta rendering data dari beberapa layanan sekaligus, maka pendekatan ini dapat menyederhanakan kode klien sehingga satu panggilan dapat mengembalikan data yang cocok untuk pengikatan data dengan elemen GUI dari kerangka kerja seperti Angular atau React. Keuntungan ini tidak berlaku untuk mutasi.

Kerugiannya adalah hubungan yang erat antara API data dan layanan orkestrasi. Rilis tidak lagi menjadi atom. Jika Anda menahan diri untuk tidak memundurkan perubahan pada API data Anda, maka hal ini dapat menimbulkan kerumitan hanya saat memutar kembali rilis. Misalnya, jika Anda akan merilis versi baru dari dua API data dengan perubahan yang sesuai dalam layanan orkestrasi dan Anda perlu memutar kembali salah satu dari rilis tersebut tetapi tidak yang lain, maka Anda akan terpaksa memutar kembali ketiganya.

Dalam perbandingan GraphQL vs REST ini, Anda akan menemukan bahwa GraphQL tidak seefisien API RESTful jadi saya tidak akan merekomendasikan mengganti REST dengan GraphQL untuk API data.

Untuk pertanyaan 1, Intuit mengakui kekuatan GraphQL beberapa tahun yang lalu ketika mengumumkan pindah ke ekosistem One Intuit API ( https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations -quickbooks-connect-2017 ). Intuit memilih untuk mengikuti pendekatan 1. Kelemahan yang Anda sebutkan sebenarnya mencegah pengembang dari memperkenalkan perubahan skema yang berpotensi mengganggu aplikasi klien.

GraphQL telah membantu meningkatkan produktivitas pengembang dalam beberapa cara.

1. Saat mendesain microservice baru untuk domain, insinyur (backend / frontend / stakeholder) menyepakati skema untuk entitas domain. Setelah skema disetujui, itu digabung dengan skema domain master (universal) dan digunakan di Gateway. Insinyur ujung depan dapat mulai pengkodean aplikasi klien dengan skema ini sementara insinyur backend menerapkan fungsi. Memiliki satu skema universal berarti bahwa tidak ada dua layanan microser dengan fungsi yang berlebihan.

2. GraphQL telah membantu aplikasi klien menjadi lebih sederhana dan lebih cepat. Ingin mengambil data dari / memperbarui data ke beberapa layanan microser? Semua aplikasi klien yang harus dilakukan adalah menjalankan SATU permintaan GraphQL dan lapisan abstraksi API Gateway akan berhati-hati untuk mengambil dan menyusun data dari berbagai sumber (layanan mikro). Kerangka kerja open source seperti Apollo ( https://www.apollographql.com/ ) telah mempercepat laju adopsi GraphQL.

3. Dengan ponsel menjadi pilihan pertama untuk aplikasi modern, penting untuk merancang persyaratan bandwidth data yang lebih rendah dari ground zero. GraphQL membantu dengan mengizinkan aplikasi klien untuk meminta bidang tertentu saja.

Untuk pertanyaan 2: Kami membuat lapisan abstraksi khusus di API Gateway yang mengetahui bagian mana dari skema yang dimiliki oleh layanan (penyedia) mana. Ketika permintaan kueri tiba, lapisan abstraksi meneruskan permintaan ke layanan yang sesuai. Setelah layanan dasar mengembalikan respons, lapisan abstraksi bertanggung jawab untuk mengembalikan bidang yang diminta.

Namun, hari ini ada beberapa platform di luar sana (server Apollo, graphql-yoga, dll.) Yang memungkinkan seseorang untuk membangun lapisan abstraksi GraphQL dalam waktu singkat.

Saya telah bekerja dengan GraphQL dan layanan microser

Berdasarkan pengalaman saya apa yang berhasil bagi saya adalah kombinasi dari kedua pendekatan tergantung pada fungsi / penggunaan, saya tidak akan pernah memiliki gateway tunggal seperti pada pendekatan 1 ... tetapi apakah graphql untuk setiap layanan mikro sebagai pendekatan 2.

Misalnya berdasarkan gambar jawaban dari Enayat, yang akan saya lakukan dalam hal ini adalah memiliki 3 gateway gateway (Bukan 5 seperti pada gambar)

• Aplikasi (Produk, Keranjang, Pengiriman, Persediaan, diperlukan / ditautkan dengan layanan lain)

• Pembayaran

• Pengguna

Dengan cara ini Anda perlu memberi perhatian ekstra pada desain data minimal yang diperlukan / ditautkan yang terpapar dari layanan yang bergantung, seperti token auth, userid, paymentid, status pembayaran

Dalam pengalaman saya misalnya, saya memiliki gateway "Pengguna", dalam GraphQL saya memiliki permintaan / mutasi pengguna, masuk, masuk, keluar, ubah kata sandi, pulihkan email, konfirmasi email, hapus akun, edit profil, unggah gambar , dll ... grafik ini sendiri cukup besar !, dipisahkan karena pada akhirnya layanan lain / gateway hanya peduli tentang info yang dihasilkan seperti userid, nama atau token.

Cara ini lebih mudah untuk ...

• Skala / shutdown node gateway yang berbeda tergantung pada penggunaannya. (misalnya orang mungkin tidak selalu mengedit profil mereka atau membayar ... tetapi mencari produk mungkin lebih sering digunakan).

• Setelah gateway matang, tumbuh, penggunaan diketahui atau Anda memiliki lebih banyak keahlian di domain Anda dapat mengidentifikasi mana yang merupakan bagian dari skema yang bisa mereka miliki gateway (... terjadi pada saya dengan skema besar yang berinteraksi dengan repositori git , Saya memisahkan gateway yang berinteraksi dengan repositori dan saya melihat bahwa satu-satunya input yang diperlukan / info yang ditautkan adalah ... path folder dan cabang yang diharapkan)

• Sejarah repositori Anda lebih jelas dan Anda dapat memiliki repositori / pengembang / tim yang didedikasikan untuk gateway dan layanan mikronya yang terlibat.

MEMPERBARUI:

Saya memiliki kubernet cluster online yang menggunakan pendekatan yang sama yang saya jelaskan di sini dengan semua backends menggunakan GraphQL, semua opensource, di sini adalah repositori utama: https://github.com/vicjicaman/microservice-realm

Ini adalah pembaruan untuk jawaban saya karena saya pikir lebih baik jika jawaban / pendekatannya didukung kode yang sedang berjalan dan dapat dikonsultasikan / ditinjau, saya harap ini membantu.

Karena arsitektur layanan microser tidak memiliki definisi yang tepat, tidak ada model khusus untuk gaya ini tetapi, sebagian besar dari mereka akan datang dengan beberapa karakteristik penting. men-tweak secara individual dan digunakan tanpa mempengaruhi integritas aplikasi Ini berarti Anda dapat dengan mudah mengubah beberapa layanan tanpa harus melakukan pemindahan aplikasi melalui pengembangan aplikasi layanan Microsoft kustom .

Lebih lanjut tentang microservices, saya pikir GraphQL bisa berfungsi sempurna dalam arsitektur tanpa server juga. Saya tidak menggunakan GraphQL tetapi saya memiliki proyek serupa saya sendiri . Saya menggunakannya sebagai agregator yang memanggil dan memusatkan banyak fungsi ke dalam hasil tunggal. Saya pikir Anda bisa menerapkan pola yang sama untuk GraphQL.