게시글 필터링: 프론트엔드 vs 백엔드, 어느 쪽이 더 효율적일까?
공지사항 기능을 개발하면서 맞닥뜨린 문제,
데이터 필터링 로직을 어디에서 처리해야 하는가?
방법은 두 가지,
1. 서버에서 전체 데이터를 불러오고 클라이언트에서 필터링 한다.
2. 필터 조건을 파라미터로 설정하여 서버에서 필터링 된 데이터를 요청한다.
사실 이전까지는 2번 방식, 서버에서 필터링 로직을 처리해 개발을 하고 있었다. 이유는 다음과 같다.
1. 필요한 데이터만 가져오기 때문에 초기 로딩 속도가 빠르다.
2. 데이터가 많아지더라도 서버와 DB에서 최적화된 방식으로 데이터를 처리하므로 성능이 안정적이다.
3. 실시간으로 변경된 데이터도 반영할 수 있다. (데이터 동기화)
만약 프론트에서 데이터를 필터링하면 클라이언트가 보유한 데이터와 서버의 데이터가 불일치할 수 있다.
4. 권한 관리가 용이하다. 필터링과 페이지네이션 로직 안에 권한 검사를 포함하면 특정 사용자가 볼 수 있는 데이터만 반환할 수 있다.
예를 들어, 관리자는 모든 데이터를 볼 수 있지만 트레이너는 지점 및 직원 데이터를 볼 수 없도록 제한 가능하다.
이밖에도 보안 및 데이터 노출 최소화, 중앙화된 비즈니스 로직 관리 등 다양한 장점이 존재한다.
그래서 새삼 궁금해진 프론트 필터링의 장점은 뭘까?
1. 서버로 요청을 보내는 횟수가 적어지므로 통신 비용 절감
2. 빠른 필터링 반응 속도. 버튼 클릭시 즉각적인 필터링 가능
3. 개발 속도 향상. 단순한 클라이언트 로직으로 구현할 수 있다.
데이터의 크기가 작고(100~200) 변화가 거의 없는 경우 & 필터링 조건이 단순하며 & 서버와의 통신 비용을 최대한 줄이고자 할 때 프론트 필터링을 고려해볼 수 있다.
통상적으로 2번, 백엔드에서 처리하는 방법을 많이 사용한다고 한다.
1번의 경우 데이터 개수가 늘어날수록 받아와야 할 데이터가 점점 늘어나기 때문에, 초기 페이지 로딩 속도가 느려져서 사용자 경험에 안좋은 영향을 미칠 수 있다.
DB 조회시에도 limit 없이 모든 데이터를 다 받아오기 때문에 부하와 비용 문제도 존재한다.
다만 Next.js 같은 SSR(서버 사이드 렌더링) 지원 프레임워크를 쓴다면 얘기가 달라질 수 있다!
미리 빌드 타임에 모든 필터 조합의 정적인 페이지들을 다 생성해놓으면 통신 비용과 초기 렌더링 문제를 모두 해결할 수 있다.
물론 이것도 데이터가 적을 때 얘기다. 앞으로 더 많아질 것으로 예상된다면 고려하지 않는 게 좋다.
아무튼, 2번 방식의 장점이 1번의 단점을 상쇄할만큼 강력하다고 생각한다.
그래서 우리 프로젝트도 2번 방식으로 개발을 하고 있었다.
그런데 공지사항 기능을 개발하면서 1번 방식을 두고 고민이 생겼다!
그 이유는 이전글, 다음글을 클릭하면 실시간으로 필터링 된 데이터가 렌더링 되어야 하는데 그 속도가 느리기 때문이었다.