
## 서론

웹 백엔드를 입문하기 위해 이 프로젝트를 시작했다. 서버에서 데이터베이스에 접속해서 데이터에 대해 CRUD기능을 구현하는데에 게시판 앱 만큼 좋은게 없어 보였다. 목적성이 있는 웹 앱을 만들면 더 재밌을 것 같아서 “조성민 연구 포럼”을 만들기로 했다.

> 조성민은 우리 부대 최고의 연구대상이다. 그를 연구하는건 매우 값진 일이다.

[조성민 연구 포럼](https://jindun-forum.vercel.app/)

[https://github.com/jindun619/forum-app](https://github.com/jindun619/forum-app)

## 데이터베이스/ORM 선택

데이터베이스의 종류는 생각보다 다양했다. 관계형 데이터베이스(RDBMS), NoSQL 데이터베이스, 그래프 데이터베이스 등이 있는데, 검색해본 결과 특수한 구조를 가진 데이터가 아닌 간단한 데이터구조라면 관계형 데이터베이스로 모두 커버가 가능하다고 했다. 관계형 데이터베이스도 MySQL, PostgreSQL, SQLite등 종류가 다양한데, 마침 내가 배포 플랫폼으로 이용하고 있는 Vercel에서 무료로 Serverless PostgreSQL을 지원 한다길래 [PostgreSQL](https://www.postgresql.org/)을 사용하기로 했다. 생산성, 안전성 그리고 편리성을 높이기 위해 강력한 Node.js, Typescript ORM인 [Prisma](https://www.prisma.io/)도 사용하기로 했다.

## NextAuth를 이용한 소셜 로그인

[NextAuth](https://next-auth.js.org/)는 Google, Facebook, Github등 전세계적으로 유명한 플랫폼 뿐만 아니라, Naver, Kakao와 같은 국내 플랫폼들도 인증 공급자로 사용할 수 있다. NextAuth에 있는 KakaoProvider와 Prisma Adapter을 이용해서 카카오톡 로그인 인증, db에 User 데이터 입력까지 매우 간편하고 안전하게 구현할 수 있었다.
항상 소셜 로그인만 사용할 수 있으면 편리하겠지만, 그렇지 않은 경우도 많기 때문에 다음번에는 Credentials Provider을 이용해서 직접 로그인/회원가입 시스템을 만드는 연습을 해봐야겠다.

## 렌더링 방식

Next.js는 일반적으로 서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR) 그리고 정적 생성(Static Generation) 방식이 있다. 각각 상황에 맞는 적합한 렌더링 방식을 사용해야 한다. 이 앱 특성상 정적 생성은 사용할 일이 없을 것 같고, SSR과 CSR중에 고민했어야 했다.

### SSR

게시글을 보여주는 페이지는 SSR 방식을 사용하는 것이 적합하다고 생각했다. 왜냐하면 보통 게시글은 SEO(검색 엔진 최적화)가 잘 되어있어야 하는 특징이 있고, 데이터 양이 적기 때문에 초기 로딩 속도를 매우 빠르게 하고 싶었다.
하지만 예상과는 다르게 오히려 SSR 방식을 사용하니까 초기 로딩 속도가 매우 느려졌다. 처음에는 무료 배포여서 서버 속도가 느린게 아닌가 의심을 했었는데(아마도 그것은 사소한 부분일 것이다), [이 글](https://velog.io/@namtaehyun/Next.js-제대로-알고-사용하기-적절하지-못한-SSR)을 읽고나서 이유를 알았다.
내 페이지는 GetServerSideProps 함수에서 비동기로 게시글 데이터를 요청하고, 데이터를 다 불러오고 나서야 페이지를 보여주기 시작한다. 바꿔서 말하면, 데이터를 다 불러오기 전에는 페이지가 그려지지 않는다. 그러니 초기 로딩 속도가 느려질 수밖에 없었다. CSR을 사용하면 이 문제는 고칠 수 있어 사용자 경험은 올라가겠지만, SEO는 포기해야 한다.

### CSR

위의 문제를 해결해 보고자 페이지 렌더링 방식을 CSR으로 바꿔봤었다. 예상했던 대로 초기 로딩 속도는 빨라졌지만, 데이터가 불러와지기 전에 정보가 있어야 할 자리가 비어있다가 (혹은 “undefined”로 채워져 있다가) 데이터가 불러와지면서 페이지가 메꿔지는 것이 부자연스럽다고 느꼈다. 차라리 초기 로딩 속도가 느리더라도 초기에 완전한 페이지를 불러오는 것이 사용자 경험 측면에서 더 좋을 것이라는 생각이 들었다.

### 결론

여러 방법을 시도해봤지만, 아직 만족스러운 결과를 보여주는 좋은 방법을 찾지 못했다. 어떤 렌더링 방식을 어떻게 사용할지 결정하는 것은 앞으로 계속 학습하고 연구해야 할 숙제인 것 같다.

## API 활용

Prisma는 보안상의 이유로 클라이언트상에서 데이터베이스에 접근할 수 없다. 그래서 API서버를 구축해서 이를 통해 데이터베이스에 간접적으로 접근해야 한다.
Next.js는 기본적으로 제공하는 API Routes 기능을 통해 간편하게 API 서버를 구축할 수 있다. REST API를 설계하기 위해 검색을 해봤는데 (CHAT GPT)

> 1.  **URI는 소문자 사용:**
>
> - 많은 경우, URI는 소문자로 작성됩니다. 이는 대소문자 구분으로 인한 혼란을 피하기 위한 것입니다.
>
> 2.  **하이픈(-) 사용:**
>
> - 공백 대신에 하이픈을 사용하여 가독성을 높일 수 있습니다. 예를 들어, `/user-profiles`와 같이 사용될 수 있습니다.
>
> 3.  **단수형 사용:**
>
> - 리소스에 대한 식별자로 단수형이 일반적으로 사용됩니다. 예를 들어, `/user` 대신에 `/users`가 아닌 `/user`로 표현할 수 있습니다.
>
> 4.  **명사 사용:**
>
> - 리소스를 나타내는데 명사를 사용합니다. 동사보다는 명사 중심으로 리소스를 표현합니다.

와 같은 답변을 받았다.
처음에는 RESTful API 설계는 누군가가 정해놓은 표준인 줄 알았는데, 개발자, 팀, 또는 커뮤니티에 따라 상이하다고 한다. 그래서 온라인상에 많은 개발자들이 참고하는 준표준(?)을 따르기로 했다.

## 반성할 점

### Typescript 제대로 이용하자

Typescript는 사전에 type을 설정해서 개발자가 옳지 않는 type을 입력하려고 하는것을 사전에 방지할 수 있다. 하지만 나는 이 프로젝트에서 type/interface를 정의하기 귀찮아서 ‘any’ 타입으로 채웠다. 이것은 스스로 Typescript의 장점을 포기하는 행위이다. 프로젝트 규모가 커질수록 타입의 중요성은 커질 것이니 앞으로는 ‘any’ 사용을 자제하겠다.

### 공식 문서를 읽는 습관을 들이자

새로운 스택을 배울 때 블로그/유튜브 강의를 보면 해당 스택에 빠르게 입문할 수 있지만, 빠르게 배운 만큼 중요 개념들을 가볍게 훑고 넘어가거나 놓치고 지나가는 경우가 많은 것 같다. 지루하고 시간이 오래 걸리더라도, 공식 문서를 꼼꼼히 읽어보는 습관을 들이는게 좋을 것 같다.


게시판 앱을 만들어봤다

참고 자료