[네이버 클라우드 (API 마켓플레이스) APPETIZER 서포터즈] 개발 기록 3차

오늘은 돌아온 블로그 작성 시간!!!

오늘은 벌써 개발 기록 3차인만큼,, 

진행 중인 사항을 공유하겠습니닷~~!

 

저는 백엔드 개발자로, Spring boot를 사용해 서버 작업을 맡았습니다.

매 프로젝트마다 익숙하지 않은 기술을 하나씩 적용해보자는게 저의 목표이기 때문에..! 

이번엔 Spring boot에서 정식으로 지원하기 시작한 GraphQL을 사용하기로 했고, 사용 후 Rest와 비교해 장단점을 알아볼 계획입니다.

spring-boot-starter-graphql에 대한 별로 자료가 없기 때문에 좀 걱정을 했고.. 역시나 공부할 때 애를 먹었습니다.. 하하

아래는 제가 찾아본 괜찮다 싶었던 자료들인데 나중에 저도 보고 여러분도 보시라구.. ㅎㅎ 기록을 해봅니다!

### Data loader와 @batchmapping (n+1문제 해결) ###
0. https://techdozo.dev/spring-for-graphql-how-to-solve-the-n1-problem/          (= n+1문제란?)
1. https://medium.com/@sunny-chung/using-graphql-with-spring-boot-36c460464f7f
2. https://jskim1991.medium.com/spring-boot-batching-graphql-queries-with-batchmapping-ed5955835432

### Graphql ###
1. https://docs.spring.io/spring-graphql/docs/1.0.0-M4/reference/html/#controllers-schema-mapping
2. https://blog.softwaremill.com/take-spring-boot-graphql-and-grpc-micro-services-solve-the-n-1-query-issue-with-dataloader-c2fec7b43517

 

 

GraphQL에 대한 공부를 어느정도 하고 바로 개발을 시작했습니다.

저희 팀은 인증 로직을 좀 변경했고 인증과 멤버까지 다 완료된 상태에서 쿠버네티스 배포를 진행했습니다. 

300만원 받고 놀라서 NCP의 뭘 이용해볼까 설레발 춤사위

(네이버 클라우드의 300만원 크레딧 지원덕분에 쿠버네티스를 써보네,, 이거 받고 진짜 입꼬리 활짝 ㅋㅎㅋㅎㅋ

300만원 정말정말 감사합니다~! 남김없이 다 써보겠습니닷!!!! 이렇게 NCP에게 빠져버리고...~ 나중에도 NCP 써야지!!)

 

 

그리고 곧 중간 프로토타입을 제출해야하기 때문에 저희 팀은 파트를 나누고 개발을 진행했는데요!

기업 미팅 때 스텝페이 개발자님과 대화했던대로 "스텝페이는 한 가게 안에 있는 구독과 제품 판매를 도와준다, 하지만 이 아이디어(오늘의 빵)는 여러 가게가 있기 때문에, 이 여러 가게와 관련된 데이터를 자체적으로 따로 관리를 해야할 것이다."를 실천하기 위해

우리 서비스 자체 DB에 사장님과 가게를 저장하는 부분을 제가 맡았고요!

다른 팀원분께서 스텝페이 API를 연동하는 부분을 맡았습니다. 

 

저는 시험기간이 겹쳐 파트가 정해지자마자 개발을 시작했습니다.

개발의 맨 첫 단계는 프론트 담당 팀원분과 DTO에 대해 정의를 했습니다.

그리고 GraphQL을 처음 사용하기 때문에 쿼리 날라가는 것 까지 세세하게 살펴봤던 것 같아요... 혹시라도 N+1문제가 나타날까봐 덜덜 걱정했지만 다행히 잘 해결했습니닷 ㅎㅎ

GraphQL을 조금 써본 경험상?? 내가 정의한 응답 내에서 Client가 필요한 응답만 알아서 가져가기 때문에 Http 응답 size를 줄일 수 있다는 점이 좋았습니다.

앞으로 엔티티의 필드가 많고 디자인적으로 그 중 필드 중 일부만 사용할 때가 있다면 GraphQL을 사용하는 것이 더 좋을 것 같다고 느꼈습니다. 

 

그리고 이전에 했던 프로젝트에서 느꼈던 문제를 해결하고자 Facade pattern을 적용해봤습니다. 

적용하려는 이유는 Service단에서 하는 일이 너무 많기 때문이었어요.

만약 Facade가 없이 Controller -> Service -> Repository 구조였다면 Controller는 요청과 응답에 대한 처리를 해주고 Service는 우리 서비스 로직, Repository는 DB에 쿼리를 날려주는 역할을 할텐데,

ServiceA에서 ServiceB를 부르면 어쩔 수 없이 나가게 되는 중복 쿼리가 발생하기 때문입니다. (예를 들어, 헤더에서 가져온 memberId로 Member를 조회하는 쿼리,,?) 

구조 상으로 봤을 때 Service가 하는 일이 너무 많았고 쓸모없는 쿼리를 또 나가게 하니,, 적용을 했봤는데

결론적으로 Facade !!! 아주 만족스럽습니다! 앞으로도 게속 사용할 것 같아요 !! 

코드도 깔끔해지고 로직도 분리되고 중복되는 코드와 쿼리가 줄었습니다..!!(ㅎㅎㅎ싱낭~)

 

이렇게 저의 파트를 개발완료했습니다!

fireCamp와 QueryDSL에 대해서도 다음 시간에 풀어볼게요!

 

---

 

저희 팀의 최대 장점은 공유를 잘 하는 팀워크입니다. 

현재 팀원들의 시험기간과 공채기간이 겹쳐 많은 시간을 들이지 못하는 상황입니다,, ㅠ 그래서 최대한 시간을 아끼고 개발 속도를 내기 위해 서로 맡은 파트와 오류에 대해 공유하는 시간을 편하게 자주자주 만들기로 했습니다! 질문 환영 마인드

(저희 팀은 구글 미트를 이용하는데 며칠 사이에 6번이나 했더라구요. 이정도면 인정해주셍...!)

 

주로 다른 팀원분이 맡으신 파트의 오류를 고치기 위한 회의? 였고.

스텝페이의 API를 사용하기 위한 RestTemplate Bean 생성과 사용법, null 나오는 이유를 찾거나 코드 리뷰를 하는 시간을 가졌습니다. 

 

이번 프로토타입에서는 원하는 목표까지 이루지 못했지만, 이제 팀원들의 실력과 성격을 파악했으니..!

이번달 안에 스텝페이 API연동을 끝내기로 계획을 다시 세워봐야 할 것 같습니다. 

 

---

마지막으로 오늘의빵 시연 화면

[NCP] ArgocCD & kubernetes

회원가입과 가게등록

 

 

그럼 이만 뿅 !