GraphQL은 어떻게 탄생했나요?
개발자로서 우리는 때때로 기술의 단순한 목적을 이해해야 할 필요가 있습니다. 그러면 스스로 배우고 코딩할 수 있습니다. 그래서 저는 GraphQL에 대한 저의 이해를 공유하기 위해 이 기사를 작성했습니다. 이 기사는 GraphQL을 시작하는 데 도움이 될 것입니다.
GraphQL이 실제로 무엇인지 제대로 이해하기 위해 이 기사를 두 부분으로 나눕니다.
REST의 문제
1. REST의 하드 코딩된 정적 구조
모든 국가의 이름이 필요하다고 가정해 보겠습니다. API를 http://yourserver../countries에 요청하면 응답이 제공되며 응답은 다음과 같습니다.
[
{
"name": "Afghanistan",
"topLevelDomain": [
".af"
],
"alpha2Code": "AF",
"alpha3Code": "AFG",
"callingCodes": [
"93"
],
"capital": "Kabul",
"altSpellings": [
"AF",
"Afġānistān"
],
"region": "Asia",
"subregion": "Southern Asia",
"population": 27657145,
"latlng": [
33.0,
65.0
],
"demonym": "Afghan",
"area": 652230.0,
"gini": 27.8,
"timezones": [
"UTC+04:30"
],
"borders": [
"IRN",
"PAK",
"TKM",
"UZB",
"TJK",
"CHN"
],
"nativeName": "افغانستان",
"numericCode": "004",
"currencies": [
{
"code": "AFN",
"name": "Afghan afghani",
"symbol": "؋"
}
],
"languages": [
{
"iso639_1": "ps",
"iso639_2": "pus",
"name": "Pashto",
"nativeName": "پښتو"
},
{
"iso639_1": "uz",
"iso639_2": "uzb",
"name": "Uzbek",
"nativeName": "Oʻzbek"
},
{
"iso639_1": "tk",
"iso639_2": "tuk",
"name": "Turkmen",
"nativeName": "Türkmen"
}
],
"translations": {
"de": "Afghanistan",
"es": "Afganistán",
"fr": "Afghanistan",
"ja": "アフガニスタン",
"it": "Afghanistan",
"br": "Afeganistão",
"pt": "Afeganistão",
"nl": "Afghanistan",
"hr": "Afganistan",
"fa": "افغانستان"
},
"flag": "https://restcountries.eu/data/afg.svg",
"regionalBlocs": [
{
"acronym": "SAARC",
"name": "South Asian Association for Regional Cooperation",
"otherAcronyms": [],
"otherNames": []
}
],
"cioc": "AFG"
},
.
.
.
So you want to fetch just name and you're getting other fields for free!
Actually it's not free and that is the second problem of REST.
그래서 여러분 중 일부는 우리 프로젝트에서 필요한 경우 유일한 이름을 가져오기 위해 다른 API가 있어야 한다고 말합니다. 저는 확실히 그렇게 할 수 있다고 말합니다. 하지만 우리가 해야 할까요?
중간 규모에서 대규모 프로젝트에 대해 몇 개의 API를 만들어야 합니까?
실현 불가능, 그렇지?
2. 성능
따라서 위의 국가 가져오기 예에서 UI에 표시되지 않는 추가 데이터를 얻고 있다고 생각할 것입니다. 음, 다음과 같은 몇 가지 문제가 발생합니다.
3. 여러 API 호출
REST에서는 UI에 구조를 구축하기 위해 많은 API 호출을 수행해야 합니다. 예를 들어, 학생의 결과 관련 데이터를 테이블에 표시하려면 먼저 학생을 가져와야 합니다. 그런 다음 각 학생에 대해 결과를 가져오기 위해 API 호출을 수행해야 합니다. 따라서 100명의 학생에 대해 101개의 API 호출이 있습니다. 그리고 실질적으로 API 호출 오버헤드가 증가하고 성능도 저하됩니다.
해결책
그래서 위에서 언급한 문제들이 GraphQL을 탄생시켰습니다.
이를 통해 위에서 논의한 문제를 어떻게 해결할 수 있는지 봅시다.
GraphQL에서는 모든 것에 대해 POST 요청을 해야 하고 POST 메서드 본문에 원하는 필드 이름을 언급해야 백엔드가 해당 필드에 대해서만 계산을 처리하고 수행하고 응답을 다시 보낼 수 있습니다.
국가의 예
the size of country data with every field is 254.69KB
the size of country data with the only name is 3.53KB
따라서 브라우저의 일부 공간을 절약하고 다운로드 시간도 단축됩니다.
따라서 기본적으로 GraphQL은 HTTP 요청-응답을 동적이고 유연하게 만듭니다. 마법이 아니라 백엔드 API도 구성해야 하지만 REST의 기존 문제를 해결하는 멋진 개념/아키텍처입니다.
Reference
이 문제에 관하여(GraphQL은 어떻게 탄생했나요?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/maulik/how-is-graphql-born-2i7g텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
