1. GOLFANI 기술 스택

구분	선택
웹 프레임워크	React
서버사이드 프레임워크	NextJS
프로그래밍 언어	TypeScript
상태 관리 라이브러리	Redux
비동기 미들웨어 라이브러리	Redux-Saga
서버 상태 관리 라이브러리	React-Query

skill-stack

2. React를 선택한 이유

최근 웹사이트들이 고도화 되면서 한 페이지에 해당하는 용량이 커지고 정적 사이트 -> 동적 사이트가 늘어나게 되었습니다. UI 를 동적으로 나타내기 위해서는 복잡하고 많은 양의 상태를 관리해야 하고, 한 페이지가 가지고있는 파일양이 많아짐에 따라 페이지 이동시 새로운 페이지를 전달하는 속도가 느려지게 되었습니다.

SPA 등장

위 문제를 해결하기 위해 SPA(Single Page Application)이 등장하였습니다. SPA 는 이름 그대로 전체 페이지를 하나의 페이지에 담아 동적으로 페이지를 표현해 줍니다. SPA 는 HTML,CSS,Javascript파일을 최초 1회만 로드하며, 이후 Javascript 파일을 통해 필요한 파일을 조작하여 동작하게 됩니다.

Why React

이러한 SPA 프레임워크의 대표적인 주자들은 React, Vue, Angular 가 존재합니다.

가장 인기있고, 생태계가 넓다 React 는 현재 가장 인기있는 SPA 프레임워크 입니다. 실제로 서비스를 개발하다보면 여러가지 시행착오들을 겪게됩니다. 이러한 과정중 커뮤니티가 활발하고 사람들이 가장 많이사용하는 프레임워크를 선택하게 되면 보다 쉽게 어려움을 헤쳐나갈수 있고 방대한 자료로 배워나가는데 지장이 없습니다.
Virtual DOM React 는 Virtual DOM을 통해 렌더링을 진행하는데, 먼저 Virtual DOM 을 그린후 실제 DOM 과 비교하여 변경점이 있는 부분만 교체하여 화면을 렌더링 하기 때문에 빠른 속도로 UI 를 렌더링 할 수 있습니다.
컴포넌트 재사용 컴포넌트 UI를 구성하는 작은 단위입니다. 한 화면은 이러한 컴포넌트들을 조합하여 만들어지는데 컴포넌트들을 다른 화면에서 쉽게 재사용 할 수 있고, 컴포넌트를 통해 유지보수를 쉽게 할 수 있습니다.

3. Next.js를 선택한 이유

현재 GOLFANI 에서는 스토어 페이지를 통해 유저들에게 스토어 페이지 와 골프장비 구매 서비스들을 제공 해주고 있습니다. GOLFANI 에서 스토어를 운영하고있는 유저 입장에서는 자기의 스토어 페이지가 노출되길 원하고, 자신이 판매중인 장비가 노출되길 원합니다. 또한 스토어 나 골프장비를 검색했을때 GOLFANI 스토어로 유도하기 위해 GOLFANI 입장에서도 각각의 페이지들의 정보가 노출되길 원합니다.

SEO(검색 엔진 최적화)를 좋게하고 싶고, HTML의 메타데이터를 잘 활용하고 싶어 SSR 구현이 필요했습니다. 따라서 SSR 방식을 사용하는 Next.js 를 통해서 SSR, SSG 를 활용하여 GOLFANI 서비스 구현이 가능합니다.

SSR?

SSR 은 Server-Side-Rendering 의 약자로 클라이언트가 아닌 서버측에서 사용자에게 렌더링될 HTML을 응답하는 방식입니다.

Next.js 에서는 Pre-Rendering 방식으로 SSR를 제공합니다. Pre-Rendering 을 언제, 어떻게 제공하는 방식에 따라 Next.js 식 SSR, SSG(Static Generation)으로 나뉘게 됩니다.

SSG SSG 는 빌드타임에 각 페이지들에 대한 HTML 파일을 만들어 Static 문서로 가지고 있습니다. 사용자가 페이지를 요청하게 되면 서버에서 생성하여 만들어지는 것이 아니라 Static 문서를 제공하여 응답속도가 매우 빠릅니다.

SSR SSR 은 사용자가 페이지 요청을 하게되면 각 요청마다 서버에서 HTML 문서를 생성하여 제공합니다.

4. Typescript를 선택한 이유

Javascript 의 장점이자 단점은 타입을 명시하지 않는 점입니다.

타입을 명시하지 않으면 작은 규모의 프로젝트, 소규모 코드에서는 편리하고 쉽게 코드를 작성할 수 있습니다.
하지만, 프로젝트의 규모가 커지게 되면 타입으로 인한 버그가 발생할 확률이 높아지게 됩니다.

버그가 발생하게 되면 어디에서 발생했는지 찾는것이 쉽지 않기때문에 큰 규모의 프로젝트에서 Javascript를 사용하는 것은 부담이 될 수 있습니다.

타입을 명시하는 TypeScript는 이러한 단점을 보완 할 수 있습니다. 또, TypeScript를 사용하게 되면 얻는 이점이 존재합니다.

TypeScript는 정적타입으로 메모리 사용량을 줄일수 있습니다.
컴파일 단계에서 버그를 잡을수 있습니다.
개발시 더 좋은 퍼포먼스를 발휘할수 있습니다.
    - 객체 필드, 함수 인자로 사용되는 Type을 알 수 있게되어 편리한 코드 작성이 가능합니다.

5. Rudux를 선택한 이유

웹 어플리케이션에서는 컴포넌트 별로 많은 데이터를 관리하게 되는데, 이때 규모가 커지게 될경우 부모 컴포넌트에서 자식 컴포넌트들간의 상태(데이터)들을 관리하는 것이 복잡해 지게 됩니다.

부모 컴포넌트에서 하위(자식)컴포넌트로 상태를 전달하려면 여러 컴포넌트를 거쳐 내려줘야합니다.

이렇게 컴포넌트 별로 관리하는 상태들을 한곳으로 모아서 상태를 관리할 필요가 있습니다.

상태관리를 도와주는 도구들이 몇가지 존재합니다.

리액트 Context-API
Mobx
Redux

Why Redux?

Redux는 현재 많은곳에서 사용되고있는 상태관리 라이브러리 입니다. 또한 리덕스는 React에 종속되어있지 않기 때문에 개념을 이해하게 되면 다른 곳에서도 사용 가능합니다.

React를 선택한 이유와 비슷하게 많이 쓰이는 라이브러리이기 때문에 문제를 해결하기 수월하고 리덕스에대한 지식을 쌓기 불편하지 않습니다.

리덕스에 대한 얘기는 추후 따로 다루도록 하겠습니다.

6. React-query를 선택한 이유

웹 어플리케이션에서 관리하는 상태는 컴포넌트에서 사용되는 데이터만 존재하는 것이 아니라
서버통신(비동기 요청)으로 가져오는 데이터들을 관리해야 합니다.

서버데이터들도 useState, Redux를 통해서만 관리하게 되면 상당히 복잡하게 됩니다. Redux에서 서버데이터를 관리하기 위해 비동기 미들웨어를 따로 사용해야하고 그때 발생하는 보일러플레이트 코드들이 많아지고 복잡하게 느껴집니다.

따라서 서버상태를 관리를 따로 해주는게 좋다고 생각하여 서버상태관리 라이브러리를 도입하기로 하였습니다.

Why React-Query

대표적인 서버상태관리 라이브러리는 React-Query 와 SWR이 존재합니다. 두 라이브러리는 대부분 비슷한 기능을 제공해줍니다.

서버상태관리 라이브러리는 보통 데이터를 가져오는 기능을 하게됩니다. 하지만 POST, DELETE 와 같은 요청이 필요할때가 있는데 React-Query 에서는 mutation Hook을 통해 쉽게 가능합니다.

또한 React-Query 에서는 쿼리가 비활성상태에서 일정시간 이상 지나게 되면 garbage로 수집할 수 있습니다. SWR 에서는 이러한 기능이 제공되지 않아 직접 캐쉬를 조작해야합니다.

이러한 점에서 조금더 편리한 React-Query 를 선탁하게 되었습니다.

GOLFANI-TECH-BLOG

목차