chzzk-study / grass-diary-server Goto Github PK

• 원격 서버에서만 허용하는 것이 아닌, localhost에서도 가능하도록 설정 추가

• 나의 일기 내역 페이지
• 일기 검색(이번주 top10 ...)

html 태그의 경우 어떻게 잘라서 보낼지 고민이 필요해 보임
일기 전송의 경우 전부 필요한 일이므로 해당 일을 하는 위치가 중요할 것 같음

api/main/grass 내 전송하는 데이터 수정 및 추가

기존

{
  "count": "int"
  "GrassInfoDTO": "list"
}

변경후

{
  "totalCount": "int"
  "thisMonthCount": "int"
  "GrassInfoDTO": "list"
}

• 이미지가 있는 일기를 이미지는 그대로 두고 글만 수정하게 됐을 때, 이미지가 없어짐

서버에서 이미지를 보내줄 수 있는 방법은 2가지를 고민해 볼 수 있다.

1. (현재) Spring boot 서버에 static 이미지(2개)를 보내주기
2. AWS S3 서버에 이미지를 저장한 다음, 클라이언트에서 S3로 요청 보내기

이미지의 경우 요청을 AWS S3로 하는 것이 맞다고는 생각되나, AWS S3 프리티어의 경우 한도가 다음과 같다.

• 5GB
• 20000건의 get요청, 2000건의 put, delete 요청 가능

때문에 쉽게 과금이 될 수도 있을 것 같아 고민해봐야 할 부분 같다.

• 이미지 존재시 hasImage(true)와 이미지 url 전송
• 이미지 존재하지 않을시 hasImage(false) 전송

• 이미지 서버 구축
• 이미지 저장 DB 설계
• 이미지 저장 api 설계

기존

{
    "date": "String",
    "todayQuestion": "String"
}

변경 후

{
    "year": "int",
    "month": "int",
    "date": "int",
    "day": "String",
    "todayQuestion": "String"
}

하나의 url <오늘의 날짜 및 질문>을 전달하려하였으나, 재사용을 위해 url을 분리하기로 결정

• 오늘의 날짜

  • api/main/today-date
  • json

    {
        "year": "int",
        "month": "int",
        "date": "int",
        "day": "String"
    }

• 오늘의 질문

  • api/diary/today-question
  • json

    {
        "question": "String"
    }

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public class BaseTimeEntity extends BaseCreatedTimeEntity {
    @LastModifiedDate
    private LocalDateTime updatedAt;
}

@Getter
@Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
public class Diary extends BaseTimeEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "diary_id")
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id")
    private Member member;

    @Column(columnDefinition = "TEXT")
    private String content;

    @ColumnDefault("true")
    private Boolean isPrivate;

    @OneToMany(mappedBy = "diary")
    private List<DiaryLike> diaryLikes = new ArrayList<>();

    @ColumnDefault("false")
    private Boolean hasImage;

    @ColumnDefault("false")
    private Boolean hasTag;

    @Enumerated(EnumType.STRING)
    private ConditionLevel conditionLevel;

    @ColumnDefault("0")
    private int likeCount;

    @Builder
    protected Diary(Member member, String content, Boolean isPrivate, Boolean hasImage,
                    Boolean hasTag, ConditionLevel conditionLevel) {
        this.member = member;
        this.content = content;
        this.isPrivate = isPrivate;
        this.hasImage = hasImage;
        this.hasTag = hasTag;
        this.conditionLevel = conditionLevel;
        this.setCreatedAt(LocalDateTime.now());
        this.likeCount = 0;
    }

    public void update(String content, Boolean isPrivate, Boolean hasImage, Boolean hasTag,
                       ConditionLevel conditionLevel) {
        this.content = content;
        this.isPrivate = isPrivate;
        this.hasImage = hasImage;
        this.hasTag = hasTag;
        this.conditionLevel = conditionLevel;
    }

    public void addDiaryLike(DiaryLike diaryLike) {
        diaryLikes.add(diaryLike);
        diaryLike.setDiary(this);
        incrementLikeCount();
    }

    public void deleteDiaryLike(DiaryLike diaryLike) {
        diaryLikes.removeIf(dl -> dl.getId().equals(diaryLike.getId()));
//        diaryLike.setDiary(null);
        decrementLikeCount();
    }

    public void incrementLikeCount() {
        this.likeCount += 1;
    }

    public void decrementLikeCount() {
        this.likeCount -= 1;
    }
}

@LastModifiedDate 어노테이션이 붙은 updatedAt 필드는 JPA의 Auditing 기능을 이용해서 엔티티의 어떤 필드라도 변경이 일어났을 때 자동으로 업데이트 시간을 현재 시간으로 변경해 줍니다. 이는 보통 데이터의 일관성과 역추적을 위해 매우 유용하지만, 특정 필드(예: likeCount)의 변경을 추적 대상에서 제외하고 싶은 경우에는 문제가 될 수 있습니다.
이를 해결하기 위해서 3가지 방법이 있습니다.

1. @LastModifiedDate를 사용하지 않고 변경된 필드만 데이터베이스에 업데이트하는 @DynamicUpdate 사용하기

• 그러나 @DynamicUpadate를 사용하면 updatedAt 필드의 주요 목적인 항상 최신 변경사항을 반영하는 것을 완벽하게 보장하지 않는다는 단점이 생깁니다.

2. likeCount를 다른 entity로 분리하기

• 이 방법을 사용할 경우 likeCount를 처리하기 위해 추가적인 클래스와 데이터베이스 테이블이 필요하다는 단점이 생깁니다.

3. likeCount 삭제하기

• 이 방법을 사용할 경우 좋아요 개수를 세기 위해 diaryLike entity를 뒤져야해 속도가 약간 느려지는 단점이 생깁니다.

그러나 이미 양방향 연결관계가 설정되어있는점, 이를 활용하면 적은 양의 코드 변경을 통해 오류를 수정할 수 있는 점, 유저가 아직 별로 없는 저희 서비스를 고려했을 때 3번 방법이 적절하다고 생각해 likeCount를 삭제하려고 합니다.

서버의 인증 정보를 .env 파일에 저장 후 사용하도록 배포

• 로그인 실패시 에러: 500에러가 아닌 다른 에러로 전송하기
• 일기 작성시 이미지 없는데 boolean값 true인 경우 FE에서 알 수 있도록 하기

• Elastic search

• 멤버 정보 필요시 memberId → JWT 사용

• 반복 요청 제한
• 트래픽 과다 방지

오류 내보낼 때 “좋아요를 이미 눌렀습니다” 와 같이 명확하게 내보내고, 400에러를 내보낼 수 있도록 rest api에서 error를 핸들링 하는 방법 알아보고 적용하기

리워드를 받거나 사용했을 때 reward_history DB 값이 추가 되어야 한다.

현재 tagUsageCount: 모든 사용자가 작성한 태그에 해당하는 개수
/api/search/hashTag/{memberId} 이 API에 해당 사용자가 작성한 특정 해시태그의 개수 추가 필요

-> 필요한 정보: 각 사용자의 해시태그에 대한 일기 개수

*배포 브랜치 네이밍 수정

• style/package -> dev로 브랜치명 변경
• 메인 배포 브랜치 dev -> release로 변경

운영을 고려한 코드를 작성하기

에러 메시지를 기술적인 지식이 없는 사람도 이해하고 액션을 취하기 쉽게 만들어야 한다.

관련해서 서버에도 로그를 최대한 많이 심어두면 문제 해결이 쉬워 질 것이다.

이는 의사소통의 능력이며 내가 만든 결과물로 인해 고생할지도 모르는 사람들을 고려한 개발을 해야한다.

Util 패키지나 클래스에서 다뤄야 할 것들

문자열 관련, 랜덤 값 생성, 날짜 및 시간 처리 등 프로젝트 전역에서 사용되는 특정 로직이나 독립적인 기능을 구현한다.

1. 프로젝트 전역에서 사용될 수도 있는 기능
2. 특정 로직이나 독립적인 기능
3. 가능하면 어떤 상태를 가지지 않는 기능

주의할 점

1. Util 패키지는 수정을 최소화 하자.
   • 잦은 수정이 필요한 경우라면 잘못 설계한 경우일 수가 있다.
   • Util의 경우 Model, View Controller와 같은 특정 계층에 있지 않고 어디서든 사용 가능하다보니 변경이 있을 경우 파급력이 클 수 있다.
2. 이 기능이 정말 Util 성격인지 고민 해보자.
   • 특정 클래스에서만 사용되는 기능이거나 비즈니스 로직이라고 불릴 정도의 로직이라면 도메인 등과 같은 위치하기 더 적절한 곳이 있을 수 있다.

참고

• Util 클래스/패키지

• 로그인 전 메인 페이지 이미지
• 테마 상점 이미지
• 교환 일기장 이미지

• DB에 오늘의 질문 리스트를 위한 테이블 생성 및 데이터 삽입
• 하루에 하나의 질문만 보내도록 설정(기준 시간 설정 필요)
• 질문에 대한 대답을 하는 일기의 경우 질문 번호와 함께 등록

• 홈서버 구축
• 인증서 발급
• 환경변수 변경
• 배포 링크 변경
• 구글 로그인 API 설정 값 변경