작성
·
156
0
읽는 시점에 populate 부분에 대한 시간도 최소화 하기 위해서 생성하는 시점에 user 의 최소한의 데이터를 넣어주고 있는거 같은데요.
이렇게 접근하면, 화면 중심으로 모델이 설계가 되는게 아닐까요?
요구사항이 바뀌거나, 다른 서비스에서 해당 API 를 사용하게 되면 매번 모델을 수정하고 데이터를 마이그레이션 해야 하는 이슈가 생길 수 있을거 같은데요.
어떻게 생각하시나요?
답변 1
0
어떻게 최적화하느냐의 문제입니다. 박종혁님이 지적하신 부분 당연히 생길 수 있습니다. 하지만 다 trade off가 있습니다. 정규화를 시킴으로써 다양한 endpoint를 비교적 쉽게 지원할 수 있어요. 단, 여기서는 장기적으로 부하가 늘어났을 때 부하 문제가 비교적 빨리 올 수 있습니다. 그에 반면 적절하게 비정규화를 하면 성능이 훨씬 좋아지죠. 장기적으로도요.
그래서 무조건 정규화다, 비정규화다 답이 있는게 아닙니다. 개발을 하시면서 도메인을 이해하시고 적절하게 비정규화를 하는겁니다. 너무 불확실한 엔드포인트다. 자주 빠뀔 것 같다. 그러면 정규화로 시작하면 되요. 어느정도 안정화가 되고 느려지기 시작하면 그 때 점진적으로 비정규화를 하면 됩니다.
강의를 끝까지 보시면 이 내용을 잘 이해할 수 있을 거에요. 관계형 디비랑도 비교를 하고요.
그리고 화면 중심 모델 설계가 되는게 아니냐고 물어보셨는데 지금 같은 블로그 서비스, 프론트가 소모하는 API개발이면 당연히 화면을 생각해야죠. 화면이 바뀌거나 기획이 바뀌면 마이그레이션 필요할 수도 있죠. 그러면 번거럽더라도 해야죠. 하지만 위에서 언급했듯이 너무 자주 바뀔 것 같고 서비스 초기이면 정규화 혹은 부분정규화를 하고 조금씩 최적화시키면 됩니다.
개발자들의 가장 큰 문제 중 하나가 사실 개발 자체보다도 비즈니스, 서비스, 기획 자체를 너무 이해 못하고 개발만 한다는겁니다. 모든 솔루션은 문제를 정확히 파악해야 만들 수 있어요. 만약 여러분들이 일반적인 B2C 서비스가 핵심인 회사에 들어가서 프론트엔드가 소모할 API를 만들어줘요. 그러면 당연히 그에 맞는 최적의 API를 고민하셔야죠. 근데 만약 public API 서비스를 만드는 곳이다. 그러면 얘기가 달라지겠죠?