Core: Jackson > JSON 직렬화 시 null 필드를 제거하는 게 어떨까요?

[merge-simpson]

🗳️	코멘트로 논의하면서, 투표를 진행하려고 합니다!

논의 및 투표: JSON 직렬화 시 null 필드를 무시하기

🗳️ 다음 제안과 함께 시작한 투표입니다.

JSON 직렬화에서 null 필드를 무시하는 것이 좋다고 생각합니다. (주로 응답 JSON)
이로써 클라이언트는 자바스크립트에서 null 대신 undefined로 속성에 접근할 수 있으므로, 타입스크립트의 optional 특성에 잘 맞습니다.

• A안: null 필드도 JSON에 포함하여 응답합니다.
• B안: null 필드를 제외하기 위해, 기본 설정을 NON_NULL 필드만 포함하도록 속성값을 입력합니다.
• C안: null 필드를 제외하기 위해, 필요하다면 각 필드에 @JsonInclude(Include.NON_NULL) 애노테이션을 표기합니다.

---

부연 설명

✍️ Jackson 라이브러리 사용 시 선택지 설명

🗳️ A안: Null 필드도 명시하기

혹시 null 필드를 명시하기를 원한다면 말씀해 주세요!
헷갈린다면 프론트엔드 개발자분들과도 소통해 보는 것이 좋을 것 같습니다.

🗳️ B안: Jackson Configuration Properties 속성값

Jackson을 메시지 컨버터로 사용하고 있다면 다음 옵션을 추가할 수 있습니다.
(참고: 스프링에서 기본 메시지 컨버터는 Jackson으로 설정되어 있습니다.)

spring:
  jackson:
    default-property-inclusion: non_null

🗳️ C안: 대안 중 하나로, @JsonInclude 애노테이션 사용

public record ExampleReponse(
        @JsonInclude(Include.NON_NULL)
        String name,
        @JsonInclude(Include.NON_NULL)
        Integer age
) {}

👀 null 필드 포함 및 불포함 차이

이 글에서는 가독성을 해치지 않게 JSON을 정리했습니다.

null 필드 포함

JSON

{
  "name": "홍길동",
  "age": null
}

타입스크립트 인터페이스

각종 optional 속성의 타입에 null을 함께 표기합니다.

// null 필드를 받을 수도 있다고 가정할 때
interface Person {
  name?: string | null;
  age?: number | null;
}

null 필드 무시

JSON

{
  "name": "홍길동"
}

타입스크립트 인터페이스

각종 optional 속성의 타입에 null을 더 이상 명시하지 않습니다.

// null 필드를 받지 않는다고 가정할 때
interface Person {
  name?: string;
  age?: number;
}

[merge-simpson]

디스커션 투표 만들면서 확인한 것

• 투표 항목에서는 마크다운이 지원되지 않는 것 같습니다.
• 투표 항목을 수정하면, 사소한 수정이더라도 그 항목에 대한 기존 투표가 초기화됩니다.

그 외 본문 작성은 이슈와 유사합니다. ( 깃허브 글쓰기가 대부분 그렇듯이.)

[merge-simpson]

추가

• 투표 항목 수정은 본문 수정과 동시에 하나의 버튼으로 완료되거나 취소됩니다. 투표 항목을 수정하려다가 취소하면, 본문 수정도 함께 취소됩니다.

[merge-simpson]

위 논의를 확인해 주시고, 혹시 아직 투표하지 않으신 분들은 투표 부탁드리겠습니다.

@silberbullet
@sweetykr7
@taewookimm
@wowddok99
@wch-os
@Ropung
@jilpoom

[merge-simpson]

❓ C안을 선택한 이유가 무엇일까요?
C안: @JsonInclude(Include.NON_NULL) 명시

C안을 선택해 주신 분들께 질문드립니다.
혹시 B안(기본 설정으로 null 필드 제거) 대신 C안을 선택하신 이유가 있을까요?

(이따가 제가 생각하는 각 방식의 장단점 설명을 보충해 보겠습니다.)

[silberbullet]

❗ 향 후, 유지보수에는 추적이 어렵다고 생각합니다.

안녕하세요. @merge-simpson 님의 깊은 제안에 감사드립니다!

해당 🗳️ B안: Jackson Configuration Properties 속성값은 공통 설정이라고 생각합니다.

공통 설정은 개발자에게 편리성을 제공하지만, 향 후 유지보수에서 다른 개발자가 왜 Null 값은 안나오는지 추적하기 어려울 수 있다고 생각합니다. 유지보수는 명시적으로 소스의 의도를 전달하는게 좋다고 생각하는 입장으로 C안을 선택하였습니다!

[merge-simpson]

투표 종료 후 추가적인 코멘트로 오늘 회의에서 정리된 설명을 남기겠습니다.