이모지 도메인을 구현하면서, 불안요소가 있음을 확인하였습니다!
그 부분에 대해 이슈 남겨요!
현재까지의 상황
단건으로 이메일을 조회하게 되면 옆의 화면처럼 UI가 구성되게 됩니다!!
보시다시피 이모지를 추가할 수 있고요!!
처음 우리가 기획했던 방향은 프론트가 이모지 정보를 주면, 그 이모지 정보를 서버에 저장하는 방법이었어요!
그리고 저장된 정보를 다시 프론트에게 제공하고요!
그래서 이모지를 저장하고 삭제하는 API를 만들었어요!
{ "message": "EMOJI_CREATE_AND_DELETE_SUCCESS", "serverDateTime": "2021-12-19T16:59:39.4483105", "data": { "emoji": "happy", "existence": false } }
JSON으로 보면 emoji라는 필드에 정보를 주고, 서버로 넘겨요! 그러면 서버가 해당 정보가 있는지 파악하고, 있으면 remove를, 없으면 add를 진행합니다!!
여기까지만 보면 OK임당! 그런데, emoji 필드에 대해 조금 더 생각하면 이상한 점을 찾을 수 있어요!
emoji를 validate하는 규칙이 없다???
프론트에서 제공하는 emoji 정보에 대해 empty 체크만 하고 db로 저장하게 됩니다!
그렇다면, rest API로 직접 통신하게 되는 경우 어떠한 정보도 다 받을 수 있는 조건이 됩니다...
서버에서 해당 이모지의 정보에 대한 validate 혹은, 존재하는지에 대한 check가 필수적으로 진행되어야 하는데... 서버는 이모지의 정보를 모르고 있으니... 해당 로직은 위험성이 존재하게 되었어요 ㅜㅜ
코드적으로 살펴보면, Emoji의 content를 찾는데 db에서 로직을 수행할 수 없습니다. (아! 정확히 수행할 수 있지만, 불편함이 존재해요 ㅜㅠㅜ)
등록 또는 수정을 진행할 때 Emoji의 Content 필드를 stream으로 모두 search하는 구조를 갖게 됩니다.... 이 구조는 추후에 이모지가 엄청 많아질 경우 CPU를 혹사시키게 됩니다..
해결방법
카카오 또는 Slack 처럼 구현합니다!
카카오와 슬랙의 공통점은 이모지에 대한 정보를 서버가 갖고 있다는 것이에요! 이모지 자체를 테이블로 가져가기 때문에 해당 이모지에 대한 관리가 편해집니다!
이모지 자체를 하나의 디비에서 관리하기 때문에, search에서 매우 유리한 구조를 가져갈 수 있습니다! 더불어, 조금 더 다양한 비즈니스 로직으로 확장할 수 있는 이점도 있구요!!
결론적으로..
현재 진행하고 있는 이모지 구현을 고도화에서 진행했으면 합니다! DB 설계를 다시 진행하고, 기획을 한번 더 검증해야 할 필요가 있는 것 같아요 ㅜㅜ