GraphQL이 API의 미래인 이유

6581 단어 graphqlapis

웹이 탄생한 이래로 API 개발은 개발자들의 어려운 임무였다.우리가 API를 개발하는 방식은 반드시 시간의 추이에 따라 발전해야 한다. 이렇게 하면 우리는 시종 양호하고 직관적이며 디자인이 좋은 API를 구축할 수 있다.
지난 몇 년 동안 GraphQL은 개발자들 사이에서 갈수록 유행했고 많은 회사들이 이미 이런 기술을 이용하여 그들의 API를 구축하기 시작했다.GraphQL은 페이스북이 2012년 개발한 조회 언어로 2015년 공개 발표했다.그것은 이미 매우 큰 매력을 얻었고, 많은 대기업에 의해 채택되었다. 예를 들어 Spotify, 페이스북, GitHub, NYTimes, 넷플릭스, 월마트 등이다.
이 시리즈 강좌에서 우리는 GraphQL을 연구하여 그것이 무엇인지, 그리고 어떤 특성이 이 이 조회 언어를 이렇게 직관적이고 사용하기 쉽게 하는지 이해할 것이다.
그러면 REST의 문제점과 GraphQL이 이 문제를 어떻게 해결하는지 연구해 봅시다.GraphQL을 사용하여 API를 구축해 온 이유와 API의 미래가 무엇인지 알아보겠습니다.

읊다, 읊조리다


오래전, 우리가 API 설계를 SOAP에서 REST로 변경했을 때, 우리는 이것이 개발자들이 업무 중에 더욱 큰 유연성을 가지게 할 것이라고 생각했다.우리는 이것이 한동안 효과가 좋았고, 당시에는 매우 좋은 행동이었다는 것을 부인할 수 없다.응용 프로그램과 웹이 갈수록 복잡해지면서 API도 이러한 변화에 따라 자연스럽게 변화한다.
하지만 REST에는 문제가 많습니다.그것들이 무엇인지 봅시다.

많은 노드


REST의 각 리소스는 하나의 끝점으로 표시됩니다.따라서 실제 응용 프로그램에서 우리는 최종적으로 대량의 자원의 단점을 가지게 될 것이다.GET 요청을 보내려면 요청의 끝점과 특정 매개변수가 있어야 합니다.POST 요청을 보내려면 해당 요청에 대한 다른 끝점만 제공해야 합니다.

그런데 이게 무슨 문제야?페이스북과 같은 거대한 소셜 미디어 앱을 구축하고 있다고 상상해 보자.우리는 결국 많은 단점이 있을 것이다. 이것은 개발자가 이 API를 개발하고 유지하는 데 더 많은 시간을 들일 것을 의미한다.

정보의 과도한 추출과 부족한 추출


많은 개발자들을 괴롭히는 진정한 문제는 RESTAPI를 통해 과도하게 정보를 얻고 부족한 것을 얻는 것이다.RESTAPI가 항상 고정된 구조를 반환하기 때문입니다.우리가 이 때문에 특정한 단점을 만들지 않으면 필요한 데이터를 정확하게 얻을 수 없습니다.
따라서 만약 우리가 일부분의 데이터만 필요로 한다면, 우리는 반드시 전체 대상을 처리해야 한다.예를 들어 REST API에서 사용자의 firstName, lastName, age만 가져오면 전체 대상을 가져오지 않는 상황에서 이 데이터를 정확하게 얻을 수 없습니다.

또 하나의 문제는 정보 획득이 부족하다는 것이다.만약 우리가 두 개의 서로 다른 자원에서 데이터를 얻고 싶다면, 우리는 두 개의 서로 다른 단점에 대해 서로 다른 호출을 해야 한다.거대한 응용 프로그램에서, 이것은 결코 잘 확장될 수 없다. 왜냐하면 어떤 경우, 우리는 특정한 데이터를 얻을 수 있을 뿐, 전체 대상을 얻을 필요가 없기 때문이다.현재, 우리가 100개의 단점이 있는 응용 프로그램을 구축하고 있다고 가정해 보세요.우리가 작성해야 할 작업량과 코드를 상상해 보세요.시간의 추이에 따라 이것은 더욱 어려워질 것이다.코드도 유지하기 어려워져 개발자들이 이 과정에서 잃어버렸다.

버전 제어


내가 보기에 REST에서 가장 고통스러운 점은 버전 제어이다.RESTAPI의 경우 v1 또는 v2를 사용하는 API를 많이 볼 수 있지만 새 유형을 추가하거나 이전 유형을 삭제하여 API를 개선할 수 있기 때문에 GraphQL에서는 필요하지 않습니다.
GraphQL에서 API 개발에 필요한 것은 새 코드를 작성하는 것입니다.다른 버전의 API를 제공하지 않고 새 유형, 조회 및 변형을 작성할 수 있습니다.
따라서 다음 끝점이 있는 GraphQL API는 표시되지 않습니다.
https://example.com/api/v1/users/12312
https://example.com/api/v2/users/12312

왜 GraphQL이 미래인지


2012년 페이스북이 모바일 앱을 개발할 때 문제가 생겨 그래프QL을 만들었다.특히 RESTful API 설계에 대해 이야기할 때 이러한 문제가 자주 발생합니다.앞에서 설명한 바와 같이 다음과 같은 질문이 있습니다.
  • 성능차
  • 많은 노드
  • 데이터의 과도한 추출 또는 부족 추출
  • 은 일부 내용을 포함하거나 삭제해야 할 때마다 다른 버전
  • 을 제공합니다
  • API 이해의 어려움
  • Facebook 개발자는 많은 개념을 고려하여 더 좋은 API 디자인 방법을 개발하여 나중에 이를 GraphQL이라고 명명했다.기본적으로 그것은 REST의 대체품으로 많은 개선이 있다.
    GraphQL을 통해 우리는 API를 구축할 때 강력한 기능을 제공하는 새로운 기능을 많이 얻었습니다.하나씩 확인해 보겠습니다.

    단일 노드


    많은 단점을 구축할 필요가 없다!GraphQL을 사용하면 하나의 단점만 얻을 수 있습니다. 이 단점을 통해 우리는 단일 요청에서 우리가 원하는 임의의 데이터를 얻을 수 있습니다.기본적으로 GraphQL은 모든 조회, 돌연변이, 구독을 하나의 노드에 봉인하여 사용할 수 있도록 합니다.그것은 두 개의 다른 자원에서 데이터를 얻을 수 있도록 두 개의 요청을 할 필요가 없기 때문에 당신의 개발 주기를 개선시켰다.그 밖에 만약에 우리가 거대한 응용 프로그램을 구축하고 있다고 가정하면 REST처럼 많은 단점과 대량의 코드를 얻지 못할 것이다.우리는 하나의 단점을 얻을 것이다. 이 단점이 있으면, 우리는 우리가 원하는 임의의 여러 가지 요구를 할 수 있다.

    또한 위에서 말한 바와 같이 "단지"방법은 당신의 API를 문서화할 수 있습니다. 왜냐하면 당신은 문서를 구축할 필요가 없기 때문입니다. 왜냐하면 개발자가 그것을 어떻게 사용하는지 알고 있기 때문입니다.그들은 코드나 운동장을 보면서 API를 이해할 수 있다.잠시 후에 우리는 더 많은 정보를 알게 될 것이다. (이 시리즈의 다음 강좌)신기해 보이지만 그래프QL일 뿐이야!

    GraphQL을 사용하면 필요한 데이터만 얻을 수 있습니다.


    더 이상 과도하게 정보를 얻거나 얻지 못합니다.필요한 데이터만 가져옵니다.우리가 처음에 토론한 성능 불량 문제를 기억하십니까?GraphQL은 API의 성능을 향상시켰기 때문에 특히 네트워크 연결 속도가 느린 상황에서 우리는 더 이상 이런 기능을 하지 않는다.

    GraphQL을 통해 API 구축을 간편하게 시작하고 일관성 유지


    많은 사람들이 GraphQL이 하나의 패턴과 단점에 관련되기 때문에 상당히 복잡하다고 생각한다.일단 그것으로 API를 개발하기 시작하면, 생각보다 쉽다는 것을 알게 될 것이다.웹 사이트/애플리케이션을 개발할 때 엔드포인트만 API가 유용합니다.이를 통해 API를 문서화할 수 있으므로 해당 API에 대한 많은 문서를 작성할 필요가 없습니다.
    JavaScript를 주 언어로 사용하지 않으면 문제가 되지 않습니다. GraphQL은 알 수 없는 검색 언어이기 때문에 모든 언어에 사용할 수 있습니다.이 강좌를 작성할 때 GraphQL은 12개 이상의 언어를 지원합니다.

    GraphQL은 미래입니다.


    GraphQL은 개원 조회 언어로 지역사회가 이에 기여하고 개선할 수 있음을 의미한다.페이스북이 이를 커뮤니티에 발표했을 때 개발자들의 큰 지지와 인정을 받았다.현재 점점 더 많은 개발자들이 GraphQL을 사용하여 API를 구축하기 시작하면서 GraphQL은 줄곧 빠르게 증가하고 있다.그러나 일부 사람들은 이것이 정말 REST를 대체하거나 실제 응용 프로그램을 위한 API를 구축하는 새로운 방법이 될 수 있는지 계속 묻고 있다.

    처음에 나는 GraphQL이 단지 투기일 뿐이고 API를 만드는 또 다른 방식이라고 생각했다.그러나 내가 그것을 연구하기 시작했을 때, 나는 GraphQL이 현대 응용 프로그램을 위해 현대 API를 만드는 데 필요한 기본적인 특성을 가지고 있다는 것을 발견했다. 왜냐하면 이것은 현대 창고와 잘 어울려 사용할 수 있기 때문이다.
    만약 내가 지금 당신들에게 알려줄 수 있는 것은: 네, GraphQL은 정말 API의 미래입니다.이것이 바로 대기업이 여기에 돈을 거는 원인이다.
    2018년 11월에 GraphQL은 Linux 기금회와 합작하여 GraphQL 기금회를 창설했다. 이것은 이 조회 언어가 개발자들이 이 언어를 위해 더 많은 문서, 도구와 지원을 구축하도록 장려하고 있음을 의미한다.이 기초는 GraphQL이 안정적이고 중립적이며 지속가능한 미래를 보장할 것이다.따라서 이것은 GraphQL을 API의 미래로 보는 또 다른 이유입니다.
    물론 REST를 바로 대체하지는 않을 것이다. 왜냐하면 많은 응용 프로그램이 여전히 그것을 사용하고 있기 때문에 하룻밤 사이에 그것을 다시 쓸 수 없기 때문이다.점점 더 많은 회사들이 GraphQL을 채택함에 따라 UX와 DX는 모두 개선될 것이다.

    결론


    GraphQL은 사실상 API의 미래입니다. 더 많은 것을 알아야 합니다.이것이 바로 내가 4개의 강좌로 구성된 시리즈를 만들어서 가장 좋은 GraphQL을 어떻게 사용하는지 보여주고 조회와 돌변부터 시작하며 구독과 신분 검증을 하기로 결정한 이유이다.
    이 글은 최초로 Hashnode에 발표되었다.만약 네가 이 문장을 좋아한다면, 거기에서 읽을 수도 있다. 그러면 너는 나를 지지하고, 내가 더 많은 문장을 쓰는 것을 도울 수 있다.You can read it here!

    좋은 웹페이지 즐겨찾기