코드베이스 핵심
모노레포 활용
- 앱 프로젝트에선 raw한 라이브러리 import 대신 내부 packages에 입맛대로 wrapped돼있는 패키지들을 가져다 쓰게 해야함
- 프로젝트 스코프에선 레이어를 적절히 분리해 각 레이어 간 관심사를 분리하는게 유지보수 비용 절감에 큰 도움이 된다
- 서버로부터 데이터를 호출하는 쿼리 레이어는 오로지 이것만 할 수 있도록 분리
- 더 세부적으로는 http 네트워킹을 위한 http 모듈, http 모듈을 활용해 각 엔드포인트별 응답과 요청에 맞는 정제 역할은 쿼리 레이어
- UI를 그려야하는 컴포넌트에선 데이터의 타입이 안정적인지 신경쓰지 않아야 함
- Fetcher 모델로 역할 분리
- 받아온 데이터를 정돈하고 각 블록에 꽂아주는 역할은 커스텀 훅
- UI 블록들은 역시나 각자의 작은 역할에만 충실하도록 간소화 + 일반화
- 이것들을 조립하는 중간 단위의 컴포넌트
- 서버로부터 데이터를 호출하는 쿼리 레이어는 오로지 이것만 할 수 있도록 분리
시스템 설계
권한
- 루트나 특정 한 곳에서 접근을 매번 체크하고 허가하는 방식은 x
- 루트에선 유저가 가진 권한을 정제하는 저장소만 두고, 권한 체크는 각 리소스에서 각자 실시하는게 효율적임.
- 어디든 동일한 형태로 리프 혹은 노드의 권한을 확인하려면
- 권한 객체는 트리 구조로 설계하고, 허가 여부는 서버에서, 허가됐을 때 어떤 기능들에 접근할 수 있는지 여부는 프론트에서 관리하도록 함
- 루트에서 정제할 때 프론트에 저장돼있는 접근 트리(서버 권한과 동일구조 + 사용 가능한 리소스 배열 리프)를 체크하는 API를 쓸 수 있는 모듈 구현
- 권한 모듈을 각 리소스에서 호출하고 어떤 위치인지만 걸어주면 심리스하게 체크가능
기능플래그
- 기능플래그는 권한과 언뜻 비슷하지만 더 세부적인 것들을 컨트롤한다는 점에 있어 살짝 다름
- 테마 색깔, 시스템 버전, 검색 필터에서 허용해줄 옵션 혹은 메타데이터 같은 것들을 설정함. 권한은 1차원적인 접근여부만
- 권한과 비슷하게 루트에서 flags 맵을 설정. 아직 예시만 구현돼있어서 확인은 못했지만 이것도 서버로부터 유저별로 받아와 주입해주는 방식일듯
- 각 컴포넌트에선 useFeatureFlag(리소스 위치) 훅으로 각종 옵션들을 받아서 컴포넌트에 뿌려준다. 그러면 컴포넌트는 옵션에 맞게 렌더만 해주면 됨
국제화(번역)
- 프로젝트가 여러개일 때 프로젝트별로 번역 리소스를 관리하면 중복되는 것도 많고 비효율적임. 이 땐 공통 리소스 파일을 두고 가져다 쓰는 방식으로 비효율을 줄임
- 번역 리소스 계층에 대해서:
- 도메인별로 계층을 나누는 것(e.g. bank-account, carrier)이 과연 효율적일까?
- 어디까지 구분을 하고 나누는 것이 의미가 있을까
- 지금은 서브도메인 - 리소스(properties, actions, action-results, description, text …) - 필드명(cancel, add, confirm / name, address, phone …) 구조임
UI, 유틸리티 리소스
- 얘넨 공통되는 애들 뽑아놓고 관리하는 패키지
- 디자인 시스템에 대한 작업자들의 지속적인 관리 및 협의(얼마만큼의 자유도를 줄지)가 필요함