💻 기술스택
- 리버스 프록시 설정을 통해 사용자가 내부 서버에 접근하지 못하도록 막아서 보안을 향상 시킬 수 있다고 생각했습니다.
- 내부적으로 서버를 확장시킬 때 트래픽 분산에 용이하다고 판단했습니다.
- 싱글 스레드로 동작하는 Node.js 기반 프론트엔드 서버와 백엔드 서버를 쉽게 클러스터링할 수 있다는 장점이 있습니다.
- 클러스터 모드와 설정을 통해서 서비스를 PM2만으로 무중단 배포할 수 있어서 선택하게 되었습니다.
- 매주 데모 시연과 사용자 피드백을 받기 위해서 빈번한 배포가 일어날 것으로 예상했습니다. 이 과정에서 수동 배포는 많은 리소스가 필요하기 때문에 이 과정을 자동화할 방법을 찾게 되었습니다.
- GitHub에 친화적이라 추가적인 설정 작업 없이 GitHub 내부에서 CI/CD를 수행할 수 있다고 판단했습니다.
- 블로그 서비스이다보니 유저가 작성한 글들이 검색 엔진에 최적화되어야 한다고 생각했고, SEO를 위한 SSR를 쉽게 할 수 있는 Next.js를 선택하게 되었습니다.
- 리액트 프레임워크이므로 러닝커브가 높지 않다고 생각했습니다.
- 프레임워크기 때문에 코드 스타일을 맞추는데 드는 시간을 절약할 수 있고, 코드의 유지보수가 편합니다.
- 리액트에서 Hook을 사용하는 것과 비슷하기 때문에 러닝커브가 낮습니다.
- Context API를 사용할 경우, 상태가 변화하면서 불필요한 렌더링이 일어나는 것을 관리하기가 까다롭다고 판단했습니다.
- 컴포넌트 단위로 스타일링할 수 있어 스타일끼리 충돌이 일어날 우려가 적습니다.
- Next.js에 의해 미리 렌더링된 HTML 파일에 스타일을 적용하는 과정이 Emotion보다 까다롭지만, 직접 진행하면서 학습해보기 좋다고 생각했습니다.
- NestJS와 같은 프레임워크를 사용하는데 러닝 커브가 높다고 생각했습니다.
- Express에서 초기 구조만 잘 설계해놓으면 저희 서비스를 구현하는데 큰 문제가 없다고 생각했습니다.
- 저희 서비스에서는 사용자가 여러 책을 가지고, 책 속에 여러 글이 들어가는 구조를 가지고 있기 때문에 테이블 간의 관계를 만들 수 있는 SQL을 사용하는 것이 적절하다고 판단했습니다.
- 이 뿐만 아니라 다른 사용자가 작성한 글을 스크랩하는 기능을 제공하기 때문에 조인 테이블을 통해서 스크랩 글을 관리하는 것이 효율적으로 데이터를 다루는 것이라고 생각했습니다.
- ORM을 사용하게 되면 테이블 간의 관계를 객체로 매핑해놓고, 이를 여러 비지니스 코드에서 재사용할 수 있다고 생각했습니다.
- Prisma의 문서화가 잘 되어있고, 관련된 커뮤니티가 활성화 되어있기 때문에 이용하는데 큰 어려움이 없을 것이라고 생각했습니다.
-
Pros
- 프레임워크기 떄문에 코드 통일성이 생긴다
- 스타일링, 컴포넌트 틀 자체를 잡아주는 것 뿐 간소화는 아닐 것 같음
- SEO가 잘 된다!!
- SSR의 기능
- 마크업된 html을 뿌려줌 → 초기 렌더링 기달리는 CSR보다 나을 것 같음
- 새로운 기술 스택을 탐방해보고 싶음
- 프레임워크기 떄문에 코드 통일성이 생긴다
-
어떻게 하면 이 기술스택을 사용한 것의 장점을 보여줄 수 있을지?
- 왜 썼는지와 어떻게 동작했는지를 설명할 수 있음
- openGraph를 활용해서 우리 사이트의 글이 검색되는 모습을 보여줄 수 있을 것 같음
- CSR과 SSR의 장점을 같이 할 수 있음
- 우리가 반드시 수치적으로 증명할 필요는 없지 않을까 다만 관련된 레포를 링크할 수 있을 것 같음
-
❌Cons
- 러닝 커브가 있을 수 있다
- 근데 리액트 기반 프레임워크다 보니 그렇게 크지는 않을 것 같다
- 만약에 혹시 러닝 커브가 좀 크다면 프로젝트의 이유에 대해서 생각해봐야 할 것 같음
- 프로젝트의 이유는 역량을 보여줘야 하는 것!!
- 우리가 8주가 익숙해했던 기능이나 스택들에 좀 더 신경쓰고 다듬어서 기본기를 충실하게 잘하고 있는 것을 보여주는 것이 필요하지 않을까
- 리액트 기반이다 보니까 큰 문제는 없을 것 같음
- 러닝 커브가 있을 수 있다
- Redux
- 단점
- 불필요한 코드가 너무 많고 기업에서도 레거시로 취급 받고 있음
- 단점
- Recoil
- 장점
- 러닝커브가 적음
- 가장 핫함
- 단점
- Recoil의 기능을 어떻게 활용할지?
- Selector의 예시
- 적절하게만 사용할 수 있으면 된다!!
- 장점
SCSS
CSS in JS
-
styled-component, emotion
→ styled-component SSR의 문제가 조금 더 있기는 한것 같지만 오히려 더 좋은 학습의 경험이 될 수 있을 것 같음 [https://velog.io/@danmin20/Next.js-Typescript-Styled-component-쉽게-구축하기#styled-components](https://velog.io/@danmin20/Next.js-Typescript-Styled-component-%EC%89%BD%EA%B2%8C-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0#styled-components) [https://velog.io/@haebin/Styled-Component-Server-Side-Rendering을-위한-style-추출](https://velog.io/@haebin/Styled-Component-Server-Side-Rendering%EC%9D%84-%EC%9C%84%ED%95%9C-style-%EC%B6%94%EC%B6%9C)
솔직히 봐도 이해 안 됨….
멘토님께 여쭤보기…ㅠ
걱정 포인트 하나는 SSR과의 궁합이 높아서 성능 향상에 크리티컬한지 여부
-
장점
- 문서화가 아주 잘 되어있음
- Nest의 탄생 자체가 구조화가 안 되어있는 것에 대한 불만에서 나온 거라서 Layer 구조가 명확하게 짜져 있음
- 프레임워크로서의 장점
-
단점
- 모듈의 의존성을 주입해서 써야 하는데 안전하지만 귀찮기는 함
- 처음에는 좀 헷갈릴 수 있음 annotation
- 플젝 내부에서 백엔드가 가지는 비중도 좀 낮다고 생각
- 현재 공부해야 할 리소스가 많다보니까 추가적으로 더 배우는데 시간이 날까…?의 고민
SQL + NoSQL
- 책에 글이 어떻게 담길지에 대해서 논의가 필요하지 않을까?
- 프로젝트에서 논의된 내용을 기준으로는 SQL이 적합할 것 같음
- 상위 개념이 너무 많음
- 블럭 → 글 → 책 이 관계가 너무 깊음
- 이 관계가 단일하다면 NoSQL일 수 있는데 요 글을 누군가 가져갈 수 있다가 키포인트인 것 같음
- 관계가 많은 상황에서는 좋지 않은 것 같음
- 누군가 글을 가져갔을 때 복사를 해서 저장을 하면 관계가 생기지는 않지만 글이 업데이트 됐을 때 그 글을 가져간 책들을 다 업데이트해줘야하는 것이다보니 SQL이 적합할 것 같음
- 유니크한 한 데이터가 수정되면 걔를 계속 불러오는 개념이니까
- 해결해야 할 하나의 문제 → 블럭을 어떻게
- 큰 틀로 관계형 DB를 가져가기는 해야 할 것 같음
-
TypeORM
- 성능적으로 더 뛰어나다 (JOIN)
- 진짜 성능 개선을 위한 것이라면 Native-Query를 날려야 하는 것으로 알고 있음
- 성능적으로 더 뛰어나다 (JOIN)
-
Prisma
- 쓰기 편하고 배우기 편하다
- 리뷰어님의 추천이 떠오른다…..