HeartBeat 알림 기능을 구현은 했지만, 이슈가 있었다. 1. 클라이언트와 연결되는 커넥션 시간이 45초를 넘으면 반드시 죽었다. 2. SSE객체의 생명주기를 조정해도(45초보다 짧게 해 의도적으로 객체가 죽도록 설정해도) 해당 결과는 변함이 없었다. 이는 첫 연결과 관련이 있다. 클라이언트는 subscribe라는 동작을 통해서 서버에게 정보를 수신할 수 있는 상태를 마련한다. 처음 이렇게 서버와 연결이 되면 서버는 커넥션이 subcribe 직후에 종료되지 않도록 dummy데이터를 보내주도록 설정했다. 문제는 초기에 이 dummy데이터를 보내주어도 위와 같은 문제가 반복되는 것이었다. 그래서 내게 된 결론은 subscribe직후 뿐만이 아니라 주기적으로 이 connection이 살아있음을 알려주는 ..

@Column(nullable=false) VS @NotNull 적용하기 기본적으로 @Column nullable false 설정을 많이 해왔다. 하지만, @NotNulll을 적용하는 방법도 있어 둘중 어떤 방법을 사용할까 고민을 하게 되었다. @Column(nullable=false) 엔티티 필드의 null을 검증하기 위해서 사용한다. 테이블 생성 시 not null조건이 적용된다. JPA에서 엔티티가 null로 적용된 필드가 있어도 DB에 도착해서 SQL 쿼리의 not null 제약에 의해서 예외가 발생한다. @NotNull DB 쪽으로 SQL 쿼리가 보내지기 전에, JPA엔티티 필드값이 null로 채워지면 예외가 발생한다. DB에 도달하기 전에 null검사를 처리한다. 만약, JPA가 아니었다면 엔..

1. 모니터링 서버를 별도로 구축한다. 2. 모니터링 서버에 Prometheus를 설치한다. 그리고 여기서 실제 서버 모니터링할 정보를 받는다. (실제 서버 ip 주소와 포트번호) 3. 모니터링 서버에 Loki를 설치한다. 실제 서버에도 appender의존성을 추가하고 Loki로 LogBack 정보를 전송한다. (실제 서버 ip주소와 포트번호) 4. Grafana는 Prometheus, Loki로 온 정보를 확인할 수 있다. 이때 prometheus,Loki 정보는 LocalHost로 받아서 확인이 가능하다. 5. 사용자는 모니터링 서버 : 3000포트로 Grafana로 시각화된 정보를 알 수 있다. 만약 포트번호 9090 3100등을 열어놓는다면 기본 Prometheus, Loki 툴로도 시각화된 정보..

일전에 와디즈 클론코딩 프로젝트를 진행한 경험이 있다. 불과 네달전? 에 진행한 프로젝트인데 지금보면 코드가 상당히 기계적으로 작성했다는 느낌을 받는다. 왜 이렇게 했을까 지금 다시 바라보면 당시 내가 알고 있던 전부였고 할 수 있던 전부였다. 너무나 지금보면 우스운 코드들이 많다 어이없기도 하고 지금은 어디 들이밀기엔 굉장히 낯부끄럽기도 하다. 그러나 어쩌겠는가. 그렇다고 케케묵혀둘 수 없고 먼지묻은 프로젝트를 다시 꺼내 리팩토링해서 내맘에 들게 뜯어 고쳐봐야 하지 않을까? 그런데, 지금 내가 알고 있는 정보와 지식에는 한계가 있다. 다른 사람들의 코드를 보고 영감을 받아서 새로운 리팩토링을 진행해보는건 어떨가 생각했다. 그렇게 생각해서 여러 프로젝트를 보며 조금 흥미로운 리팩토링을 해보고자 한다. 다..

서론 연관관계는 편하다. 정말 편하기 때문에 이유없이 사용하기 마련이다. 공부를 하기 전까지는 이렇게밖에 생각할 수 없었다. 내가 원하는 정보를 쉽게 탐색해오고 사용할 수 있었기 때문에 그어떤 문제도 발생하지 않아 편리하게 사용했다. 그런데, 언젠가 객체 관점에서 생각하는 경우 이렇게 마음대로 탐색할 수 있다는 장점 뒤에 불필요한 단점들도 존재할 것이라고 생각했고, JPA를 조금 비판적인 시각으로 바라보고자 했다. 그때 연관관계를 제거하는 생각을 먼저 하게되었는데, 놀랍게도 구글링해보면 JPA 영속성 관계 연관관계 책 내용을 개인이 재정리하는 글들이 많이 보였다. 그래서 이번 기회에 이런 주제를 가지고 객체지향을 바라보는 방법에 대해 생각해야겠다 싶어 지금과 같은 글을 작성하게 되어써다. 연관관계를 제거..