게시글 필터링 백엔드가 낫나요 프론트가 낫나요

통상적으로 2번, 백엔드에서 처리하는 방법을 많이 사용합니다. 1번의 경우 게시글의 개수가 고정적이라면 문제 없겠지만, 게시글이 늘어날수록 받아와야 할 데이터가 점점 늘어나기 때문에, 초기 페이지 로딩 속도가 느려져서 사용자 경험에 안좋은 영향을 미칠 수 있습니다. DB 조회시에도 limit 없이 모든 데이터를 다 받아오기 때문에 부하와 비용 문제도 존재합니다. 다만, Next.js같은 SSR 지원 프레임워크를 쓴다면 얘기가 조금 달라질 수 있습니다. 미리 빌드 타임에 모든 필터 조합의 정적인 페이지들을 다 생성해놓으면 통신 비용과 초기 렌더링 문제를 모두 해결할 수 있습니다. 근데 요것도 게시글이 적을 때 얘기고, 게시글이 몇 천개가 넘어가면 빌드 타임이 엄청 길어져서 또 다른 문제가 생길겁니다. 따라서, 게시글이 앞으로 많아질 것으로 예상되지 않는 상황에서만 고려해볼 수 있는 선택지입니다. 2번 선택지, 백엔드에서 대부분 처리하는 이유는 백엔드가 이런 일을 잘하기 때문입니다. DB를 조회할 때 최적화 전략으로 빠르게 데이터를 조회하거나, 인덱싱/캐싱 등을 이용해서 조회가 많이 되는 정보들을 미리 갖고있다가 내려준다던지 좀 더 세밀한 컨트롤이 가능하거든요. 2번 방법의 단점은 백엔드에 대한 지식이 어느정도 있어야 한다는 정도..?밖에 생각이 안나네요. 만약 백엔드에 대한 지식이 부족하고, 게시글이 그렇게 많지 않은(앞으로도 많아지지 않을) 상황이라면 오히려 앞서 말씀드린 Next.js 같은 프레임워크를 활용해볼수도 있겠습니다. > 2번 방법을 했을 때, 클릭시 param을 백엔드에 넘겨서 필터링 처리하고 싶은데 그러면 /board/filter?category='IT' & status='complete' & sort('point') 이런식으로 넘기려는데 뭔가 너무 비효율적인 것 같아서 효율적인 방법이나 일반적으로 많이 사용하는 방법 알려주시면 감사할 것 같습니다 라고 남겨주셨는데 쿼리 파라메터로 필터를 정의하는 건 굉장히 직관적이고 많이 쓰는 방법입니다. 그대로 쓰셔도 될 것 같습니다.

저도 백엔드에 한 표 던집니다ㅎㅎ 의견을 아주 약간 덧붙이자면, 1번 방식의 같은 경우, 필터링 되기 이전의 전체 데이터를 가져와야 하기 때문에 서버의 컴퓨팅 비용은 약간 줄일 수 있어도, 송신되는 데이터 양이 방대해짐에 따라 오히려 비용을 증가시킬 수 있습니다. 또한, 추후 infinityScroll 등을 도입하며 pagination을 하게될 경우에도 더 비효율적인 통신을 야기할 수 있습니다 (ex. 실제 유저가 보는건 처음 10개지만 미리 800개를 로드해옴) 물론 위의 고려사항들은 게시글이 많은 케이스의 문제이지만, 100개 미만으로 예상되는 소형 사이드 정도라면 프론트에서 해주는 것도 크게 문제가 되지는 않을듯 싶습니다,,ㅎㅎ +) 위에 대댓 질문에서 recoil 언급하신것도 살짝 덧붙이자면, 서버에 요청을 덜 하게 된다면 효율적으로 동작은 가능하겠지만, 페이지를 연 상태에서 새로운 글이 업데이트가 안되는 등의 invalidation 측면 이슈를 잘 고려하셔야 합니다.