첫 계획
- OAuth2 인증 및 로그인 관련 토큰 사용
- 로그인 api 사용
- 페이징 관련 구현 (클릭, 스크롤 → 무한 스크롤)’
- 파일 업로드 및 사진 및 동영상 처리
- 검색에서 elastic search사용 해보기
+a1. 동영상 재생 할수있음 하기
+a2. 위치기반 api 사용할수 있으면 해보기
블로그 만들 생각임 (근데 동영상재생을 어떻게 우겨넣지)
업로드 관련 블로그
구상
파일 업로드(클라이언트 주도)
클라이언트가 url을 받아 직접 클라우드에 업로드하고 url을 서버로 보내는 방식, 보안적 문제와, 동기화 문제를 안고 있다 요약된 워크플로우
- 클라이언트 → 백엔드: Pre-signed URL 요청.
- 백엔드 → 클라이언트: Pre-signed URL 반환.
- 클라이언트 → 클라우드 저장소: 파일 업로드.
- 클라이언트 → 백엔드: 업로드된 URL 전달.
- 백엔드 → 클라우드 저장소: 파일 검증 및 이동 요청.
- 백엔드 → 데이터베이스: URL 및 관련 데이터 저장.
추가 고려 사항
- 미확인 파일 삭제: temp/ 폴더에 남아 있는 파일은 클라우드 저장소의 수명 주기 정책(Lifecycle Policy)을 사용해 자동 삭제.
- 파일 이름 충돌 방지: 고유한 파일 이름 생성(예: UUID) 또는 사용자별 경로 분리.
- 오류 처리: 각 단계에서 실패 시 적절한 오류 메시지 반환 및 롤백 처리.
이 구조는 보안, 유연성, 효율성을 모두 만족하며, 불필요한 저장소 낭비를 방지할 수 있는 표준적인 방식입니다.
파일업로드(일반적)
그냥 서버가 파일을 받고 클라우드로 전송하는 방식을 사용한다고 한다 보안적이슈도 줄고, 서버 db와 동기화 문제도 생기지 않음, 로그도 제대로 남음
근데 동영상 업로드가 잦고 서버의 부담이 커지면 클라이언트 부담으로 구조를 변경시킬 생각을 가지고 있어야함