Skip to content

1주차 회의록

Jump to bottom
DongHwan Kim edited this page Nov 4, 2021 · 10 revisions

10월 25일 (월)

프로젝트 아이디어 브레인스토밍

  • 팀원 모두가 완전히 이해할 수 있는 코드를 작성하자!
  • 4주 꽉 채울 수 있는 프로젝트 (5주 동안 할일을 만들면 4주 빡빡하게 갈 수 있지 않을까?)
  • 경매 방식을 결합한 중고거래? ( 사용자 인증 같은 기능을 덧붙이자!)
  • 캐치마인드
  • 소켓을 사용한 실시간 서비스가 들어있으면 좋겠다.
  • 클라우드 스토리지 ( 너무 어렵나? 이 아이디어 좋아보이는데....)
  • 사진 gif로 만들어주는 사이트
  • 메타버스(부캠타운에서 업그레이드 된)
  • 라이브커머스 (비디오 송출, 댓글)

<후보> 캐치마인드
경매인데 어떤 경매..
클라우드 스토리지 (파일 종류는 vscode 처럼..)

이름 짓기.....

  • boombox
  • booStack
  • BooStore
  • geekbox
  • boostup!
  • wherever
  • storeshare

1주차 해야할 일

  • 유저 스토리 및 Task 작성
  • 백로그 작성
  • 와이어프레임 제작 (테마 컬러..로고 포함)
  • FE, BE 프로젝트 설계
    • 프로젝트 구조(디렉토리 구조 등?)
    • DB 선정
    • 스키마 설계
  • 프로젝트 환경 구축
    • prettier
    • typescript
    • node version
    • package manager
  • 배포 환경 구축
    • Github action CI/CD
    • nCloud Server
    • nCloud Object Storage

스케줄러

구글 스프레드 시트로 관리하면 좋을 것 같다. 구글 스프레드 시트

데이터 관리 예상

  • NCloud Object Storage
    • 실제 파일들이 위치
  • NCloud Server
    • MongoDB, MySQL과 같은 DB
    • 여기다 폴더 구조를 저장

10월 26일 (화)

Planning

  • 사용자는 업로드 버튼을 눌러 파일을 업로드한다.

    • 업로드 버튼을 누르면 업로드 타입(파일, 폴더) 선택창을 표시한다.
    • 확인 버튼을 누르면 클라이언트에서 파일 유효성 검사를 한다.
    • 클라이언트 유효성 검사를 통과했으면, 서버에 파일 메타데이터를 전송하여 유효성 검사를 한다.
    • 클라이언트의 유효성 검사에 통과하지 못한다면, 사용자에게 업로드가 불가함을 알리고 원인을 표시한다.
    • 클라이언트가 서버로 부터 상태코드(업로드 불가)를 응답받으면 사용자에게 업로드가 불가함을 알리고 원인을 표시한다.
    • 서버는 수신한 메타데이터를 기반으로 업로드 가능 여부를 클라이언트에 전송한다.
    • 서버의 유효성 검사를 통과하였으면, 실제 파일을 서버에 전송한다.
    • 서버에 요청을 처리하는 동안 로딩화면을 보여준다.
    • 응답이 성공하면, 화면에 업로드한 파일을 보여준다.
    • 응답이 실패하면, 실패 메시지를 표시한다.

  • 사용자는 스토리지에 올라온 파일들을 선택할 수 있다.

    • 마우스 선택으로 여러 개의 개별 파일을 선택할 수 있다.
    • 파일을 우클릭하여 모달을 통해 수행할 동작을 선택할 수 있다.
    • 마우스로 범위를 선택하면 내부의 모든 파일들이 선택된다.(선택사항)
    • shift + 방향키 조합으로 똑같이 여러 파일들을 선택할 수 있다.(선택사항)

  • 사용자는 스토리지에 올라온 파일을 다운로드 받을 수 있다.

    • 사용자는 파일을 선택한다.
    • 올리기 버튼이 다운로드 버튼으로 변경된다.
    • 다운로드 받을 위치를 선택한다.
    • 확인 버튼을 눌러 다운로드 받는다.

  • 사용자는 업로드 버튼을 눌러 폴더를 업로드한다.

    • 업로드 버튼을 누르면 업로드 타입(파일, 폴더) 선택창을 표시한다.
    • 확인 버튼을 누르면 클라이언트에서 폴더 내 파일들의 유효성 검사를 한다.
    • 클라이언트 유효성 검사를 통과했으면, 서버에 파일들의 메타데이터를 전송하여 유효성 검사를 한다.
    • 클라이언트의 유효성 검사에 통과하지 못한다면, 사용자에게 업로드가 불가함을 알리고 원인을 표시한다.
    • 클라이언트가 서버로 부터 상태코드(업로드 불가)를 응답받으면 사용자에게 업로드가 불가함을 알리고 원인을 표시한다.
    • 서버는 수신한 메타데이터를 기반으로 업로드 가능 여부를 클라이언트에 전송한다.
    • 서버의 유효성 검사를 통과하였으면, 실제 폴더를 서버에 전송한다.
    • 서버에 요청을 처리하는 동안 로딩화면을 보여준다.
    • 응답이 성공하면, 화면에 업로드한 파일을 보여준다.
    • 응답이 실패하면, 실패 메시지를 표시한다.

파일 처리

  1. 클라이언트에서 Multipart/form-data로 서버에 파일을 보내준다.
  2. 서버에서 Multer 미들웨어를 사용하여, 데이터를 수신한다.
    • 이 과정에서 임시로 파일로 저장할지, 메모리에 저장할지는 내일 결정
  3. 해당 파일을 Object Storage에 저장한다.
  4. 저장 후 받은 URI를 서버의 데이터베이스에 메타데이터와 함께 저장한다.
    • 메타 데이터들?
      • 용량
      • 파일 이름
      • Object Storage URI
      • 파일 타입 등등

같이 학습할 부분

  • Multer
  • Multipart/form-data
  • Object Storage (시간 남으면..?)

10월 27일 (수)

멘토님과 미팅

  • 디자인과 기획을 같이 볼 수 있도록?

DB 선택

MongoDB

스키마 설계

  • Object Storage
    • 유저 별로 폴더를 생성
    • 해당 유저 폴더안에 실제 파일을 저장
  • nCloud MongoDB
    • 유저 콜렉션
      • 스키마
        • _id : Object ID (UserId)
        • loginId : String
        • password : String
        • directoryId : root DirId
        • maxCapacity : Number
        • currentCapacity : Number
    • 클라우드 콜렉션
      • 스키마
        • _id: ObjectId
        • children: this[]
        • osLink: String,
        • name: String,
        • size: Number, (byte단위)
        • ownerId: ObjectId, (FK)
        • contentType: String (EX. Dir, image/JPEG)
        • createdAt: Date,
        • updatedAt: Date

오늘 학습할 것

  • MongoDB
    • mongoose : ODM
  • AWS S3

10월 28일 (목)

CI/CD

  • nCloud의 SourcePipeline, SourceBuild, SourceDeploy를 사용하여 CI/CD를 구현할 것이다.

주말에 공부해야할 것?

  • Docker
  • Nginx
  • nCloud의 SourcePipeline, SourceBuild, SourceDeploy
  • 드래그 & 드랍

Reference

스키마 설계

  • Object Storage
    • 유저 별로 폴더를 생성
    • 해당 유저 폴더안에 실제 파일을 저장
  • nCloud MongoDB
    • 유저 콜렉션
      • 스키마
        • _id : Object ID (UserId)
        • loginId : String
        • password : String
        • directoryId : root DirId
        • limitCapacity : Number
        • currentCapacity : Number
    • 클라우드 콜렉션
      • 스키마
        • _id: ObjectId
        • children: Element[]
        • osLink: String,
        • name: String,
        • size: Number, (byte단위)
        • ownerId: ObjectId, (FK)
        • contentType: String (EX. Folder, image/JPEG)
        • createdAt: Date,
        • updatedAt: Date
Element 
{
    _id: ObjectId,
    children: Element[],
    osLink: String,
    name: String,
    size: Number, (byte단위)
    ownerId: ObjectId, (FK)
    contentType: String (EX. Folder, image/JPEG)
}
ShareList (나중에......3주차)
{
    ownerId: ObjectId,
    elementId: ObjectId,
    accessCode,
    password,
    startPath,
}
  • 공유기능 디자인 및 기획서에 추가해야함 (나중에...아마 3주차)

url objectID encoding 된 것..?

도큐먼트를 여러개 나누는 것이 좋을까? (FK를 쓰는게 좋을까?)

mongoose 2단 SubDocument 사용법(with koa) mongodb 버리고 관계형 db로 갈아타자

mongoDB와 같은 NoSQL의 특성을 살릴려면, FK를 쓰지않는게 좋다... 한 유저당 디렉토리 및 파일이 지나치게 많은 것이 아니라면, 서브 도큐먼트로 쓰는게 좋지않을까??

아니면 MySQL을 사용하면서 Join을 쓰는 것도 방법이긴 한데, 이경우도 Join이 많이 발생하면 성능상 불리할 것 같다...

Clone this wiki locally