Product-apim: Dukungan untuk graphql

+1

+1

+1

+1

+1

+1

:+1:

Hai @YannickB ,

Terima kasih telah mengangkat ini. Kami ingin menambahkan ini ke peta jalan kami.

Saya belum banyak menggunakan GraphQL dan karenanya mengalami kesulitan memahami ruang lingkup persyaratan yang tepat. Untuk kejelasan, dapatkah Anda menjelaskan batasan yang tepat dari fungsi saat ini menggunakan contoh? Pada dasarnya apa yang diekspos melalui server Apollo dan bagaimana Anda harus mengekspos ini melalui API Gateway hari ini vs apa cara ideal untuk mengeksposnya melalui API Gateway.

Terima kasih,
Nuwan.

+1

Hai @nuwand ,

Pertama sebagai penafian, bahkan jika saya membuka tiket, saya tidak yakin saya adalah orang yang paling tepat untuk menjelaskan cara kerja fitur tersebut. Pikirkan saya sebagai seseorang yang belajar untuk membangun arsitektur perangkat lunak yang sangat bagus, jadi termasuk hal-hal seperti GraphQL dan API Gateway, dan ketika saya mempelajari ini, saya menjadi jelas bagi saya bahwa tidak ada API Gateway di pasaran saat ini yang dirancang untuk sepenuhnya mendukung GraphQL. Karenanya saya belum memiliki kasus penggunaan nyata dalam produksi, tetapi saya akan melakukan yang terbaik untuk membantu.

Saya setuju cara terbaik untuk menjelaskan akan menjadi contoh jadi ini dia:

Katakanlah Anda memiliki API yang menyediakan fungsi CRUD untuk dua objek, produk dan faktur.

Dengan API Istirahat, Anda akan memiliki dua titik akhir untuk digunakan, http://myapi.com/api/product dan http://myapi.com/api/invoice , dan Anda kemudian melakukan operasi GET/POST/PUT/DELETE pada mereka.
Di WSO2, Anda dapat mengonfigurasi setiap titik akhir secara independen, satu untuk produk dan satu untuk faktur, lalu memberikan konfigurasi khusus untuk masing-masing titik tersebut untuk mengelola secara mandiri fitur keamanan/pelambatan/monetisasi/dll... yang disediakan oleh WSO2.

Tetapi jika kami menyediakan GraphQL API, saat ini kami jauh lebih terbatas. Ini karena kedua objek akan dapat diakses di titik akhir yang sama http://myapi.com/graphql. Dan tidak ada cara untuk membuat beberapa titik akhir http://myapi.com/graphql/product dan http://myapi.com/graphql/invoice , ini sepenuhnya anti-pola dengan praktik terbaik GraphQL dan akan membuat sebagian besar alat dalam ekosistemnya untuk berhenti bekerja. Selain itu, saya percaya semua operasi HTTP adalah POST.

Jadi sebagai contoh, kami mungkin ingin melakukan permintaan tesis pada titik akhir GraphQL :

query {
  product(id: 1) {
    id
    name
  }
}

mutation {
  createInvoice(data: {
    'customerID': 1
    'productID': 1
    'price': 20
  }) {
    id
    number
    total
  }
}

Permintaan pertama akan menanyakan informasi produk yang ditentukan, dan yang kedua akan membuat faktur untuk produk ini. Kedua kueri dieksekusi pada titik akhir http://myapi.com/graphql .

Jadi dengan keadaan WSO2 Gateway saat ini, yang jika saya tidak salah hanya mengizinkan untuk mengkonfigurasi per titik akhir, jika saya ingin misalnya untuk memonetisasi pada 0,01 sen setiap panggilan ke createInvoice dengan mengonfigurasi titik akhir http://myapi.com/graphql , maka panggilan ke produk juga akan dimonetisasi pada 0,01sen. Dengan REST, Anda baru saja mengonfigurasi 0,01cent ke http://myapi.com/api/invoice di POST dan itu saja.
Saya harap ini cukup bagi Anda untuk memahami maksud saya, ini adalah contoh sederhana tetapi kami dapat menemukan banyak contoh lainnya, pada kondisi saat ini tidak mungkin menggunakan fitur Gateway dengan GraphQL karena kurangnya fleksibilitas dalam konfigurasi. Dan itu bukan salah Anda, saya yakin semua API Gateway lain di pasar memiliki masalah yang sama.

Jadi solusi IMHO memungkinkan untuk melampirkan konfigurasi WSO2 tidak hanya ke titik akhir, tetapi juga fungsi GraphQL. Ini mungkin terbukti menjadi tantangan teknis menurut saya, tetapi pasti ada kebutuhan untuk ini di pasar karena saat ini GraphQL tidak bekerja dengan API Gateway, atau dengan cara yang sangat terdegradasi.

Tampaknya saran ini cukup menarik perhatian. Kepada orang-orang yang mengikuti masalah ini, saya mengundang Anda untuk memberikan beberapa informasi tentang kasus penggunaan Anda dan bagaimana seharusnya WSO2 merancang fitur ini. Saya harap saya melakukan yang terbaik untuk menggambarkan situasinya, tetapi saya yakin mereka akan membutuhkan beberapa contoh nyata untuk menerapkan ini dengan benar.

Salam,
Yannick

Sebagai solusi sementara, akan sangat bagus untuk memiliki setidaknya kemungkinan untuk mengimpor di titik akhir graphql WSO2-AM, untuk menggunakannya sebagai Direktori Layanan sambil menunggu dukungan penuh ke dalam API Gateway

Hai @YannickB ,

Terima kasih atas penjelasan Anda. Maafkan saya, tetapi saya masih mencoba mencari tahu batasan dengan titik akhir. Biarkan saya menjelaskan kemampuan yang dimiliki Manajer API sehubungan dengan titik akhir dan mungkin Anda dapat menunjukkan batasannya.

Asumsikan Anda memiliki dua titik akhir sebagai http://myapi.com/api/invoice dan http://myapi.com/api/product. Perhatikan bahwa saya menggunakan contoh yang sama seperti yang Anda lakukan, di mana kedua titik akhir tampaknya berada di Host yang sama (myapi.com). Jika persyaratan Anda adalah memiliki satu API pada Manajer API untuk mem-proksi kedua titik akhir, yang harus Anda lakukan adalah membuat dua sumber daya, satu sebagai POST /faktur dan lainnya sebagai POST /produk dan tentukan http://myapi.com/ api/ sebagai titik akhir dari masing-masing API. Ini akan memungkinkan Anda untuk mengakses kedua titik akhir di atas menggunakan satu API. Misalnya, jika host gateway Anda adalah gateway.myapi.com dan konteks API yang Anda buat adalah /graphql dan versinya adalah 1.0.0, permintaan berikut akan mem-proksi masing-masing ke titik akhir yang sesuai seperti di bawah ini.

POSTING http://gateway.myqpi.com/graphql/1.0.0/invoice -> POSTING http://myqpi.com/api/invoice
POSTING http://gateway.myqpi.com/graphql/1.0.0/product -> POSTING http://myqpi.com/api/product

Perhatikan bahwa Anda hanya perlu membuat 1 API (/graphql/1.0.0) untuk mem-proksi kedua titik akhir. Saya minta maaf jika saya mengulangi sesuatu yang sudah Anda ketahui :), tetapi jika Anda dapat menunjukkan batasan pada sumber daya kami untuk pemetaan yang membuat tidak mungkin menggunakan GraphQL yang akan membantu saya untuk memahami masalah dengan lebih baik.

Terima kasih,
Nuwan.

nuwand, saya kurang teknis dari Anda. Namun dalam pemahaman saya dengan APIM / Identity server, kami mendefinisikan pada API Level pengelolaan API (keamanan, pembatasan, ... ..) . GraphQL adalah sejenis bahasa 'super' yang menggabungkan API melalui bahasa 'meta' . Apa yang menarik bagi saya adalah untuk memahami bagaimana konsep GraphQL dan konsep WS02 APIM dicocokkan. dan jika kedua konsep akan diintegrasikan. Tentu saja Anda dapat mempertimbangkan sumber daya GraphQL als 1 yang mengelola semuanya sendiri .... tetapi nilai WS02 terbatas jika semua layanan 'warisan' saya dapat diakses melalui server graphql.

+1

Dengan GraphQL, sebenarnya hanya ada satu titik akhir, jadi tidak ada yang namanya myapi.com/graphql/invoice dan graphql/product, endpoint hanya "myapi.com/graphql", dan tidak ada setelah itu. Ini secara harfiah adalah URL yang sama untuk setiap kueri dan mutasi, dengan operasi yang ditentukan di dalam isi permintaan.

Beberapa fitur manajemen api kemudian akan memerlukan introspeksi badan permintaan, pengetahuan tentang skema graphql, dll. Mari kita asumsikan bahwa ini _tidak_ layak dalam jangka pendek: WSO2 seharusnya hampir menjadi server/gerbang GraphQL itu sendiri (atau mengintegrasikan satu).

Sebagai gantinya, kita harus fokus pada fitur manajemen API apa yang _mungkin_. Saya kira kita perlu kerjasama antara WSO2 dan server/gateway GraphQL yang sebenarnya, misalnya dengan mengatur header. Misalnya monetisasi: server GraphQL dapat menghitung kompleksitas kueri, menambahkan informasi ini sebagai header HTTP ke respons, di mana WSO2 menerjemahkan nilai ini menjadi harga. Demikian pula untuk pemantauan, server GraphQL dapat 'mengubah' kueri berbentuk JSON menjadi (daftar) titik akhir semu seperti istirahat, yang dibaca WSO2 dari header respons untuk memperbarui informasi pemantauan. Hal yang sama dapat dilakukan untuk keamanan, mungkin dalam 2 fase: pertama meminta server GraphQL untuk mengubah kueri menjadi titik akhir seperti istirahat, WSO2 memutuskan untuk lulus atau tidak, meneruskan kueri ke titik akhir yang sebenarnya.

Saya benar-benar baru di WSO2 dan belum membaca sebagian besar dokumentasi, jadi mungkin fitur ini sudah ada di WSO2 (lebih khusus: untuk semua fungsi WSO2 yang biasanya diturunkan dari URI titik akhir REST yang tepat, apakah fungsi yang sama dapat diturunkan dengan cara alternatif (misalnya nilai header atau API lain untuk WSO2 itu sendiri)). Tampaknya server GraphQL perlu dimodifikasi untuk mendukung fitur khusus WSO2 ini. Pertanyaannya adalah: buah gantung rendah apa yang bisa kita mulai?

(Tentu saja saya ingin melihat WSO2 membuat komitmen besar ke GraphQL... tapi kita harus mulai dari suatu tempat, kan?)

Umpan balik yang bagus, saya merasakan hal yang sama;)

Op di 6 nov. 2018 om 12:06 schreef keempat44 [email protected] :

Dengan GraphQL, hanya ada satu titik akhir, jadi tidak ada
hal seperti myapi.com/graphql/invoice dan graphql/product, tujuannya adalah
hanya "myapi.com/graphql", dan tidak ada setelah itu. Ini secara harfiah adalah
URL yang sama untuk setiap kueri dan mutasi, dengan operasi yang ditentukan di dalamnya
tubuh permintaan.

Beberapa fitur manajemen api kemudian akan membutuhkan introspeksi dari
badan permintaan, pengetahuan tentang skema graphql, dll. Mari kita asumsikan bahwa ini
tidak layak dalam jangka pendek: WSO2 hampir harus menjadi GraphQL
server/gateway itu sendiri (atau mengintegrasikan satu).

Sebagai gantinya, kita harus fokus pada fitur manajemen API yang memungkinkan.
Saya kira kita perlu kerjasama antara WSO2 dan GraphQL yang sebenarnya
server/gateway, misalnya dengan mengatur header. Misalnya monetisasi: the
Server GraphQL dapat menghitung kompleksitas kueri, tambahkan ini
informasi sebagai header HTTP ke respons, di mana WSO2 menerjemahkan ini
nilai menjadi harga. Demikian pula untuk pemantauan, server GraphQL dapat
'ubah' kueri berbentuk JSON menjadi (daftar) seperti istirahat
pseudo-endpoint(s), yang dibaca WSO2 dari header respons untuk memperbarui
informasi pemantauan. Hal yang sama dapat dilakukan untuk keamanan, mungkin dalam 2
fase: pertama minta server GraphQL untuk mengubah kueri menjadi seperti istirahat
titik akhir, WSO2 memutuskan untuk lulus atau tidak, meneruskan kueri ke yang sebenarnya
titik akhir.

Saya benar-benar baru di WSO2 dan belum membaca sebagian besar dokumentasi, jadi
mungkin fitur-fitur ini sudah ada di WSO2 (lebih khusus: untuk apa saja
fungsionalitas WSO2 yang biasanya diturunkan dari titik akhir REST yang tepat
URI, apakah fungsi yang sama dapat diturunkan dengan cara alternatif
(misalnya nilai header atau API lain ke WSO2 itu sendiri)). Kemungkinan itu
server GraphQL perlu dimodifikasi untuk mendukung spesifik WSO2 ini
fitur. Pertanyaannya adalah: buah gantung rendah apa yang bisa kita mulai?

(Tentu saja saya ingin melihat WSO2 membuat komitmen besar ke GraphQL...
tapi kita harus mulai dari suatu tempat, kan?)

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

--
Bart Van Vlierberghe

Halo,
Berikut ini adalah ekstrak dari dokumentasi Apollo Server:
_"Jika Anda menggunakan REST API yang memiliki otorisasi bawaan, seperti dengan header HTTP, Anda memiliki satu opsi lagi. Daripada melakukan pekerjaan autentikasi atau otorisasi apa pun di lapisan GraphQL (dalam resolver/model), itu mungkin untuk hanya melewati header atau cookie ke titik akhir REST Anda dan membiarkannya bekerja."_
Jika kunci API sama untuk semua titik akhir yang terlibat oleh kueri graphql Anda, sepertinya itu bisa berhasil.
Adakah pemikiran tentang "solusi" ini (letakkan server Apollo di depan API-M)?

Analisis Kebutuhan

• GraphQL dikembangkan oleh Facebook yang merupakan alternatif untuk REST. Ini adalah bahasa kueri untuk API di mana pengguna tertentu dapat menentukan dengan tepat data apa yang dibutuhkan dari API.
• Kita tahu bahwa kita dapat menggunakan Definisi Swagger (Spesifikasi API Terbuka) untuk mendesain REST API. Tapi di GraphQL, kita bisa menggunakan Schema Definition Language (SDL) untuk menulis skema untuk GraphQL API.
• Menggunakan GraphQL API berarti mengambil data menggunakan kueri GraphQL dan menulis data menggunakan mutasi GraphQL.
• Di sini persyaratan kami adalah memberikan dukungan dari WSO2 APIM untuk membuat dan menerbitkan GraphQL API dan menjalankannya melalui https/http.

Pendekatan yang Disarankan

• Saat memublikasikan GraphQL API, kami meminta pengguna (penerbit) untuk mengunggah file skema yang berisi definisi. Kemudian pengguna dapat mengisi detail tentang API seperti nama, versi, konteks, dll. Tetapi pengguna tidak akan diminta untuk membuat sumber daya untuk metode GET, POST saat membuat API.
  

• Selanjutnya, di tab Implement , jika pengguna memilih,

  • Kelola API

    • Jenis Titik Akhir harus disetel ke Titik Akhir HTTP/REST secara otomatis. (Pengguna tidak boleh memiliki kemampuan untuk mengubah ini)
    • Pengguna harus memiliki kemampuan untuk mengubah Endpoint (Produksi dan Sandbox) seperti biasa.
    • Bidang lain harus tetap sama.
      

  • API prototipe

    • Dalam metode implementasi Inline , dua metode GET dan POST harus dibuat dan ditampilkan secara otomatis seperti yang ditampilkan pada tangkapan layar berikut.
      

• Jika Anda memilih opsi Kelola API maka Anda harus mengatur pengaturan di tab Kelola .

  • Di sini prosedur yang sama harus diikuti.
  • Khususnya seperti dalam metode prototipe Inline , dua metode GET dan POST harus dibuat dan ditampilkan secara otomatis seperti pada tangkapan layar berikut.
    

• Setelah API diterbitkan atau dibuat prototipe

  • API harus diberi label sebagai GraphQL API di API Store.
  • Konsumen harus memiliki kemampuan untuk mengunduh file skema API tersebut melalui API Store.

Tampak hebat

@wasuradananjith dapatkah Anda juga memposting bagaimana tampilan GraphQL API di toko? Apakah kueri tersedia di Portal API, mungkin dengan skema?

Setidaknya Apollo mendukung penggunaan GET untuk permintaan data GraphQL.

Halo semua,

Silakan temukan informasi dan PR dukungan Graphql terkait dengan rilis WSO2 APIM 3.0.0. Karena kita akan merilis WSO2 APIM 3.0.0 di bawah UI berbasis React yang baru, screenshot dari UI baru telah ditambahkan sebagai berikut.

penerbit API
Keterangan:
Saat pembuat API mengunggah skema graphQL ke penerbit API, operasi kueri dan mutasi akan dicantumkan di portal penerbit. Kemudian dia akan mengizinkan untuk menentukan cakupan, kebijakan pelambatan, mengaktifkan/menonaktifkan keamanan terhadap operasi.

Fungsi di penerbit.

1. Buat GraphQL API dengan mengimpor skema GraphQL SDL
2. Validasi skema dan ekstrak operasinya dari definisi skema
3. Ambil/Impor/Unduh skema SDL di penerbit.
4. Menunjukkan operasi alih-alih sumber daya
5. Tambahkan/Perbarui pelambatan, cakupan, keamanan terhadap operasi
6. Lihat API graphQL yang berlabel 'GRAPHQL' di Halaman Daftar API

Toko API
Setelah API diterbitkan oleh pengguna penerbit, semua operasi di skema SDL telah diisi di portal pengembang dan file skema juga tersedia untuk diunduh. Pengembang dapat menguji operasi menggunakan konsol Tryout dengan jenis permintaan GET dan POST.

Fungsionalitas di toko.

1. Lihat API graphQL yang berlabel 'GRAPHQL' di Halaman Daftar API
2. Lihat operasi untuk API tertentu
3. Dapat mengunduh skema pengambilan skema SDL
4. Sediakan konsol pengembang dengan GET dan POST untuk memanggil API

Tangkapan layar tampilan

1. Buat halaman API GrpahQL
   

1. Unggah halaman skema
   

2. Klik berikutnya dan isi formulir untuk mengisi detail
   

3. Membuat halaman ikhtisar GraphQL API
   

4. Tampilan operasi GraphQL API
   

5. Definisi skema yang diunggah
   

6. Tambahkan/Perbarui cakupan, pembatasan, keamanan
   

7. Ikhtisar operasi toko
   

8. Unduh skema
   

9. Konsol Pengembang
   

Waktu pemanggilan Graphql API

1. Otorisasi - Pembuat API dapat menambahkan cakupan per operasi di penerbit
   Ketika pengguna APP memanggil API graphQL dengan operasi kueri/mutasi (hanya baca/baca-tulis), gateway API akan mengidentifikasi operasi mana yang terdapat dalam muatan dan mencocokkannya sesuai dengan cakupan token pengguna. Jika payload berisi beberapa operasi dengan beberapa cakupan, token harus memiliki setidaknya gabungan dari cakupan operasi.
   Misalnya: - Katakanlah ketika kueri berisi, (operasi A - lingkup 1, operasi B - lingkup 2)
   token pengguna yang akan menjalankan kueri harus memiliki kedua cakupan (lingkup1 dan cakupan2)

2. Keamanan - Pembuat API dapat mengaktifkan/menonaktifkan keamanan per operasi di penerbit.
   Ketika permintaan kueri datang dengan beberapa nama operasi, keamanan telah dianggap sebagai gabungan dari keamanan operasi. Jika satu operasi telah mengaktifkan keamanan, kami mendukung keamanan untuk seluruh permintaan.

3. Pembatasan - Pembuat API dapat menambahkan kebijakan pembatasan per operasi di penerbit.
   Saat permintaan kueri datang dengan beberapa nama operasi, kebijakan pembatasan akan berlaku per operasi. Jika satu nama operasi permintaan telah dibatasi sesuai dengan kebijakannya, seluruh permintaan akan dibatasi dalam kasus operasi yang dibatasi.

PR akan ditemukan di https://github.com/wso2/carbon-apimgt/pull/6784.

• Pada level ini, kami tidak akan mendukung pemeriksaan dan analisis kueri, mendukung API MicroGateway untuk titik akhir GraphQL, mendukung langganan Graphql dengan titik akhir masuk (API soket Web), Sertakan widget tambahan untuk API Graphql untuk melihat jumlah permintaan operasi berdasarkan jenis operasi, dll. Oleh karena itu, masalah baru telah dibuka untuk menambahkan dukungan yang relevan untuk peta jalan masa depan kami.

1. https://github.com/wso2/product-apim/issues/5432
2. https://github.com/wso2/product-apim/issues/5431
3. https://github.com/wso2/product-microgateway/issues/773
4. https://github.com/wso2/analytics-solutions/issues/310

Hargai pemikiran dan masukan berharga Anda terkait hal ini.

Terima kasih!

Halo semua,

Silakan temukan informasi dan PR dukungan Graphql terkait dengan rilis WSO2 APIM 3.0.0. Karena kita akan merilis WSO2 APIM 3.0.0 di bawah UI berbasis React yang baru, screenshot dari UI baru telah ditambahkan sebagai berikut.

penerbit API
Keterangan:
Saat pembuat API mengunggah skema graphQL ke penerbit API, operasi kueri dan mutasi akan dicantumkan di portal penerbit. Kemudian dia akan mengizinkan untuk menentukan cakupan, kebijakan pelambatan, mengaktifkan/menonaktifkan keamanan terhadap operasi.

Fungsi di penerbit.

1. Create a GraphQL APIs by importing GraphQL SDL schema

2. Validate the schema and extract its operations from the schema definition

3. Retrieve/Import/Download  SDL schema at the publisher.

4. Shows operations instead of resources

5. Add/Update throttling,scopes,security against operations

6. View graphQL APIs labeling 'GRAPHQL' at API Listing Page

Toko API
Setelah API diterbitkan oleh pengguna penerbit, semua operasi di skema SDL telah diisi di portal pengembang dan file skema juga tersedia untuk diunduh. Pengembang dapat menguji operasi menggunakan konsol Tryout dengan jenis permintaan GET dan POST.

Fungsionalitas di toko.

1. View graphQL APIs labeling 'GRAPHQL' at API Listing Page

2. View operations for particular API

3. Able to download SDL schema retrieving schema

4. Provide developer console with GET and POST to invoke the API

Tangkapan layar tampilan

1. Create GrpahQL API page

1. Upload schema page

1. Click next and populate a form to fill details

1. Created GraphQL API overview page

1. GraphQL API operation view

1. Uploaded schema definition

1. Add/Update scopes,throttling,security

1. Store operation overview

1. Schema download

1. Developer Console

Waktu pemanggilan Graphql API

1. Authorization - API Creator can add scopes per operations at the publisher
   When the APP user invokes the graphQL API with query/mutation (read-only/ read-write) operation, API gateway will identify which operations are containing in the payload and match them according to the token scope of the user. If the payload contains multiple operations with multiple scopes, the token should have at least a union of the operation scopes.
   Eg:- Let's say when a query contains, (operation A  - scope 1, operation B -  scope 2)
   the token of the user who is going to execute the query should have both scopes (scope1 and scope2)

2. Security - API Creator can enable/disable security per operations at the publisher.
   When a query request comes with multiple operation names, security has been considered as the union of the operations security. If one operation has been enabled the security, we support security for whole request.

3. Throttling - API Creator can add throttling policy per operations at the publisher.
   When a query request comes with multiple operation names, throttle policies will apply per operation. If one operation name of the request has been throttled out according to its policy, the whole request is going to be throttled out in the case of throttled operation.

PR akan ditemukan di wso2/carbon-apimgt#6784 .

* At this level, we are not going to support on inspecting and analyzing queries, support API MicroGateway for GraphQL endpoints, support Graphql subscriptions with the inbound endpoints(Web socket APIs), Include an extra widget for Graphql APIs to see the count of operation invocation based on operation types, etc. Therefore, new issues have been opened to add relevant support for our future roadmap.


1. #5432

2. #5431

3. [wso2/product-microgateway#773](https://github.com/wso2/product-microgateway/issues/773)

4. [wso2/analytics-solutions#310](https://github.com/wso2/analytics-solutions/issues/310)

Hargai pemikiran dan masukan berharga Anda terkait hal ini.

Terima kasih!

Hai @HiranyaKavishani ,
Apakah dukungan ini memperkenalkan penerbitan GraphQL API yang ada melalui APIM seperti yang biasa kami lakukan untuk API yang ada melalui wso apim ?

Juga apakah ada Rilis Beta/Alpha untuk menguji fitur tersebut?

Terima kasih !

Hai @arvindkannan ,

Untuk Graphql API yang ada, diperlukan untuk membuat ulang API dan memublikasikan ulang karena graphql memiliki dukungan yang berbeda jika dibandingkan dengan API lainnya. Tetapi jika demikian, itu harus memastikan bahwa token yang ada dan URL yang ada tidak akan berubah dengan ini karena akan mempengaruhi pelanggan yang sudah ada.

Fitur ini akan tersedia dengan APIM 3.0.0 yang akan dirilis pada bulan Oktober.

Terima kasih!

Tutup masalah karena dukungan ini tersedia di APIM 3.0.0 versi Beta