[Team-26][BE : Shine] Issue-Tracker 2주차 1회차 PR #124
Conversation
| @@ -39,6 +39,8 @@ dependencies { | |||
| implementation 'io.jsonwebtoken:jjwt:0.9.1' | |||
| implementation 'io.netty:netty-resolver-dns-native-macos:4.1.68.Final:osx-aarch_64' | |||
| implementation 'com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.6.2' | |||
| implementation group: 'org.springframework.boot', name: 'spring-boot-starter-actuator', version: '2.7.0' | |||
| CURRENT_PORT=$(cat /home/ec2-user/service_url.inc | grep -Po '[0-9]+' | tail -1) | ||
| TARGET_PORT=0 | ||
|
|
||
| echo "> Current port of running WAS is ${CURRENT_PORT}." |
There was a problem hiding this comment.
워우 좋네요. 👍 어떤 회사에서 많이 사용하는 스타일의 스크립트입니다. @honux77 그쵸? ㅋㅋ
| echo "> Now Nginx proxies to ${TARGET_PORT}." | ||
|
|
||
| # Reload nginx | ||
| sudo service nginx reload |
There was a problem hiding this comment.
nginx를 RHEL이나 RPM, apt로 까는 것과 직접 바이너리 다운로드/빌드 후 사용하는 것의 차이점도 한번 학습해 보시길 권합니다.
보통 기업들은 후자의 방법을 선호하기는 합니다. 어떤 차이점에서 그런 선호 포인트(?) 가 발생할지 한번 탐구해 보시죠
There was a problem hiding this comment.
apt-get을 통해 설치하는 방식은 NGINX 공식 repository를 통해 다운받기 때문에 안전하다고 합니다.
또한 페키지메니저를 통해 설치할 경우, Nginx를 사용하는 port를 방화벽에서 따로 열어줄 필요 없이 사용하는 포트들을 자동 등록하며, 로그로테이트 설정이 자동으로 되기 때문에 편하다는 장점이 있습니다.
반대로 직접 컴파일 해서 사용할경우 기본패키지에 추가되어있는 모듈 외의 추가적인 모듈을 사용하고 싶다면 소스파일을 추가하여 컴파일 할수 있다는 장점이 있다고 합니다.
기업들 같은 경우 자기 회사만의 특이사항을 만족시킬수 있어야 할탠데, 이런 면에서 장점이 있다고 생각합니다!!
https://extrememanual.net/9910
| public static Comment create(String comment, Issue issue, User user) { | ||
| return Comment.builder() | ||
| .description(comment) | ||
| .issue(issue) | ||
| .user(user) | ||
| .build(); | ||
| } |
| public boolean isSameCommentId(Long commentId) { | ||
| return this.id == commentId; | ||
| } |
There was a problem hiding this comment.
생각해보니 Long 도 객체니 .equals()로 변경하도록 하겠습니다!!
| User findUser = userRepository.findUserByEmail(userEmail) | ||
| .orElseThrow(() -> new NotFoundException(ErrorCode.USER_NOT_FOUND)); | ||
|
|
||
| findIssue.addComment(Comment.create(comment, findIssue, findUser)); // 변경감지로 저장? |
There was a problem hiding this comment.
넵!! 테스트 코드를 통하여 확인해보겠습니다!!
| @@ -27,7 +27,7 @@ public class Issue extends BaseTimeEntity { | |||
| private String title; | |||
| private boolean isOpen; | |||
|
|
|||
| @OneToMany(mappedBy = "issue") | |||
| @OneToMany(mappedBy = "issue", cascade = CascadeType.ALL) | |||
There was a problem hiding this comment.
여기에 뭔가 하나의 옵션을 더 주면, Comment 에 대한 서비스 클래스의 별도의 접근 없이도 댓글 추가/삭제를 할 수 있을 것 같습니다.
어떤 옵션일까요? o. o.... or... orp.... h... 여기까집니다. 검색해보세요.
There was a problem hiding this comment.
orphanRemoval = true 옵션을 추가하여 부모와의 life-cycle을 동일하게 가져가겠습니다!!
|
|
||
| public void deleteComment(Comment comment) { | ||
| this.comments.remove(comment); | ||
| comment.deleteIssue(); |
There was a problem hiding this comment.
감사합니다!! 양뱡향으로 매핑을 해놨기에 양쪽에서 끊어야 데이터의 정합성이 어플리케이션에서 부합할거라 생각했습니다!!
|
@zbqmgldjfh 사실 어떤 방법이든 FE와 협의하면 된다고 생각합니다만 회사에서의 제 경험은 거의 항상 "201, 200 응답 후 FE가 다음에 어디로 갈지 알아서 결정" 이었긴 합니다. API를 설계한 목적이 리디렉션이 아닌 자원 혹은 정보의 생성 이었기 때문에 302는 좀 어색한 면도 있다고 생각합니다. 그래서 저는 200, 201 어떤 걸 사용해야 할지는 모르겠으나 200번대 응답에 한 표 드립니ㅏㄷ. |
|
우선 merge후, 수정 사항들은 내일 PR에 함께 반영하서 올리도록 하겠습니다!! 갑사합니다!! |
안녕하세요! Shine 입니다!
저의 리뷰를 담당해주시게 되어 감사하다는 말씀 전하고 싶습니다.
질문 1가지
1. API에서의 Redirction은?
Client 측에서 POST로 자원 생성 요청이 올 경우,
궁금합니다!
예전에 타임리프를 직접 사용하던 시기에는 1번이 맞는것 같은데... API에서의 방식은 다를지 궁금합니다!!