[오크모크] 2주차 : DB설계와 Nextjs13 그리고 GraphQL과의 전투...

jabae·2023년 2월 9일

프로젝트

목록 보기

8/8

2주차는 크게 DB설계와 Nextjs 13, GraphQL 공부하기로 나눌 수 있다.

⚙️ DB 설계

DB 설계부분은 프론트인 나는 잘 몰랐던 부분이었는데, (과거 백엔드와 API 설계 정도만 참여했었다.) 꽤나 흥미로웠다. 본격적인 테이블 설계에 들어가기 전에, 알아야할 부분이 있다. 동현님이 간략하게 알려주었는데, 정리하자면 아래와 같다.

✓ 테이블 설계 들어가기

무결성, 유연성, 확장성, 그리고 성능 고려

Column 설계를 제대로 하지 않으면 성능 저하!(두 번 요청, 조회 필요할 수도) 무결성!(같은 정보임에도 한 테이블은 바뀌는데 다른 테이블에서 안 바뀔 수도)

조회시, Column을 두번 조회하는가? 업데이트시, 두번 요청하는가? 를 시뮬레이션 돌려보며 설계한다.

또한, 우리는 소켓통신도 구현해야하기 때문에, DB와 메모리를 구분해 알고 있어야 한다. 각 특징을 잘 알고, 어디에 어떤 정보를 저장해야 효율적일 지 고려해보아야 한다. 그리고 사용자 입장에서 생각해보면, 조회가 느려지면 답답함을 느낄 수 있다. 따라서, 수정보다는 조회를 빠르게 할 수 있도록 설계하는 것이 좋다.

✓ DB, 메모리 어디에 저장하지?

DB: 파일, 하드디스크를 참조하기 때문에 속도가 느리다.

중요한 정보, 날아가면 안 되는 정보 저장

API요청 응답에 주로 조회된다.

메모리: 속도는 빠르지만(데이터 접근이 빠름), 휘발되면 복구가 불가능하다.

접근성이 빨라야 하는 정보

소켓 통신을 통해 주로 조회된다.

ex. 현재 유저 상태, 진행중 게임

둘 다 중요하다면 둘 다 저장하고 있어야 한다. 동기화가 필요하다.

ex. 개인 프로필 수정, 유저 전적

위 내용들을 상각하면서, 지난 시간 정리한 데이터를 바탕으로 데이터 형식과 저장 공간을 정리했다. (아래는 게임 중 발생하는 요청들을 정리한 것이다.)

지난주 api 설계에서 정리한 것과 달라진 부분들이 있었다. 세부적으로 어떻게 처리할 지 논의하는 과정에서 데이터가 추가되거나 삭제되었다. 이 과정이 지치고 힘들었는데, 이렇게 상세히 논의하는 과정에서 앞으로 어떻게 구현될 지 이미지를 그릴 수 있었다.

재밌는 부분도 있었다. 게임이 시작하면 DB에 공간을 만들어 놓고, 메모리에 게임을 기록하고, 소켓으로 뿌리고, 게임이 종료되면 배열로 관리하던 정보를 스트링 타입으로 바꿔서 DB에 저장하는 과정이 흥미로웠다.

🧨 Nextjs 13 사용하기

Nextjs 를 사용하려는데, 새 13 베타버전이 나왔다는 소식...!☄️

😵 Next.js 13 Upgrade Guide 😵

하루 날 잡아 프론트 팀원들과 살펴보았는데, 생각보다 많은 기능들이 추가/삭제 되었고 꽤 괜찮다고 생각이 들었다.

페이지 구조(app/) 및 layout
라우팅
구글 폰트 내장
서버 컴포넌트, 클라이언트 컴포넌트

등 기존 NextJS와 달라진 점을 확인했다. 자체적으로 제공하는 기능이 많아지고, 렌더링 속도가 향상 됐다고 한다.

코드 레퍼런스가 많이 없어 고민되었다. 아무래도 GraphQL도 처음 사용하는 것인데, Nextjs까지 익숙하지 않은 버전을 사용하게 된다면 발생할 고난이 걱정되었다. 그럼에도 불구하고 공식 문서를 살펴보면서 매력적인 점이 많아 13버전을 사용해보기로 했다.😆

✓ 왜 NExtjs 13 app을 사용해야할까?

서버 컴포넌트와 클라이언트 컴포넌트를 분리하여 사용한다는 점에서 SSR과 CSR에 대해 심도 있게 공부할 수 있을 것으로 예상된다. (지난 프로젝트에서 조금 아쉬웠던 부분... 데드라인까지 빠르게 달려가느라 SSR을 사용하지 못했다.)

자체적으로 제공하는 기능을 통해 코드를 줄이며 명확한 라우팅이 가능하다. 기존에 폴더 구조로 라우팅을 해주는 것과 더불어, 새롭게 latout 기능이 추가되었다. layout.tsx파일을 통해 해당 폴더 내 페이지의 레이아웃 구현이 가능해졌다.

(🔥가장 끌렸던 점) 서버 컴포넌트와 클라이언트 컴포넌트를 분리해 작성해 렌더링에 최적화시킬 수 있다. useState, useEffect 등 js 코드를 사용해 클라이언트 단에서 렌더링 하는 컴포넌트와, SSR을 하는 컴포넌트를 분리해서 작성해야 한다. 명확한 이유를 통해 관심사 분리를 할 수 있을 것으로 예상된다! 코드가 예뻐질 것 같아!✨

☄️ GraphQL 사용하기

GraphQL 사용을 제일 원했어서, 제일 두근두근했다. 본 프로젝트 파일을 만들기 전에, stydy 레포지토리를 파서 간단하게 사용법을 공부해보기로 했다.

처음 환경구축부터 고난과 역경의 연속... Nextjs 위에 apollo/client는 겨우겨우 설치했다. Nextjs 13에는 _app.tsx 파일대신 head.tsx, layout.tsx 이 생겼는데 ApolloClient로 전체를 감사줘야 하는데 어디다가 넣을 지 멘붕이었다. 😵 나는 layout을 감싸는 client components를 만들었다. 서치해보니, 다들 그렇게 하는듯!!

client는 되었는데 apollo/server가 말썽이었다. 아무래도 서버는 다룬적이 없다보니 더 헤맸던 것 같다. 또, 기존 v3 서비스를 올해 중으로 종료하고, 새로운 v4를 사용하라고 나와있는 것이 아닌가! apollo-server-micro 대신, <@apollo/server>를 사용해야 했다... 그것도 타입스크립트로 말이지! 🤯

결국 테스트는 server는 조금 더 사용이 쉬운 grapql-yoga를 통해서 데이터를 주고 받는 테스트를 해보았다. 그렇담 그냥 yoga를 쓸까? 그래서 apollo랑 차이가 뭔데?

grapql을 사용하기위한 환경을 만드는데, 대표적으로 3가지 프레임워크가 있다고 한다.

✓ GraphQL yoga? apollo? express?

GraphQL Yoga
진입장벽이 가장 낮다. 초기 설정을 추상화해주어(많은 코드를 숨겨주어) 최소한의 설정만 필요하다. 따라서 초보자와 grapql을 처음 사용하는 사용자에게 적합하다. (우…리..?😲) 또, 프로젝트가 확장된다면 apollo-server로 쉽게 교체할 수 있다고 한다. (과연...)

Apollo Server(v3)
qrapql에서 널리 사용되고 있다.(그렇담 당연히 레퍼런스가 많겠ㅈ?😉) yoga도 부분적으로 apollo를 기반으로 한다. 프로젝트가 좀 더 크고, 미묘한 설정이 필요하다면, 또 apollo-client를 사용하고 있다면, 확실하게 apollo-server를 사용하는 것이 좋다.

Express GraphQL
또 다른 유명한 서버 옵션입니다. express는 Connect, Express, and Restify를 포함하는 HTTPframework와 작동되어, RESTful API에게 익숙한 사용자에게 매력적이라고 한다.

사실 코드를 뜯어보면, type, schema, resolver, graphql 등 구문은 매우 비슷해서 쉽게 교체할 수 있다고한다. 개인적으로는 당장 결론 내리기 힘들다면, yoga를 쓰다가 충분히 그 구문에 익숙해진 뒤 아폴로로 갈아타는 것도 방법일 수 있다.

우리는 일단 yoga로 익숙해지고, 레퍼런스가 많은 apollo-server-micro로도 테스트를 해 보았다. 이것저것 써 보니 익숙해져서 v4로 apollo client를 생성해서 사용할 수 있었다.

🤣 마무리

처음 공부해보는 백엔드, GraphQL, 새로운 Nextjs 13 과 함께하는 즐거운 2주차였다. 이전 프로젝트에서보다 꼼꼼히 알아보고, 준비하고, 연습하고 들어가는 것 같다. 그리고 점점 하면 할 수록 이전 프로젝트보다 훨씬 더 큰 프로젝트라는 것을 느낄 수 있었다...

그렇지만 이렇게 꼼꼼히 공부하고 들어가니까 또 느낌이 색다르다. 급하게 진행하면서 놓치고 갈 수 있는 부분을 다같이 잡아가는 것 같아서 좋다. 💕