📖 목차

  1. 주제
  2. 스펙
  3. ERD 설계
  4. API 명세서
  5. 구현
  6. 트러블 슈팅

📌 주제

중고 거래 서비스 플랫폼인 번개장터 클론 코딩을 주제로 백엔드 개발을 맡아서 프로젝트를 진행

📌 스펙

  • 클라우드 : AWS(EC2, RDS)
  • OS : Ubuntu 18.04
  • 서버 : Nginx 1.14.0
  • IDE(툴) : Intellij, MySQL
  • 프레임워크 : Spring Boot
  • SDK : 11

📌 ERD 설계

1) 개체

  • 요구사항 기능 분석 후 개체, 속성 파악
    예) 회원 테이블, 상품 테이블, 카테고리 테이블 등등
  • 개체 간의 관계 파악 (이 과정에서 관계 테이블이 생성될 수 있음)
    예) 1:N관계, M:N관계

2) 속성

  • PK의 데이터 타입은 BIGINT : 데이터가 무한히 많아지는 경우 고려 -> 개발 시 long 자료형
  • 회원정보에서 password의 데이터 타입은 길이를 넉넉하게 VARCHAR(200)으로 : password는 암호화 과정을 거친 후에 저장하기 때문에
  • 미디어 파일 URL의 데이터 타입은 TEXT
  • Y/N값으로 구분하는 필드의 경우 BIT자료형을 사용하면 true/false값으로 사용이 가능
  • 컬럼명명 규칙은 카멜케이스로 : java에서 카멜케이스 사용
  • createdAt, updatedAt, status 컬럼을 테이블에 전체적으로 추가하는 것을 추천, 필요 없는 테이블을 추려서 제외하는 방향으로 고려
    꼭 모든 테이블에 추가할 필요는 없지만, 서비스에서 중요한 데이터를 저장하는 테이블에는 추가해주는 것이 좋음
  • 음수를 사용하는 경우가 아니라면 int unsigned 타입으로 수정(불필요한 공간을 최소화하기 위해)

📌 API 명세서

1) 도메인 별로 나누기

  • /products
  • /users
  • /categories
  • /chats
  • /accounts
  • /purchases

2) RESTful API 규칙에 따라 리스트업

  • 마지막이 / 로 끝나서는 안 된다.
  • _(언더바) 대신 -(하이픈)을 사용한다.
  • 소문자로 구성한다.
  • 동사는 포함하지 않고, HTTP Method로 대체한다.
  • 복수형 명사를 사용한다.
  • 파일 확장자는 표시하지 않는다.
  • 관계 표현
  1. 서브리소스로 관계 표현하는 방법
    ⇒ 일반적으로 소유 “has”의 관계를 묵시적으로 표현할 때 좋다.
    예) GET, users/{userId}/devices
  2. 서브리소스에 관계를 명시하는 방법
    ⇒ 관계의 명이 애매하거나 “구체적인 표현”이 필요할 때 사용한다.
    예) GET, /users/{userId}/likes/devices

3) 각 API 세부사항 작성

  • HTTP Method와 url
  • Header (토큰, 타입 등)
  • Body (요청 값, 타입, 예시, 설명)
  • Query String & Path Valiable (사용될 경우에만 기입, 타입, 예시, 설명)
  • Response (응답 값, 타입, 예시, 설명)
  • 응답 코드 (정상 응답 코드, 에러 코드)
  • 기타 : 응답 샘플

같이 협업하는 프론트엔드에서 봤을 때 이해하기 쉽고 정확하게 의사소통이 될 수 있도록 작성하는 것이 중요

📌 구현

1) 회원 관련

  1. 싸이클 : 소셜(일반) 회원가입 - > 소셜(일반) 로그인 - > 이름, 소개글 수정 - > 회원 탈퇴 - > 재 회원가입
  2. 회원 테이블과 소셜로그인 회원 테이블로 관리
  3. 소셜 회원가입/로그인 : access token으로 네이버에 회원 정보 요청, 네이버로부터 받은 "회원 ID"를 PK로 사용하고 회원 테이블에서 네이버 "회원 ID"를 참조
  4. 회원 탈퇴 시에는 status 값을 A(ctive)에서 D(elete)로 수정
  5. 재 회원가입 시에 status 값을 D(elete)에서 A(ctive)로 수정 => status 값을 이용하여 DB를 효율적으로 관리

소셜 로그인
1. 네이버 id와 pw를 입력
2. 네이버 서버에서 클라이언트(프론트)한테 access token을 줌
3. 클라이언트 서버에서 백엔드 서버에게 그 토큰을 줌
4. 백엔드에서 토큰을 사용하여 네이버 서버에 있는 필요한 정보를 가져옴
5. 이미 저장해놨던 소셜로그인 ID와 비교
6. 비교해서 맞으면 JWT 뿌림

2) 상품 관련

  1. 싸이클 : 상품 조회 / 상품 등록 - > 상품 수정 - > 삭제
  2. 제목의 키워드로 검색하거나 특정 상품을 조회
  3. 상품 등록 시에 상품 정보와 이미지들을 등록할 수 있도록 구현 (Transation 어노테이션 사용)
  4. 상품 수정 시에 원하는 부분만 수정할 수 있음
  5. 상품 삭제 시에는 status 값을 A(ctive)에서 D(elete)로 수정 => status 값을 이용하여 DB를 효율적으로 관리

3) 카테고리 관련

  1. 대분류 - 중분류 - 소분류 관계
  2. 대분류는 백의 자리로 구분(ex. 100, 200, 300)
  3. 중분류는 십의 자리로 구분(ex. 110, 120, 130)
  4. 소분류는 일의 자리로 구분(ex. 111, 112, 113)
  5. 카테고리 종속 관계를 관리하기에 편리
    백의 자리가 같은 것은 같은 대분류 카테고리
    십의 자리가 같은 것은 같은 중분류 카테고리

4) 찜

  1. 하나의 API에 찜하기 기능과 찜 해제 기능
  2. 처음에 찜 => 찜 생성
  3. 두번째 찜 => 찜 해제(status 값을 A에서 D)
  4. 세번째 찜 => 찜(status 값을 D에서 A)
    => status 값을 이용하여 DB를 효율적으로 관리
    => 하나의 API로 통합하여 클라이언트에게 편리한 API 제공

5) 팔로우

  1. 하나의 API에 팔로우 기능과 언팔로우 기능
  2. 처음에 팔로우 => 팔로우 생성
  3. 두번째 팔로우 => 언팔로우(status 값을 A에서 D)
  4. 세번째 팔로우 => 팔로우(status 값을 D에서 A)
    => status 값을 이용하여 DB를 효율적으로 관리 => 하나의 API로 통합하여 클라이언트에게 편리한 API 제공

📌 트러블 슈팅

1) 조인 후 데이터 조회할 때, 누락된 데이터가 있다?

=> INNER JOIN과 OUTER JOIN을 잘 확인해 볼 것

2) AWS EC2의 IP 주소가 바껴있다?

=>EC2 재부팅을 하면 IP 주소가 바뀐다. 탄력적 IP 설정으로 IP 주소를 고정시킬 수 있으니 처음부터 탄력적 IP로 고정시킬 것

3) API 테스트 도중 Cannot construct instance of 'dto 이름' 에러가 콘솔에 떴다면?

=> @NoArgsConstructor 어노테이션을 추가해 볼 것

4) AWS에서 스프링부트 실행 시에 에러 Message:HikariPool-1 - Thread starvation or clock leap detected ??

=> 11개 이상의 Connection을 제공
예) spring.datasource.hikari.maximum-pool-size=20

5) 트랜잭션 추가 후에 Post, Patch API가 실행이 안된다?

=> 여러 이유가 있겠지만, @Transactional(readOnly = true) 이 어노테이션을 사용한 경우 insert, update sql문 에러가 발생하니 @Transactional(readOnly = false)로 바꿔볼 것

6) 소셜 로그인 구현 시 네이버 서버에서 회원 정보를 가져오지 못한다면?

=> SSL 인증한 서버로부터 회원 정보를 요청해야 한다. SSL 인증이 된 서버인지 확인해 볼 것

7) nullpointerexception

null인 객체를 선언하고서, 그 객체가 갖는 메소드를 사용하려고 할 때 발생한 에러
=> 처음에 객체가 null이 아니도록 값을 넣어서 선언해 볼 것

profile
https://github.com/DaanChoi

0개의 댓글

Powered by GraphCDN, the GraphQL CDN