Hello, Freakin world!

기능 - 아이템 조회 - 아이템 추가 - 아이템 삭제 - 아이템 수정 validation, 예외처리 등 대부분의 골자는 Customer 엔티티 때와 비슷하다. 개선된 점이라면 REST의 하이퍼링크를 테스트하기가 참 곤란했는데 JsonPath 라이브러리를 이용해 만든 헬퍼메서드로 꽤나 간편하게 테스트를 수행하게 된 점이다. https://github.com/johnna-endure/myshop/tree/develop johnna-endure/myshop Contribute to johnna-endure/myshop development by creating an account on GitHub. github.com

시간이 엄청나게 걸렸다. 간단한 CRUD라도 테스트를 일일이 작성하고 예외처리, validation 등 견고한 코드를 작성하는건 꽤 어려운 일이었다. 구현한 것들 - api 응답에 하이퍼미디어 추가 - ControllerAdvice를 이용한 예외처리 - api 메서드 마다 단위테스트 추가 구현 보류한 것들 - AOP이용한 validation : AOP에 대한 학습이 더 필요하다. 휴~ 일단 결과물부터 살펴보자. /customers 는 고객 도메인의 aggregate root의 진입점에 해당한다. 페이징 파라미터를 따로 추가하지 않으면 size = 5다. 굳이 이렇게 말하지 않아도 응답에 _link 객체의 all의 href를 보거나, 여기서는 보이지 않지만 self 속성의 href 속성을 보면 어떤 파라미..

레퍼런스들을 읽어보고 어떤 걸로 하이퍼미디어를 구현할지 알아보는데 3일? 정도 걸렸다. 하루 대부분 영어 문서들을 거북이처럼 읽어가며 보냈기 때문에 체감상 훨씬 오래걸린 듯한 기분이다. 내가 찾아본 바로 RESTful API를 구현하기 위해서 3가지 방법이 있다. 1. 직접 JSON 응답 객체를 작성한다. 2. Spring HATEOAS 를 이용한다. 3. Spring Data REST 를 이용한다. 1,2번과 3번을 두 그룹으로 나눠서 보자. 내가 느끼기엔 서로 느낌이 좀 달랐다. 1번은 너무너무너무너무 거추장스럽고 고생스럽다. 2번은 1번을 하지 않도록 유틸 클래스와 메서드를 제공한다. 2번은 딱히 어떤 계층에 의존하지 않는다. 보통 컨트롤러 계층에서 작성하지만 굳이 다른 계층에서 할려고 한다면 객체..

생각해보니 RoleType 이라는 속성도 의미가 없었다. 비회원은 User 엔티티 속성이 모두 null이여야 한다. 비회원, 회원, 관리자를 단순히 하나의 필드로 구분할게 아니라 완전히 다른 개체로 분리해야 하는건 아닌가라는 생각이 들었다. 그래서 일단 지금은 User -> Customer 로 바꾸고 RoleType 속성은 삭제하자. 비회원과 관리자는 일단 미뤄둔다. import ... @Getter @ToString @NoArgsConstructor @Entity @EntityListeners(value = AuditingEntityListener.class) public class Customer { @Id @GeneratedValue(strategy = GenerationType.SEQUENCE) ..

이전 글에서 설계한 명세대로 User 엔티티를 작성해보자. User package com.springboot.myshop.domain.user; import lombok.Builder; import lombok.Getter; import lombok.NoArgsConstructor; import javax.persistence.*; import java.time.LocalDateTime; @Getter @NoArgsConstructor @Entity public class User { @Id @GeneratedValue(strategy = GenerationType.SEQUENCE) @Column(name = "USER_ID") private Long id; @Column(nullable = false,..

시작하는 단계라 대략적인 도메인을 나누고 수량 관계만 표현했다. 이제 회원 도메인을 좀 더 다듬어보자. 회원 필요한 기능1. 회원 등록2. 회원 정보 조회3. 회원 정보 수정4. 회원 탈퇴5. 인증 (관리자, 비회원, 멤버를 구분해야 한다) 1~4 는 결국 간단한 CRUD다.5번도 일단은 간단하게 이메일, 비밀번호를 받아 데이터베이스에서 비교하는 식으로 구현할 계획. (추후에 OAuth, Spring Security를 다시 적용할 예정) 위를 바탕으로 회원 객체 속성들을 나열해 보자. 회원 클래스 속성- id : Long = JPA 식별자- email : String - password : String- address : Address - createdDate : LocalDatetime - modifi..

여러 수정을 하다보니 초기의 설계와는 완전히 달라졌네요. 우선 그림으로 살펴보도록 하겠습니다. 서버는 크게 ChatRoomServer 와 ChatServer. 두 가지가 있습니다. 채팅룸 서버(ChatRoomServer) : 채팅방의 정보(방이름, 현재 인원수, 최대 인원수, id)를 관리하는 서버입니다. 채팅메세지 서버(ChatServer) : 읽은 채팅 메세지를 같은 방의 모든 인원에게 다시 보내주는 역할의 서버입니다. 채팅은 이 서버를 통해 이루어집니다. 이렇게 서버를 두 가지로 분리시켰던 이유는 솔직히 말하자면 이벤트방식으로 모든 요청을 처리하기가 난감했기 때문이었습니다. 채팅룸 서버는 동기방식의 논블로킹 방식(자바 서블릿이 웹 요청을 처리하는 방식)이고, 채팅 메세지 서버는 이벤트 방식의 논블로..

소감 정말 네트워크 실습 겸해서 간단하게 시작한 토이 프로젝트였는데, 주워들은 것들을 실험하다보니 엄청나게 시간이 걸려버렸습니다. 하지만 이로인해 배운 것들이 정말정말정말 많네요. 앞으로 몇 일동안은 배운 것들을 정리하며 이 프로젝트를 마무리하려 합니다. 예외 처리를 최대한 한다고 했지만, 코드를 작성하면서도 미숙함이 많이 느껴졌습니다. 특히 삭제 관련 요청에 대해서도 트랜잭션을 지원해야 할 필요성을 느꼈지만, 너무 프로젝트가 복잡해질까 제외시켰습니다. 허접하지만 처음으로 뭔가 난이도있는 앱이라고 부를만한 것을 만들어낸 것 같네요. 정말 개운하면서도 아쉬움이 남네요. 정말 수고가 많았고 수고했다고 자신에게 위로의 말을 전하면서~ 소감은 여기에서 마무리하겠습니다 https://github.com/johnn..

프로젝트 막바지에 중요한 결함을 발견하고, 결국 코드를 리셋하기로 마음먹었습니다ㅠㅠ (남는게 시간인 백수라 쌉가능) (빨리 완성하고 스프링 프로젝트를 시작하고 싶었지만...) 결함은 허술한 아키텍쳐 설계가 원인이었습니다. 하지만 이 당시엔 이벤트 방식의 논블로킹 서버에 대한 지식이 전무했기 때문에 어떻게보면 이와 같은 결정이 필연적인 수순 같기도 하네요. 문제점을 간단하게 설명하자면, 처음 설계된 구조는 서버에서 하나의 EventLoop(전달 받은 이벤트를 처리하는 스레드)를 이용해 모든 이벤트를 처리하려고 했습니다. 이렇게 할 경우, 이벤트를 read 하는건 상관없지만 write 해야되는 경우에 난감해집니다. 채팅방에 있는 사람들에게만 write하려면 채널들을 선별하는 과정이 필요합니다. 고민해본 결과..

사용자는 콘솔을 통해 - 채팅방 생성 - 채팅방 리스트 조회 - 채팅방 나가기 - 채팅방 참가 의 기능을 이용할 수 있다. https://github.com/johnna-endure/chatting-project-entire johnna-endure/chatting-project-entire Contribute to johnna-endure/chatting-project-entire development by creating an account on GitHub. github.com 전체 코드이다. 완벽하진 않지만 그래도 끝이 보인다!!!