칵테일 믹서에서 GraphQL 회의

REST 및 GraphQL은 웹 사이트 API를 구축하기위한 두 가지 사양입니다. REST는 응용 프로그램이 데이터를 요청하고 보내는 데 사용하는 일련의 고유 식별자 (URL)를 정의합니다. GraphQL 클라이언트 응용 프로그램이 단일 엔드 포인트에서 가져 오는 데 필요한 데이터를 정확하게 지정할 수있는 쿼리 언어를 정의합니다. 그것들은 대략 똑같은 것과 관련된 기술이지만 (실제로, 그들은 종종 공존 할 수 있고 종종 공존 할 수 있지만, 그것들도 매우 다릅니다.

더 흥미로운 방식으로 설명해 봅시다. 이는 더 잘 이해하는 데 도움이되고 GraphQL에 대해 조금 흥분하게 만들 수 있습니다!

? 당신은 칵테일 파티에 있습니다

이 칵테일 파티에 참석하여 전문적인 연결을 확장하므로 자연스럽게 주변 사람들에 대한 데이터를 수집하고 싶습니다. 근처에 5 명의 다른 참석자가있었습니다.

그들의 이름 태그는 다음과 같이 말합니다.

• 풍부한 휴식
• Richy Rest의 친구
• Richy Rest의 고용주
• 조지아 그래프 QL

당신의 활기차고 사회적, 외향적 인 성격으로, 당신은 부유 한 휴식으로 곧장 걸어 가서 "안녕하세요, 나는 당신이 누구입니까?"라고 말했습니다. Richy Rest가 대답했습니다.

 <code>{ name: "Richy REST", age: 33, married: false, hometown: "Circuits-ville", employed: true // ... Richy REST的其他20条信息}</code>

"와우, 정보가 너무 많다"고 스스로 생각했다. 어색한 침묵을 피하기 위해 Richy Rest는 그가 고용되어“어디에서 일하고 있습니까?”라고 물었다는 것을 기억합니다.

이상하게도, 풍부한 휴식은 그가 어디에서 일하는지 모릅니다. Richy Rest의 고용주가 알고 있습니까?

당신은 풍부한 휴식 고용주에게 같은 질문을했고 그는 당신의 문의에 기꺼이 답변하게 될 것입니다! 그는 이런 식으로 대답했습니다.

 <code>{ company: "Mega Corp", employee_count: 11230, head_quarters: "1 Main Avenue, Big City, 10001, PL" year_founded: 2005, revenue: 100000000, // ... Richy REST雇主的其他20条信息}</code>

현재, 당신은 지쳤습니다. 당신은 Richy Rest의 친구들을 만나고 싶지도 않습니다! 오랜 시간이 걸리고 모든 에너지를 배수 할 수 있으며 시간이 없습니다.

그러나 Georgia GraphQL은 정중하게 거기에 서 있었으므로 그녀와 의사 소통하기로 결정했습니다.

"안녕하세요, 당신의 이름은 무엇입니까?"

 <code>{ name: "Georgia GraphQL" }</code>

"어디서 왔니, 몇 살입니까?"*

 <code>{ hometown: "Pleasant-Ville", age: 28 }</code>

"취미와 친구가 몇 명입니까? 친구의 이름은 무엇입니까?"

 <code>{ hobbies_count: 12, friends_count: 50, friends: [ { name: "Steve" }, { name: "Anjalla" }, // ...等等] }</code>

Georgia GraphQL은 훌륭하고 명확하며 간결하며 요점입니다. 당신은 그녀와 명함을 교환하고 향후 프로젝트에서 그녀와 함께 일하고 싶습니다.

이 이야기는 REST 대신 GraphQL을 사용하여 개발자의 경험을 요약합니다. GraphQL을 사용하면 개발자가 간결한 쿼리로 자신의 요구를 표현하고 지정한 컨텐츠 만 수신 할 수 있습니다. 이 쿼리는 완전히 동적이므로 하나의 엔드 포인트 만 필요합니다. 반면에 REST는 사전 정의 된 응답을 가지고 있으며 종종 응용 프로그램이 여러 데이터 요구 사항을 충족시키기 위해 여러 엔드 포인트를 사용하도록 요구합니다.

은유가 끝납니다! 핵심 요점에 대해 이야기합시다.

칵테일 파티 은유에서 제안 된 기본 개념에 대해 더 자세히 설명하려면 REST를 사용할 때 종종 나타나는 두 가지 한계에 대해 자세히 논의하겠습니다.

1. 관련 리소스를 얻을 때는 여러 요청이 필요합니다

데이터 중심의 모바일 및 웹 애플리케이션에는 종종 관련 리소스 및 데이터 세트가 필요합니다. 따라서 REST API를 사용하여 데이터를 검색하려면 여러 엔드 포인트에 여러 요청이 필요할 수 있습니다. 예를 들어, 우체국 및 관련 저자를 요청하는 것은 다른 엔드 포인트에 두 가지 요청을 발행해야 할 수도 있습니다.

 <code>someServer.com/authors/:id someServer.com/posts/:id</code>

API에 대한 다중 액세스는 응용 프로그램의 성능 및 가용성에 영향을 줄 수 있습니다. 이것은 또한 저 대역폭 장치 (예 : 스마트 워치, 사물 인터넷, 오래된 모바일 장치 등)의 더 중요한 문제입니다.

2. 과잉 획득 및 불충분 한 데이터 수집

RESTFUL API를 사용할 때 과도한 데이터 수집 및 불충분 한 데이터 수집이 불가피합니다. 위의 예제를 사용하여 endpoint domainname.com/posts/:id는 특정 게시물의 데이터를 가져옵니다. 각 게시물은 ID, Body, Title, PublishingDate, AuthorID 등과 같은 속성으로 구성됩니다. REST에서는 동일한 데이터 객체가 항상 반환됩니다. 응답이 사전 정의되었습니다.

게시물 제목과 신체 만 필요한 경우 데이터가 너무 많이 사용되는 것보다 더 많은 데이터가 네트워크로 전송되기 때문에 데이터의 과도한 수치가 발생합니다. 전체 게시물 및 저자와 관련된 데이터가 필요할 때, 데이터 수집이 충분하지 않아 실제로 사용되는 것보다 네트워크로 전송되기 때문입니다. 데이터 수집이 부족하면 API에 대한 여러 요청으로 인해 과도한 대역폭 사용이 발생할 수 있습니다.

GraphQL을 사용한 클라이언트 쿼리

GraphQL은 클라이언트 애플리케이션에 유연성을 제공하는 진정한 독특한 접근 방식을 소개합니다. GraphQL을 사용하면 쿼리가 API로 전송되며 요청에 필요한 것만으로도 반환합니다. 쿼리 결과는 쿼리와 동일한 모양으로 반환되므로 응답 구조가 항상 예측 가능합니다. 이러한 요소를 사용하면 응용 프로그램이 서버가 아닌 데이터를 제어 할 수 있기 때문에 응용 프로그램이 더 빠르고 안정적으로 실행될 수 있습니다.

"결과는 쿼리와 같은 모양으로 반환됩니다."

 <code>/* 查询*/ { myFriends(first: 2) { items { name age } } }</code>

 <code>/* 响应*/ { "data": { "items": [ { "name": "Steve", "age": 27 }, { "name": "Kelly", "age": 31 } ] } }</code>

현실 테스트 ✅

이제 GraphQL이 사무라이 나이프로 뜨거운 버터를 자르는 것만 큼 쉽다고 생각할 수 있습니다. 프론트 엔드 개발자의 경우, 이는 현실 일 수 있습니다. 특히 GraphQL API를 사용하는 사람들. 그러나 서버 측 설정과 관련하여 누군가는 소시지를 만들어야합니다. 우리의 친구 Georgia GraphQL은 그녀가 지금 탁월한 전문가가되기 위해 많은 노력을 기울였습니다!

GraphQL API (서버 측)를 구축하려면 시간, 노력 및 전문 지식이 필요합니다. 즉, 도전에 직면 할 준비가 된 사람들을 위해 처리 할 수없는 것은 아닙니다! 모든 수준의 추상화에 참여하는 방법에는 여러 가지가 있습니다. 예를 들어:

• 헬퍼 없음 : 실제로 직접하고 싶다면 소프트웨어 패키지를 사용하여 GraphQL API를 구축 할 수 있습니다. 예를 들어, 레일처럼? GraphQL-Ruby를 확인하십시오. node.js처럼? Express-GraphQL을 시도하십시오.
• 어시스턴트 : 서버/자체 호스팅을 완전히 유지하는 것이 우선 순위 인 경우 그래프와 같은 것이 GraphQL 프로젝트를 시작하는 데 도움이 될 수 있습니다.
• 즉석 : Crud Boilerplate Code 작성에 지친 피곤, 신속하게 시작하고 싶습니까? 8Base는 즉각적인 GraphQL API 및 Serverless 백엔드를 제공하며, 이는 완전히 확장 가능합니다.

요약

REST는 고도로 사용 가능한 리소스 관련 API를 가능하게하여 웹 서비스에 큰 진전을 가져 왔습니다. 즉, 오늘날의 상호 연결된 장치의 급증을 고려하지 않고 설계되었으며,이 모든 데이터 제한 사항과 요구 사항이 다릅니다. 이 감독은 빠르게 프론트 엔드 개발자에게 유연성을 제공하기 때문에 GraphQL (2015 년 Facebook의 오픈 소스)의 인기를 빠르게 만들었습니다. GraphQL을 사용하는 것은 개별 개발자와 팀 모두에게 훌륭한 개발 경험입니다.

위 내용은 칵테일 믹서에서 GraphQL 회의의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!