반려식물 정보 수정 요청시, 수정 요청 날짜를 프론트에서 보내줄 것인가, 백엔드에서 직접 생성해 저장할 것인가?

[rawfishthelgh]

현재 반려 식물 정보 수정 요청 형태는 다음과 같습니다.

{
  "nickname": "기영이",
  "flowerpot": "플라스틱",
  "waterCycle": 7,
  "light": "창 밖",
  "location": "욕실",
  "wind": "바람이 안통해요",
  "birthDate": "2023-07-08",
  "lastWaterDate": "2023-07-10"
}

이번 스프린트 기능에서 History 테이블에 물주기 정보 뿐만이 아닌, 총체적인 수정 정보를 담기 시작하면서 의문이 발생했습니다.

이전과 마찬가지로 물주기 날짜 수정일을 history의 date에 저장할 때는 그냥 request body의 lastWaterDate 필드 값을 넣어주면 됩니다.

history.date = requestBody.lastWaterDate

와 같은 형태로요(위는 실제 코드가 아니라 그냥 슈도코드입니다)

그러나 다른 정보(화분, 바람 등...)변경 날짜가 history 테이블의 date에 저장될 때는, 현재 프론트에서 보내주는 날짜 정보가 없어,
백엔드에서 자체적으로 history.date = LocalDate.now() 와 같은 형태로 현재 시각을 끌고 와 저장해야 합니다.

위와 같은 방법론(백엔드에서 시간 생성)을 적용한다고 해도 식물 환경 정보 수정을 한 날짜의 로그 기록을 히스토리에 남긴다는
현재 요구사항에서 로그 기록에는 문제가 없겠지만,

만약 화분 환경 수정 날짜를 잘못 기록했는데, 사용자가 자체적으로 지정해서 변경해야 한다면?
환경 정보 수정일을 오늘이 아닌 다른 날짜로 기록해야 한다면?(화분 위치를 3일 전에 옮겼는데, 현재는 오늘 옮긴 걸로 기록할 수 밖에 없음)

과 같은 추가적인 대응 상황에 대처하지 못 한다는 단점이 생기게 됩니다.
따라서, 프론트엔드에서 식물 정보 수정 요청을 보낼 때,

{
  "updateDate" : "2023-08-10"
  "nickname": "기영이",
  "flowerpot": "플라스틱",
  "waterCycle": 7,
  "light": "창 밖",
  "location": "욕실",
  "wind": "바람이 안통해요",
  "birthDate": "2023-07-08",
  "lastWaterDate": "2023-07-10"
}

과 같은 형태로 updateDate 필드를 추가해 정보 수정이 어느 타이밍에 일어났는지를 보내준다면, 위와 같은 요구사항이 나중에 추가되어도 코드 수정이 적을 것 같다는 생각이 들었습니다! (현재는 "사용자가 수정일을 직접 선택한다"라는 요구사항이 없으므로 "현재 시각"만을 프론트엔드에서 보내주는 방법일 듯 합니다.)

이에 대해 의견이 필요합니다ㅎㅎ

정리

반려식물 정보 변경 Request Body에서, 정보 수정일을 담은 "updateDate" 필드를 추가해 보내준다.

[Choi-JJunho]

추가 고려사항

현재 기획상 언제 정보를수정했다를 보여주는것이 핵심 기능이라고 판단했습니다.
하마드가 우려하는 부분도 충분히 공감하지만 updateDate필드를 추가하는 과정에서 다음과 같은 내용들도 고려해봐야할 것 같습니다.

1. updateDate필드의 validation 조건

지금 당장 생각나는 조건은 updateDate는 오늘 이후일 수 없다정도의 조건이 생각나네요

2. 반려 식물 로직에 히스토리 내용이 자꾸 침투하게됨

현재 방식을 도입하게 된다면 반려 식물 정보를 수정하는 API에 반려 식물 도메인에서는 필요하지 않은 정보가 계속 추가될 것 같습니다.
해당 작업이 이뤄질 때 마다 프론트엔드, 백엔드에서 관리하고 있는 RequsetBody를 변경해야하는데 해당 요소도 무시할 수는 없을 것 같네요

Body를 건드리지 않는 선에서 쿼리 파라미터로 받는 것도 하나의 방법이 될 것 같습니다.

/pet-plants/{id}?updateDate="2023/08/01"

의견

하마드의 말처럼 updateDate 필드가 필요하다는 말에는 동의합니다.

하지만 현재 History 로직을 명확하게 분리하지 못한 현재 해당 기획내용을 고려한다면 도메인 간 의존성이 복잡한 프로덕션 코드가 작성될 것 같다는 우려가 생깁니다.

따라서 개인적인 의견으로는 사용자가 선택해서 기록하는 방향은 백엔드 단에서 히스토리에 대한 관심사 분리가 어느정도 이뤄진 뒤 진행하는것이 좋다고 생각합니다.

해당 작업은 4차스프린트 내에 적용하기에는 어렵다고 생각하여 고도화 혹은 추가기능으로 제공하는편이 어떨까 싶은 의견입니다 😅

[WaiNaat]

만약 화분 환경 수정 날짜를 잘못 기록했는데, 사용자가 자체적으로 지정해서 변경해야 한다면? 처럼 이미 저장된 특정 기록을 조작해야 하는 경우에는 아예 새로운 api를 만들어야 한다고 생각해요. 히스토리를 새로 만드는 거랑 있는 걸 고치는 거랑 차이가 있을 것 같습니다

화분 위치를 3일 전에 옮겼는데, 현재는 오늘 옮긴 걸로 기록할 수 밖에 없음 이걸 생각해보면 필요하겠다는 생각이 들어요. 그런데 이걸 고려하면 최종적으로는 정보 수정에 달력을 이용한 날짜 선택 기능이 추가되어야 하는데, 정보 수정에 있어서 한 단계의 절차가 추가되는 것이 과하다고 생각합니다. 환경 정보를 바꾸는 일이 그렇게 많을 것 같지는 않아서요.. (제가 예전에 리마인더에서 물주기에 달력 열리는 걸 반대했던 이유랑 비슷합니다)

프론트 쪽에서는 일단 오늘 날짜로 updateDate를 보내는 절차 자체는 크게 복잡하지 않아서 기술적인 부담은 없어요

[hozzijeong]

확실히 수정 정보의 날짜를 표시하는게 더 괜찮을것 같긴 하네요.

저는 그렇게 된다면 하나의 의문점이 생기게 됩니다. 분갈이를 한 날과 이사를 한 날이 다르다면? 저희의 의도를 생각했을 때 각각의 업데이트 날짜를 따로 받는게 최종적으로 올바른 행동이지 않을까? 하는 생각입니다.

확실히 수정한 날짜를 직접 받는게 중요하다고 생각이 들지만, 현재 모든 조건 변경 사항을 한번에 받는 상황에서 업데이트 날짜만 따로 받는게 맞을까 라는 생각이 듭니다.

요약. 아래 2가지중 하나가 나은것 같습니다.

1. 업데이트 날짜를 받을거라면 변화 항목에 대한 업데이트 날짜를 각자 받아야 한다. (그렇게 되면 API변경이나 UI변경이 불가피하겠죠..?ㅠ)
2. 수정된 날짜를 기준으로 history에 기록한다 (백엔드에서 현재 날짜 지정해서)

[yeonkkk]

저도 어떤 방법이든 updateDate 로 수정 정보를 받아서 변경하는 것이 좋아보입니다.
그리고 앞서 다른 분들이 말씀해주신 것 처럼 api를 분리하는 게 좋을 것 같아요.
한번에 전체 정보를 다 받게 되면 상세정보를 수정하는 태스크가 너무 커지는 것 뿐만 아니라, 너무 많은 역할을 하는 것 같습니다.
그런데 우선 순위를 고려하면 이번 스프린트보다는 다음 레벨에 진행하면 좋을 것 같아요!