본문 바로가기

Spring 이 정도는 해줘야지 - 01. 시작하기 바로가기

💻 백엔드 개발7

Jackson SnakeCase / CamelCase 한번에 변경 하기 시작하며 오늘은 특정 GW에서는 카멜 케이스가 아니라 스네이크 케이스로 응답을 줘야 하는 상황이 생겼다. 개발자들은 전통적으로 반복 작업을 싫어하고 key를 바꾸기 위해서 모든 key 마다, @JsonProperty 를 넣어주기엔... 무리가 있다. 어노테이션 하나로 편리하게 변경을 해보자. @JsonProperty 멈춰! 해당 Task를 다른 분에게 부탁을 했더니 Response 객체의 Data Class에 @JsonProperty로 떡칠을 해두었다. 물론 이렇게 해도 개발에 문제가 없고 동작에도 문제는 없다. 하지만 코드의 가독성이 떨어지고, 솔직히 귀찮다. @JsonNaming을 써보자 어노테이션 하나로 손쉽게, 스네이크케이스와 카멜케이스를 변경 할 수 있다. 아래의 예시 코드를 보자. @JsonN.. 2021. 10. 20.

03. Soft Delete 더 편하게 하기 들어가며 DB를 만들면서 우리는 삭제 하는 방법은 두 가지 방법이 있다. 방식 설명 Soft Delete `UPDATE table SET delete = 1 WHERE id = 2` 형태로 ROW가 삭제 되지 않고 flag를 통한 제어 하는 방식 Hard Delete DELETE FROM table WHERE id = 2 형태로 ROW가 실제로 삭제 되는 방식 `Hard Delete`를 하는 경우도 있지만, `Soft Delete`를 하는 경우가 더 많다. 이런 경우에 JPA Entity Graph 의 경우는 `Soft Delete`시 데이터가 같이 담겨서 온다. `Application level에서 필터 하면 되는거 아니냐? ` 라고 생각 할 수 있지만, 인간이기 때문에 로직에 구멍이 많이 생길 수 있.. 2021. 7. 15.

02. 당신의 @Transactional의 readOnly 옵션 잘 쓰고 있나요? 시작하며 오늘은 Spring에서 마법의 어노테이션이라고 부르는 @Transactional의 readOnly 옵션에 대하여 이야기해보려고 한다. 엥? @Transactional에는 readOnly라는 옵션이 없는데? 엥? @Transactional에는 readOnly 옵션이 없는데 이게 무슨일이죠? 없는 걸로 이야기를 하려고 하는 건가? 우리는 이번 readOnly 이야기를 하기 전에 @Transactional은 2가지 있다는 것을 이야기하고 넘어가려고 한다. 이 2가지가 궁극적으로 하려고 하는 일은 동일하다. (실제 Spring AOP 상에서는 javax 패키지의 트랜젝션과 Spring 패키지의 트랜젝션도 모두 지원하고 있다.) Spring 패키지를 통해 제공되는 어노테이션이 더 많은 옵션을 제공하게 된.. 2021. 2. 4.

01. 알아두면 쓸떼있는 GeneratedValue 이야기 Part1 시작하며 우리는 Entity를 만들 때 우리는 PK (Primary Key)를 지정한다. 그중에서도 Primary Key를 선택할 때, 전략적으로 생각했을 때 순차 증가 값을 포기할 수가 없다. 과연 그럼 JPA에서는 이런 대체 키를 어떻게 생성하고, 어떤식으로 동작하는지에 대해 알아보도록 하자. GeneratedValue란? import javax.persistence.*; import java.io.Serializable; import java.time.LocalDateTime; @Table(name = "coupon") @Entity @Getter @Setter public class Coupon implements Serializable { private static final long seria.. 2020. 6. 4.

Spring 이 정도는 해줘야지 - 01. 시작하며 거 제목이 너무 자극적인거 아니요? 제목은 원래 자극적이게 적는거다. 그래야 "이놈보게~" 하는 자극을 주면서 사용자가 유입되게 된다. 사실 최근에 지인을 통해 @city7310 님의 '백엔드가 이정도는 해줘야함'에서 아이디어를 얻어서, 'Spring 이정도는 해줘야지' 으로 제목을 가지게 되었다. 백엔드가 이정도는 해줘야 함 - 1. 컨텐츠의 동기와 개요 필자가 고등학교 1학년 말에 처음으로 백엔드 포지션에서 프로젝트를 진행하며, 멍청했던 과거 이야기와 이 컨텐츠를 기획한 동기를 공유합니다. velog.io 이 연재는 왜 시작하게 되었나요? 최근 주변에서 여러가지 이유로, Spring에 관심을 가지는 선/후배들이 많아졌다. 근데 이들이 물어보는 내용이 거기서 거기고, 매번 똑같은 내용 다시 설명 해주기.. 2020. 5. 7.

대용량 푸시 발송 시스템 개발기 - (1) 시작 B2B 서비스에 대한 지루함을 느끼던 상황에서, 회사 실장님의 추천으로 B2B 서비스 팀에서 B2C 서비스팀으로 팀을 옮기게 되었다. 문제의 시작 약 6년간 공석이던 B2C 서비스 서버 개발자의 자리에 내가 들어가게 되었는데, 어느 정도 예상은 했지만 공석의 문제는 생각보다 컸다. 처음에 팀에 왔을 때, 정말 많은 문제가 있었지만, 가장 큰 문제는 푸시 전송 시스템이 없어서, 클라이언트 개발자가 일명 돌려치기 (땜빵) 하면서 겨우 겨우 서비스가 운영되고 있었다. 이렇게 돌아가는데 문제가 없었냐? 당연히 서비스적으로 문제가 많았고, 그러다 보니 유저에게 좋지 못한 경험이 많이 노출 되게 되기도 하였고, 비용적인 관점에서 봤을 때도 비효율적으로 사용되는 비용이 많았다. 또한, 우리 팀의 2020년 로드맵을 .. 2020. 3. 9.

MSA 고군분투기 — (1) JAVA의 DNS Cache 이슈 해결기 내가 만든 서비스는 기본적으로 DNS 기반으로 서비스를 다 하고 있다. account.yangs.internal , search.yangs.internal, mariadb.yangs.internal 등등.. 서비스중에 문제가 생기거나 구성 변경으로 인하여 혹은 아마존 내부의 이슈가 생기면 DNS에 IP를 스위칭해서 HA하는 형태로 운영중이었다. 어느날은 DB에 장애가 발생하여, 자동으로 IP가 변경되었는데 Application 레벨에서 전환이 진행이 안되어서 재기동으로 해결 한 기억이 있다. DNS 서버 설정 문제인가 봤는데, DNS서버의 문제가 아닌 JAVA 클라이언트 의 DNS Cache 정책으로 인하여 발생한 이슈였다. 오늘은 그 이야기를 해보려고 한다. DNS 공격을 방지하기 위한 JAVA의 정책.. 2020. 1. 6.

이전 1 다음

티스토리툴바