프로젝트를 마치며
대략 두 달간동안 개인 프로젝트를 하며 진행했다. 취준을 하던차에 자기소개서들을 작성하면서 작성했던 자기소개서를 보기좋게 관리해주는 서비스가있다면 좋겠다는 생각으로 직접 만들어봐야겠다싶어 시작하게 되었다.
혼자서 프로젝트를 하면서 확실히 협업의 중요성을 더욱 느껴지게 되었다. 협업을 통해서 팀원들과 데이터의 스키마를 같이 상의하거나 어떤 라이브러리가 더 적합할지에 대한 협의가 필요한데 혼자서 하려하니 이게 과연 적합할지에 대한 고민을 공유하기에 다소 부족함이 있었다. 그리고 UI/UX적인 요소도 팀원들과 의논을 통해서 진행했다면 더욱 짧은 시간안에 완성될 수 있지 않았을까하는 생각을 갖게 되었다. 😭 😭
자기소개서 관리 서비스
- 재사용을 고려한 UI컴포넌트 만들기
- Styled-component에서 emotion 사용하기
- API 명세서도 작성해보기
- 데이터를 상태관리 or 캐싱된 데이터 사용하기
- Auth를 검증을 위한 미들웨어 설정과 jwt 토큰을 사용하기
- vercel을 통해 모노 레포 배포
작업 기간
2023.02 ~ 2023.04
기술 스택
- FE - React / React query / emotion / recoil / Axios
- BE - Express / firebase
라이브러리 선정
Redux vs React Query
이번 프로젝트에서는 상태관리에 대해서 어떤 라이브러리를 사용할까에 대한 고민이 있었다. 상태관리를 위한 대표적인 라이브러리로 Redux가 있고, 서버의 상태관리를 관리하는 라이브러리로 React Query가 있다. Redux와 React Query는 모두 React 애플리케이션에서 상태를 관리하기 위한 라이브러리이지만, 사용목적에 따라서 차이가 있다.
What is Purpose of Redux?
Redux는 상태를 전역적으로 관리하는 데 중점을 두고 있지만, React Query는 데이터 가져오기와 캐싱에 중점을 두고 있다. 따라서, Redux는 대규모 애플리케이션의 복잡한 상태 관리에 적합하며, 상태가 전역에서 공유되는 경우에 사용하는 것이 적합하다.
What is Purpose of React Query?
React Query는 API 호출과 데이터 캐싱을 간단하게 처리하기 위한 목적으로 React Query는 각각의 데이터를 독립적으로 가져오고 관리하며, 컴포넌트 단위로 사용된다. 따라서 SPA나 중간 규모의 애플리케이션에 적합성이 있다.
사용자 개인의 데이터르 관리하는 서비스로서
CRUD가 많기에 보다 나은 사용경험을 적용하기 위해서 React Query로 캐싱된 데이터를 이용하는 것이 좀 더 적합하지 않을까(?)하는 생각이 들어 React Query를 사용했다.
Emotion vs Styled-component
CSS-in-JS의 라이브러리로 대표적으로 Emotion 과 styled-components가 있다. 블로그나 사이트들 등을 참고해보니 대게 emotion이 styled-components보다 조금 가볍고 빠르다고 알려져있다.
그렇다면 어떤 차이점이?
문법?
- emotion의 경우 css props로 css를 더 활용도 높게 조립할 수 있었다. 이를 통해 프로젝트의 UI와 관련된 컴포넌트에 대해서 커스텀이 쉽게 사용이 가능하다고 생각 되었다.
- 예를들어서 재사용 가능한
Button을 만들었을때 추가적인 CSS요소가 필요할 수 있었다. 이떄CSSProps를 내려주므로써 그때그떄 대응이 편리했다.
서버 렌더링
- Emotion은 서버 측 렌더링을 지원하고, styled-components는 서버 측 렌더링을 지원하지만 구현 방법이 Emotion과 다르다. 하지만, SSR로 구현한 것은 아니었으니 이건 패스였다. 나중에 Next.js를 활용할때 사용하면 더 적합할 것 같다.
JSX pragma
- 물론 emotion의 경우 단점이라면 스타일을 추가하고 싶을 떄,
/** @jsx jsx */을 컴포넌트마다 작성해야하는 단점이 있었다.
결론적으로 테마나 글로벌 스타일을 전역적으로 타입을 선언해서 사용하는 것에 더 사용이 유용하여 emtion을 적용하였다.
진행하며 고민했던 부분들?
- 임시 저장 기능
- 검색 기능
임시 저장 기능
사용자들이 자기소개서 작성을 할 때, 사람마다 스타일이 있겠지만 나같은 경우도 벨로그와 같은 글을 작성할 때, 수시로 임시저장 기능을 한다. 그렇기떄문에 임시 저장을 구현해야겠다는 생각을 하게 되었다.
먼저 사용자의 입장에서 사용 흐름을 정리해보면 다음과 같았다
임시 저장 기능 서비스 흐름
1. 글을 작성하기 위해 + 버튼을 누른다.
2. 글 작성 페이지로 들어간다.
3. 글을 작성하던 도중 임시 저장 버튼을 누른다.
4. 뒤로가기 혹은 다른 네비게이션 메뉴 버튼을 클릭 후, 페이지 이동을 한다.
5. 다시 작성했던 글을 보기 위해 임시 글 페이지에 들어간다.
6. 임시 글 목록에서 해당 글을 클릭한뒤, 작성 페이지로 이동한다.
7. 이때 이동시 해당 글의 페이지 url은 /parma가 뒤에 들어간다.
8. 이에 맞게 데이터가 불러와진다.
따라서, 글을 작성하는 행위에 있어서 작성 페이지, 작성한 글의 상세 페이지가 필요했다.
결국 기능은 비슷하기에 하나의 컴포넌트에서 재사용이 가능하도록 구현하는 것이 좋겠다는 생각을 하게 되었다.
POST / PUT 어떻게 구분할까?
초기에 작성할 때는 POST를 해야하고, 도중에 임시 저장을 할 땐, PUT을 해야하는데 이때를 어떻게 구분을 할 수 있을까 생각을 하였을때, 단순히 useState로 상태관리해보자니 새로고침시 다시 초기화된다는 단점이 있었다 따라서, Recoil을 통해 전역상태 라이브러리를 사용하여 새로고침에도 대응하는 것이 좋겠다 판단 하였다.
페이지에 들어올 때, /:id params가 없다면 빈문자열을 전역상태로 넣고, 있을 경우에 해당 /:id params를 전역상태에 넣어준다.
- 임시 저장버튼을 누를때, id의 전역상태가 없다면 HTTP요청으로
POST를 사용하고 return된 데이터의 id를 전역상태로 관리해준다. - 그리고 다시 임시저장 기능때 전역상태의 id가 있다면, HTTP 요청을 PUT로 하게 해주면서, 임시 저장의 기능을 구현할 수 있었다.
검색 기능
처음에 Server-side에서 /api/v1/search의 라우터를 통해 검색 로직을 작성하다보니 한가지 의문이 들었다.
과연 나의 데이터안에서 검색 요청을 하는 것인데, 굳이 api 요청을 하는 것이 적합할까??
어쨋든 firebase 내에서도 쿼리를 통해 데이터를 찾고 해당 데이터를 가져오고 가져온 데이터를 뿌려주는 역할을 하겠지만 보다 많은 유저가 사용하고 많은 데이터가 있을 경우 개인의 데이터를 찾기에 이러한 방법이 적합할지 의문이었다.
그렇다면 적합한 것은?
React Query
React query의 가장 강력한 위력은 데이터 캐싱에 있지 않을까 한다. 미리 캐싱된 데이터를 가공 처리하여 검색할 때마다 보여주면 굳이 검색 요청을 하지 않아도 되기에 요청의 비용도 줄일 수 있었다.
프로젝트의 회고
혼자서 진행하다보니 정말 많은 공부와 지식을 쌓는 좋은 경험이었지만 반대로 아주 베이스가 되는 부분들 부터 서버와 데이터 스키마 등 기능적인 부분에서도 혼자서 고민하며 진행하다보니 시간적 소요가 정말 길어졌지 않을까 했다.😇😇
하지만 혼자인 나에게 한줄기 빛 같던 선생님이 있었는데 그건 바로 The King GPT!!!
물론 GPT자체에만 의존한다면 정말 검증도 되지 않은? 코드들을 알려주거나 확실치 않은 답변을 내려줄때가 많다. 따라서 공식문서와 적절히 교차 검증은 필수이다.
덕분에 일의 능률이나 생산성이 정말 크게 상승될 수 있었던 The King GPT야 고맙다!
