GraphQL dan Arsitektur Layanan Mikro


176

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?

Jawaban:


242

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.


2
@helfer: Ini sangat masuk akal :) terima kasih. Saya punya beberapa pertanyaan di atas jawaban yang indah ini. - Anda mengatakan bahwa GraphQL harus digunakan sebagai gateway API? - Katakanlah saya memiliki Order Microservice yang mengekspos baik titik akhir REST atau GraphQL. Setelah saya selesai dengan itu saya harus memperbarui skema GraphQL utama untuk mencerminkan data yang sama persis dengan yang akan diekspos oleh microservice? Apakah itu tidak terdengar duplikasi atau menjauh dari kultur layanan mikro yang seharusnya digunakan secara independen? Adakah perubahan pada perangkat mikro harus tercermin / diduplikasi ke Skema GraphQL Utama?
Fabrizio Fenoglio

13
@ Fabrizio hal yang menyenangkan dengan GraphQL adalah bahwa bahkan jika backend REST API berubah, skema GraphQL masih bisa tetap sama, selama ada cara untuk mendapatkan data bahwa layanan REST terpapar sebelumnya. Jika itu mengekspos lebih banyak data, maka cara kanonik untuk menangani ini adalah dengan hanya menambahkan bidang / tipe baru ke skema yang ada. Orang-orang di Facebook yang membuat GraphQL mengatakan kepada saya bahwa mereka tidak pernah membuat perubahan besar pada skema mereka dalam empat tahun. Semua perubahan yang mereka buat adalah aditif, yang berarti bahwa klien baru dapat menggunakan fungsionalitas baru, sementara klien lama akan terus bekerja.
helfer

4
Baik! :) Terima kasih sudah menulis ini! Saya mengikuti Anda di Medium dan di github melalui apollo repo! Artikel dan tulisan Anda sangat berharga! :) Terus bekerja dengan baik! Saya juga berpikir bahwa artikel media dengan topik GraphQL + Microservices akan sangat menyenangkan untuk dibaca!
Fabrizio Fenoglio

1
Terima kasih, saya akan mengingatnya. Pasti berencana untuk menulis tentang GraphQL dan Layanan Microsoft di beberapa titik, tetapi mungkin tidak dalam beberapa minggu ke depan.
helfer

Bagaimana dengan kombinasi opsi # 2 dan github.com/AEB-labs/graphql-weaver ?
Mohsen

35

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: masukkan deskripsi gambar di sini

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/


HI, maaf untuk pertanyaan noob, tetapi bukankah gerbang graphQL Anda titik retensi baru? Misalnya, jika saya memiliki layanan keranjang yang tiba-tiba kelebihan, bukankah gerbang graphQL saya juga akan rusak? Pada dasarnya saya tidak yakin dengan perannya, gateway ini seharusnya mengandung banyak resolver untuk setiap layanan?
Eric Burel

1
@EricBurel Terima kasih atas pertanyaannya. Sebenarnya, sejauh yang saya mengerti dari artikel ini, semua skema dari layanan yang berbeda disatukan dalam satu skema GraphQL, jadi seperti yang Anda sebutkan, layanan lain masih berada pada dataset mereka sendiri. Mengenai kemungkinan sumber tunggal kegagalan untuk gerbang graphQL, selalu ada opsi lain seperti menyediakan rencana cadangan. Silakan baca artikel ini ( labs.getninjas.com.br/... ) untuk informasi lebih lanjut. Semoga ini membantu.
Enayat

Bagaimana Anda menguji gateway API pusat dan layanan individual? Apakah Anda melakukan integrasi atau mengejek respons http?
Jaime Sangcap

7

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.


Menggunakan GraphQL di Android adalah keharusan bahwa saya membuat file .graphql dengan semua pertanyaan? Atau bisakah saya membuatnya dalam kode tanpa file ini?
MauroAlexandro

1
@ MauroAlexandro Saya bukan orang Android, tetapi Anda dapat memiliki pertanyaan dalam file yang berbeda. Ini lebih merupakan masalah desain. IMHO, saya lebih suka yang pertama :)
HFX

5

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.


valid juga untuk mengetahui bahwa solusi ini menuntut Apollo Server yang sedikit terbatas dalam versi gratis (maks 25 juta kueri per bulan)
Marx

0

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

0

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.


0

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.


0

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)

masukkan deskripsi gambar di sini

  • 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.


-3

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 .


Sekalipun tidak memiliki "definisi yang tepat", itu adalah konsep yang dipahami dengan baik dan dibatasi dengan jelas dalam konteks pertanyaan. Selain itu, jawaban Anda tidak menjawab pertanyaan sama sekali.
Roy Prins

-7

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.


2
Maaf, ini sama sekali tidak relevan untuk pertanyaan OP. Pertanyaannya adalah tentang dua pendekatan spesifik menggunakan GraphQL. Ini mungkin lebih baik dimasukkan sebagai komentar.
tiomno
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.