<div id="readability-page-1" class="page"><div><h2 id="graphql">GraphQL</h2>
<p>Graph Query Language<br>
GraphQL 은 단하나의 Endpoint 가 존재합니다.<br>
또한 , gql API 에서는 불러오는 데이터의 종류를 쿼리 조합을 통해서 결정합니다.</p>
<p><img src="https://media.vlpt.us/images/bbio3o/post/0a0cdec5-5a85-4076-8a98-2f363a9a63d8/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-06-01%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2012.46.13.jpg"></p>
<p>Endpoint 는 1개만 생성하고 클라이언트에게 필요한 데이터는 클라이언트가 직접 쿼리작성 , 호출하여 반환받습니다.</p>
<h3 id="-장점">✨ 장점</h3>
<ul>
<li>No over/under fetching</li>
<li>Don't have to version an api 버전 신경 쓸 필요 없음<br>
-&gt; 	api.example.com/v1/posts<br>
api.example.com/v2/posts(REST api에서는 이런식으로 버전을 따로 다루었음)<br>
GraphQL을 이용하면 이전 버전을 사용하는 클라이언트에게 영향가지 않고, 새버전 손쉽게 업데이트 가능</li>
<li>It's a type system<br>
-&gt; self documenting, caches silly error, tooling 등을 통해 시간절약 가능</li>
</ul>
<h3 id="-단점">💩 단점</h3>
<ul>
<li>효율적인 데이터 fetch의 복잡성<br>
dataloader 같은 도구의 도움 필요할 수 있음<br>
prisma/hasura/postgraphille/appsync/etc</li>
<li>Harder to cache and rate limit</li>
<li>모니터링 어려움<br>
-&gt; 하나의 endpoint를 가지고 있는 graphql에서는 resolver가 중첩된 형태로 존재하기에 어떤 데이터 쿼리가 가져 오는데 오래걸리는지 등의 모니터링이 어려울 수 있다. Apollo engine, tracing 등을 사용할 수 있지만 성능 문제 있을 수 있음</li>
<li>프론트엔드에서 graphql을 사용함으로써 많은 시간을 줄일 수 있었지만, 백엔드 설정이 어렵다.(백엔드에 능숙하지 않다면 툴의 도움을 받을 수 있다.)</li>
<li>파일 업로드 문제</li>
</ul>
<p><a href="https://tech.kakao.com/2019/08/01/graphql-basic/">출처1</a> <a href="https://owin2828.github.io/devlog/2020/11/12/GraphQL-1.html">출처2</a><br>
<a href="https://www.youtube.com/watch?v=AYZOHt6kz6Y">출처3</a></p>
<p>graphql과 apollo를 통해 flux 아키텍쳐(vuex, redux) 대체가능한가? 작성중..</p></div></div>

Minji.dev

GraphQL
Graph Query Language
GraphQL 은 단하나의 Endpoint 가 존재합니다.
또한 , gql API 에서는 불러오는 데이터의 종류를 쿼리 조합을 통해서 결정합니다.
Endpoint 는 1개만 생성하고 클라이언트에게 필요한 데이터는 클라이언트가 직접 쿼리작성 , 호출하여 반환받습니다.
✨ 장점
No over/under fetching
Don't have to version an api 버전 신경 쓸 필요 없음
api.example.com/v1/posts
   api.example.com/v2/posts(REST api에서는 이런식으로 버전을 따로 다루었음)
   GraphQL을 이용하면 이전 버전을 사용하는 클라이언트에게 영향가지 않고, 새버전 손쉽게 업데이트 가능
It's a type system
self documenting, caches silly error, tooling 등을 통해 시간절약 가능
💩 단점
효율적인 데이터 fetch의 복잡성
dataloader 같은 도구의 도움 필요할 수 있음
prisma/hasura/postgraphille/appsync/etc
Harder to cache and rate limit
모니터링 어려움
하나의 endpoint를 가지고 있는 graphql에서는 resolver가 중첩된 형태로 존재하기에 어떤 데이터 쿼리가 가져 오는데 오래걸리는지 등의 모니터링이 어려울 수 있다. Apollo engine, tracing 등을 사용할 수 있지만 성능 문제 있을 수 있음
프론트엔드에서 graphql을 사용함으로써 많은 시간을 줄일 수 있었지만, 백엔드 설정이 어렵다.(백엔드에 능숙하지 않다면 툴의 도움을 받을 수 있다.)
파일 업로드 문제
출처1 출처2
출처3
graphql과 apollo를 통해 flux 아키텍쳐(vuex, redux) 대체가능한가? 작성중..

GraphQL VS REST (정리중)

댓글