프론트엔드 기술스택 및 아키텍처

프론트엔드  

Language : JavaScript & TypeScript

Library & Framework : React, NextJS

상태관리 : redux

비동기 데이터 패칭 : redux-thunk

CSS디자인 : TailwindCSS

Test : Jest,React Testing Library, Cypress

.

.

.

우선 이번 프론트엔드 파트에서 사용할 언어 및 프레임워크, 인프라들이다.

파트 별로 왜 해당 언어 와 프레임워크 인프라들을 사용했는지를 기록해보자.

.

.

.

Language : TypeScript

https://moca9012.tistory.com/510.

백엔드 기술스택 및 아키텍쳐

타입스크립트의 사용이유는 이전 백엔드 기술스택 및 아키텍처에 포스팅이 되어있다.

.

.

.

Library & Framework : React, NextJS

현재 2023년 9월 19일 기준으로 최근 1년간의 프론트엔드에서 가장 인기가 많은 프레임워크들이다.

또한 오른쪽 2021년 StackOverFlow에서 조사한 웹 프레임워크 사용 순위에서 백 프론트 통합으로 

압도적 1위인것을 확인할 수 있다.

물론 vue의 사용이 증가 하고 있지만 현재 국내시장에서는 더욱더 리액트 시장이 압도적으로 넓다.

그래서 백엔드 개발만 해왔던 나는 가장 많은 레퍼런스와 많은 사람들이 오랜시간 사용한 리액트를 택하게 되었다.

.

.

.

처음에는 리액트만 사용하여 프론트 개발을 하려고 하였지만 백엔드 개발자를 목표로 전반적인 웹 생태 사이클을 파악하기 위해 프론트까지 개발을 하며이후 Spring를 공부하며 내가 만든 프론트엔드 단을 연결하며 다른 백엔드 프레임워크를 공부할 계획이 있기에 프론트 단도 하나의 프레임워크를 잡고 완성된 프론트를 만들고 싶어졌다....또한 리액트 기반 프레임워크인 NextJS가 1위로 있었기에 Next를 택하게 되으며현재 프론트에서 렌더링 방식이 SSR를 지향 하고 있다.

출처 : https://www.youtube.com/@codingapple

부가적으로 리액트만 사용하면 라우팅을 위해 각종 라이브러리를 사용해야 하지만

next를 사용하면 폴더/파일 시스템으로 관리를 할수 있으며 slug를 활용한 동적 라우팅기능을 제공하는 점 또한

next를 선택하게 한 이유 였다.

.

.

무엇보다 Next를 사용하게된 가장 큰 이유는 우선 SEO 최적화를 할수 있다.

즉, 구글과 같은 검색엔진에서 상위 노출을 시킬수 있다는 것이고

그것은 많은 사용자의 유입으로 이러져 다중의 사용자를 가진 서비스를 유지보수해보고싶다는

나의 첫 목표와 가장큰 연관이 있어서 고르게 되었다.

.

.

.

상태관리 : redux

우선 프론트엔드 공부를 하며 가장 많은 고민을 했던것이 이번 프로젝트에서

어떻게 상태관리를 할 것인가 였다.

물론 상태관리가 없어도 개발에 큰 문제가 없었지만 해당 프로젝트를 1년 6개월간의 기간을 가진 채

유지보수를 할 계획이라 프로젝트의 사이즈가 커질것이 생각하여 Props 드릴링(Props drilling)이

심해 질것을 고려해 상태 관리 라이브러리를 사용하기로 하였다.

.

.

.

그 후보 군으로는 총 3가지가 있었다.

1. ContextAPI(리액트 내장 API)

2. useReducer(리액트 내장 훅)

3. Redux(라이브러리)

4. SWR(라이브러리)

5.recoil(라이브러리)

.

하나씩 장단점을 비교해보자.

결론적으로 기능이 가장 좋고 강력할수록 사용법이 어렵다는 트레이드오프가 있다.

우선 각각의 상태관리를 모두 사용하여 사이드 프로젝트를 진행해본결과 결론적으로 Redux를 이번 프로젝트로 사용 하게 되었다.

그 이유로 우선 redux자체에 대한 사용법은 확실히 어려웠고 코드량이 상당히 많았다.

하지만 redux-toolkit을 사용하면 코드량을 여전히 꽤나 많지만 사용법은 그나마 덜 어렵게 사용할 수 있었다.

또한 위에서 말한바와 같이 프로젝트의 크기가 점점 거질것을 고려하고 진행하는과정에서

내가 원하는 필요를 느낀 기능을 추가할 수록 더 체계적으로 관리하고 싶은 욕심에 Redux를 사용하게 되었다.

.

.

.

비동기 데이터 패칭 : redux-thunk

상태관리와 마찬가지로 비동기 데이터 패칭 또한 어떤 라이브러리를 사용해서 처리할지 고민을 많이 하였다.

Nextjs와 궁합이 너무 좋은 swr과 최근 떠오르고 있으며  react-qeury와 redux의 thunk, saga

총 4개를 후보군으로 두고 고민을 가졌다.

.

.

결론적으로 redux-thunk를 사용할 것이다.

상태 관리를 redux로 할계획이라 thunk나 saga를 고려 하고 있는 상태에서

saga는 더 많은 기술과 기능이있는 반면 generator 개념에 대한 깊은 이해가 필요 해서

러닝 커브가 걱정되서 선택하지 않았고 안그래도 상태관리에 redux가 오버 엔지니어링이 아닐까 

하는 생각이 있던 참이라 상대적으로 작은 러닝커브를 가진 thunk에 더 눈이 가게 되었다.
또한 무엇보다 아래 표와 같이 사용량이 가장 많은  라이브러리가 thunk이다.

.

.

.

그 이유롤 짧게 기록하자면 요즘 많은 사람들에게 각광 받고 있는 react-query는 이상하게 

나와 취향(?)이 안맞았다..또한 swr또한 뭔가 next와 궁합이 좋지만 나랑 안맞는다는 생각이 들었다.

아마도 레퍼런스들이 redux에 비해 압도적으로 부족해서 그런 이유가 가장 큰것 같다.

 

 

 

.

.

.

CSS디자인 : TailwindCSS

우선 현재의 난 css디자인에는 전혀 관심이 없다.

차후 피그마로 프로토 타이핑이 끝난후 최대한 가시적으로만 불편하지 않을 정도로

UI /UX 디자인을 할 것이며 그저 코드에 대한 가독성을 위해 TailwindCSS를 택하였다.

.

.

.

아무래도 CSS 디자인 라이브러리는 취향이 많이 탄다고 생각을 한다.

우선 후보군으로 1.tailwind 2. styled-components 3. emotion이 있었다.

크게 코드 작성 및 형태로 보면 1. tailwind 2.emotion(styled-components)로 나뉜다.

.

.

.
tailwind의 경우  클래스 네임에 속성으로 스타일 디자인을 한며

styled-components의 경우  태그로 스타일 디자인을 하는게 가장큰 특징이다.

위의 왼쪽 코드는 styled-components를 사용 하여 작성한 코드 이다.

컴포넌트의 return 단에 너무 많은 스타일 컴포넌트 태그 들로 인해 하위의 컴포넌트들이 한눈에 들어 오지 않는다.(나는.)

.

.

오른쪽 코드는 tailwind를 사용하여 작성한 코드로 물론 다른 페이지지만 확실히 컴포넌트 태그가 몇개 없어 

가독성이 좋게 느껴지며 전체적인 코드량이 줄는것을 알 수 있다.

위의 통계를 보면 대체로 비슷한 사용량 보이며 개발자의 취향에 따라 디자인 라이브러리를 택한다는것을 확인할 수 있다.

 

.

.

.

Test : Jest,React Testing Library, Cypress

테스트 관련 기술 스택은 아직 공부해보지 못했지만 가장 많은 사용량과 레퍼런스가 있는

Jest,React Testing Library, Cypress를 선택