Frontend와 Backend간 editable table row 업데이트 / 삭제 로직

CRUD로 페이지를 만들다보면 업데이트, 삭제 request를 매번 보내야할지 한번에 보내야할지 애매한 경우가 있다.

 

예를들면 내 경우 부동산 매물 기능을 구현하던 중, 부동산 매물에 세부 방정보가 있을 수 있었다.

예를들면 쉐어하우스 경우 하나의 주택이지만 방을 따로 나눠 쓰기 때문에 사진 정보들은 한 곳에 올라가지만 세부적인 방별 월세 정보, 입주가능일 등은 달라질 수 있다.

 

이 경우 방별 정보는 개별적으로 추가되고 갯수 또한 동적이기 때문에 몇개의 방이 추가될거라는 예상이 불가능하다.

방별 정보는 없을 수도 있고, 10개 20개가 될 수도 있는거다.

아무튼 그 경우에 초기 첫 제출 시에는 건축물 정보와 함께 방 정보를 함께 기재해주고 모든 정보를 새롭게 추가해주면 된다. 이땐 House를 생성해주고, 생성된 House를 FK로 연결해서 각 방을 추가로 생성해주면 되니 아주 간단하고 깔끔하다.

 

하지만 이후 House 정보와 함께 방정보 또한 추가/수정/삭제가 동시에 이뤄진다고 생각해보자.

 

House 정보는 이전과 동일하게 update해주면된다.

다만 여기서 방정보의 수정 삭제를 개별적인 request로 처리할 것인지, 아니면 house 정보와 함께 한번에 요청하고 처리할 것인지에 따라 복잡도가 매우 달라진다.

 

개별적으로 처리한다면, 방이 Create 되는 경우와 delete/update 되는 경우가 나뉘어 처리될 것이고 그 경우 delete와 update reuqest가 매우 많이 생길 수도 있다. 또한 사용자 입장에서도 처음 House 정보를 생성할때 방정보 추가하는 방법과는 다르게 개별적으로 방 정보를 업데이트 / 삭제 처리해야한다는게 조금 번거로울 수 있다.

왜냐하면 request마다 response가 올것인데, 그에 대한 응답을 계속해서 frontend에 반영하여 노출한다는것은 사용자 입장에서는 초기 form 제출시와 다르기 때문에 이질감을 느낄 수 있기 때문이다.

또한 서버 측에서도 한번에 처리할 수 있는 요청을 불필요하게 여러 request로 나누어 처리한다는 것도 오버헤드가 될 수 있다.

 

따라서 나는 house 정보와 함께 한번에 요청하고 처리하는 쪽으로 방향을 세웠다.

여기서 생기는 약간의 난관이 있었는데, 그렇다면 방정보의 추가/수정/삭제를 어떻게 구분할 것이냐는거다.

 

깔끔하게 코드를 작성할 수 있는 방법이 무엇일까 고민하다 결정한 것이,

삭제되는 대상에 대해서는 id와 함께 is_deleted 플래그를 통해서 삭제하고

업데이트 되는 대상에 대해서는 id와 함께 데이터를 보내야할 것이다.

추가되는 대상은 별도의 id가 없이 전달되면 추가 되는 방정보로 보고 추가 처리할 것이다.

 

이렇게 처리를 하면 내용이 깔끔해지는 것 같다.

물론 프론트엔드에서 삭제 / 각 방별로 수정이 가해졌을때 따로 데이터 관리를 해야할 필요는 있다.

조금 번거롭긴하지만 그렇지 않고 개별적으로 처리한다면 서버측 성능 저하나 프론트엔드 UX에도 혼란이 생기지 않을까 싶다.

제출시에는 제출버튼 클릭으로 모든게 처리되는데, 페이지 수정시에는 방정보를 각각 업데이트/ 삭제 해줘야 반영이 된다는게 분명 이상하게 느껴질 수 있다.