KBW's cosmos

필자는 Next.js와 Spring Boot를 이용해 서비스를 개발하고 있다. 이번에 무한 스크롤 기능이 필요했는데, No-Offset 방식의 레퍼런스가 많이 없어 애를 먹었다. 시행착오 끝에 잘 작동하여 이를 정리해보고자 한다. 근데 No-Offset이 뭐지? No-Offset 페이지네이션은 Offset을 사용하지 않고 페이지네이션을 진행한다는 말이다. Offset은 게임 개발할 때 많이 쓰이는 단어이기도 하다. 일반적으로 Offset을 사용하는 페이지네이션은 Offset(어디부터) limit(몇개의) 데이터를 불러올지 결정한다. 즉, 네이버 카페 같은 곳에서 볼 수 있는 위와 같은 번호들이 페이지 넘버이고 이 페이지 넘버가 Offset이라고 생각하면 된다. No-Offset은 이러한 Offset을 사..

문제의 발단은 이러했다. @Getter @NoArgsConstructor @Entity(name = "question_posts") public class QuestionPosts extends BaseTimeEntity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "question_post_id") private Long questionPostId; @ManyToOne @JoinColumn(name = "user_id", nullable = false) private Users user; @ManyToOne @JoinColumn(name = "dept_id", nullable = false) private DeptCl..

위와 같은 에러가 발생했다. 처음에 다른 에러도 나서 Service, Controller 부분 다 찾아보고 디버깅 해봤는데 아래 부분에서 계속 오류가 나고 멈추는 것이었다. 하지만 문제는 역시 에러 코드를 잘 읽어야했다... Dto 부분이 문제였고 이는 기본 생성자가 없기 때문이었다. ObjectMapper가 @RequestBody를 바인딩 할 때 기본 생성자를 사용하기 때문에 그런 것이었다. lombok으로 기본 생성자를 만들어 준 후 해결되었다.

위 테스트 코드를 작성하던 중 발생한 문제였다. post를 하기 전 requestDto에서는 분명히 isActive라는 변수의 값이 true였으나 post 한 후 isActive의 값이 false로 나오는 것이었다. 다른 변수의 값들은 멀쩡히 잘 나와서 참 이해하기 어려운 버그였다... 코드를 더 살펴보니 dto에는 문제가 없어보였고 repository의 test 코드는 성공했다. 이에 controller단의 버그라 생각하고 디버깅을 진행하였다. 진행해보니 확실히 Controller에서 문제가 있었다. Controller에서 requestDto를 받는 과정에서 값이 위와 같이 바뀌는 것 같았다. 그렇다면 왜 다른 값들은 멀쩡한데 isActive 값만 버그가 나는걸까? https://projectlombo..

● Web Layer - 흔히 사용하는 컨트롤러(@Controller)와 JSP/Freemarker 등의 뷰 템플릿 영역이다. - 이외에도 필터(@Filter), 인터셉터, 컨트롤러 어드바이스(@ControllerAdvice)등 외부 요청과 응답에 대한 전반적인 영역을 이야기한다. ● Service Layer - @Service에 사용되는 서비스 영역이다. - 일반적으로 Controller와 Dao의 중간 영역에서 사용된다. - @Transactional이 사용되어야 하는 영역이기도 하다. ● Repository Layer - Database와 같이 데이터 저장소에 접근하는 영역이다. - Dao(Data Access Object) 영역으로 이해할 수 있다. ● Dtos - Dto(Data Transfer..

기존의 문제점 현대의 웹 어플리케이션에서는 대부분 관계형 데이터베이스(RDB)가 쓰인다. (ex. Oracle, MySQL...) 그러다 보니 객체를 관계형 데이터베이스에서 관리하는 것은 무척 중요해졌다. 문제는 코드의 대부분이 어플리케이션 코드보다 SQL로 가득차게 됐다는 것이다. 이는 관계형 데이터베이스가 SQL만 인식할 수 있었기 때문이었다. 이에 각 테이블마다 기본적인 CRUD SQL을 매번 생성해야 했다. 이런 문제로 인해 자바 클래스를 아무리 잘 설계한다해도 결국은 SQL을 통해야만 저장, 조회가 가능했고 반복적인 SQL들이 늘어났다. 규모가 커질수록 테이블은 늘어났고 테이블의 몇 배가 되는 SQl은 만드는 것 뿐만 아니라 유지 보수도 굉장히 어려웠다. 또한 패러다임 불일치 문제도 있었는데, ..