그냥 구글 번역해서 Copy & Paste로  

요즘은 GraphQL을 넘어서 gRPC도 많이 나오긴 합니다.

Facebook에 의해 도입 된 이후 GraphQL은 REST API의 대안으로 API 세계를 강타했습니다. GraphQL은 API 개발자와 사용자가 RESTful 아키텍처에서 발견 한 많은 문제를 수정합니다. 그러나 평가해야 할 새로운 과제도 도입합니다. GraphQL은 단순히 REST의 진화적인 대체물이 아니기 때문에이 게시물에서는 GraphQL이 애플리케이션에 적합한 경우 각각의 장단점에 대해 자세히 알아볼 것입니다.

역사

RESTful API 이전에는 RPC, SOAP, CORBA 및 기타 덜 개방 된 프로토콜이있었습니다. 많은 사전 REST API에는 유선을 통해 페이로드를 직렬화 / 역 직렬화하기 위해 복잡한 클라이언트 라이브러리가 필요했습니다. 오늘날의 RESTful API와 근본적인 차이점은 SOAP는 WSDL (Web Services Description Language)을 통해 공식 계약을 사용하여 강력하게 입력된다는 것입니다. 64 비트 길이를 허용하는 32 비트 정수 제한을 제거하더라도 업스트림 클라이언트가 중단되기 때문에 상호 운용성에 혼란을 줄 수 있습니다. SOAP는 아키텍처가 아니지만 보안, 오류 처리, ACID 트랜잭션 등으로 구성된 완전한 프로토콜 구현입니다. 일부 복잡성은 SOAP에 구워진 많은 추상화 계층으로 인해 발생합니다. 예를 들어 SOAP는 HTTP, TCP, UDP 등에서 실행할 수 있습니다. 프로토콜 구현은 많은 추상화를 제공했지만

RESTful 아키텍처는 무 상태 및 유형없는 방식으로 추가 계층없이 유비쿼터스 HTTP 프로토콜 만 사용하여 머신 간 통신을 가능하게하는 훨씬 간단한 방법으로 2000 년에 도입되었습니다. 이로 인해 시스템이 느슨하게 결합되고 회사 간과 같은 시스템 간 계약 변경에 대해 더 관용 할 수 있습니다.

오늘 휴식

REST API는 API를 배포하고 개발자 플랫폼을 출시하는 회사의 사실상 표준이되었습니다. REST의 장점은 다른 사람의 API로 작업하는 개발자가 특별한 초기화 나 라이브러리가 필요 없다는 것입니다. 요청은 cURL 및 웹 브라우저와 같은 일반적인 소프트웨어를 통해 간단히 전송할 수 있습니다.

REST는 표준 CRUD HTTP 동사 (GET, POST, PUT, DELETE)를 사용하고 HTTP와 싸우는 대신 HTTP 규칙을 활용하고 데이터 리소스 (HTTP URI)를 중심으로합니다. 따라서 리소스 api.acmestore.com/items가 있는 전자 상거래는 리소스 가있는 은행과 유사하게 동작 할 수 있습니다 api.examplebank.com/deposits. 둘은 아마 해당 자원에 CRUD 작업이 필요하고 캐시 쿼리에 선호하는 (즉, 둘 것 GET api.acmestore.com/items및 GET api.examplebank.com/transactions캐시 할 것이다). 새로운 API에 대한 타사 개발자는 수천 개의 작업을 깊이 파고 드는 대신 데이터 모델에 대해 추론하고 나머지는 HTTP 규칙에 맡기면됩니다. 즉, REST는 SOAP에 비해 HTTP 및 CRUD에 훨씬 더 긴밀하게 결합되지만 느슨한 데이터 계약을 제공합니다.

REST 문제

더 다양한 API가 프로덕션 용도로 배치되고 극한 수준으로 확장됨에 따라 RESTful 아키텍처의 특정 문제가 발생했습니다. GraphQL이 SOAP와 REST 사이에 있다고 말할 수도 있습니다.

서버 기반 선택

RESTful API에서 서버는 클라이언트에 다시 응답 할 리소스의 표현을 만듭니다.

그러나 클라이언트가 자신의 직업이 엔지니어 인 사용자 친구의 친구 이름을 반환하는 것과 같은 특정 작업을 원하는 경우에는 어떻게해야 합니까 ?

REST를 사용하면 다음과 같은 결과를 얻을 수 있습니다.

GET api.example.com/users/123?include=friend.friend.name&friend.friend.ocupation=engineer

GraphQL을 사용하면이 쿼리를보다 깔끔하게 표현할 수 있습니다.

{
 user(id: 123) {
   friends {
     friends(job: "engineer") {
       name
     }
   }
 }
}

여러 리소스 가져 오기

GraphQL의 주요 이점 중 하나는 API를 덜 수다스럽게 만드는 것입니다. 우리 중 많은 사람들이 먼저 엔드 포인트 GET /user를 통해 각 친구를 개별적으로 가져와야 하는 API를 보았습니다. GET /user/:id/friend/:id이로 인해 N + 1 쿼리가 발생할 수 있으며 이는 API 및 데이터베이스 쿼리에서 알려진 성능 문제입니다. 즉, RESTful API 호출은 최종 표현이 표시되기 전에 클라이언트에서 연결됩니다. GraphQL은 서버가 클라이언트에 대한 데이터를 단일 쿼리로 집계 할 수 있도록함으로써이를 줄일 수 있습니다.

심층 분석

API 분석은 또한 도구가 거의 없기 때문에 GraphQL API에 부정적인 영향을 미칩니다. GraphQL API를 지원하는 도구는 RESTful API보다 쿼리에 대한 더 많은 통찰력을 제공 할 수 있습니다.

GraphQL의 문제

캐싱

캐싱은 RESTful API가 활용할 수있는 HTTP 사양에 내장되어 있습니다. 캐싱과 관련된 GET 대 POST 의미 체계가 잘 정의되어 브라우저 캐시, 중간 프록시 및 서버 프레임 워크가 따를 수 있습니다. 다음 지침을 따를 수 있습니다.

• GET 요청을 캐시 할 수 있습니다.
• GET 요청은 브라우저 기록에 남아있을 수 있습니다.
• GET 요청을 북마크 할 수 있습니다.
• GET 요청은 멱 등성입니다.

GraphQL은 캐싱을 위해 HTTP 사양을 따르지 않고 대신 단일 엔드 포인트를 사용합니다. 따라서 캐시 될 수있는 변경 불가능한 쿼리에 대해 캐싱이 올바르게 구현되는지 확인하는 것은 개발자의 몫입니다. 본문 내용 검사를 포함 할 수있는 캐시에 올바른 키를 사용해야합니다.

GraphQL 의미 체계를 이해하는 Relay 또는 Dataloader와 같은 도구를 사용할 수 있지만 여전히 브라우저 및 모바일 캐싱과 같은 것은 다루지 않습니다.

비공유 아키텍처 감소

RESTful API의 장점은 비공유 아키텍처를 잘 보완한다는 것입니다. 예를 들어 Moesif에는 api.moesif.com/v1/search엔드 포인트와 api.moesif.com/v1/alerting엔드 포인트가 있습니다. 공개적으로이 두 끝점은 단순히 두 개의 다른 REST 리소스처럼 보입니다. 그러나 내부적으로는 격리 된 컴퓨팅 클러스터에있는 두 개의 다른 마이크로 서비스를 가리 킵니다. 검색 서비스는 Scala로 작성되고 경고 서비스는 NodeJS로 작성됩니다. 호스트 또는 URL을 통해 HTTP 요청을 라우팅하는 복잡성은 GraphQL 쿼리를 검사하고 여러 조인을 수행하는 것보다 훨씬 낮습니다.

임의 요청에 노출됨

GraphQL의 주요 이점은 클라이언트가 필요한 데이터 만 쿼리 할 수 ​​있도록하는 것이지만 이는 특히 조직이 타사 클라이언트 쿼리 동작을 제어 할 수없는 개방형 API의 경우 문제가 될 수 있습니다. GraphQL 쿼리로 인해 서버 성능을 저하 시키거나 서버를 DDoS 할 수있는 값 비싼 조인 쿼리가 발생하지 않도록 세심한주의를 기울여야합니다. RESTful API는 사용 된 데이터 모델 및 인덱싱과 일치하도록 제한 될 수 있습니다.

쿼리의 엄격함

GraphQL은 API 위에서 사용자 지정 쿼리 DSL 또는 부작용 작업에 대한 기능을 제거합니다. 예를 들어 Elasticsearch API는 RESTful이지만 고급 집계 및 메트릭 계산을 수행하는 매우 강력한 Elasticsearch DSL도 있습니다. 이러한 집계 쿼리는 GraphQL 언어 내에서 모델링하기가 더 어려울 수 있습니다.

존재하지 않는 모니터링

RESTful API는 웹 사이트와 같은 리소스와 관련하여 HTTP 사양을 따르는 이점이 있습니다. 이를 통해 많은 도구가 api.moesif.com/health확인되지 않은 경우 5xx를 반환하는 것과 같은 URL을 검색 할 수 있습니다 . GraphQL API의 경우 대부분의 핑 도구가 HTTP 및 요청 본문을 지원하지 않으므로 쿼리를 URL 매개 변수로 배치하는 것을 지원하지 않는 한 이러한 도구를 활용하지 못할 수 있습니다.

핑 서비스 외에도 API 분석 또는 API 호출에 대한 심층 분석을 지원하는 SaaS 또는 오픈 소스 도구는 거의 없습니다. 클라이언트 오류는 GraphQL API에서 200 OK로 표시됩니다. 400 오류를 예상하는 기존 도구는 작동하지 않으므로 API에서 발생하는 오류를 놓칠 수 있습니다. 그러나 동시에 클라이언트에 제공되는 더 많은 유연성에는 API 문제를 파악하고 이해하는 데 더 많은 도구가 필요합니다.

Moesif는 무엇입니까? Moesif 는 수천 개의 플랫폼에서 쿼리가 수행되는 방식을 측정하고 가장 충성도가 높은 고객이 API로 수행하는 작업을 이해하는 데 사용하는 가장 진보 된 REST 및 GraphQL 분석 플랫폼입니다.

결론

GraphQL API는 흥미로운 신기술이 될 수 있지만 이러한 아키텍처 결정을 내리기 전에 장단점을 이해하는 것이 중요합니다. 엔터티가 매우 적고 분석 API와 같은 엔터티 간의 관계와 같은 일부 API는 GraphQL에 적합하지 않을 수 있습니다. 항목, 사용자, 주문, 결제 등이있는 전자 상거래와 같은 다양한 도메인 개체가있는 애플리케이션은 GraphQL을 훨씬 더 많이 활용할 수 있습니다.

실제로 GraphQL과 REST는 SQL 기술과 noSQL을 비교하는 것과 같습니다. SQL Db에서 복잡한 엔터티를 모델링하는 것이 합당한 특정 애플리케이션이 있습니다. 대용량 채팅 앱이나 유일한 엔티티가 "이벤트"인 분석 API 에서처럼 "메시지"만있는 다른 앱은 Cassandra와 같은 것을 사용하는 것이 더 적합 할 수 있습니다.