IT회사 팀사람들과 스터디 하기 2탄, graphql 스터디

     

 

목차

    graphql 스터디의 시작

     

    DDD 스터디를 진행하고, 그 기세를 모아 바로 다음 스터디 시작~!

     

    어떤 스터디를 할까 후보에 이것저것 올라왔는데, 그중에서 무난했던 graphql이 선택되었다.

     

    후보 리스트: 

    • 스프링 (코틀린)
    • 카프카
    • 클린 아키텍처 : 지금 할 만함
    • 클린 코드 : 지금 할만함
    • Google RPC : 독학이 더 좋음
    • graphQL : 지금 할 만함 
    • 디자인패턴 : 지금 할 만함
    • 리팩토링
    • http http/2.0
    • database

     

    생각보다 많은 후보군이 있었는데 ㅋㅋ 코딩하는 건 뭔가 독학이 더 효율적일 것 같고, 5주간 DDD를 했더니, 너무 범위가 커서 오래 걸릴 것 같은 스터디는 피했다. 그래서 선택된 것이 graphQL!! 🙌

     

    graphQL은 사이드 프로젝트로 진행한 경험이 있기 때문에 나에게 아주 익숙한 프레임워크다. 😁

    사이드 프로젝트는 django를 이용해 graphQL을 구현했었는데, 패키지중에 grapene라는 패키지를 사용했다. 장고에서 제공하는 ORM과 연동이 너무 쉬워서 편안하게 진행했던 것 같다. 근데 이번 공부를 하면서 내가 사용하지 않은 graphQL에 기능들이 엄청 많다는 것을 깨달았다!!!😵‍💫

     

    역시 책이나 공식 문서를 참고하며 개발해야 뭔가 숨겨진 기능, 더 편리한 기능들을 많이 사용할 수 있는것 같다. 추가로 올바른 사용은 덤!

     

    공식 문서나 책을 참고하는 것은 항상 옳다.

     

     

     

    사용한 책

     

    사용한 책

    스터디에서 사용한 책은 웹 앱 API 개발을 위한 GraphQL이다. 생각보다 아주 얇다 ㅋㅋ 

    GraphQL in action도 후보에 있었는데, in action시리즈는 워낙 두껍고 방대해서,, 가볍게 찍먹 하기 위해서 얇은 책을 골랐다. 

     

    이 책에 목차는 다음과 같다.

    1장 GraphQL에 오신 것을 환영합니다
    2장 그래프 이론
    3장 GraphQL 쿼리어
    4장 스키마 설계하기
    5장 GraphQL API 만들기
    6장 GraphQL 클라이언트
    7장 실제 제품을 위한 GraphQL

     

    책도 얇고 한 챕터당 30페이지 정도라서 1~4장을 1주 차에 보고 5~7장을 2주 차에 봐서 2주 만에 끝내는 일정으로 진행했다. 

     

     

    어떤 것을 배웠나?

    1장 ~ 2장

    일단,, graphQL의 장단점이라고 해야 하나? 이것저것 많이 설명을 해준다. 사실 GraphQL의 장단점이라기보다는 REST와 비교했을 때의 장단점이라고 해야 맞을 것 같다. 그만큼 REST가 거의 표준이니까 ㅋㅋ 

     

    내가 사용했을 때의 장점은, 서버와 클라이언트가 어느 정도 API 스펙을 맞출 수 있다는 점이다. 사람이 맞추는 게 아니라 프로그램이 맞춘다. 즉 서로 회의해서 정하는 게 아니라 Instropection이라는 기능을 제공해 줘서 클라이언트가 최초에 서버에 조회해서 사용할 수 있는 API스펙을 긁어간다 ㅋㅋ 따라서 아폴로와 같은 라이브러리를 쓰면 클라이언트도 알아서 API 응답에 대한 모델을 자동으로 만들어준다.

     

    또 다른 장점은, 여러 가지 상황에 대한 응답값 커스터마이징을 안 해줘도 된다는 점이다. 화면마다 응답값이 조금씩 다른데 사용하는 모델이 같은 경우, REST의 경우 각각 따로 만들어줘야 했지만, GraphQL의 경우 클라이언트가 알아서 응답값을 정해서 조회할 수 있기 때문에 작업이 매우 편하다. 하지만 특정 값에 대한 특정 계산식이 들어가야 하는 경우는 REST와 마찬가지로 API를 분리해서 만들어줘야 하는 건 동일하다.

     

    단점은,, 음 binary를 이용한 업로드가 불편하다. 쉽게 말하면 파일 업로드가 불편하다. 그리고 인증도 불편했는데, 기존에 사용하던 oauth방식을 그대로 사용하기 위해 이것저것 설정해야 하는 게 맞다. 이건 사실 인증 문제라기보다는 개발자의 접근성? 문제인 것 같다. 많이 안 써봤으니 어려운 게 당연하지 ㅋㅋ 

     

    그 밖에도 REST에 비해 빈약한 커뮤니티가 있다. 문제가 생겼을 때 검색을 해도 잘 안 나온다. 

     

    3장 ~ 4장

    GraphQL에 대한 문법이다 설계방법 등이 나온다. GraphQL에는 조회를 위한 기능 Query, 수정 업데이트를 위한 기능 Mutation을 제공한다. CRUD에서 R과 CUD를 따로 분리해서 Query와 Mutation으로 나눴다고 생각하면 편하다. 사이드 프로젝트를 할 때 이 두 가지 기능만 생각하고 만들었는데, 책을 보니 다른 기능들도 제공하고 있었다. 

     

    Subscription - 구독하는 기능. 이 Subscription이 있었다면 클라이언트에서 polling 하는 구조로 만들지 않았을 텐데 ㅋㅋ 자체적으로 아마 웹소켓을 구현해서 서버에서 클라이언트로 푸시하는 기능을 제공하고 있다. 대단..

     

    Instrospection - 위에서 말했듯이 GraphQL에서 제공하는 API 스펙을 조회할 수 있는 기능이다. 

     

     

    5장 ~ 7장

    실제 GraphQL로 API를 만드는 내용을 다루고 있다. 꽤 실무적이긴 한데 너무 간단한(?) 예제라서 지루하다. ㅎㅎ 회사에서는 아주 복잡한 비즈니스 모델을 다룬다고!! 😵

     

     

     

     

    스터디 후기

    2주 만에 후딱 끝낸 스터디라서 후기가 쓸게 없다 ㅋㅋ

    팀원들 모두 간단하게 아~ 이런 게 있구나~ 하고 넘어간 느낌? 특히나 GraphQL에 대한 경험이 없는 팀원들은 그냥 쓰-윽- 하고 책을 읽은 느낌이라고 한다. 이런 프레임워크는 실습이 중요하기 때문에 뭔가 만들어보면서 하는 게 좋은데, 직장인이라 시간이 없잖아!?! 🫠

     

    그래도 평일 짬시간과 주말을 노려서 각자 어느 정도 GraphQL을 이용한 API를 만들어보긴 했다. 어느 정도 짬이 있으면 간단한 API는 금방 만드니까 ㅎㅎ 

     

    GraphQL을 배우고 가장 큰 수확은 Query와 Mutation 말고 다양한 방법이 있다랄까? REST에 비해 코드를 적게 써도 돼서 생산성이 높게 보일 수 있는데, 이것도 제대로 쓰려면 REST와 비슷하게 이것저것 설정해줘야 할게 많고 최적화를 위해 이것저것 해줘야 할 것 같다.

     

    우리 팀에서 내린 결론은

     

    조회가 많은 서비스에는 용이하지만 CUD가 많은 서비스에는 글쎄?

     

     

    반응형

    댓글

    Designed by JB FACTORY