[ERD|API] ERD 및 API 설계

ERD 및 API 설계

이제 서버를 실질적으로 구현해볼 시간이다! 일단 기능사항을 분석하여 ERD를 설계해야 한다.
우리 글에서 발견한 길 팀은 GUI를 보면서 필요한 기능사항을 분석하여 ERD로 표현하였다.
서로 놓치는 부분이 없게 하기 위해 회의로 즉각 진행하였다. 아래에 기억에 남는 내용들을 기록해보았다!

• delete 부분은 어떻게 처리할까요?
• 아예 DB 상에서 없애는 방법보다는 boolean 값으로 없앴다는 처리를 남기는 방법을 사용하기로 했다(soft delete)
• 다대다 관계의 것은 매핑테이블을 통해 1대 다 / 다대 1로 풀자. 즉 단방향으로만 관계를 표현하도록 노력하자. 이를 위해 매핑 테이블을 만들었다.
• id는 LONG으로, 티어(브론즈, 플래티넘 등)는 enum으로, 데이터 생성/수정시간은 TIMESTAMP으로, 유무를 나타내는 데이터는 boolean으로 나타내자! 그리고 NOT NULL / NULL 표시도 일관성 있게 표현할 수 있도록 노력하였다.
• 아래 ERD에서는 user_id 처럼 언더바 형식으로 표현하였지만, API나 url 상에서는 userId 처럼 camelCase로 표현하기로 약속하였다.

설계한 ERD의 일부 모습입니다.

내가 맡게 된 부분은 User 부분!
전체적으로 회원가입 부분과 user가 가지는 정보들을 저장해놓는 부분, 그리고 다른 곳에서 user가 parameter로 관여하는 곳도 내가 함께 손보기로 했다.
API도 팀원과 함께 동시에 짰는데, 가장 헷갈렸던 의존성은 다음과 같았다.
user의 마이페이지에서 user가 지금까지 forum(광장, 즉 커뮤니티 기능을 하는 곳이다) 에서 썼던 글들을 모두 가져오고 싶은 상황이라면,
1. user 데이터 안에 List로 user가 지금껏 쓴 forum의 id를 모아둔다.
2. forum(광장, 커뮤니티 기능을 한다.) 에서 특정 user가 쓴 글을 parameter로 검색한다.
이 두 상황 중에 어떤 걸로 하는 게 나을지 고민이었다. 우리는 2번을 선택하였다.

설계한 API 중 일부입니다.

SPRINGBOOT 프로젝트 생성 시작, 그리고 툴 고민

✅SWAGGER 사용
위에 notion으로 잘 보이게 정리를 하긴 하였으나 이를 토대로 Swagger를 또 따로 사용해보기로 했다. 이후 front 분들이 보기에도 훨씬 가시적일 것이다.

swagger 환경설정은 어렵지 않다. config>swaggerconfiguration 파일을 만들어 아래 코드를 저장한다.
(로직은 직관적이다. 검색으로 봐도 어렵지 않다. YOUTUBE에 swagger java 검색키워드로 찾아보면 이해가 빠르다)

swagger 환경설정 코드 중 일부입니다.

트러블 슈팅이 하나 있었으나, 어렵지 않았다.
[SpringBoot] Failed to start bean 'documentationPluginsBootstrapper'; nested exception is java.lang.NullPointerException
그냥 application.properties 파일에서 한 줄을 추가하자.

spring.mvc.pathmatch.matching-strategy=ant_path_matcher

✅MYSQL 또는 H2 우선 사용 후 AWS RDS와 EC2, S3 사용
일단 개인적으로 개발할 시에는 MYSQL 또는 H2를 사용하고, 나중에 AWS를 사용하기로 했다.
이미지나 동영상 파일, 녹음 파일 등은 S3를 사용하고 텍스트 파일은 EC2를 사용할 예정이다. 이에 관한 내용은 이후 자세히 다뤄보겠다.
✅파일 구조는 아래와 같이 통일하기로 했다.
지금 생각해보니 이렇게 생성하는 게 나았을지 , 폴더 자체를 user안에 controller/domain/repository ..등을 넣는 게 더 효율적이었을지 좀 고민이 되지만 일단은 이렇게 해보기로 했다! 불편한 점이 생기면 그것도 정리해둘 생각이다.

구조 생성 이야기했던 카톡 내용

✅API request response 정리 잘해두기
front와 협업을 하는 것이기 때문에, 구현 완성도 중요하지만, 구현 전에 API의 request / response를 잘 정리해서 주고받기로 했다.
위 API에서 3번째 기능인 회원 닉네임 변경 기능 API를 살펴보자.

아래에서 설명하게 될 기능

POST를 제외하고는 가져오거나 수정, 삭제 할 시 request-params가 다수 포함된다. request-params/ request-body/ response-body를 잘 고려해서 짜자!
아래를 보면 알겠지만, response body에는 status 뿐만 아니라 변경사항에 대한 id값도 return해주어 혹시나 필요한 상황에 대비하였다.

✅다양한 request 정리해두기
잘 처리 되었을 때 201, 에러사항(404)일 때 (exception파일에서 구현 예정)는 무엇 때문에 에러가 났는지 처리할 API를 미리 생성해두었다.
userId가 없는 상황, 또는 login이 되어있지 않은 상황 등 404 error가 나는 상황은 다양할 수 있으므로 꼼꼼히 생각해나가면서 꾸준히 갱신시킬 예정이다.

다음 3탄부터는 SPRING 툴과 관련된 이야기를 더 해보도록 하자!