PROJECT

⌨️ 순차적인 상황만 고려했었네...? TODO 리스트 https://romanc3.tistory.com/56 2023.04.03 [PROJECT][TODO] Culinari V2 DB 최적화 및 고민 ⌨️ DB 최적화 및 고민 미처 진행하지 못했던 DB의 최적화와 이해 그리고 고민 등을 이번 주, 길게는 2주에 걸쳐 진행 그리고 계속 늘어지는 일정 관리 때문에 약간은 스프린트 식으로 1주, 2주 단 romanc3.tistory.com 에서 JPA 연관 관계 매핑과 정규화 부분에 대한 고민을 하던 중 문득 이런 생각이 들었다. 너무 순차적으로만 생각하는데..? 부분 부분에 있어서 오류가 있을거 같다. 추상적인 생각이기에 마땅한 제목이 생각이 안나서 여러 번의 포스팅으로 정리하려 한다. 우선 생성과 수정 ..

⌨️ 기존에 구현했던 서비스의 V2 버전에 대한 본격적인 고민하기 이커머스에 대한 이해가 부족한 상태에서 만든 애플리케이션이므로, 부족한 점이 많았다. 조금은 이커머스에 대한 이해를 가지고 다시 만들어보자. 1. 이커머스 서비스에 대해 1.1. 구현 한 프로젝트의 비즈니스 모델 첫째로 구현 한 서비스는 '무신사'같은 Vertical Market 형식이다. 불특정 다수가 상품을 올리는 Open Market 이 아닌 , 쉽게 말하면 관리자가 전 상품을 관리하여 올리는 형식이라고 보면 된다. B2C의 방식이고 그렇기에 Admin의 구현이 있어야 했지만, 개발 공정 상 편의를 위해 배제를 했었다. 1.2. 이커머스 서비스에서의 MSA MSA가 핫해서가 아니라, 이커머스는 알 수록 그냥 monolithic 보단 ..

⌨️ 기존 로그 관리에서 불편한 점들을 고려하여 개선 기존 로그 관리는 EC2에서 nohup.txt 파일을 생성해서 관리하는 방식이었기 때문에, 직접 인스턴스의 파일을 보지 않고선 확인이 힘들었다. 해당 부분을 개선하고자 logback을 적용했다 1. logback logback은 log4j 이후에 출시된 Java 기반 Logging Framework 중 하나로 가장 널리 사용되고 있으며, SLF4j의 구현체이다. 우리는 Boot를 사용한 환경이라 별도의 dependency 추가 없이 사용할 수 있으므로 logback을 선택했다. 1.1. defaults.xml 별도의 로그 구현 없이도 기본적으로 콘솔에 로그가 찍혀 나온다. 이는 따로 logback.xml을 생성하지 않는 다면 Spring boot에서 ..

⌨️ Free Tier 사용 시 발생한 문제 아무래도 AWS에서 Free Tier로 제공해 주는 인스턴스의 성능이 달리다 보니, 작은 애플리케이션을 띄울 때도 메모리 초과로 인한 문제점이 발생했다. 해당 부분을 기존 틀에서 크게 벗어나지는 않는 방식으로 해결한 방법을 써보려 한다. 1. Free Tier 사용 시 문제점 파악 사진으로 남겨두지 못한 점이 아쉽다. 우선 인스턴스에서 어떠한 문제점이 발생한다면 첫째로는 모니터링을 통해 해당 부분을 찾아낼 수 있다. 1.1. ERROR 문제점 파악하기 AWS에서는 생각보다 친절하게 트러블슈팅을 도와주고 있다 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html#trou..

Culinari culinari.s3-website.ap-northeast-2.amazonaws.com Culinari V1.0.0 https://github.com/frontLine-kim/Culinari.git GitHub - frontLine-kim/Culinari Contribute to frontLine-kim/Culinari development by creating an account on GitHub. github.com Culinari 와 부트캠프 회고 기획의 시작과 기술 스택 ERD 설계 도메인 설계 및 구현 회고 비지니스 로직 구현 (신상품, 베스트상품) 비지니스 로직 구현 (찜한 상품, 리뷰,통합 검색) AWS S3에 이미지 업로드 구현 Github Action을 활용한 CI 진행 ..

⌨️ 비즈니스 로직 구현 회고 (찜한 상품, 리뷰, 통합검색) 찜한 상품 쪽은 비즈니스 로직 적으로 완벽히 구현하기보다는 프런트에서 해보고 싶은 것을 같이 협의하여 작성하였다, 리뷰 또한 마찬 가지이나 이 쪽은 백엔드 적인 로직이 들어갔다. 1. 찜한 상품 구현 첫 번 째는 찜한 상품의 구현이다. 로직은 간단한 Create와 Delete만 만들었다, 이유는 프런트에서 한 버튼 (♥) 의 상태에 따라 다른 요청을 보내는 것을 구현해보고 싶다는 의견을 주었다. 예를 들어 ♡ 에서는 Post 요청을 보내 찜 상품을 Create 하고 상태를 ♥ 로 바꾼다. 반대로 ♥ 에서는 Delete 요청을 보내 찜 상품을 Delete 하고 상태를 ♡ 로 바꾼다. 위 로직을 백엔드 적으로 해결하려고 내가 생각했던 것은 둘 다..

⌨️ 비즈니스 로직 구현 회고 내가 맡은 부분은 주로 상품 쪽이었다. 상품 외에도 여러 가지 자질구레하게 진행했으나, 대부분은 상품관 관련이 있었기에 이 쪽의 비즈니스 로직 구현을 회고하려 한다. 1. 신상품 페이지 구현 첫번 째는 신상품 페이지의 구현이다. 크게는 2가지의 로직이 존재한다. 첫 번째로는 페이지네이션 정렬 된 신상품의 출력, 그리고 얹어서 왼쪽 카테고리의 로직을 추가한 신상품의 출력이다. 1.1. 신상품 Pagination 구현 페이지네이션은 쉬워보이지만, 깊게 들어가면 어려운 부분이 한 두 개가 아니다. offset의 활용이나 여러 부분에서의 최적화 등 생각보다 고려할 것이 많았다. //신상품 조회 @Override public Page readProductWithSortedType(S..

⌨️ 도메인 설계 및 구현 회고 우리 프로젝트는 우선 Java 17을 이용하여 개발하였다. 백엔드 팀원 전부 가 Java Record를 활용해보고 싶어 했기에, 그리고 11에서 17로의 마이그레이션 시의 장·단점을 알고 싶었기에 17을 선택했다. 또한, 기존 캠프 학습 간 배운 MapStruct 방식의 Mapper 클래스 구현이 아닌, from, to 방식을 활용했다. 1. DTO 그리고 Java record 먼저 가볍게 DTO에 대한 개념부터 잡고가는 것이 좋을 것 같다. 1.1. DTO 란? DTO는 Data Transfer Object의 약자로, 계층 간(Controlelr, View, Business Layer) 데이터 교환을 위한 Java Bean를 의미한다. DTO는 로직을 가지지 않는 데이터..

⌨️ ERD 설계 회고 우리가 가장 힘들어했던 ERD 설계에서의 회고를 한번 해보려 한다. 이번에도 기술적인 것보단, 익숙지 않은 것들에 대한 어려움이 큰 부분을 차지했었다. 1. ERD 우선 ERD 다이어그램에서 볼 수 있듯이 우리의 프로젝트는 부트캠프에서 한 달이 채 안 되는 시간에 완성도를 높이기엔 힘든 크기였다고 생각한다. (더 고도화의 단계까지 바라본다면) 1.1. ERD 단계에서의 마찰 ERD를 설계할 때면 항상 마찰이 있었다. 물론 이것이 감정적으로 치고받고 하는 것이 아니라 긍정적인 토론인 점은 참 다행이다. 연관관계를 매핑한다거나 이럴 때는 크게 문제가 없다. 문제 상황은 1. 조인테이블 생성 및 관리 측면에서의 중복 테이블 생성 2. 정규화 원칙을 철저히 지키자 개발을 떠나 서비스 측면..