개인프로젝트 - clone market 기술적 의사결정

웹 사이트 클론 코딩

취업을 위한 포폴용 개인프로젝트를 진행하려 한다.
이는 특정 웹사이트들을 클론 코딩하여 이커머스 웹을 하나 뚝딱! 만들어낼 예정.

클론 코딩의 이유 : 디자인, 기능 명세 등 개발에 앞선 기획과 디자인에서 시간을 잡아먹지 않기 위함

후보는 마켓컬리, 애플 등이 있으며 개발 도중 여러 웹을 보고 UI가 괜찮고 도전해보고 싶은 부분을 가져다가 쓸 예정

1. DB는 무엇으로?
   supabase vs json-server로 고민을 하였다.
   데이터는 어떻게 구하지? -> 마켓 컬리 또는 쿠팡같은 이커머스 사이트의 데이터를 크롤링 해와서 해당 데이터를 하드코딩으로 보관하는 것이 어떤가?
   즉, supabase를 굳이 쓸 필요없이 가볍게 json-server로 데이터를 하드코딩하여 넣어주어 사용하면 된다고 생각했기에 json-server 체택 땅땅!

2. request handler는 node.js? route handler?
   Next.js만을 사용하여 프로젝트를 진행할지, node.js 프로젝트를 하나 만들어서 서버로 사용할지를 고민했음.
   미들웨어든 뭐든 어차피 어느 것을 써도 간단하게 쓸 것 같다는 생각 왜? 난 프론트엔드 개발자를 목표로 하기에 지금 서버에 시간을 쓸 여유가 없음.
   현 상황에서의 장단점
   node.js - 품이 더 많이든다 그러나, 포폴용으론 더 매력적일 수 있다.
   next.js route handler - 품이 더 적게든다 포폴용으로 더 매력적이지 않은가? 그건 아니라고 생각한다.
   request handler는 그냥 next.js에서 진행하기로 결정 땅땅!

3. css
   tailwind? scss? styledComponent?
   본인은 cva를 좀 제대로 적용하여 진행하고 싶은 부분이 있기도 하고 tailwind를 썻을 때 가장 생산성이 좋았던 것 같다.
   tailwind css를 css Framework로 채택 땅땅

4. 배포
   배포에 관해선 아직 결정을 못내렸다.
   ngnix, docker 등 여러 기술들이 있다고는 알지만 아직 잘 모르는 부분이기도 하고 프로토타입을 만든 후 배포에 대해 결정하도록 하려 한다.

5. Axios vs fetch
   Next.13버전에서는 getStaticPaths, getStaticProps들을 fetch() api로 다룰 수 있게 수정이 되었고 이는 axios를 쓰게 된다면 불가능한 부분,(기존 getStaticPaths를 써서 하던지 아니면 react-query로 하이드레이션해줘서 SSR을 구현하던지)
   그러므로 fetch() api를 써서 SSR,SSG,ISR,CSR 등 내가 원하는 컴포넌트를 제대로 다뤄보기 위해서 fetch 체택 땅땅

6. app router vs page router
   현업에선 아직 page router를 많이들 쓴다해서 좀 고민이 있었음...
   그래도 fetch를 쓰는 이유는 13버전에서 새로운 기능들에 대해 연습하고자 하는 부분이니 이에 맞춰 app router 방식을 취하는 것이 지금 내 관점?에선 맞다고 느껴짐
   app router 채택 땅땅!

7. 상태관리
   Tanstack-query
   1. API 요청 수행을 위한 규격화된 방식 제공
   2. 사용자 경험 향상을 위한 기능(Hook) 제공
   3. 적은 양의 BoilerPlate

   zustand, redux같은 전역 상태 관리 라이브러리가 필요할까?
   중앙 집중적으로 상태를 관리하여 디버깅, 비동기 통신의 흐름 파악 등을 편하게 할 수 있겠지만, 굳이 필요하지 않아 보이는 것도 있다.
   그리고 너무 전역 상태관리 라이브러리에 의존하여 기본적인 것들을 피해온 경향이 있어, 이번 프로젝트에선 custom hook을 최대한 활용하면서 이에 대한 부분을 연습해볼 예정
   굳이 필요하다라 판단되는 부분은 ContextAPI를 쓰도록 하겠음.

8. 인증/인가
   JWT 토큰 쓸거임 아 몰라 쓸거임
   그간 프로젝트에서 supabase의 인증/인가를 사용해와 실제로 어떻게 굴러가는지(물론 백엔드에서 api명세 주면 그거대로 하긴 하겠지만)도 보고 소셜 로그인에 대해서는 kakao api를 활용하여 진행해보려 한다.

9. 라이브러리
   생산성을 위해 아래 라이브러리들은 가져갈 계획

• lodash
• headless css
• cva(이 친구는 연습해야지..)
• clsx
• svgr(이모티콘 싫어...)

일단 기술적 의사결정은 이정도로 마치고 내일부터 당장 시작할 계획이다.
각 페이지별 포스팅을 할 것이고, 에러 또는 특이사항에 대한 포스팅을 꾸준하게 하여 내 개인 프로젝트의 진행 정도를 매일 확인할 수 있게 잘 해보겠다..