기술 스택
Common:
- TypeScript
- yarn berry
- ESLint
- Prettier
- dotenv vault
Front-end:
- Vite
- React
- SCSS
- (상태관리 논의 중)
Back-end:
- Express
DB:
- MongoDB
CI/CD:
- github Action
Testing:
- Jest
- 세영: 구현체들이 사용하는 인터페이스 타입을 정할 수 있다는 점이 협업할 때 확실히 효율적이에요.
- 도훈: 협업을 위해서 타입이 필요하다고 느꼈어요. 그리고 인터페이스나 추상클래스를 사용할 수 있다는 점이 js에 비해서 장점이라고 생각해요.
- 주영: 협업할 때 타입 정해놓는게 좋을 것 같아요. 버그 잡기도 쉬워서 좋아요.
성능과 팀원들의 사용 경험을 고려할 때 yarn berry를 사용하는게 좋겠다고 결정했어요.
성능으로 미뤄 보건데,
yarn berry+Plug n Play strict가 가장 설치도 빠르고 디스크 효율적인 모습을 보여주었고, 그다음으로는 pnpm이 뒤를 이었다.
- 세영: yarn berry 사용해봤는데 자동화 배포 서버에서 설치, 빌드 속도가 빠르다는 점이 강점이었어요. pnpm도 효율적인 방식을 사용하는 것 같지만 (안써봐서)… 이것도 나중에 공부…
- 도훈: 성능, 디스크 효율성, 속도면에서 뛰어나다고 해요.
- 주영: 둘다 좋아요.. npm, yarn보다 빠르잖아요 ..
속도가 빨라요. CI/CD에 있어서 장점이에요.
- 세영: 빠른 이유에 대해서 나중에 공부해볼게요. 써보면 공부할 것 같아서 좋아요.
- 도훈: HMR이 빨라서 개발환경에서 매우 큰 장점이라고 생각해요.
- 주영: 안써봤지만 빠른 빌드 속도가 탐나서 써보고 싶어요.
- 세영: css props 활용할 수 있다는 점이 편해요. 사용한다면 emotion보다는 styled-component가 더 편리하게 스타일을 분리할 수 있는 것 같아요.
- 도훈: props를 활용할 수 있고, 컴포넌트와 스타일을 같이 작성해서 파일 관리가 비교적 쉽다고 생각했어요. 또 ts의 변수도 같이 공유할 수 있다는 점이 좋아요.
- 주영: html 태그를 쓰지 않고 스타일 태그를 직접 만들어 쓰는 점이 불편했어요.
- 태그마다 스타일 변수를 만들어 주기는 불편해요. 그렇지 않으면 클래스네임을 써야하는데 css-in-css 와 비교했을 때 큰 장점이 되는지 모르겠어요
- 저희 서비스에 props를 잘 활용할 만한 부분을 잘 모르겠어요. css-in-css 로도 충분히 컬러
- 주영: 실시간성 서비스이기 때문에 렌더링마다 스타일이 로드되는 css-in-js 보다는 초기에만 로딩되는 css-in-css가 좋을 거 같다는 의견이에요
- css-in-js와 다르게 확장자로 스타일 파일임이 확실히 보여서 좋아요.
- 스타일 변수를 따로 export/import 해주지 않아도 돼서 좋아요.
- 주영: 전역으로 관리해야할 데이터가 없는거 같아요 사용여부를 고려해봐야 할 거 같아요
- 주영: 써본 경험이 있어서 러닝커브가 줄어들어서 좋아요 + 사용하기 쉬워서 편해요
- 도훈: flux 패턴이라서 이벤트 흐름을 추적하기 편하다고 생각하고, 곰이 귀여워요.
- 세영: 써봤는데 배우기 쉬웠고 참고할 자료도 많을 것 같아서 좋아요.
- 주영: 제대로 사용안해봐서 러닝커브가 좀 있다. 아직 정식버전이 아니기 때문에 zustand에 마음이 가요
- 도훈: 제대로 사용안해봤지만 React 친화적으로 보여서 호감이에요.
- 세영: 얘도 쓰기 쉽고 React와 함께 사용했을 때 시너지가 있어서 좋아요.
- 도훈: 어감이 별로에요.
- 팀 생성, join에 사이드바에 반영되어야 함
- 새로운 문서 생성되면 목록에 반영되어야 함
- 주영: 실시간성 서비스에는 캐싱할 데이터가 없기 때문에 서버 상태 관리 라이브러리를 사용한 만큼의 큰 이점을 불러오지 못할 거 같아요. 그냥 데이터 패치에 한번 사용해봤다 정도로 끝날 거 같아요. 실시간이 아닌 데이터는 워크스페이스 추가 정도인 것 같은데 이 기능 하나에 사용하기에는 오버 엔지리어링이 아닐까 생각이 들었어요
- 세영: 이 결정을 내리기 위해서 소켓 사용과 공유문서 구현 방식에 대한 논의가 필요해요.
- 저희가 기술적으로 중점을 두어야 할 부분이 어디일까요? 저는 공유문서 동시성 제어와 지연시간 최소화 == 효율적인 업데이트 방식과 소켓 서버 설계라고 생각했어요.
👍 서버 상태가 업데이트 되었을 때 refetch 속도가 빠름
react-query mutate는 캐시를 invalidate하고 다시 fetch하는 형태라서 SWR이 더 빠름
- 주영: 써본 경험이 있어서 러닝커브가 줄어들어서 좋다 + 사용하기 편해요
- 세영: 저도 써본 경험이 있어서 편하고, mutate로 컨트롤하기 쉬워서 좋아요
- 👍 번들 사이즈가 작음, 빠른 fetch
주영: react-query, zustand
도훈: react-query, zustand
세영: react-query, recoil
설계를 프레임워크가 만들어줘서 통일된 구조 위에서 협업할 수 있어요.
swagger 문서를 자동으로 달 수 있어요.
- 도훈: 구조가 미리 잡혀져 있어서 이 부분에 대해서 부담을 덜 수 있고. 생산성 향상을 기대할 수 있어요. 하지만 새로운 기술을 배워야 한다는게 부담이 돼요.
- 주영: 사용안해봤지만, 구조가 잡혀있어서 좋다. 배우는 데 조금 걸릴 것 같지만 swagger 달려있어서 좋아요.
- 세영: 간단한 실습 해봤는데 좋아보이긴하네요.. 사용은 어렵지 않은데 설계를 잘 하려면 공부가 필요할 것 같아요. 테스트 코드나 swagger 등이 이미 달려있어서 편리한 부분도 많아보여요.
import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';
@Controller()
export class AppController {
constructor(private readonly appService: AppService) {}
@Get()
getHello(): string {
return this.appService.getHello();
}
}- 세영: 다같이 아키텍처 이해만 맞춰두면 러닝커브가 없어요. 자유도가 높아서 어떤 생각으로 설계했는지가 드러날 수 있다는 것도 장점이 될 것 같아요.
- 주영: 다들 사용해봐서 러닝커브가 없어요. 저도 이거요.
- 도훈: 러닝커브가 없고 자유롭게 아키텍쳐를 설계할 수 있어요. 설계 과정에서 4명 모두가 이 프로젝트에 대해서 충분히 이해할 수 있을것 같아요.
- 원희: 저는 이거요
👍 Nest 설계 위에서 함수 단위로만 고민하면 됨
👎 제대로 알고 사용하지 못할 것 같아서, Express 사용할 때와 큰 차이를 모르겠음
11/10 16:16 도훈님: “세 명이서 같이 이야기하고”
→ 한명은 누구..?
→ 그러니까요; 그럴리가;;
→ 한명: 백도훈
→ 급포장..
-
유저
-
워크스페이스
-
기능 블록
-
회의록
- 회의록의 구성요소인 블록은 여러가지 타입을 가질 수 있음
- 엄청나게 자주 바뀌는 데이터임
// 회의록 하나의 데이터
{
id: 1,
name: '왭의 회의록',
blocks: [
{ type: 'p', content: '어쩌고' },
{ type: 'h1', content: '이건 제목입니다' },
{ type: 'vote', category: [], content: [] }
]
}RDBMS보다는 key-value를 사용하는게 적합할 것 같아요.
우선 MongoDB를 쓰고 캐싱 DB는 천천히 생각해보기!
- 세영: 프로젝트 셋업에 꼭 필요한 것들(패키지 매니저, 사용할 기본 프레임워크 등)은 어느정도 정리된 것 같아요. 상태관리 방식은 아직 어떤 상태와 문제상황이 있는지 정리되지 않은 상황에서 이야기하기에 시기상조라는 생각이 들어요. 설계를 해보고 논의하자고 제안하고 싶어요.
