"구글 캘린더와 쓰레디를 모티브"로 만든 캘린더 기반 커뮤니티 플랫폼 API 프로젝트

• 기존에 사용하던 TODO LIST 어플 및 웹 앱은 친구들과 함께 일정을 공유하는 것이 아닌 자신의 일정 데이터만 공유가 가능했으며, 함께하기 기능 같은 기능이 없었음.
• 구글 캘린더는 일정 공유에 특화되어 있지만, 사용자들끼리 플랫폼 내에서 커뮤니케이션을 하기 어렵다고 생각

• 프론트 : react,
• 백엔드 : nestjs, redis, postgresql, socket.io(추가예정), typeorm, elasticsearch(학습 중 | 추가 예정),docker, swagger
• 클라우드 및 인프라 :
  • dev 배포 환경 : aws apprunner, aws lightsail(redis upstash로 변경가능성 o), vpc , github, github actions, aws s3
  • prod 배포 환경 : aws ec2, aws rds, aws elasticache, aws opensearch(ELK 추가 후), aws vpc, aws codedeploy, github, github actions, aws s3

• Node.js 프레임워크인 DI 프레임워크인 Nest.js를 사용하여 확장이 쉬운 아키텍처로 구성

  • REST API
  • 협업을 위한 api문서 swagger
  • 데이터베이스 추상화 및 트랜잭션 일관성(typeorm queryRunner)을 위해 typeorm을 사용, postgresql과 연결

• aws S3 public에 대한 ddos 공격의 문제점 대두

  • 해결방안 : cloud front를 이용하여, ddos 공격에 대비 (추후 추가)

• dev 배포환경에서의 rds, ec2, elasticache를 통한 배포는 사이드 프로젝트의 과도한 비용

  • 해결방안 : aws apprunner를 통한 nestjs 서버 배포와 lightsail의 docker를 통하여 postgresql, redis 배포
  • 추가 문제점 : lightsail은 오토스케일링을 지원하지 않기 때문에 사용량이 많아지면, redis와 postgresql의 문제점 발생, apprunner 서울 리전 미지원
    • 이후 해결 방안 : prod 배포시 배포 환경 변화를 통한 확장이 가능한 aws 서비스 사용

• JWT accessToken과 refreshToken을 활용한 인증/인가 처리

  • 로그아웃 시 refreshToken을 redis에 버림으로써 악의적인 사용자가 사용못하도록 처리

• oauth 사용자와 local 사용자의 테이블 분리로 인한 트랜잭션 추가 발생 여부

  • 테이블을 통합, oauth와 local 사용자 구분을 위한 별도의 컬럼 추가
  • 1:1 관계의 사용자 정보 테이블 : 사용자 추가 정보를 위한 user_info 테이블을 도입하고, user 테이블과 1:1 관계를 구축. 이를 통해 데이터의 정확성과 쿼리의 효율성을 동시에 달성

• ci/cd

  • github과 github actions를 통해 aws ecr에 컨테이너 배포
  • jenkins와 k8s 추가 학습 예정

• gitmoji를 통한 commit 메시지 이모지 통합