지난 번 내가 Django + Restframework에서 지원하는 검색기능으로 filter_fields와 search_fields를 이야기하면서 나의 멘탈이 증발한 것을 이야기했다. 뭐, 나쁜 기능은 아니다. 나름 개발 속도를 높이기 위한 방법으로 약간 ㅂㅅ같은 길로 들어섰을뿐 아주 단순한 방법으로 아주 빠르게 자동으로 기능을 구현해주지만 성능은 책임지지 않는 뭔가 반쪽짜리 API를 만들어도 괜찮을 때는 괜찮은 방법이다. 하지만!! 그런데!! 이런 것으로는 안되는게, 만약에 높은 성능을 요구하는 프로젝트에서 Django로 프로젝트를 진행하는 경우는 드물지만 만약에 진행을 하게 된다면 온 사방에서 성능 이슈로 문제들이 펑펑 터지는 일이 생기게 될 거라는 사실이 너무나도 분명하다. 먼저 이야기했던 filt..
모름지기 웹 개발에 있어서, 웹 개발에서도 게시판을 개발하는데 있어서 가장 큰일 중에 하나는 Paginate라는 기능일 거다. 뭐, 검색기능도 있긴한데 그건 비즈니스 레이어(Business Layer: 데이터의 처리를 위한 서비스계층)에서 처리하는 거라기보다는 파시스턴스 레이어(Persistence Layer: 데이터의 영속성을 관리하는 계층)에서 처리하는 내용이라 난이도로 치면 아무래도 Paginate(이하 페이징)가 손이 많이 가고 할 일도 많고 귀찮은 일이 많다. 그래서 페이징을 먼저 처리하려고 생각해보면 아이러니하게도 검색부분이 먼저 선행되어야하는 이슈가 생긴다. 왜 그런지 잠깐 설명하자면 페이징의 기능을 차근차근 생각해보면 이해가 된다. 페이징을 만들때 가장 중요한 것은 게시글의 전체 카운트를 ..