[TIL] 프리온보딩 두 번째 과제_MAPIA

두 번째 과제 🔥 

11월 4일 ~ 11월 6일까지 두 번째 과제를 진행했다.

두 회사의 과제중에 원하는 것을 골라서 수행하는 것이었는데,

한 과제는 보편적으로 많이 쓰일 것 같은 내용이었고,

한 과제는 graphDB와 graphQL을 이용한 색다른 내용이었다.

우리팀은 만장일치로 색다른 내용의 마피아컴퍼니 과제를 수행하기로 했다.

사실 과제를 정할 때 좀 놀랐다. 보편적으로 많이 쓰이는 내용을 선택하는 팀원이 있을 줄 알았는데,

다들 재미있어 보이고, 도전적인 과제를 선택했기 때문이다. 모두 같은 생각이라는 것이 좋았다.

음악 스트리밍 서비스에서, 뮤지션, 곡, 앨범의 세 가지 요소가 존재할 때, CRUD API를 구성해야 했다.

 

화면별 Read API 요구사항 (GraphQL)

곡 페이지

✅ 해당 곡이 속한 앨범을 가져오는 API

✅ 해당 곡을 쓴 뮤지션 목록을 가져오는 API

 

앨범 페이지

✅ 해당 앨범을 쓴 뮤지션 목록 가져오는 API

✅ 해당 앨범의 곡 목록을 가져오는 API

 

뮤지션 페이지

✅ 해당 뮤지션의 모든 앨범 API

✅ 해당 뮤지션의 곡 목록 가져오는 API

 

Create, Update, Delete API 요구사항 (RESTful API)

✅ 앨범 생성 API

✅ 뮤지션 - 곡 연결

✅ 곡 - 앨범 연결

✅ 곡 - 앨범연결해제 API

✅ 뮤지션 - 곡 연결해제 API

✅ 뮤지션 생성 API

✅ 곡 생성 API

 

github Repository 주소 : https://github.com/preOnboarding-Team13/Assignment_2_MAPIA

Neo4j (GraphDB) 🏗️ 

이번 과제를 통해 graphDB를 처음 써봤다. 이전에 NoSQL을 공부했을 때, 이런 종류가 있다~ 라고만 들었었는데 실제로 써보게 되어 두근거렸다.

과제 기한도 짧은데, 새로 배워서 써야한다고 생각하니 부담감이 들기도 했다. 그래서 팀원들과 회의 전에 공식문서와 각종 블로그들을 열심히 찾아봤다.

다행히도 컨셉이 그래프 자료구조와 거의 같아서 이해하는데 크게 어렵지 않았다.

쿼리 역시 깊게 공부하지는 못했지만, 과제를 수행하는데 필요한 정도의 쿼리는 어렵지 않게 작성할 수 있었다.

공부하면서 굉장히 직관적인 DB라는 생각이 들었다. 인덱스나, 관계 설정이나, 복잡한 구조가 없이 Node와 Relationship만으로 사용할 수 있었기 때문이다. 관계를 하나의 객체처럼 보는 관점도 새로웠다.

Neo4j Browser를 통해 쿼리를 작성해보고, 쿼리의 결과를 시각적으로 바로바로 확인할 수 있어서 편리했다.

 

DB Modeling🎡 

공식문서에 모델링 가이드가 명확하게 작성되어 있어 큰 고민없이 모델링을 할 수 있었다.

https://neo4j.com/developer/guide-data-modeling/

Graph Modeling Guidelines - Developer Guides

Node를 만들고, Node안에 필요한 property를 넣고, Node를 적절한 Relationship으로 연결하면 끝이었다.

흥미로운건 우리는 사용할 필요가 없었지만  RelationShip에도 property를 작성할 수 있다는 점이었다.

모델링을 하면서, RDBMS에서 N:M 관계를 해소했던 경험이 떠오르면서, GraphDB의 장점을 크게 느낄 수 있었다.

우리팀의 모델링 결과는 다음과 같다!

위처럼 단방향으로 관계를 설정했을 때, song에서는 album이나 musician같이 자신을 가리키고 있는 노드에 접근이 불가능한 것이 아니냐는 논의가 있었다. 공식문서를 살펴본 결과 방향에 상관없이 연결된 노드에 접근이 가능했다.

 

Query 작성 ⛳ 

우리팀은 이번 과제에서 문자열로 쿼리를 짰다.

딱히 마땅한 ORM? ODM?이 생각나지 않았고, 처음 접하는 DB컨셉이므로 직접 문자열로 쿼리를 짜보는 것이 의미 있을 것 같았기 때문이다.

TIL을 작성하면서 찾아보니 OGM(Object Graph Mapper)가 존재했다.

다음에 GraphDB를 쓸 때는 OGM을 이용하는 것으로! JS OGM package

나와 동균님이 필요한 쿼리를 노션에 하나씩 적어나갔다.

적으면서 이 쿼리에서 return값이 필요할까요? 변수 이름은 어떻게 통일할까요?등의 논의를 했다.

작성했던 몇 개의 쿼리를 가져와봤다.

// MUSICIAN 생성
CREATE(m:MUSICIAN {name: '레드벨벳', company: 'JYP'}) return m

// MUSICIAN 업데이트
MATCH (m:MUSICIAN {name:'레드벨벳'}) SET m.company = 'JYP' RETURN m

// MUSICIAN 삭제
MATCH (m:MUSICIAN {id:'어쩌구저쩌구'}) DELETE m

// ALBUM과 연결되어있는 MUSICIAN 찾기 
MATCH (m:MUSICIAN)-[r1:HAVE]->(s:SONG)<-[r2:CONTAIN]-(a:ALBUM)
WHERE a.name = 'Perfect Velvet'
RETURN m

// MUSICIAN, SONG, ALBUM 연결 여부
MATCH (m:MUSICIAN {name: '레드벨벳'}),(s:SONG {name: 'Perfect Velvet'}), (a:ALBUM {name: '피카부'}) 
RETURN EXISTS((m)-[:HAVE]-(s)-[:CONTAIN]-(a))

쿼리를 작성하고 테스트하면서 모델링을 수정했다.

그 전에는 id property가 없이 name이 PK같은 기능을 수행할 수 있을거라고 생각했는데,

name으로 하면 해당 name을 가진 모든 객체가 영향을 받는다.

하지만 이름이 같은 뮤지션, 노래, 앨범이 충분히 존재할 것 같아 id property를 각 노드에 추가하고, uuid를 생성해 넣어주었다. 

id가 추가된 후의 실제로 사용한 쿼리들은 여기에 잘 작성되어 있다. 

 

GraphQL 🍕 

GraphQL은 정말 용어조차도 생소했다. 처음에는 GraphDB에 사용하는 SQL문 같은건가 생각했다.

한참을 고뇌하다가 이 영상을 통해 이해하게 되었다. 

https://youtu.be/EkWI6Ru8lFQ

컨셉을 이해하는데 정말 많은 도움이 되었다. 앞으로 누군가 나에게 GraphQL이 뭐냐고 물어보면 이 영상을 보여줄 것 같다.

 

GraphQL은 Rest API밖에 존재하지 않는 내 머릿속에 큰 충격을 주었다. 야 이게되네ㅋㅋ

Client가 Body에 뭘 담아보내느냐에 따라 Res에 존재하는 필드값들이 달라진다니!! 그리고 이 것이 비교적 간단한 로직으로 해결된다니!! 

 

GraphQL 기본적인 설정 및 적용은 동균님이 해주셨고, 나는 희진님, 나영님과 함께 where절의 조건같은, client가 특정 id를 넣어보냈을 때를 위한 코드를 추가했다. 

 

Resolver코드를 수정해서 Arg로 id를 받도록 했는데, 제대로 작동하지 않았다. 

// AlbumRead Resolver 코드
...
// 기존 코드 (모든 앨범)
@Query(() => [Album])
	async readAllAlbum() {
		return this.readService.readAllAlbum();
}

// 추가한 코드 (특정 id)
@Query(() => [Album])
	async readAlbum(@Args("id") id: string) {
		return this.readService.readAlbum(id);
}
...

원인은 graphql파일에 있었다.

이 파일에 정의된 형태의 요청만 처리할 수 있었기 때문이다. 따라서 id를 인자로 받을 수 있는 Query를 추가했다. 

type Query {
	readAlbum(id: String!): [Album!]! // 추가!
	readAllAlbum: [Album!]!
}

이렇게 단 2가지만 추가해서 특정 id에 대한 결과만 보여주는 쿼리를 완성할 수 있었다. 물론 동균님이 GraphQL을 설정하시는데 많은 노력이 들어갔지만, API를 이렇게 간단하게 작성할 수 있어서 정말 신기했다.

다음번에 GraphQL을 쓰게된다면, 내가 설정을 맡아보고 싶다. 

 

NestJS 🎆 

이번 프로젝트에서 NestJS도 처음 써봤다. 첫 번째 과제에서는 express를 이용했었기 때문이다.

저번 과제에서 NestJS를 이용한 우리팀 과제 레포를 살펴보면서 구조를 파악했다. 

써본적이 없긴 했지만, 대강 훑어보니 'JS의 Spring같은 친구구나'라는 생각이 들었다.

자유도가 굉장히 높았던 express와 다르게 대부분이 정형화, 구조화 되어있었다. 

처음에는 이 부분이 살짝 불편하기도 했는데, 프로젝트를 진행하면서 보니 오히려 협업하기에는 express보다 훨씬 편리하다는 생각이 들었다. 

 

MVC패턴이고, router 대신에 Controller에 어노테이션으로 url을 설정하는 것도 달랐다. (Spring이랑 정말 비슷하다고 느낀 대목이었다.)

* NestJS에서는 어노테이션이아니라 데코레이터라고 부른다. 

 

TS도 처음써봤는데, 딱히 낯설지 않았다. JS와 다르게 type을 정해줄 수 있는 점이 오히려 좋았다. 

 

Controller, Service, Repository를 만들어서 실행을 시켰는데 에러가 났다. 의존성 주입을 해주지 않아서였다.

급한대로 저번레포를 보고 많이 참고했다. 이 때는 의존성부분은 잘 이해가 되진 않았지만, 현재 6번째 프로젝트를 진행중인 상황에서 스스로 의존성주입을 할 수 있는 수준이 되었다. 

 

@Global() 🌍 

Neo4jService를 만들어서, 각 엔티티(노드)의 Repository파일에서 Neo4jService를 import해서 사용했다. 

그래서 일일이 각 노드의 Module마다 Neo4jModule을 주입해주었는데, 이게 맞나 싶었다. 

역시나, 더 편리한 방법이 있었다. 바로 @Global() 데코레이터!      공식문서

이 데코레이터를 이용하면 Module을 전역범위로 만들어서 필요한 곳마다 일일이 넣어줄 필요가 없었다.

 

 

공통 응답 클래스 🚀 

이전에 express를 썼을 때에는(첫 번째 과제), 공통 Error Handler는 적용했지만 성공시에 res를 보내는 코드가 각 컨트롤러마다 따로 붙어있었다.

이번 과제에서는 global 폴더에 공통 응답 클래스를 만들어서 이용했다. github

적용하기 이전보다 코드가 깔끔해지고, 모듈화가 잘 이루어졌다는 느낌이 들었다.