Bina Gateway GraphQL: Gabungkan, jahitan atau gabungan mana -mana sumber data

mata teras

GraphQL Gateway menggabungkan kelebihan gerbang API tradisional dan GraphQL, yang membolehkan jurutera perisian mendapatkan data dari pelbagai sumber data sambil mengekalkan kecekapan front-end.
backend, iaitu, corak seni bina front-end (BFF) mengurangkan bilangan permintaan di bahagian depan, memudahkan proses dengan membenarkan permintaan tunggal ke gerbang API, yang kemudiannya mengambil data dari setiap perkhidmatan back-end dan menggabungkannya.
GraphQL menyediakan BFF dengan banyak kelebihan, termasuk pengambilalihan data yang cekap, titik akhir untuk semua permintaan, dan pertanyaan fleksibel yang membolehkan bahagian depan hanya memilih data yang diperlukan untuk setiap permintaan.
Tiga rangka kerja yang disyorkan untuk mewujudkan gerbang GraphQL termasuk Hasura, Stepzen, dan Graphweaver. Rangka kerja ini menyediakan pelbagai keupayaan seperti sambungan sumber data berganda, penghalaan, pemprosesan batch, keselamatan, penapisan sumber silang data, dan skalabiliti.

Artikel ini akan membincangkan bagaimana untuk mendapatkan data dari pelbagai sumber data sambil mengekalkan responsif depan dengan cepat, dan penyelesaian yang berpotensi: menggunakan Gateway GraphQL.

Sebagai jurutera perisian, kita semua menghadapi cabaran menyusun data dari pelbagai sistem. Malah satu halaman memerlukan data dari pelbagai perkhidmatan yang akan diberikan.

Data ada di mana -mana, dari CRM ke sistem kewangan, dari platform SaaS ke pangkalan data. Tidak dapat dielakkan bahawa setiap perniagaan akan membeli sejumlah besar platform SaaS dan kemudian berharap untuk mendapatkan pandangan perniagaan bersatu di atas semuanya. Kita harus menghadapi masalah ini dan menyatukan semuanya.

GraphQL Gateway menggabungkan kelebihan gerbang API tradisional dan GraphQL.

kami akan membincangkan kelebihan gerbang API dan kemudian melihat bagaimana GraphQL sesuai dengannya. Sila terus membaca artikel ini, kami akan merangkumi beberapa rangka kerja untuk membina gerbang API kami sendiri.

Kelebihan API Gateway

Melindungi API yang menghadap awam dari penggodam adalah pekerjaan semua cuaca. Dari masa ke masa, organisasi telah berkembang untuk mewujudkan banyak API, dari seni bina berorientasikan perkhidmatan ke microservices. Organisasi cenderung menambah lapisan tambahan keselamatan dan bukannya meletakkan API ini secara langsung di Internet, yang lebih awal daripada semua API ini dan memastikan akses kepada data sentiasa mengikuti peraturan pengesahan yang sama.

Mereka menggunakan API Gateway untuk melakukan ini.

Produk seperti Kong atau Apigee mendedahkan API dalaman dari lokasi pusat. Mereka bertindak sebagai proksi terbalik dengan ciri -ciri seperti pengurusan utama API, mengehadkan kadar dan pemantauan.

API Gateway membolehkan kami mengawal siapa dan apa yang boleh mengakses setiap perkhidmatan, memantau sambungan dan akses rekod.

Baru -baru ini, aplikasi perlu menggabungkan data dari gerbang API dan penyedia SaaS luaran yang lain. Ini bermakna bahawa alat berpusat lama (pastikan peraturan kami diikuti) kini dilangkau secara teratur.

Katakan kami sedang membina aplikasi web untuk syarikat itu. Tugas kami adalah untuk membuat halaman profil pengguna. Semasa proses log masuk, kita perlu menggabungkan data dari pelbagai sistem:

• Salesforce CRM: Simpan data pelanggan umum, seperti nama pertama dan terakhir.
• Pesanan: Unit pesanan yang paling terkini berada dalam sistem pesanan dalam organisasi.
• Perkhidmatan pemberitahuan: Tetapan pemberitahuan dan mesej baru-baru ini terletak dalam pangkalan data khusus aplikasi yang disambungkan ke perkhidmatan Node.js.

Pelanggan perlu mengeluarkan tiga permintaan berasingan untuk mendapatkan data, seperti yang ditunjukkan dalam gambar di bawah.

Dalam imej di atas, klien web menghantar tiga permintaan API berasingan, dan kemudian hasilnya mesti digabungkan dalam kod depan. Menghantar pelbagai permintaan boleh menjejaskan prestasi aplikasi anda, dan menggabungkan data ini dapat meningkatkan kerumitan kod anda. Di samping itu, jika terdapat banyak aplikasi, kini semua aplikasi mesti tahu tentang semua backends, dan perubahan API tunggal dalam perkhidmatan boleh menghasilkan kemas kini untuk semua aplikasi kami.

kita boleh melakukan yang lebih baik. Idealnya, kami mahu mengurangkan permintaan dari tiga hingga satu. Kami boleh membuat perkhidmatan baru untuk melakukan ini - perkhidmatan yang menyelaraskan permintaan untuk perkhidmatan backend. Idea ini mempunyai nama: mod BFF.

backend, iaitu, mod seni bina frontend (BFF) membolehkan frontend mengeluarkan permintaan tunggal.

Tetapi bagaimana ia berfungsi? Mari kita lihat corak ini dengan lebih dekat.

kelebihan mod BFF

Menggunakan mod BFF, aplikasi menghantar permintaan tunggal ke Gateway API. Perkhidmatan BFF kemudian meminta data dari setiap perkhidmatan backend dan menggabungkannya. Akhirnya, data ditapis dan hanya data yang diperlukan oleh hujung depan dikembalikan, dengan itu mengurangkan jumlah data yang dihantar melalui rangkaian.

Seperti yang ditunjukkan dalam imej di atas, kami memperkenalkan lapisan tambahan ke dalam timbunan untuk menyelaraskan permintaan.

Titik akhir profil pengguna mengembalikan data yang diperlukan oleh aplikasi pada halaman profil. Mengurangkan tiga permintaan kami kepada seseorang telah menyelesaikan masalah prestasi kami yang terdahulu.

tetapi kami belum selesai.

Enterprise memutuskan untuk melepaskan aplikasi mudah alih. Aplikasi mudah alih juga mempunyai halaman profil, tetapi skrin ini memaparkan maklumat profil yang kurang.

Pada ketika ini, pasukan mudah alih mempunyai dua pilihan. Pasukan ini boleh menggunakan titik akhir pasukan web, yang bermaksud kami terlalu banyak data (dapatkan lebih banyak data yang tidak diperlukan oleh aplikasi mudah alih). Pilihan lain adalah untuk membuat BFF anda sendiri pada pasukan mudah alih.

Menurut jangkaan, pasukan mudah alih memutuskan untuk mencipta BFF mereka sendiri kerana mereka mahukan prestasi yang baik untuk aplikasi mereka.

seperti yang ditunjukkan dalam gambar di atas, perkara -perkara mula menjadi rumit, dan kini kami mempunyai dua masalah baru:

• Setiap pasukan mesti membuat perkhidmatan BFF baru untuk setiap aplikasi yang mereka buat, yang melambatkan setiap pasukan dan menjadikannya sukar untuk menyeragamkan.
• Setiap BFF memerlukan ujian penembusan untuk memastikan ia selamat.

Bagaimana kita menyelesaikan masalah ini?

Kami memerlukan penyelesaian di mana setiap aplikasi boleh memilih data yang diperlukan, dan ia harus menjadi API tunggal yang digunakan oleh semua aplikasi syarikat.

Sebagai BFF matang, banyak pemaju telah mula cuba menggunakan GraphQL dan bukannya berehat.

mari kita lihat bagaimana teknologi ini dapat membantu.

Kelebihan Graphql Over BFF

GraphQL mempunyai banyak kelebihan yang menjadikannya teknologi yang ideal untuk BFF:

• Pengambilalihan data yang cekap. GraphQL membolehkan pelanggan meminta data yang diperlukan dengan tepat, tidak lebih atau kurang. Ini meningkatkan prestasi dengan mengurangkan data yang dipindahkan dari API.
• titik akhir tunggal. Daripada mendedahkan banyak titik akhir melalui pintu masuk, GraphQL menggunakan titik akhir tunggal untuk semua permintaan. Ini memudahkan keperluan penyelenggaraan dan kawalan versi.
• pertanyaan fleksibel. Pelanggan boleh membina pertanyaan dengan menggabungkan bidang dan hubungan menjadi satu permintaan. Ini membolehkan pemaju front-end mengoptimumkan pengambilalihan data, dengan itu meningkatkan prestasi. Juga, jika keperluan perubahan depan, ia boleh dikemas kini untuk mendapatkan data yang berbeza tanpa mengubah back-end dalam apa cara sekalipun.

bahagian depan kini boleh memilih hanya data yang diperlukan untuk setiap permintaan.

kini boleh menyambungkan dua aplikasi kami ke pelayan GraphQL yang sama, mengurangkan keperluan untuk perkhidmatan BFF kedua.

Kami kini boleh berkongsi BFF untuk sebarang permohonan dalam organisasi kami. Kami juga mempunyai satu titik akhir yang perlu diuji untuk penembusan.

Tetapi, kami telah memperkenalkan satu lagi masalah baru! Kami masih perlu menguruskan dua sistem - API Gateway dan GraphQL BFF.

Bagaimana jika kita menggabungkan kedua -duanya ke dalam gerbang graphql?

Seterusnya, mari kita lihat bagaimana Gateway GraphQL berfungsi.

Apakah gerbang graphql?

GraphQL Gateway menggabungkan API Gateway dengan API GraphQL untuk hasil terbaik dari kedua -dua teknologi.

mari kita semak kelebihan:

pemaju mempunyai titik akhir API tunggal untuk meminta data. Ini mengurangkan pengambilan yang berlebihan atau tidak mencukupi, kerana setiap aplikasi hanya memilih data yang diperlukan.
GraphQL Gateway dikongsi oleh banyak aplikasi dalam organisasi anda. Ini bermakna kita telah mengurangkan risiko keselamatan ke titik akhir API tunggal.
Kami kini hanya mempunyai satu perkhidmatan yang perlu diuruskan dan digunakan kerana BFF digabungkan dengan pintu masuk.

Imej berikut menunjukkan bagaimana permintaan API profil pengguna berfungsi dengan GraphQL Gateway.

Dalam imej di atas, klien menghantar permintaan tunggal ke Gateway GraphQL, meminta data yang diperlukan. Gateway mengeluarkan permintaan tunggal untuk setiap perkhidmatan dan menggabungkan hasilnya. Kami kini hanya mempunyai satu perkhidmatan yang perlu diuruskan dan digunakan.

saya harap anda sudah bersedia untuk mencubanya sendiri. Seterusnya, mari kita lihat cara membina Gateway GraphQL.

Membina Graphql Gateway

Apabila memilih rangka kerja gerbang, kita perlu mencari beberapa ciri utama:

• Sumber data berganda. Gateway mesti disambungkan ke banyak sumber data -dari pangkalan data ke SaaS -kita harus dapat membuat sambungan kami.
• laluan. Gateway harus dapat meminta data secara langsung dari perkhidmatan yang mendasari.
• pemprosesan batch. Pelbagai pertanyaan yang dihantar ke perkhidmatan yang sama dihantar dalam kelompok, mengurangkan bilangan permintaan.
• selamat. Pengesahan dan kebenaran harus mengawal siapa yang boleh mengakses data yang disambungkan.
• Penapis di seluruh sumber data. Penapis yang kuat harus disediakan untuk mengelakkan lebih banyak data yang diperlukan oleh klien.
• skalabiliti. Pemaju harus dapat melanjutkan kod menggunakan middleware atau fungsi untuk memenuhi keperluan mereka.

Terdapat banyak rangka kerja untuk dipilih, tetapi saya cadangkan meneroka tiga rangka kerja berikut.

Hasura

Hasura telah menjadi semakin popular selama bertahun-tahun, pada mulanya sebagai pelayan Graphql-over-Postgres. Walau bagaimanapun, ia meningkatkan keupayaan untuk menyambung ke sistem luaran.

kita boleh menyambung ke "mod jauh" yang menggabungkan GraphQL dari pelayan lain.

Kaedah ini mempunyai beberapa kelemahan. Pertama, kita perlu membuat dan mengurus skema jauh kami dalam perkhidmatan yang berasingan, dan perkhidmatan ini mestilah titik akhir GraphQL. Ini membawa kepada masalah kedua: kita tidak boleh menyambung secara langsung ke sumber data.

Di samping itu, Hasura tidak membenarkan kami menapis data dalam satu sumber data berdasarkan nilai -nilai dalam sumber data lain. Ini mungkin terdengar akademik, tetapi kami sering ingin menyatakan sesuatu seperti "memberi saya perintah dengan nama 'ABC'".

Ini memberikan fleksibiliti, tetapi dengan kos menjalankan pelbagai perkhidmatan. Mari kita lihat pilihan yang boleh disambungkan secara langsung.

Stepzen

Stepzen membolehkan kami menyambung terus ke sumber data dari pelayan GraphQL. Ini mengurangkan keperluan untuk menjalankan pelbagai perkhidmatan untuk membuat pintu masuk.

Untuk menyambungkan Stepzen ke sumber data, kami membuat fail skema GraphQL seperti yang ditunjukkan di bawah:

<code>type Query {
  anything(message: String): JSON
  @rest (
    endpoint: "https://httpbin.org/anything"
    method: POST
    headers: [
      {name: "User-Agent", value: "StepZen"}
      {name: "X-Api-Key", value: "12345"}
    ]
    postbody: """
      {
        "user": {
          "id": "1000",
          "name": "The User"
         }
      }
    """
    )
}
</code>

Dalam contoh ini, kami menggunakan mod tersuai untuk menyambungkan pelayan ke pangkalan data.

Terdapat pilihan lain yang mungkin anda sukai, iaitu pendekatan kod tulen. Mari lihat seterusnya.

Graphweaver

Sejak beberapa tahun kebelakangan ini, saya telah membangunkan produk sumber terbuka yang dipanggil Graphweaver yang boleh digunakan sebagai Gateway GraphQL.

Ia menghubungkan terus ke sumber data kami dan mencipta API GraphQL segera. API ini mengandungi semua operasi CRUD yang mungkin kami harapkan untuk membuat, membaca, mengemas kini, dan memadam. Ia secara automatik menjana penapis, menyusun dan memage parameter, menjimatkan masa. Kami boleh melanjutkan operasi terbina dalam dengan kod kami untuk fleksibiliti lengkap.

Graphweaver menyediakan penyambung data keluar dari kotak untuk pangkalan data seperti Postgres dan MySQL, serta penyedia SaaS seperti Xero dan Contentful.

Membuat perubahan atau menyambung ke sumber data melibatkan penulisan kod typescript, yang membolehkan kami membuat penyesuaian penuh.

Jika anda berminat untuk membuat API GraphQL anda sendiri, saya sangat mengesyorkan anda menyemak kod Github Graphweaver.

Kesimpulan

Dalam artikel ini, kami mengkaji cara menggantikan Gateway API semasa kami dan corak BFF dengan gerbang GraphQL tunggal.

kami memeriksa kelebihan gerbang API dan mengapa organisasi menggunakannya. Versioning, mengehadkan kadar, dan pengurusan akses adalah beberapa sebab.

kami juga melihat corak BFF dan bagaimana ia menyelaraskan permintaan API untuk aplikasi front-end.

Akhirnya, kita melihat GraphQL dan mengapa ia adalah teknik yang bermanfaat untuk BFF.

akhir hari, ini membawa kami untuk membuat gerbang GraphQL, dan kami melihat tiga pilihan untuk membuat sendiri: Hasura, Stepzen dan Graphweaver produk, yang saya telah berkembang.

Saya harap artikel ini meyakinkan anda untuk cuba menggunakan Gateway Graphql sendiri, dan jika anda boleh, pertimbangkan untuk mencuba Graphweaver.

Graphql Gateway FAQ (FAQ)

Apakah tujuan utama Gateway GraphQL?

Gateway GraphQL bertindak sebagai titik kemasukan tunggal untuk semua operasi GraphQL. Ia bertanggungjawab untuk permintaan penghalaan kepada perkhidmatan yang sepadan, mengagregatkan respons dan menghantarnya kembali kepada pelanggan. Ini membolehkan anda menguruskan pelbagai corak dan perkhidmatan GraphQL dari satu lokasi, menjadikan aplikasi anda lebih berskala dan mudah dijaga.

Bagaimana perbezaan antara Gateway GraphQL dan Gateway API tradisional?

Gateway API tradisional direka untuk mengendalikan API yang tenang, dan mod operasinya berbeza daripada GraphQL. Sebaliknya, gerbang GraphQL direka khas untuk mengendalikan operasi GraphQL. Ia menyediakan ciri -ciri seperti jahitan corak dan penggabungan yang membolehkan anda menggabungkan pelbagai corak GraphQL menjadi satu. Ini adalah sesuatu yang tidak dapat dilakukan oleh gerbang API tradisional.

Apakah corak splicing di Gateway GraphQL?

Jahitan mod

adalah ciri gerbang GraphQL yang membolehkan anda menggabungkan pelbagai corak GraphQL ke dalam satu. Ini amat berguna apabila anda mempunyai pelbagai perkhidmatan dan masing -masing mempunyai skema sendiri dan anda ingin mendedahkannya sebagai API tunggal. Jahitan corak bertanggungjawab untuk menggabungkan corak dan menyelesaikan sebarang konflik, memberikan pengalaman yang lancar untuk pelanggan.

Bagaimanakah Gateway GraphQL meningkatkan prestasi?

Gateway GraphQL dapat meningkatkan prestasi dengan ketara dengan mengurangkan bilangan perjalanan bulat antara pelanggan dan pelayan. Daripada membuat pelbagai permintaan kepada perkhidmatan yang berbeza, pelanggan hanya membuat permintaan tunggal ke Gateway GraphQL, yang kemudian mengarahkan permintaan ke perkhidmatan yang sepadan, mengagregatkan respons dan menghantarnya kembali kepada pelanggan. Ini mengurangkan latensi rangkaian dan meningkatkan prestasi keseluruhan.

Bolehkah saya menggunakan Gateway Graphql di microservice saya?

Ya, gerbang GraphQL sangat sesuai untuk seni bina microservice. Setiap microservice boleh mempunyai corak GraphQL sendiri, yang Gateway dapat bersambung untuk menyediakan API bersatu. Ini membolehkan anda mengurus dan skala microservices secara bebas sementara masih menyediakan antara muka yang konsisten kepada pelanggan anda.

Adakah Gateway GraphQL serasi dengan semua bahasa pengaturcaraan?

GraphQL Gateway adalah bahasa yang bebas, bermakna ia boleh digunakan dengan mana-mana bahasa pengaturcaraan yang menyokong GraphQL. Ini termasuk bahasa popular seperti JavaScript, Python, Ruby, dan Java.

Bagaimana ralat mengendalikan gerbang GraphQL?

GraphQL Gateway menyediakan keupayaan pengendalian ralat yang kuat. Jika ralat berlaku di salah satu perkhidmatan, Gateway mengembalikan mesej ralat terperinci kepada pelanggan, termasuk maklumat mengenai perkhidmatan yang menyebabkan ralat dan ralat apa yang berlaku. Ini menjadikan diagnosis dan memperbaiki masalah lebih mudah.

Bolehkah saya menggunakan Gateway Graphql dalam seni bina tanpa pelayan?

Ya, GraphQL Gateway serasi dengan seni bina tanpa pelayan. Anda boleh menggunakan gerbang anda sebagai fungsi tanpa pelayan, yang membolehkan anda memanfaatkan skalabilitas dan keberkesanan kos pengkomputeran tanpa pelayan.

Bagaimanakah GraphQL Gateway Handle Security?

GraphQL Gateway menyediakan pelbagai ciri keselamatan termasuk pengesahan dan kebenaran, pengurangan kadar dan pengesahan permintaan. Ciri -ciri ini membantu melindungi perkhidmatan anda daripada akses dan penyalahgunaan yang tidak dibenarkan.

Bolehkah saya menggunakan Gateway GraphQL dengan API RESTFUL yang sedia ada?

Ya, anda boleh menggunakan Gateway GraphQL dengan API RESTful anda yang sedia ada. Gateway boleh membungkus API RESTFUL anda dalam corak GraphQL, yang membolehkan anda memanfaatkan GraphQL semasa masih menggunakan API yang sedia ada.

Atas ialah kandungan terperinci Bina Gateway GraphQL: Gabungkan, jahitan atau gabungan mana -mana sumber data. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!