Product-apim: graphql 지원

+1

+1

+1

+1

+1

+1

:+1:

안녕하세요 @YannickB 입니다 .

올려주셔서 감사합니다. 이것을 로드맵에 추가하고 싶습니다.

저는 GraphQL을 많이 사용하지 않았기 때문에 요구 사항의 정확한 범위를 이해하는 데 문제가 있습니다. 명확성을 위해 예를 사용하여 현재 기능의 정확한 제한 사항을 설명할 수 있습니까? 기본적으로 Apollo 서버를 통해 노출되는 내용과 현재 API Gateway를 통해 이를 어떻게 노출해야 하는지와 API Gateway를 통해 노출하는 이상적인 방법이 무엇인지 비교합니다.

감사 해요,
누완.

+1

안녕하세요 @nuwand 입니다 .

먼저 면책 조항으로, 티켓을 열어도 기능이 어떻게 작동해야 하는지 설명할 수 있는 가장 좋은 사람인지 확신할 수 없습니다. 나를 GraphQL 및 API Gateway와 같은 것을 포함하여 정말 좋은 소프트웨어 아키텍처를 구축하기 위해 공부하는 사람이라고 생각하십시오. 이 연구를 하는 동안 현재 시장에 있는 어떤 API 게이트웨이도 GraphQL을 완벽하게 지원하도록 설계되지 않았다는 것이 분명해졌습니다. 따라서 아직 실제 사용 사례가 없지만 최선을 다해 도와드리겠습니다.

설명하는 가장 좋은 방법이 예가 될 것이라는 데 동의하므로 다음과 같습니다.

제품과 송장이라는 두 객체에 대해 CRUD 기능을 제공하는 API가 있다고 가정해 보겠습니다.

Rest API를 사용하면 http://myapi.com/api/product 및 http://myapi.com/api/invoice 라는 두 개의 엔드포인트를 사용할 수 있으며 그런 다음 GET/POST/PUT/DELETE 작업을 수행합니다. 그들에.
WSO2에서는 각 엔드포인트를 개별적으로(하나는 제품용으로, 다른 하나는 송장용으로) 구성한 다음 WSO2에서 제공하는 보안/제한/수익 창출 등... 기능을 독립적으로 관리하도록 각 엔드포인트에 대한 특정 구성을 제공할 수 있습니다.

그러나 GraphQL API를 제공하는 경우 현재 훨씬 더 제한적입니다. 이는 두 개체 모두 동일한 끝점 http://myapi.com/graphql에서 액세스할 수 있기 때문입니다. 그리고 http://myapi.com/graphql/product 및 http://myapi.com/graphql/invoice 끝점을 여러 개 만들 수 있는 방법이 없습니다. 이것은 GraphQL의 모범 사례와 완전히 반대 패턴이며 최대한 활용할 것입니다. 생태계의 도구가 작동을 중지합니다. 또한 모든 HTTP 작업이 POST라고 생각합니다.

예를 들어 GraphQL 엔드포인트에서 다음 요청을 수행할 수 있습니다.

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

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

첫 번째 요청은 지정된 제품의 정보를 쿼리하고 두 번째 요청은 이 제품에 대한 송장을 생성합니다. 두 쿼리 모두 http://myapi.com/graphql 끝점에서 실행됩니다.

따라서 WSO2 게이트웨이의 현재 상태에서 내가 잘못하지 않은 경우 끝점당 구성만 허용합니다. 예를 들어 http://myapi.com/graphql 끝점을 구성하여 createInvoice에 대한 각 호출에서 0.01센트로 수익을 창출하려면 그러면 제품 호출도 0.01센트로 수익을 창출합니다. REST를 사용하면 POST에서 0.01cent를 http://myapi.com/api/invoice 로 구성하기만 하면 됩니다.
이것이 제 요점을 이해하기에 충분하기를 바랍니다. 이것은 간단한 예이지만 다른 많은 것을 찾을 수 있습니다. 현재 상태에서는 구성의 유연성 부족으로 인해 GraphQL에서 게이트웨이 기능을 사용할 수 없습니다. 그리고 그것은 당신의 잘못이 아닙니다. 나는 시장에 있는 다른 모든 API 게이트웨이가 같은 문제를 가지고 있다고 믿습니다.

따라서 솔루션 IMHO는 WSO2 구성을 끝점뿐만 아니라 GraphQL 기능에도 연결할 수 있습니다. 이것은 내가 생각하기에 기술적인 문제로 판명될 수 있지만 현재 GraphQL은 API 게이트웨이와 작동하지 않거나 매우 저하된 방식으로 작동하지 않기 때문에 시장에서 확실히 필요합니다.

이 제안이 상당한 관심을 끌었던 것 같습니다. 이 문제를 따르는 사람들에게 귀하의 사용 사례와 WSO2가 이 기능을 설계하는 방법에 대한 정보를 제공하도록 초대합니다. 상황을 설명하기 위해 최선을 다했지만, 이를 적절하게 구현하려면 실제 예가 필요하다고 생각합니다.

친애하는,
야닉

임시 솔루션으로 API 게이트웨이에 대한 완전한 지원을 기다리는 동안 서비스 디렉터리로 사용하기 위해 최소한 WSO2-AM graphql 끝점에서 가져올 가능성이 있는 것이 좋습니다.

안녕하세요 @YannickB 입니다 .

설명 감사합니다. 죄송합니다. 하지만 저는 여전히 끝점의 한계를 파악하려고 노력하고 있습니다. 끝점과 관련하여 API Manager의 기능을 설명하면 한계를 정확히 지적할 수 있습니다.

http://myapi.com/api/invoice 및 http://myapi.com/api/product와 같은 두 개의 엔드포인트가 있다고 가정합니다. 두 끝점이 동일한 호스트(myapi.com)에 있는 것처럼 보이는 동일한 예제를 사용하고 있습니다. API Manager에 두 엔드포인트를 프록시하는 단일 API가 있어야 하는 요구 사항이 있는 경우 해야 할 일은 두 개의 리소스를 생성하는 것입니다. 하나는 POST /invoice로, 다른 하나는 POST /product로 지정하고 http://myapi.com/ api/ 를 해당 API의 끝점으로 사용합니다. 이렇게 하면 단일 API를 사용하여 위의 두 엔드포인트에 모두 액세스할 수 있습니다. 예를 들어 게이트웨이 호스트가 gateway.myapi.com이고 생성하는 API의 컨텍스트가 /graphql이고 버전이 1.0.0인 경우 다음 요청은 아래와 같이 적절한 엔드포인트로 각각 프록시됩니다.

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

두 끝점을 모두 프록시하려면 1개의 API(/graphql/1.0.0)만 생성하면 됩니다. 이미 알고 있는 내용을 반복해서 말씀드려 죄송합니다. 하지만 매핑에 대한 리소스의 제한 사항을 지적할 수 있다면 문제를 더 잘 이해하는 데 도움이 될 GraphQL을 사용할 수 없습니다.

감사 해요,
누완.

nuwand, 나는 당신보다 덜 기술적입니다. 그러나 APIM/Identity 서버에 대한 내 이해에서 우리는 API 수준에서 API 관리(보안, 조절, ... ..)를 정의합니다. GraphQL은 '메타' 언어를 통해 API를 결합한 일종의 '수퍼' 언어입니다. 내가 관심을 가질 만한 것은 GraphQL의 개념과 WS02 APIM의 개념이 어떻게 일치하는지 이해하는 것입니다. 두 개념이 통합될 경우. 물론 모든 것을 자체적으로 관리하는 GraphQL als 1 리소스를 고려할 수 있습니다. 하지만 내 모든 '레거시' 서비스가 graphql 서버를 통해 액세스할 수 있는 경우 WS02의 값이 제한됩니다.

+1

GraphQL을 사용하면 실제로는 단 하나의 엔드포인트만 있으므로 myapi.com/graphql/invoice 및 graphql/product와 같은 항목이 없으며 엔도인트는 "myapi.com/graphql"이며 그 이후에는 아무 것도 없습니다. 각 쿼리 및 변형에 대해 문자 그대로 동일한 URL이며 요청 본문 내부에 정의된 작업이 있습니다.

그러면 일부 API 관리 기능은 요청 본문에 대한 내성, graphql 스키마에 대한 지식 등을 필요로 합니다. 이것이 단기적으로는 _불가능_하다고 가정해 봅시다. WSO2는 거의 그 자체로 GraphQL 서버/게이트웨이가 되어야 합니다(또는 이를 통합해야 함).

대신, 우리는 어떤 API 관리 기능이 _가능한_지에 초점을 맞춰야 합니다. 예를 들어 헤더를 설정하여 WSO2와 실제 GraphQL 서버/게이트웨이 간의 협력이 필요하다고 생각합니다. 예를 들어 수익화: GraphQL 서버는 쿼리의 복잡성을 계산하고 이 정보를 HTTP 헤더로 응답에 추가할 수 있습니다. 여기서 WSO2는 이 값을 가격으로 변환합니다. 마찬가지로 모니터링을 위해 GraphQL 서버는 JSON 형태의 쿼리를 휴식과 유사한 의사 엔드포인트(들)로 '변환'할 수 있으며, WSO2는 모니터링 정보를 업데이트하기 위해 응답 헤더에서 읽어 이를 읽습니다. 보안을 위해 동일한 작업을 2단계로 수행할 수 있습니다. 첫째, GraphQL 서버에 쿼리를 나머지 유형의 엔드포인트로 변환하도록 요청하고, WSO2는 통과 여부를 결정하고 쿼리를 실제 엔드포인트로 전달합니다.

저는 WSO2를 처음 접했고 대부분의 문서를 읽지 않았으므로 이러한 기능이 이미 WSO2에 있을 수 있습니다(더 구체적으로: 일반적으로 정확한 REST 끝점 URI에서 파생되는 WSO2의 모든 기능에 대해 동일한 기능을 사용할 수 있는지 여부). 다른 방식으로 파생됩니다(예: 헤더 값 또는 WSO2 자체에 대한 다른 API). 이러한 WSO2 관련 기능을 지원하려면 GraphQL 서버를 수정해야 할 수 있습니다. 질문은 다음과 같습니다. 어떤 낮은 매달린 과일로 시작할 수 있습니까?

(물론 WSO2가 GraphQL에 큰 공을 들이는 것을 보고 싶지만... 하지만 우리는 어딘가에서 시작해야 합니다. 그렇죠?)

좋은 피드백, 나도 같은 느낌 ;)

Op di 6 11월 2018 om 12:06 schreef four44 [email protected] :

GraphQL에는 실제로 단 하나의 끝점이 있으므로 그러한 끝점이 없습니다.
myapi.com/graphql/invoice 및 graphql/product와 같은 엔도인트는
"myapi.com/graphql"만 있고 그 이후에는 아무 것도 없습니다. 그것은 말 그대로
내부에 정의된 작업과 함께 각 쿼리 및 변형에 대해 동일한 URL
요청의 본문.

그러면 일부 API 관리 기능은
요청 본문, graphql 스키마에 대한 지식 등
단기간에 실현 불가능 : WSO2는 거의 GraphQL이 되어야 합니다.
서버/게이트웨이 자체(또는 통합).

대신 어떤 API 관리 기능 이 가능한지에 초점을 맞춰야 합니다.
WSO2와 실제 GraphQL 간의 협력이 필요하다고 생각합니다.
서버/게이트웨이(예: 헤더 설정). 예를 들어 수익 창출:
GraphQL 서버는 쿼리의 복잡성을 계산할 수 있습니다.
WSO2가 이것을 번역하는 응답에 대한 HTTP 헤더로 정보
가치를 가격으로. 마찬가지로 모니터링을 위해 GraphQL 서버는
JSON 형태의 쿼리를 나머지 형태의 (목록)으로 '변환'
WSO2가 업데이트를 위해 응답 헤더에서 읽는 의사 끝점
모니터링 정보. 보안을 위해 동일한 작업을 수행할 수 있습니다.
단계: 먼저 GraphQL 서버에 쿼리를 나머지 쿼리로 변환하도록 요청합니다.
끝점, WSO2는 통과 여부를 결정하고 쿼리를 실제
끝점.

저는 WSO2를 처음 접했고 대부분의 문서를 읽지 않았으므로
아마도 이러한 기능은 이미 WSO2에 있을 수 있습니다(더 구체적으로:
일반적으로 정확한 REST 끝점에서 파생되는 WSO2의 기능
URI, 동일한 기능을 대체 방법으로 파생할 수 있는지 여부
(예: 헤더 값 또는 WSO2 자체에 대한 다른 API)). 그럴 가능성이 있다
이러한 WSO2 전용을 지원하려면 GraphQL 서버를 수정해야 합니다.
특징. 질문은 다음과 같습니다. 어떤 낮은 매달린 과일로 시작할 수 있습니까?

(물론 WSO2가 GraphQL에 큰 공을 들이는 것을 보고 싶습니다...
하지만 우리는 어딘가에서 시작해야 합니다. 그렇죠?)

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

--
바트 반 블리에베르게

안녕하세요,
다음은 Apollo 서버 문서의 일부입니다.
_"HTTP 헤더와 같이 권한 부여가 내장된 REST API를 사용하는 경우 옵션이 하나 더 있습니다. GraphQL 계층(리졸버/모델)에서 인증 또는 권한 부여 작업을 수행하는 대신 헤더나 쿠키를 통해 REST 엔드포인트로 전달하고 작업을 수행하도록 하십시오."_
API 키가 graphql 쿼리와 관련된 모든 엔드포인트에 대해 동일하면 트릭을 수행할 수 있는 것 같습니다.
이 "해결 방법"(API-M 앞에 Apollo 서버 배치)에 대한 생각이 있습니까?

요구 사항 분석

• GraphQL은 REST의 대안으로 Facebook에서 개발했습니다. 특정 사용자가 API에서 필요한 데이터를 정확히 지정할 수 있는 API용 쿼리 언어입니다.
• Swagger 정의(Open API 사양)를 사용하여 REST API를 설계할 수 있다는 것을 알고 있습니다. 그러나 GraphQL에서는 SDL(스키마 정의 언어)을 사용하여 GraphQL API용 스키마를 작성할 수 있습니다.
• GraphQL API를 호출한다는 것은 단순히 GraphQL 쿼리를 사용하여 데이터를 가져오고 GraphQL 변형을 사용하여 데이터를 쓰는 것을 의미합니다.
• 여기에서 우리의 요구 사항은 GraphQL API를 생성 및 게시하고 https/http를 통해 호출하기 위해 WSO2 APIM의 지원을 제공하는 것입니다.

제안된 접근 방식

• GraphQL API를 게시할 때 사용자(게시자)에게 정의를 구성하는 스키마 파일을 업로드하도록 요청합니다. 그런 다음 사용자는 이름, 버전, 컨텍스트 등과 같은 API에 대한 세부 정보를 채울 수 있습니다. 그러나 사용자는 API를 생성할 때 GET, POST 메서드에 대한 리소스를 생성 하라는 요청을 받지 않습니다 .
  

• 다음으로 구현 탭에서 사용자가 선택하면

  • API 관리

    • 끝점 유형 은 자동으로 HTTP/REST 끝점 으로 설정되어야 합니다. (사용자는 이것을 변경할 수 있는 권한이 없어야 합니다)
    • 사용자는 평소와 같이 엔드포인트 (프로덕션 및 샌드박스)를 변경할 수 있는 기능이 있어야 합니다.
    • 다른 필드는 동일하게 유지되어야 합니다.
      

  • 프로토타입 API

    • 인라인 구현 방식에서는 두 개의 GET 및 POST 방식이 자동으로 생성되어 다음 스크린샷과 같이 표시되어야 합니다.
      

• API 관리 옵션을 선택하면 관리 탭에서 설정을 지정해야 합니다.

  • 여기에서도 동일한 절차를 따라야 합니다.
  • 특히 인라인 프로토타입 방식과 마찬가지로 두 개의 GET 및 POST 방식이 자동으로 생성되어 다음 스크린샷과 같이 표시되어야 합니다.
    

• API가 게시되거나 프로토타입화된 후

  • API는 API 스토어에서 GraphQL API로 레이블이 지정되어야 합니다.
  • 소비자는 API Store를 통해 해당 API의 스키마 파일을 다운로드할 수 있어야 합니다.

멋져 보인다

@wasuradananjith 또한 GraphQL API가 상점에서 어떻게 보이는지 게시할 수 있습니까? 아마도 스키마와 함께 API 포털에서 쿼리를 사용할 수 있습니까?

최소한 Apollo 는 GraphQL 데이터 요청에 GET 사용을 지원합니다.

안녕하세요 여러분,

WSO2 APIM 3.0.0 릴리스와 관련된 Graphql 지원 정보 및 PR을 찾으십시오. 새로운 React 기반 UI에서 WSO2 APIM 3.0.0을 출시할 예정이므로 다음과 같이 새로운 UI의 스크린샷을 추가했습니다.

API 게시자
설명:
API 작성자가 API 게시자에 graphQL 스키마를 업로드하면 쿼리 및 변형 작업이 게시자 포털에 나열됩니다. 그런 다음 그/그녀는 범위, 조절 정책, 작업에 대한 보안 활성화/비활성화를 정의할 수 있습니다.

게시자의 기능.

1. GraphQL SDL 스키마를 가져와 GraphQL API 생성
2. 스키마의 유효성을 검사하고 스키마 정의에서 해당 작업을 추출합니다.
3. 게시자에서 SDL 스키마를 검색/가져오기/다운로드합니다.
4. 리소스 대신 작업 표시
5. 작업에 대한 제한, 범위, 보안 추가/업데이트
6. API 목록 페이지에서 'GRAPHQL' 라벨이 붙은 graphQL API 보기

API 스토어
게시자 사용자가 API를 게시하면 SDL 스키마의 모든 작업이 개발자 포털에 채워지고 스키마 파일도 다운로드할 수 있습니다. 개발자는 GET 및 POST 요청 유형이 있는 Tryout 콘솔을 사용하여 작업을 테스트할 수 있습니다.

상점의 기능.

1. API 목록 페이지에서 'GRAPHQL' 라벨이 붙은 graphQL API 보기
2. 특정 API에 대한 작업 보기
3. SDL 스키마 검색 스키마 다운로드 가능
4. API를 호출하기 위해 개발자 콘솔에 GET 및 POST 제공

조회수 스크린샷

1. GrpahQL API 페이지 생성
   

1. 스키마 페이지 업로드
   

2. 다음을 클릭하고 양식을 채워 세부정보를 입력하세요.
   

3. GraphQL API 개요 페이지 생성
   

4. GraphQL API 작업 보기
   

5. 업로드된 스키마 정의
   

6. 범위 추가/업데이트, 조절, 보안
   

7. 매장 운영 개요
   

8. 스키마 다운로드
   

9. 개발자 콘솔
   

Graphql API 호출 시간

1. 권한 부여 - API 작성자는 게시자에서 작업별로 범위를 추가할 수 있습니다.
   APP 사용자가 쿼리/변이(읽기 전용/읽기-쓰기) 작업으로 graphQL API를 호출하면 API 게이트웨이는 페이로드에 포함된 작업을 식별하고 사용자의 토큰 범위에 따라 일치시킵니다. 페이로드에 여러 범위가 있는 여러 작업이 포함된 경우 토큰에는 작업 범위의 최소한 통합이 있어야 합니다.
   예:- 쿼리에 다음이 포함된 경우 (작업 A - 범위 1, 작업 B - 범위 2)
   쿼리를 실행하려는 사용자의 토큰에는 두 범위(scope1 및 scope2)가 모두 있어야 합니다.

2. 보안 - API Creator는 게시자의 작업별로 보안을 활성화/비활성화할 수 있습니다.
   쿼리 요청에 여러 작업 이름이 있는 경우 보안은 작업 보안의 통합으로 간주됩니다. 하나의 작업이 보안을 활성화한 경우 전체 요청에 대한 보안을 지원합니다.

3. 조절 - API 작성자는 게시자의 작업별로 조절 정책을 추가할 수 있습니다.
   쿼리 요청이 여러 작업 이름과 함께 제공되는 경우 제한 정책이 작업별로 적용됩니다. 요청의 한 작업 이름이 해당 정책에 따라 조절된 경우 전체 요청이 조절된 작업의 경우 조절됩니다.

PR은 https://github.com/wso2/carbon-apimgt/pull/6784에서 찾을 수 있습니다.

• 이 수준에서는 쿼리 검사 및 분석 지원, GraphQL 엔드포인트용 API MicroGateway 지원, 인바운드 엔드포인트(웹 소켓 API)로 Graphql 구독 지원, 작업 호출 횟수를 확인하기 위한 Graphql API용 추가 위젯 포함 따라서 향후 로드맵에 대한 관련 지원을 추가하기 위해 새로운 문제가 열렸습니다.

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

이에 대한 귀하의 생각과 귀중한 정보를 감사합니다.

감사 해요!

안녕하세요 여러분,

WSO2 APIM 3.0.0 릴리스와 관련된 Graphql 지원 정보 및 PR을 찾으십시오. 새로운 React 기반 UI에서 WSO2 APIM 3.0.0을 출시할 예정이므로 다음과 같이 새로운 UI의 스크린샷을 추가했습니다.

API 게시자
설명:
API 작성자가 API 게시자에 graphQL 스키마를 업로드하면 쿼리 및 변형 작업이 게시자 포털에 나열됩니다. 그런 다음 그/그녀는 범위, 조절 정책, 작업에 대한 보안 활성화/비활성화를 정의할 수 있습니다.

게시자의 기능.

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

API 스토어
게시자 사용자가 API를 게시하면 SDL 스키마의 모든 작업이 개발자 포털에 채워지고 스키마 파일도 다운로드할 수 있습니다. 개발자는 GET 및 POST 요청 유형이 있는 Tryout 콘솔을 사용하여 작업을 테스트할 수 있습니다.

상점의 기능.

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

조회수 스크린샷

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

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은 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)

이에 대한 귀하의 생각과 귀중한 정보를 감사합니다.

감사 해요!

안녕하세요 @HiranyaKavishani ,
이 지원은 우리가 일반적으로 wso apim을 통해 기존 API에 대해 수행하는 것처럼 APIM을 통해 기존 GraphQL API 게시를 도입합니까?

또한 기능을 테스트할 베타/알파 릴리스가 있습니까?

감사 해요 !

안녕하세요 @arvindkannan ,

기존 Graphql API의 경우 나머지 API와 비교할 때 graphql이 지원하는 방식이 다르기 때문에 API를 다시 생성하고 다시 게시해야 합니다. 그러나 그렇게 할 경우 기존 고객에게 영향을 미치므로 기존 토큰과 기존 URL이 변경되지 않도록 해야 합니다.

이 기능은 10월에 출시될 APIM 3.0.0에서 사용할 수 있습니다.

감사 해요!

APIM 3.0.0 베타 버전에서 이 지원을 사용할 수 있으므로 문제를 종료합니다.