brunch

You can make anything
by writing

C.S.Lewis

by 에디의 기술블로그 Mar 21. 2021

Netflix GraphQL OpenSource

넷플릭스 GraphQL 오픈소스 라이브러리 검토

Netflix(이하 넷플릭스)의 GraphQL 오픈소스에 대해서 검토 후 공유합니다. 이 글은, 매우 재미없고 지루한 글이니깐, 각자 필요한 내용만 골라서 읽으시면 됩니다. 넷플릭스의 GraphQL 라이브러리에 대해서는 이 글의 3장부터 상세하게 설명하니, GraphQL 기본 개념을 알고 있는 개발자는 3장부터 읽으시면 됩니다. 


필자는, 해당 라이브러리를 실무에서 사용한 경험이 없습니다. 

잘못된 내용은 댓글로 제보 부탁드립니다.


OverView

넷플릭스에서 GraphQL 라이브러리를 오픈소스로 공개하였다. 이 글에서는, 넷플릭스의 GraphQL 오픈소스에 대해서 간략하게 설명한다. 


해당 글을 읽기 적합한 개발자는 아래와 같다.

- 스프링부트 백엔드 API 개발자

- Rest API 의 단점을 보완하기 위한 방법을 찾는 개발자

- GraphQL에 대해서 한번이라도 들어본 경험이 있는 개발자

- 그냥 심심한 개발자


해당 글을 읽기 적합하지 않은 개발자는 아래와 같다. 

스프링부트에 대해서 전혀 모르는 개발자 예) Node.js 서버 개발자, 프론트엔드 개발자, 퍼블리셔 등

- GraphQL 에 대해서 전혀 들어본적도 없고, 앞으로도 관심 없을 예정인 개발자 

 

[필자의 개인적인 의견]

2년 전에 회사 업무로 GraphQL 기술검토를 잠시 했었다. 당시 시스템에 도입하진 못했고, 그 이후 언젠가는 실무에서 GraphQL 을 사용하게 될 것이라 생각을 했었는데... 막상 그동안 전혀 사용할 기회가 없었다. 솔직히 앞으로도 당장 도입음 못할 것 같다현재 실무에서 서비스 중인 Rest API 를 굳이 GraphQL 로 바꿔야하는 필요성을 느끼진 못했다. 신규 프로젝트에서 업무 비즈니스 요구사항을 검토 후 Rest API, GraphQL 의 장단점을 비교한 후 신중하게 선택하면 될 것같다. 


2년 전에 필자가 작성했던 GraphQL 관련 글은 참고만 해주길 바란다. 

https://brunch.co.kr/@springboot/191



1. GraphQL 기본 개념 이해


GraphQL 은 페이스북에서 개발하여 발표한 "API를 위한 퀴리 언어"이다. GraphQL 은 매우 직관적이며, 클라이언트에서 필요한 정보를 정확하게 요청할 수 있는 기능을 제공한다. 자세한 내용은 아래 링크를 읽어보자. 

https://graphql-kr.github.io/


GraphQL 구현하기 위해서는 아래와 같은 작업을 수행해야 한다.


- 스키마 정의

- 요청

- 응답


이해하기 쉽게 표현하면 아래와 같다.


1. 스키마 정의 : 데이터를 표현하세요

2. 요청 : 클라이언트가 원하는 것을 정확하게 요청하세요

3. 응답 : 예측 가능한 결과를 얻으세요




1. 데이터를 표현하세요!

데이터를 표현하기 위해서 스키마를 정의한다. "커피"를 표현하기 위해서 type Coffee를 정의하였다. 




2. 원하는 것을 요청하세요.

GraphQL API를 호출할 때 원하는 것에 대해서 선택해서 요청할 수 있다. "커피" 중에서 "mocha"라는 이름의 커피를 찾고, 응답 값으로는 커피의 이름과 가격의 정보를 받고 싶다면...? 


아래와 같이 원하는 데이터를 명시적으로 요청할 수 있다. 




3. 예측 가능한 결과를 얻으세요. 

클라이언트에서 서버에 원하는 것을 요청한 후, 서버에서는 요청에 대해서 데이터를 응답한다. 클라이언트는 예측 가능한 결과를 얻게 될 것이다. "커피" 중에서 "mocha"라는 이름의 커피를 찾아서, 커피의 이름과 가격의 결과를 응답 받을 수 있다, 


스키마 정의(데이터를 표현하는)에서, Coffee는 "모카", "라테", "아메리카노"와 같은 이름 외에도 id, 가격 등 필요한 필드를 정의할 수 있다. 


또한 interface 를 사용할 수 있다. Human이라는 인터페이스의 구현체인 Barista 타입을 정의해보자. 


Enum을 사용할 수도 있다. 자세한 내용은 생략한다. 공식 github을 참고하길 바란다.

https://github.com/graphql/graphql-spec


혹시, 필자의 글이 이해가 잘 되는가? 아마 잘 안될 것이다. 



GraphQL 관련 자료를 먼저 읽어보고 다시 돌아오길 바란다.



2. GraphQL 경험해보기 : Github API


GraphQL 에 대해서 잘 아는 개발자는 해당 내용은 패스하길 바란다. 중요한 내용은 아니다. 


Github 에서는 GraphQL 기반의 오픈 API 를 제공한다. 

https://docs.github.com/en/graphql/overview/explorer

좌측에 Query 를 작성하면, Github Open API 를 호출할 수 있다. 필자는 깃헙 Repository 를 검색하기 위한 쿼리를 요청하였다, 

필자의 github 저장소 중에서, graphql-gds-sample 이라는 이름의 Repository 를 검색하였다. 해당 쿼리에 대한 스키마는 아래와 같이 정의가 되어있다. 


type : repository

arguments : name, owner



Github 에서 제공하는 UI 는 이미 사용자 인증이 완료된 상태에서 호출하는 기능이다. 만약,Postman 에서 테스트해보고 싶으면 어떻게 하면 될까? 토큰 정보를 생성한 후, 해당 토큰을 헤더에 포험해서 호출하면 된다. 



Access 토큰 을 생성하는 방법에 대해서 설명한다. 

1)

2)

3)

4)

5)


Access 토큰을 발급 받을 수 있다. Postman 에서 토큰 정보를 헤더에 담아서 요청해보자. 


위와 같이 필요한 데이터를 쿼리로 요청하면 된다. 

중요한 사실은.. Github GraphQL 엔드포인트는 동일하다는 점이다. 


api.github.com/graphql


참고자료

https://docs.github.com/en/graphql/guides/forming-calls-with-graphql



3. Netflix GraphQL 사용(1) - 기본


넷플릭스에서는 2019년 부터 다수의 팀에서 GraphQL 라이브러리를 사용하였다. 다수의 팀에서 1년 반 이상 프레임워크를 사용하면서, 안정적인 라이브러리로 발전하였고, 결국 2020년 연말에 넷플릭스는 오픈소스로 공개하기로 결정하였다. 


넷플릭스 GraphQL 오픈소스는 스프링부트 애플리케이션에서 사용할 수 있도록 설계가 되었다. 


https://netflix.github.io/dgs/


넷플릭스의 GraphQL 사용 경험에 대해서는 아래 링크를 읽어보자.

https://netflixtechblog.com/our-learnings-from-adopting-graphql-f099de39ae5f


샘플 코드를 작성하면서, 상세하게 알아보도록 하자. 필자의 샘플 코드에서는, 인물 검색 기능을 구현한다. 필자의 허접한 샘플 코드는 아래 github 에서...

https://github.com/sieunkr/graphql-gds-sample


넷플릭스 GraphQL 라이브러리를 사용하기 위해서 의존성을 추가해준다. 


참고로, spring-boot-starter-web 의존성은 필요없다. spring-boot-starter 의존성만 있어도 된다.


가장 먼저 해야하는 중요한 작업은 바로 스키마를 정의하는 작업이다. 

스키마 파일은 resources/schema/schema.graphqls 로 생성해야 한다.


아래와 같이 스키마를 작성한다. 

Query 타입의 singers 필드는 전체 가수를 검색하는 기능이다. name 이 없으면 전체 가수를 검색하며, name 을 지정하면 이름으로 필터링해서 검색한다. singersBySameAge 는 특정 가수와 나이가 같은 가수를 검색하는 기능이다. 


Singer 타입에는 name(이름), age(나이), gender(성별)을 정의하였다. 클라이언트에서 이름, 나이, 성별 등 모든 데이터를 원한다면 모든 데이터 전부를 응답 받을 수 있다. 하지만, 필요한 데이터만 선택해서 요청할 수 있다. 이름과 나이만 응답받고 싶다면 아래와 같이 gender 를 포함하지 않고, name, age 만 정의해서 쿼리를 요청하면 된다. 


만약에

"아이유" 라는 이름으로 검색하며, 나이, 이름, 성별 등 모든 데이터를 응답받고 싶다면... 

아래와 같이 요청하면 된다. 이때 호출하는 URL(엔드포인트) 는 변함이 없다. 

정리하면, 중요한 사실은 아래와 같다. 


- 호출하는 URL (엔드포인트) 는 동일하다. localhost:8080/graphql 이다. 

- 클라이언트는 원하는 데이터를 선택해서 받을 수 있다. 






잠시, Rest API 에 대해서 생각해보자. 사실, 단순 인물 검색 기능은 Rest API 로 충분히 구현할 수 있다. 심플한 데이터 통신이라면, 굳이 GraphQL을 사용할 필요가 없다. 아래와 같이 Rest API 로 구현할 수 있다. 

각각의 요청에 대해서, 응답은 아래와 같다. 

전체 가수 조회는 아래와 같다. localhost:8080/api/v1/singers

특정 가수 조회는 아래와 같다. localhost:8080/api/v1/singers/가수이름


이 정도 요청은 Rest API 로 개발해도 충분하다. 


하지만, 아래와 같은 요구사항은 어떻게 구현해야할까? 


"아이유 와 동갑(같은 나이)의 가수를 모두 검색해주세요" 

"아이유 와 같은 소속사 가수를 모두 검색해주세요" 

"아이유가 주인공인 영화에 함께 출연한 가수를 검색해주세요"



위와 같이 복잡한 요구사항에 대해서, Rest API로 모든 엔드포인트를 제공하는 것은, 시간이 지날수록 복잡해지고, 운영하기 어려워진다. 이런 경우에 GraphQL 을 사용하게 되면, Rest API 에 비교해서, 운영하기 심플한 백엔드 API 를 구축할 수 있다. 


(사실, 모든 기술에는 장단점이 있다...)


또한, 중요한 사실은... GraphQL 은 원하는 데이터만 선택해서 받을 수 있기 때문에, B to B, 또는 프론트엔드-백엔드 연동 시 개발 생산성이 Rest API 에 비교해서 상대적으로 좋은 편이다. Rest API 는 응답 데이터 스펙이 항상 고정되어있다. 즉, 원하는 데이터만 응답 받도록 Rest API 로 구현하는것이 쉽지 않다. 

위와 같은 장점으로 인해서, GraphQL 은 서비스 확장 시에도 큰 장점을 갖는다. Rest API 는 응답 데이터가 정해져있기 때문에, 필드 추가 시 무중단 배포가 어려울 수 있다. 물론, 버저닝을 사용해서 API 를 확장하면.. .예를 들어서 api/v1/singers, api/v2/singers 와 같이 확장하면, 클라이언트 측에서 API 를 선택해서 호출하면 되기 때문에, 무중단 서비스 전환이 가능할 수는 있겠지만... 

암튼, GraphQL 의 경우에는, 백엔드 서버에서 필요한 필드를 추가해도, 클라이언트에서는 여전히 기존 쿼리를 그대로 사용하기 때문에, 전혀 영향을 주지 않는다. 클라이언트에서 필요한 필드를 쿼리에 추가해서 요청하면 되기 때문에, 백엔드와 프론트엔드 사이에 개발 생산성이 Rest API 에 비교해서 더 좋을수밖에 없다. 더 이상의 자세한 내용은 생략하겠다..




아무튼, 마무리로...Rest API 와 graphQL 그림으로 표현하면 아래와 같다. 

https://medium.com/@akh.rasika.priyadarshani/graphql-vs-rest-eec88d282617

Rest API 는 각각의 엔드포인트를 전부 정의해야 하지만, GraphQL 은 단 하나의 엔드포인트를 통해서 데이터를 통신한다. 


해당 방식의 또다른 장점은 네트워크 통신 비용의 절감이다. 클라이언트에서는 단 한번의 요청으로 필요한 데이터만 응답받을 수 있기 때문에, 네트워크 통신 비용이 효과적이다. 반면에, Rest API 를 사용하면 불필요한 필드를 통신하게 될 수도 있고, 2회 이상 HTTP 통신을 해야할 수도 있다. 


다양한 관점에서 검토해보면, GraphQL 이 Rest API 에 비교해서 장점이 있다는 것은 사실이다. 그럼에도 불구하고 기존 Rest API 를 전부 GraphQL 로 변경해야 한다는 필요성은 아직은 느끼지 못하고 있다. Rest API 역시 장점이 크다고 생각한다. 선택은 각자 알아서... 이정도로 마무리하고 다시.. 넷플릭스의 GraphQL 에 대한 애기로 넘어가겠다.




 


"아이유 와 동갑(같은 나이)의 가수를 모두 검색해주세요"  

최종적으로는 아래와 같이 요청한다. 

스키마 파일을 다시 보자. 제일 중요하다. 반드시 스키마 작성 규약에 맞게 정의해야 한다. 

참고로 [Singer] 는 가수 객체의 리스트를 의미한다. 그리고, Gender 는 Enum 타입으로 정의하였다. 


애플리케이션에서 사용할 Singer 타입 클래스는 아래와 같이 정의하였다. 


추가로, 성별에 대한 ENUM 코드는 아래와 같이 정의를 하였다. 

이제 드디어, 엔드포인트를 정의해보자. RestAPI 개발 방식과는 전혀 다르다. 넷플릭스 GraphQL 라이브러리에서 제공하는 어노테이션을 사용해야 한다. 


- @DgsComponent

- @DgsData


@DgsData(parentType="Query", field = "singers") 는 아래 요청에 매핑된다. 


@DgsData(parentType = "Query", field = "singersBySameAge") 는 아래 요청에 매핑된다. 




참고로, 필자의 샘플 코드에서는 타입을 정의하는 Singer 클래스를 직접 작성하였다. 넷플릭스에서는 애플리케이션에서 사용하는 타입 클래스를 자동으로 생성해주는 기능을 제공한다. QueryDSL 의 Q클래스 생성과 비슷한 개념이라 생각해도 될것 같다. 암튼, 해당 내용에 대해서는 글 후반에 다시 설명하겠다.


이게 끝이다. 

위와 같이 개발하면, GraphQL API 를 심플하게 구축할 수 있다. 너무 간단하다.



4. Netflix GraphQL 사용(2) - 중급


가수 검색 데이터를 제공할 때, 가수를 팔로잉 하는 팔로워 리스트를 제공해야 한다. Follower 라는 간단한 클래스를 정의한다. 

Singer 클래스는 followers 필드를 추가하였다. 


그리고, 가장 중요한 GraphQL 스키마는 아래와 같이 수정하였다. Follower 타입이 추가되었다. 


그런데, 개발자는 깨달았다. 

팔로워 리스트를 제공하는 기능 구현에, 작은 문제가 있다는 사실을 알게 되었다.


가수 데이터와 팔로워 데이터는 별도의 데이터베이스에서 관리하고 있다. 그래서, 가수 데이터와 팔로워 데이터를 매핑하는 과정은 부득이하게 최소 두번 이상, 각자 다른 데이터베이스에 조회를 해야하는 상황이다. 


어쨋든, 개발자는 어렵게어렵게, Singer 객체에 Follower 리스트를 같이 제공하도록 개발을 완료했다고 가정하자. 아래와 같이 가수 검색 시, 팔로워 리스트를 응답 받을 수 있다.  

응답 데이터는 아래와 같다. 

기능은 잘 동작하지만, 뭔가 찝찝하다. 만약, 팔로워 리스트가 필요하지 않는 경우에 내부에서 어떻게 동작할까? 수차례 설명했듯이 요청 쿼리에 followers 를 제외하면, 아래와 같이 팔로워 리스트는 응답하지 않는다. 즉, 내부 애플리케이션에서 굳이 조회할 필요가 없는 데이터이다.  


하지만, 내부 로직에서는 Singer 데이터를 생성시에 Follower 데이터를 넣어주고 있었다... 

즉, 굳이 필요하지 않은 데이터까지 만들어주는 것이다. 


Singer 데이터 생성 시 Follower 는 필요한 경우에만 조회하고 싶다. 


즉, 지연로딩 을 하고 싶다!!!


어떻게 하면 될까? Singer Type 클래스에서 followers 필드는 필요없다. 


아래 코드와 같이, parentType = "Singer", field = "followers" 속성으로 @DgsData 를 신규로 정의해준다. 그리고, DgsDataFetchingEnvironment 를 파라미터로 주입해준다. 

해당 메서드는 아래 그림과 같이, Singer - followers 요청이 있는 경우에만 동작한다. 

디버깅을 해서 직접 확인해보자. 

우선, dfe.getSource() 메서드가 동작하면"아이유" 라는 이름의 가수를 조회한다. 

그리고, followerService 응용서비스에서 가수 "아이유" 를 팔로잉하는 팔로워 리스트를 찾는다.


다시 한번 또 얘기하지만, followers 요청이 있는 경우만 동작한다. 없다면, 위 메서드는 실행을 하지 않는다. 즉, 필요한 경우에만 팔로워 리스트를 조회하는 것이다. 


이해가 잘 되는가??ㅠㅠ  설명하기 너무 어려운데, 필자도 잘 모르겠다. 



5. Netflix GraphQL 테스트


테스트 방법에 대해서 알아보자. 


6.1 테스트 코드 작성하기

스프링부트에서는 테스트 코드를 위한 다양한 기능을 제공한다. 그 중에서, @SpringBootTest 어노테이션은 스프링부트 애플리케이션을 쉽게 테스트할 수 있도록 도와준다. (사실, 필자는 @SpringBootTest 어노테이션을 남용하는 것을 선호하지는 않는다. @SpringBootTest 의 남용은 객체간의 의존성 설계에 대한 잘못을 감출 수 있기 때문에 주의가 필요하다.) 


어쨋든, 아래와 같이 @SpringBootTest 어노테이션을 사용해서 테스트 코드를 작성하자.

@SpringBootTest 어노테이션에 classes 속성에 DgsAutoConfiguration.class, SingerDataFetcher.class 를 선언하였는데, classes 에 선언된 클래스만 스프링 의존성 컨텍스트에 빈으로 등록한다. 만약, classes 를 선언하지 않고 @SpringBootTest 를 그대로 사용하면, 애플리케이션에서 등록 가능한 모든 컴포넌트 빈(bean)이 애플리케이션 컨텍스트에 등록이 될 것이다. 테스트 실행 시간이 지연되며, 해당 테스트에서 굳이 필요하지 않은 Bean 이 모두 등록이 될것이다. 


첫번째 테스트, 전체 가수 검색 기능에 대한 검증을 해보자. dgsQueryExecutor 의 executeAndExtractJsonPath 메서드를 사용하면 된다. 

해당 소스코드는 아래 요청과 동일한 쿼리에 대한 검증이다. 

테스트는 잘 성공할 것이다. 

두번째, 특정 가수 검색이 잘 되는지 검증하자. 

"아이유"라는 이름의 가수만 검색을 하였다. 결과는 당연히 "아이유"라는 이름의 한명의 가수만 검색한다.


마지막으로, 특정 가수와 동갑인 가수를 모두 검색하는 기능을 테스트해보자. 

역시, 아래와 같이 테스트 코드는 잘 동작한다. 


전체 테스트를 돌려도, 다같이 성공할 것이다. 

물론, 해당 테스트는 전부 @SpringBootTest 어노테이션을 사용했기 떄문에, 

아래 그림과 같이 테스트 실행 시 스프링 프레임워크가 함께 실행이 된다. 위에서도 설명하였지만, 모든 Bean 을 스프링 컨텍스트에 등록하지는 않는다. classes 에 선언해준 클래스만 스프링 컨텍스트에 등록을 해서 관리하게 된다.



6.2 런타임 시 API 검증을 위한 테스트 UI 제공

6.1 은 개발 단계에서의 테스트이다. 개발 단계가 아닌, 런타임 시점에서의 테스트는 어떻게 할 수 있을까? 일반적으로 우리는 스웨거 라고 하는 툴을 주로 사용한다. 또는, 필자의 글에서는 Postman 이라는 도구를 사용해서 직접 API 를 호출하였다. GraphQL 에서 쿼리 테스트를 위한 UI 를 제공한다.


애플리케이션을 실행하자. 그리고 크롬 브라우저에서 /graphiql 을 실행하자.

http://localhost:8080/graphiql

쿼리를 직접 실행할 수 있다. 


"아이유" 와 동갑인 모든 가수를 검색하고 싶다면.. 응답 데이터를 이름, 나이, 팔로워 리스트를 전부 응답받고 싶다면 아래와 같이 요청하면 된다. 


좀 더 자세한 내용은 아래 링크를 참고하길...

https://netflix.github.io/dgs/query-execution-testing/



6. Netflix GraphQL 관련 기타 내용 정리


기타 잡다한 내용을 정리하였다.


6.1 Code Generation Plugin

DGS Code Generation plugin GraphQL 스키마 파일에 정의한 타입에 대해서 자동으로 클래스를 생성해주는 기능이다. 이게 무슨 의미냐면.. 필자가 샘플 소스에서 정의했던, Singer 클래스, Follower 클래스 등을 굳이 개발자가 정의해줄 필요가 없단는 얘기다. 


오해가 있을까봐.. 스키마 정의는 반드시 해줘야 한다. 지금 얘기하는 건, java 로 작성한 Singer 클래스에 대한 얘기다. 


넷플릭스의 샘플 코드를 확인해보면, type 클래스에 대해서 전혀 소스코드가 없다.

https://github.com/Netflix/dgs-examples-java

해당 샘플 코드를 빌드해보면, 아래와 같이 자동으로 클래스가 생성이 된 것을 확인할 수 있다. build 디렉토리에 생성되었다. 


자세한 내용은 공식 레퍼런스를 참고하길 바란다. 

https://netflix.github.io/dgs/generating-code-from-schema/


Code Generation Plugin 을 사용하는 것이 어떤 장단점이 있는지 아직은 잘 모르겠다. 혹시, 알고 있는 개발자는 댓글로 의견을 남겨주길 바란다. 근데, 아마도 2021년 3월 기준으로 국내에서 해당 라이브러리를 사용해본 개발자는 거의 없을 것 같기는 하다..... 



6.2 Mapping custom exceptions

DataFetcher 메서드에서 커스텀 예외처리를 하는 방법을 소개한다. 같은 나이의 가수를 검색하는 기능에서, 검색 결과가 없는 경우에 예외 처리를 하고 싶다면 어떻게하면 될까? 일단, 간단한 런타임 Exception 을 정의해준다. 

같은 나이의 가수 검색결과가 없다면, 필자가 따로 정의한 NotFoundSingerRuntimeException 클래스를 throw 하도록 예외처리를 한다.

그리고, 아래 소스와 같이 DataFetcherExceptionHandler 인터페이스를 구현하는 핸들러 클래스를 정의해줘야 한다. 

호출 결과는 아래와 같이, 필자가 정의한 Error 스펙에 맞게 응답한다.

추가 설명은 생략한다. 공식 레퍼런스를 참고하기를...

https://netflix.github.io/dgs/error-handling/


6.3 Security

레퍼런스를 읽다보니, Spring Security 와 연동된다고 설명이 되어있다. 

정확히 어떻게 구현이 가능한지 궁금하지만, 시간 관계상 상세하게 검토는 생략하겠다. 



6.4 라이브러리 소스코드 까보기

넷플릭스 라이브러리의 com.netflix.graphql.dgs.mvc 패키지에 DgsRestController 클래스를 보자. 해당 소스에서는 @RestController 을 사용하였고, @RequestMapping 으로 엔드포인트가 설정된다. 

속성 정의는 아래 프로퍼티에 정의되어 있다. 

해당 소스를 보니, graphql 엔드포인트 url 를 변경할 수 있을것 같다. 


application.properties 파일에 엔드포인트 정의를 다시 해주자.

기존 엔드포인트는 404 에러가 발생할 것이다. 

필자가 새로 정의한 엔드포인트로 호출하면 정상적으로 동작할 것이다. 

암튼, 소스코드를 따라가다보면, 결국 넷플릭스 GraphQL 라이브러리는, 기본적으로 graphql-java 를 사용하는 것을 확인할 수 있다. 나중에 시간 여유가 생긴다면, 그때 다시 상세하게 검토는 해보겠다. 당장 실무에서 사용할 예정이 아니라서, 시간이 없으니 이정도만 검토하는게 좋을 듯 싶다. 



7. 글 마무리


넷플릭스 GraphQL 라이브러리에 대해서 아주 간단한 내용에 대해서만 알아보았다. 필자의 이 글에서 모든 내용을 설명할수는 없었다. 레퍼런스 문서를 보면, 필자의 글 내용 외에도, 더 방대한 기능을 포함하고 있다는 것을 알 수 있다. 



주말 하루를 투자해서 글을 작성해봤는데, 너무 기본적인 내용이라서 이 글을 읽는 개발자에게 많은 도움은 되지 못한것 같다. 모든 내용을 검토해보고 싶었지만... 시간 관계상 이정도만 검토하고 마무리하겠다. 


스프링부트 애플리케이션에서 GraphQL 을 도입한 경험이 있는 개발자는 의견을 남겨주길 바란다. 


레퍼런스


https://netflix.github.io/dgs/getting-started/

매거진의 이전글 JWT & Spring Security
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari