현업에서 조회,수정,삭제 등 사용자의 사용 이력을 어떻게 관리하시나요?

ㅎㅎ, 담당 백엔드 개발자의 API가 마음에 안 드시는군요? 그럴 수 있습니다. 내게는 뭔가 더 좋은 방안이 보이는데, 저 사람에게는 안 보이는 거 같고, 내 일은 아니니까 대놓고 뭐라고 하기는 좀 애매한 상황. 다른 회사에서 관리하는 방안이 다르다고 할 때, 어떻게 하실려구요? 딴데는 이렇게 저렇게 한다드라며 설득하시려는 건가요? 아니면, 아 딴 데는 내가 생각한대로 하는구나.. 라고 안심이 되기 위한 것인지요. 암튼, 질문에 답을 하자면, 저라면, 어떤 행위를 프론트엔드에서 요청했을 때, 파생되는 히스토리 관리는 백엔드에서 알아서 하겠습니다만, 님 팀의 다른 API와 현황이 어떤지 모르니 섵불리 판단하기 어려운 문제겠습니다. 해당 이슈는 백엔드파트에서 알아서 할 일이니 간섭하기는 어려운 부분이고, 정 문제가 심각하면 중재할 수 있는 팀장이나 (작은 회사라면) CTO를 통하시는 것도 방법이겠습니다. 백엔드 개발자가 질문자 님한테 리액트 클래스 컴포넌트를 아직도 쓰고 있으면 구린 거 아니냐, 딴데서는 다 함수형 컴포넌트 쓴다더라... 뭐 이런 식으로 의견을 주면 내 반응이 어떨지 생각해보시면 답이 되지 않을까 싶습니다.

조회 수정 삭제 등의 히스토리 관리는 백엔드에서 관리하는게 일반적인데요. 이를 백엔드에 요청하더라도 충분히 합리적이라고 생각합니다. 애초에 프론트에서 이력 관리의 책임을 갖는다는 것부터가 이해하기 어렵네요. 사용자와의 인터렉션에서 어떤 오류가 발생할지 모르기 때문에 데이터의 히스토리는 그와 무관하게 남겨져야 한다고 생각합니다. 데이터로써의 가치도 중요하기 때문에 이를 관리하는 쪽에서 히스토리 관리도 맡아야할 것 같네요.

작성해주신 질문이랑 어느정도의 상상력을 더해서 답변드려봅니다 일단 그 히스토리라는게 정확하게 어떤걸 의미하는지 알아야 할것 같네요 말씀하신것처럼 정말로 어떤 테이블을 언제 어떻게 사용했고 업데이트 하였는지 히스토리를 남기려는 목적인지, 아니면 실제 사용자의 사용성이나 user journey 관점의 정보 수집이 목적인지 말이죠 그리고 제가 봤을땐 후자인것 같습니다 프론트 입장에서 백앤드가 어떤 동작을 하는지 정확하게 알수가 없습니다 반대로 백앤드에서는 프론트에서 어떠한 일들이 벌어지고 있는지 알수 없구요 동일한 동작을 두번 하는것 처럼 느끼시는것 같은데 제가보기엔 전혀 다른 의미의 동작으로 보여집니다 혹시나 정말 만약에 디비 crud의 히스토리만을 위한 추가호출이라면 백앤드 개발자가 혼나야죠 그런 히스토리 추가는 필터 등을 사용해서 저장했는지도 모르게 자동으로 남길수 있습니다

안녕하세요! 제 생각도 백엔드에서 history 를 관리하는게 맞을것 같습니다. 이렇게 생각한 이유는 다음과 같습니다. 1. 클라이언트의 종류가 다양할 경우 각 클라이언트마다 history 관리에 필요한 요청을 신경써야 하고 실수로 누락될 가능성이 있습니다. 2. history 관리가 하나의 트랜잭션으로 묶이지 못하기 때문에 Backend 요청은 정상 처리 되었지만 history 는 남지 않는 현상이 발생할 수 있습니다. 3. history API 가 독립적으로 운영되는 것이기 때문에 Backend 에 요청을 전달하지 않더라도 History 를 남길 수 있거나 Backend 요청과 다른 History 를 남길 수 있습니다. 따라서 프론트에서 Backend 에 기능과 History 요청을 각각 보내는 것보다는 Backend 에서 History 까지 관리하는게 여러모로 장점이 많다고 봅니다. 저의 짧은 지식이 조금이나마 도움이 되시길 바라겠습니다.

백엔드에서 해줍니다. 굳이 프론트에서 요청을 두 번 할 이유가 없네요.. 조회 수정 삭제 까지 서버에슈 잘 이루어지면 후에 히스토리에 추가로 트랜잭션 묶습니다