쇼핑몰

상품 생성(판매자 생성)상품을 생성할 수 있다. 상품에 맞는 속성들을 productRequestDTO의 형식을 아래 속성들을 지닌채로 POST 요청을 서버에 보낸다. 상품의 생성은 '관리자'만 가능하다. 상품 이미지 등록상품의 이미지를 등록할 수 있다. 이미지 등록은

쇼핑몰 기반의 토이 프로젝트를 만들고 있다. 프로젝트를 진행하는 것이지만, 학습을 병행하며 진도를 나가는 중이다. 쇼핑몰에서 판매자와 구매자 간의 상품에 관해 문의를 할 수 있는 기능을 상정하고 실시간 채팅기능을 구현하는 것을 목표로 삼았다.채팅을 구현해보자하면, 주요

결제 API를 구축하는 과정에서 외부 API와 통신을 해야하는 필요성이 생겼다.토스 API를 호출해야하는데, 통신을 함에 있어서 어떤 클라이언트가 존재하고 또 어떤 클라이언트를 사용해야하는지 고민이 되었다. 토스 API에 결제 요청을 비동기 방식으로 보내고 클라이언트에

배경 현재 진행하는 토이프로젝트에서 멀티모듈을 적용해보기로 했다. 소프트웨어 개발에서 유지보수성과 확장성은 프로젝트에서 아주 중요한 요소라고 할 수 있는데, 현대적 시스템 개발에서는 이러한 요소를 효과적으로 지원하는 아키텍처 설계가 필수적이라고 할 수 있다. 다양

이전 편에 이어서 멀티 모듈 도입과 관련된 글을 작성한다. 처음 구상한 멀티모듈은 어떻게 빈과 관련된 의존성들을 해결해주어서 스프링부트 어플리케이션 자체는 띄웠으나 아래와 같은 문제를 해결해야했다.모듈 이름 및 역할 명확화 Entry-Point 다변화 대비 설계 개선특

지난 편에 이어서 멀티모듈 도입을 하며 겪게된 여러가지 상황을 공유하는 글을 써보고자 한다. 저번편까지의 글은 큰 틀에서 아키텍처와 같이 설계를 어떤 식으로 하고 어떻게 방향을 잡고자하는 글이었다면 본편의 글은 조금 더 코드레벨로 들어가서 어떻게 코드를 짜며 어떤 문제

우리가 웹 상에서 결제를 한 번이라도 해봤으면 모두 알겠지만, 사용자가 요청하는 결제수단은 ‘무통장입금’, ‘휴대폰결제’, ‘XX페이’, ‘카드결제’ 등.. 수 많은 결제 수단이 존재합니다. 각각의 결제수단들에 대해서 하나의 쇼핑몰이 모든 것을 구현하는 것은 분명 비효

현재 진행 중인 토이프로젝트에 이전에 웹소켓을 이용해서 채팅을 구현하였습니다.웹소켓이라는 건 HTTP와 같은 통신프로토콜이며 Http와 달리 양방향 통신이 가능하며 Connection을 끊지 않고 지속해서 유지하는 특성을 지니고 있습니다. 현재는 단일한 서버의 인스턴스

토이 프로젝트를 진행하며 멀티모듈을 도입하고 각 모듈의 성격에 맞게 코드를 작성하고 싶어서 도메인 객체와 Entity를 분리하였습니다. 또한 도메인 객체는 최대한 POJO로 구성하여 해당 객체를 특정 DB또는 기술과의 결합도를 낮추고자 하였습니다. 이에 따라 트레이드오

서버 운영체제로 널리 활용되는 OS 중 하나로 리눅스를 꼽을 수 있습니다. 예를 들어 AWS 같은 클라우드 서비스에서 EC2 인스턴스를 생성할 때, 기본적으로 리눅스를 사용하는 경우가 많습니다.리눅스에는 ‘파일 디스크립터(File Descriptor, FD)’라는 중요

토이프로젝트를 만들면서 ‘동시성’에 대한 고민을 지금까지는 크게 하지 않았습니다. ‘동시성’과 관련된 키워드와 연관된 예제 또는 강의가 특정 도메인(쿠폰 또는 재고처리 등)과 강결합되어 있는 경우가 많아서 해당 도메인을 프로젝트에 추가해야만 동시성을 다룰 수 있을 것만

내가 대규모 트래픽을 처리하는게 중요한 실운영하는 서버의 개발자라고 가정을 해봤을때 중요한 것이 무엇이 있을까요? 사람에 따라서 꼽는 우선순위가 다를 수 있지만, 그 목록 중에 ’모니터링’이 다소 상위권에 들지 않을까요?이번 글에서는 Database에 가해지는 부하에

성능개선 시리즈 - N+1 해결을 중심으로 #docs/쇼핑몰프로젝트 배경 저번 글에 이어서 성능개선 시리즈를 작성해보겠습니다. 슬로우 쿼리의 속도를 제한적으로(10ms)로 설정해서 임의로 슬로우 쿼리 탐지가 정상적으로 잘 작동하는 것을 확인해봤습니다. AOP를