[JAVA] piedra_de_flor

[회고록] Stock-simulation 프로젝트 API 완성도 기록지

이번 회고록 또한 저번 프로젝트 회고록과 마찬가지로 늦은 감이 있다. 이번 회고록의 목적은 학생 신분의 재정상 유지하기가 어려운 서버 비용때문에, 서비스 배포를 유지할 수 없었기에이 프로젝트의 완성도를 기록하고, 회고하는 것이다. 이 회고록의 목적이 기술적 기록이 아닌 프로젝트의 완성도에 대한 기록이니만큼, 코드나 기술적 설명 없이 Api 호출에 대한 캡처 내용으로 구성된다. 로그인, 회원가입과 같은 기본적인 기능을 제외하고 주요 기능이라 판단되는 Api들을 위주로 작성할 예정이다.추가적으로 해당 기능을 개발하며 겪은 고민과 트러블 슈팅등 또한 간략하게 소개해보고자 한다. 프로젝트 소개 해당 Stock-simulation 프로젝트는 프로젝트 이름 그대로 모의 주식 투자 서비스이다.가상의 돈을 사용하여, ..

이번에 진행하고 있는 모의 주식 투자 프로젝트에서 influx DB 도입을 결정했다.모의 주식 투자인 만큼 실시간 주식 가격을 받아와야했고, 과거의 주식 가격을 그래프로 보여줘야했다.이러한 방식의 데이터 저장을 하기 위해서는 초 단위로 변화하는 주식의 가격을 모두 저장해야했고, 이렇게 하면수십 수백가지가 되는 주식 수만큼의 쿼리가 초단위로 RDB에 날라가게 된다. 그럼 주식의 가짓수가 300가지라고 했을 때, 1분동안 서비스가 실행된다면 300 * 60 으로 총 18,000개의 쿼리가 발생한다.이는 매우 비효율적일 것이라고 생각되었다. 그래서 어떻게 하면 시간을 기준으로 변화하는 데이터를 효율적으로 저장할 수 있을지 고민을 하며, 방법을 찾던중Influx DB라는 시계열 DB를 발견했다. Influx D..

굉장히 늦은 감이 있는 Triple 프로젝트의 회고록이다. 이렇게 늦게 회고록 느낌의 글을 쓰는 이유는 나는 Spring 기반의 웹 서버 개발자를 희망하기에, 주로 백엔드 개발을 공부하고, 연습한다. 따라서, 이 프로젝트의 경우에도 백엔드 부분은 모든 기능을 완성했고, 이를 Postman과 같은 툴을 사용해서 테스트까지 마쳤지만, 프론트가 없고, 실제 배포를 해서 유지하는 프로젝트가 아닌 만큼, 추후에 다른 사람이 이 프로젝트의 기능이 잘 작동하는지 확인할 방법이 없었다. 따라서 나는 내가 만든 프로젝트의 모든 api들의 작동을 Postman으로 호출하여, 어떻게 응답이 오는지 기록을 해놓고자 했고, 이 회고록을 쓰게 되었다. 이 회고록의 목적이 기술적 기록이 아닌 프로젝트의 완성도에 대한 기록이니만큼,..

해당 글은 모의 주식 투자 프로젝트에서 real time DB (실시간 DB)를 적용하는 과정을 회고하는 글이다.주로 어떤 고민을 했고, real time을 선택하게 된 과정을 적어놓은 글이니 가볍게 읽을 수 있는 포스팅이라 생각한다.  최근 진행한 프로젝트는 모의 주식 투자 시뮬레이션 프로젝트다.해당 프로젝트의 특성상 실제 주식 가격을 실시간으로 받아와야만 했다.내가 선택한 방법은 KIS, 한국투자증권에서 제공하는 실시간 주식 체결가 API를 통해 KIS에서 제공하는 web socket으로 데이터를 받아오는 방식이었다.  따라서 초기에 실시간으로 변경되는 주식의 가격을 저장하기 위해 위와 같은 플로우로 계획했었다.이러한 방식에서 만약 사용자가 현재 실시간으로 전체 주식들의 가격을 보고자 한다면, 나는 ..

이 글에서는 프로젝트를 진행하면서 겪은 동시성 문제와 이를 해결한 과정을 기록하고자 한다. 주식 투자 시뮬레이션 프로젝트를 진행하는 과정에서, 나는 특정 주식에 대한 매도와 매수 기능을 구현해야했다. @RequiredArgsConstructor@Servicepublic class TradeService { private final TradeTraceService traceService; private final MemberRepository memberRepository; private final AccountRepository accountRepository; private final StockService stockService; @Transactional public..

현재 진행 중인 프로젝트의 객체지향적 리팩터링 과정을 기록해보고자 한다.구체적인 리팩터링 과정에 앞서 리팩터링이란 무엇인지 짧게 설명하자면 Refactoring이란 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법이다. 즉, 결과는 바뀌지 않지만 내부적으로 코드의 구조 혹은 코드의 디자인을 개선시켜서 코드의 가독성과 유연성, 유지보수성등을 향상하는데 목적이 있다. 지금 쓰는 글이 단순히 리팩터링에 대한 글이라고 생각하지는 않았으면 한다.내가 한 리팩터링은 사실 리팩터링보다는 구조 개선에 가까운 코드 수정이며, 진행하면서 많은 것들이 바뀐다.다만 객체지향설계와 객체지향프로그래밍을 공부하면서 최대한 프로젝트를 객체지향적으로 고치고자 하기에, 코드를 고쳐가며, 어떤 문제점들이 있었는지 자세한 코드와 함께..

2024-05-24 체인저의 API 명세서와 협업[10분 테코톡] 체인저의 API 명세서와 협업 (youtube.com) 프론트와 백엔드 개발자는 API 명세서와 여러가지 의사소통을 통해서 협업을 한다. API 명세서란?=> API의 기능, 동작, 사용법 등을 나타낸 문서 API 명세서 구성- 이름 및 설명 : API 이름과 설명- 기본 정보 : Host 주소, EndPoint, HTTP Method- Request : Header, Parameter, Body- Response : Header, Body 여기서 추가적으로 API 호출의 예시와 여러 응답의 예시가 추가된다면 더욱 좋음 " API 명세서만 보고도 사용할 수 있는가? " 를 기준으로 잡고 API 명세서를 작성하면 좋음  프론트와 백엔드 협업..

이번 Triple 클론 코딩 프로젝트를 진행하면서, 순환 참조로 인한 문제가 발생했다. 이번에는 이를 해결한 과정에 대해서 글을 써보고자 한다. 내 프로젝트에서 순환 참조가 발생한 부분은 내가 짠 계획 전체 조회와 내 예약 전체 조회를 하는 로직에서 순환 참조가 발생했다. 먼저 나의 계획 전체 조회 기능이다. 문제가 되었던 코드 먼저 보자 1.Controller @GetMapping("/plans") public ResponseEntity readPlan(@RequestParam long userId) { PlanReadAllResponseDto responseDto = service.findAllPlan(userId); return ResponseEntity.ok(responseDto); } 2. Se..

이번에는 저번 좋아요 기능 성능 개선해보기(1)에 이어서 리팩터링을 해보고자 한다. 저번 리팩터링에서 기존 하나의 요청마다 DB에 좋아요(좋아요 취소) 쿼리를 전송하여 사용자가 많이짐에 따라 DB 커넥션도 증가하면서 DB 부하가 너무 크게 걸리는 것을 해결하고자 하였고, 나는 좋아요 요청을 따로 local의 Map에 임시 저장 시켜놨다가 Spring Batch를 사용하여 5초마다 DB에 벌크 업데이트 시켜주도록 리팩터링을 진행하여 TPS 2.5배 향상, MTT 81%감소 라는 개선을 하였다. 하지만 이는 Map연산이 추가됨에 따른 리소스를 생각해보니 너무 많은 자원을 사용하지 않을까 싶었고, 다른 사람들 혹은 기업은 어떻게 좋아요를 구현했고, 어떤 방식으로 개선하였는지 궁금해졌다. 먼저 말하자면, 다른 ..

Trilple 클론 코딩 프로젝트를 진행하면서, 특정 게시물에 대해 좋아요를 누르는 기능이 요구되었다. 이번 글은 좋아요 기능에 대한 성능을 어떻게 개선했는지에 대한 기록이다. 초기의 코드 (좋아요 기능이 아닌 일부 기능 제외) public class Place { @ElementCollection @CollectionTable(name = "place_like", joinColumns = @JoinColumn(name = "place_id")) private List likes = new ArrayList(); public void like(long userId) { if (isLikedBy(userId)) { likes.remove(userId); return; } likes.add(userId); ..