docs(feature): add activity cms specification (feature 2) (#1)#2
docs(feature): add activity cms specification (feature 2) (#1)#2all4null wants to merge 6 commits intoquipu-uos:mainfrom
Conversation
There was a problem hiding this comment.
문서 내 용어 혼용(Type/탭, Content/게시물/카드)으로 개발 시 네이밍에 어려움이 있을 거 같습니다.
아래와 같이 용어를 통일하면 어떨지 검토해주세요.
Type: 활동 분류 단위 (name, 예:study)Field: 스키마 항목 (label+key, 예:label="작성일",key="writtenAt")Item: 실제 데이터 레코드 (data객체, 예:data.writtenAt = "...")
즉 구조는 Type > Field > Item으로 고정하고, 실제 값은 Item.data로 관리하는 구조입니다.
There was a problem hiding this comment.
각 Type 공개 여부(isActive)
각 Content 공개 여부(isVisible)
라고 이해했습니다.
Activity 섹션의 목적은 동아리 활동의 상세 기록을 담는 포럼이 아니라,
우리 동아리가 어떤 활동을 하는지 보여주는 홍보용 대표 콘텐츠를 노출하는 데 있다고 생각합니다.
그래서 저장된 데이터 중에 모집 시기나 운영 시점에 맞춰 노출 대상을 조절할 수 있는 이러한 기능(공개 여부 조절, 드래그로 순서 변경)이 있으면 상당히 편할 거 같습니다.
이걸 편하고 안전하게 컨트롤 할 수 있도록 UX에 더욱 신경을 쓰면 좋을 거 같습니다.
There was a problem hiding this comment.
이미지 업로드 기능에서 AWS S3는 과금이 붙기 때문에 Cloudflare R2를 쓰는게 좋을 거 같습니다. 이건 개발을 할때부터 Quipu 계정으로 만들면 좋을 거 같아서, 개발을 시작할 때 저에게 말씀주시면 Quipu 이메일 계정 알려드리겠습니다. 이걸로 Cloudflare에 가입해서 사용하면 됩니다.
상세 구현 계획상 이미지는 업로드 즉시 클라우드에 저장되고 URL을 발급받는 흐름으로 이해했습니다.
이 경우 사용자가 작성 중 취소/이탈하면 미사용 이미지가 스토리지에 누적될 수 있는데,
취소 시 즉시 삭제 쪽으로 방법을 고려해주시면 좋겠습니다.
There was a problem hiding this comment.
type.name, field.label 같은 변경 가능한 문자열을 식별 key로 사용하는 것은 위험해 보입니다.
해당 값들은 언제든지 수정될 수 있으므로,
참조 기준은 별도의 immutable id(typeId, fieldId)로 두는 것이 안전할 것 같습니다.
표시용 이름(name, label)은 언제든 변경 가능하게 분리하면 좋겠습니다.
There was a problem hiding this comment.
백오피스와 메인이 동일 MongoDB를 직접 조회하는 구조인지,
혹은 한쪽(예: 백오피스 백엔드)이 API를 제공하고 다른 쪽이 이를 구독하는 구조인지 문서에 명확히 기재하면 좋겠습니다.
서비스 의존도를 낮추고 운영 단순화를 위해서는,
기존처럼 각 서비스가 동일 DB를 직접 조회하는 구조가 더 적합해 보입니다.
2 participants
Changes
Implementation
Type, Field, Content3단계로 명확히 분리하여 설계ActivityTypes,ActivityContents컬렉션 모델 설계map순회 및 Fallback 렌더링 로직 정의.sort({ order: 1 })) 방식 지정Notes
Closes #1