[팀 프로젝트] 소셜 미디어 통합 Feed 서비스

github 주소

GitHub - wanted-pre-onboarding-backend-team-s/social-media-integrated-feed-service: 소셜 미디어 통합 Feed 서비스 🐳

 

❓ 프로젝트 목적

- Token 인증 방식 구현
- JWT (Json Web Token) 구현
- RESTful API 설계
- API Document 생성

 

📆 작업 기간 & 인원

2023.10.24 ~ 2023.10.30 (7일)
5인 팀프로젝트

 

🎤 프로젝트 소개

본 서비스는 유저 계정의 해시태그(”#username”) 를 기반으로 인스타그램, 스레드, 페이스북, 트위터 등 복수의 SNS에 게시된 시물 중 유저의 해시태그가 포함된 게시물들을 하나의 서비스에서 확인할 수 있는 통합 Feed 애플리케이션입니다. 이를 통해 본 서비스의 고객은 하나의 채널로 유저(”#username”) 또는 브랜드(”#wanted”) 의 SNS 노출 게시물 및 통계를 확인할 수 있습니다.

 

⏳ 요구사항 분석

• 유저의 계정은 unique 합니다.
• 회원 가입 시 이메일과 비밀번호는 유효성 검사가 필요합니다.
  • 이메일: 올바른 이메일 구조인지 검증되어야 합니다.
  • 비밀번호: 두 가지 이상의 제약조건을 가지며, 암호화되어 저장됩니다.
• 회원 가입 시, 이메일로 발송된 코드를 입력하여 가입승인을 받고 서비스 이용이 가능합니다. (이메일 발송은 생략)
• 계정, 비밀번호, 인증코드가 올바르게 입력되었을 시 가입 승인이 되어 서비스 이용이 가능합니다.
• 계정, 비밀번호로 로그인 시 JWT가 발급됩니다.
• 이후 모든 API 요청 Header에 JWT가 항시 포함되며, JWT 유효성을 검증합니다.
• 서비스 로그인 시, 메뉴는 통합 Feed 단일입니다.
• 통합 Feed 에선 인스타그램, 스레드, 페이스북, 트위터에서 유저의 계정이 태그 된 글들을 확인합니다.
  또는, 특정 해시태그(1건)를 입력하여, 해당 해시태그가 포함된 게시물들을 확인합니다.
• 게시물들은 본 서비스가 아닌 외부 서비스에서 관리됩니다. 그렇기에 좋아요 클릭 시 각 SNS 별 아래 명시된 API를 호출합니다. (기능 개발을 위한 요소로, 실제 동작하지 않습니다.)

type	method	endpoint
facebook	POST	https://www.facebook.com/likes또는share/{게시물고유아이디}
twitter	POST	https://www.twitter.com/likes또는share /{게시물고유아이디}
instagram	POST	https://www.instagram.com/likes또는share /{게시물고유아이디}
threads	POST	https://www.threads.net/likes또는share /{게시물고유아이디}

 

• 해당 호출이 성공할 시 response status 200 해당 게시물의 좋아요 수 또는 공유 수가 1 증가합니다. (횟수제한 없음)
• 실제 서비스가 된다면 게시물들은 SNS에서 생성되겠지만, 본 프로젝트에선 기능 검증을 위해 자체 생산합니다. 그렇기에 조회 수, 좋아요 수, 공유하기 수 등은 본 서비스 내에서 증가시키도록 처리합니다.
• 유저는 본인 계정명 또는 특정 해시태그 일자별, 시간별 게시물 개수 통계를 확인할 수 있습니다.
• 쿼리 파라미터를 이용한 시계열 통계를 보여줍니다. 데이터 조회 방법으로는 조회 기간, 조회 시간이 있습니다.
  • 조회 기간: 최대 한 달(30일) 조회 가능, 응답의 형태는 일자별로 제공합니다.
  • 조회 시간: 최대 일주일(7일) 조회 가능, 응답의 형태는 시간별로 제공합니다.
  • 예) ?value=count&type=hour / ?value=view_count&type=date

 

🧪 요구사항 분석에 따른 개체 추출

개체	속성
유저	유저 아이디(pk), 유저 계정(uk), 비밀번호, 이메일, 가입 승인 여부, 인증코드, 가입일
게시물	게시글 아이디(pk), 게시글 고유 아이디, sns 종류, 게시글 제목, 게시글 내용, 해시태그, 조회 수, 좋아요 수, 공유 수, 생성일, 수정일

             테이블 따로 관리

 

🔨 구현 과정

개체 추출에 따른 ERD 작성

 

API 설계

Description	Method	URL
회원가입	POST	/join
가입승인	PATCH	/join
로그인	POST	/login
게시물 목록	GET	/feeds
게시물 상세	GET	/feeds/{id}
게시물 좋아요	POST	/feeds/{id}/likes
게시물 공유	POST	/feeds/{id}/shares
통계	GET	/stats

 

📌기여

ExceptionHandler 추가

가장 최근에 진행한 개인프로젝트에서 사용했던 예외 핸들러 코드를 팀원들과 상의 후 팀 프로젝트에 적용시키기로 했다. API 접근 시 일어나는 핸들러는 예외의 종류에 맞는 핸들러를 생성하였고, API 접근 후 발생되는 예외는 커스텀으로 부모 예외 클래스를 생성하여 자식 예외 클래스들이 상속받게 한 후, 부모타입의 예외가 발생할 경우 한 개의 핸들러에서 처리할 수 있도록 하였다.

 

로그인 인증, JWT 발급

로그인 API 호출 시 요청 파라미터의 계정과 비밀번호가 DB에 존재할 경우 JWT를 발급해 준다.
JWT의 인증방식과 원리정도는 알고 있었지만 구현은 처음 해보았다. 강의와 구글링을 통하여 차근차근 구현하였고, 그 결과 기간 안에 완료하였다. JWT를 생성과 유효성을 검사해 주는 Util 클래스를 생성하였다. 이 부분은 크게 어렵지 않았고, 구현하면서 JWT의 인증방식과 원리에 대해 보다 정확하게 알게 되었다.

 

JWT 유효성 검증

회원가입, 가입승인, 로그인 API를 제외한 모든 API는 JWT를 헤더에 항시 포함되며, 해당 JWT의 유효성을 검증하는 부분을 구현하였다.
강의와 구글링을 통한 예시 코드들이 스프링 시큐리티를 사용하고 있어서 사전 지식 없이 스프링 시큐리티 필터로 구현하려다 보니 굉장히 애를 많이 먹었다. 목표가 기간 안에 코드를 완성시키는 것이었기에 스프링 시큐리티 필터를 이용하여 JWT의 유효성 검증을 할 수 있는 코드를 완성하였고, 예외발생이 빈번할 수밖에 없는 로직이라 생각되어 예외 발생 지점과 로그를 최대한 꼼꼼히 체크했다.

 

Swagger를 이용한 API 문서화

어노테이션을 사용하여 손쉽게 API 문서화를 할 수 있다는점이 좋았다. 그리고 문서 안에서 테스트를 진행해볼 수 있다는 점도 좋았다.

 

❗ 프로젝트를 마친 후

참고한 강의와 사이트에서 JWT 관련 예시코드로 스프링 시큐리티를 적용하고 있어서 그대로 개발하게 되었다.
프로젝트 완료 후 부족했던 부분을 다시 공부하며 느낀 점은 현재의 프로젝트에서는 인가를 해야 하는 부분이 존재하지 않기 때문에 스프링 시큐리티를 사실상 적용하지 않아도 되며, 일반 필터 또는 인터셉터를 적용하여 구현하는 것이 더 깔끔할 수 있다는 것을 깨달았다.
또한 refresh 토큰과 access 토큰을 이용한 인증방식도 존재한다는 것을 알게 되었다. refresh 토큰을 어디에 저장하느냐가 관건인 것 같은데 Redis에 저장, DB에 저장, 쿠키에 저장 등 다양한 방식이 존재한다는 것도 알게 됐다. DB에 저장하는 방법은 refresh 토큰 탈취 시 DB에서 바로 삭제하여 토큰을 무효화시키기엔 좋지만 토큰의 장점인 무상태를 유지하지 못한다는 점에서 의미가 없다는 생각이 들었다. 그래서 만약 다음 프로젝트 또는 해당 프로젝트를 리팩터링 할 경우 Redis 또는 쿠키에 저장하는 방식으로 구현하게 될 것 같다.