기술적 의사결정 - UniverseStop/FE GitHub Wiki

어떤 프레임워크를 사용할까?

• 결정 : Next.js를 사용하기로 결정했다.
• 전제
  • 짧은 기간에 프로젝트 완성해야 하므로 학습 곡선이 낮아야 한다.
  • 요즘 트렌드인 SSR을 경험해보고 싶다.
• 고려 : React, Vue.js
• 논쟁
  • React
    • 기존 React 경험으로 학습 곡선이 낮지만, SSR을 직접 구현해야 하여 개발 시간과 노력이 증가한다.
    • 사용자의 웹 브라우저에서만 실행되기 때문에 리액트를 사용하는 경우 SEO의 효과를 거의 볼 수 없어 초기 실행 성능에 부담이 생긴다.
  • Vue.js
    • 학습 곡선이 비교적 낮은 편이지만 React에 비해 사용법이 숙지 되어 있지 않다.
    • SSR을 구현하기 쉽지 않다.
  • Next.js
    • React 기반 프레임워크이기 때문에 기존 React 지식 활용할 수 있어 학습 비용 적다.
    • 실제 사용해 본 결과 SSR이 매우 간단하다, 컴포넌트 개발에만 집중할 수 있다.
    • SSR 지원하여 SEO에 최적화된 HTML을 제공하여 초기 로딩 속도가 빠르다.

어떤 상태 관리 라이브러리를 사용할까?

• 결정 : recoil-persist 를 사용하기로 결정했다.
• 전제
  • 전역 관리가 필요하고, 브라우저 새로고침 시에도 데이터가 유지되어야 한다.
  • 사용이 복잡하지 않고, 코드가 깔끔했으면 좋겠다.
• 고려 : Redux, ContextAPI
• 논쟁
  • Redux
    • 데이터 흐름이 명확하기 때문에 추적이 쉽지만, 필수 파일들을 생성해야 해서 사용 과정이 다소 복잡하다.
    • 작은 규모 프로젝트에서 사용하면 오히려 개발 과정을 번거롭게 만들고, 불필요한 오버헤드를 발생시킬 수 있다.
  • ContextAPI
    • 설정 및 사용이 간편하고, 컴포넌트 간 상태 공유가 용이하지만, 데이터 변경 시 Context를 구독하고 있는 모든 컴포넌트가 다시 렌더링 되는 단점이 있다.
  • Recoil
    • API가 직관적이고 간단하고, 컴포넌트가 필요한 데이터만 가져와서 사용할 수 있다.
    • 상태와 컴포넌트를 분리하여 관리할 수 있어 코드 간결성을 높여 유지 관리 용이하다.

어떤 방법으로 서버와 통신할까?

• 결정 : Axios, React Query를 사용하기로 결정했다.
• 전제
  • 비동기적으로 처리되어야 한다.
  • 에러와 예외 처리가 간단해야 한다.
  • 토근 재발급 기능을 구현하는데 어려움이 없어야 한다.
• 고려
  • 통신: fetch, Axios
  • 미들웨어: React Query, Redux-thunk
• 논쟁
  • 통신
    • fetch
      • 자바스크립트 내장 라이브러리라 별도의 설치가 필요 없지만, 미지원 브라우저가 존재하며, 개발자에 불친절한 response를 주고, axios에 비해 기능이 부족하다.
    • Axios
      • API가 사용하기 쉽고, 직관적이며, 에러 처리 및 헤더 설정 등을 쉽게 수행할 수 있다.
      • 하지만 fetch보다 약간 성능이 느리며, 별도의 설치가 필요하다.
  • 미들웨어
    • React-Query
      • 컴포넌트 훅을 사용해 쉽게 데이터 페치 및 캐싱 관리가 가능하고 지속적으로 동기화하고 업데이트 작업을 할 수 있다.
      • 학습 곡선이 다소 높으며, 복잡한 데이터 페치 로직 구현이 어렵다.
    • Redux-thunk
      • redux와 함께 사용하여 데이터 패치 및 캐싱 로직을 자유롭게 구현 가능하다.
      • 비동기 데이터를 관리하기 위해선 관련 코드를 직접 구현해야 한다.