필터 논리는 프런트 엔드 또는 백엔드에 있어야 합니까?

필터 논리는 프런트 엔드 또는 백엔드에 있어야 합니까?

웹 응용 프로그램을 만들고 있습니다.

프런트 엔드 - reactjs 및 백엔드 Java.

프런트엔드와 백엔드는 레스트를 통해 서로 통신합니다.

UI에서 항목 목록을 표시합니다.그리고 나는 그들을 몇 개의 패러머로 걸러야 합니다.

옵션 1: 필터 로직이 프런트 엔드에 있음

이 경우 백엔드에 get call을 걸어 모든 아이템을 가져오면 됩니다.사용자가 일부 필터 옵션을 선택하면 UI에서 필터링이 수행됩니다.

장점: 따라서 데이터를 백엔드로 전송하고 응답을 기다릴 필요가 없습니다.목록을 새로 고치는 속도가 빨라야 합니다.

단점: 복수의 프런트 엔드 클라이언트가 필요한 경우.모바일 앱이라고 합시다.그리고 이 앱에서도 필터를 다시 만들어야 합니다.

옵션 2: 필터 로직이 백엔드에 있음

이 경우 앱 로드 시 모든 목록 항목이 표시됩니다.사용자가 필터 옵션을 변경한 후 필터 매개 변수와 함께 get 요청을 보내고 응답을 기다려야 합니다.그런 다음 UI의 항목 목록을 업데이트합니다.

장점: 필터 로직은 한 번만 작성됩니다.

단점: 속도는 아마 훨씬 느려질 것이다.요청을 보내고 결과를 돌려받는데 시간이 걸리기 때문입니다.

질문:필터 로직은 어디에 있어야 합니까?프런트 엔드 또는 백엔드?아니면 어떤 것이 베스트 프랙티스일까요?

백엔드의 필터와 제한.100만 개의 레코드가 있고, 그 레코드에 동시에 액세스하려고 하는 유저가 10만 명이라면, 정말로 모든 유저에게 100만 개의 레코드를 송신하고 싶다고 생각하십니까?서버 및 사용자 경험(모든 사용자의 백엔드에서 100만 개의 레코드가 전파될 때까지 기다렸다가 프런트엔드로 전파되는 데 걸리는 시간은 20-100개의 레코드를 취득하고 (pagination) 버튼을 클릭하여 다음 20-100개를 취득하는 데 걸리는 시간과 비교할 때)이 됩니다.게다가, 프런트 엔드에서 백만 개의 레코드를 필터링 하는 것은, 다시 말하지만, 매우 오랜 시간이 걸리고, 궁극적으로는 그다지 실용적이지 않습니다.

실제의 관점에서 보면, 대부분의 웹 사이트에는 다음과 같은 기록 제한이 있습니다.ebay = 50-200 레코드, Amazon = ~20, 대상 = ~20...이것에 의해, 모든 유저가 서버의 신속한 응답과 원활한 유저 익스피리언스를 실현할 수 있습니다.

이는 데이터 크기에 따라 달라집니다.예: 대량의 데이터가 있는 경우 백엔드에 필터 로직을 구현하여 DB가 작업을 수행하도록 하는 것이 좋습니다.

데이터 양이 적은 경우 데이터를 가져온 후 프런트 엔드에서 필터 로직을 수행할 수 있습니다.

예를 들어 이것을 이해하자.1,00,000개의 레코드를 가진 엔티티가 있으며 이를 그리드로 표시하려고 합니다.이 경우 콜마다 10개의 레코드를 취득하여 그리드로 표시하는 것이 좋습니다.이에 대해 필터 작업을 수행하려면 백엔드에서 db에 대한 쿼리를 작성하여 결과를 얻는 것이 좋습니다.

엔티티에 레코드가 1000개밖에 없는 경우 모든 데이터를 가져오고 프런트엔드에서 모든 필터 작업을 수행하는 것이 좋습니다.

프런트엔드로 시작하는 경우가 대부분입니다(대량의 데이터를 취급하는 경우는 제외).

1. 프런트 엔드에 필터링을 실장합니다(백엔드에서 하는 것이 쉽다고는 생각되지 않는 한).
2. 필터링 기능이 어느 정도 안정될 때까지 반복합니다.
3. 트래픽을 분석하여 백엔드 필터링을 구현하는 것이 적절한지 확인합니다.실제로 필터링된 요청의 비율과 백엔드 필터링을 통해 얻을 수 있는 절감 효과를 확인하십시오.
4. #3 의 결과에 따라 백엔드 필터링을 실장(또는 실장하지 않음)합니다.

개인적인 메모로서 받아들여지는 대답은 끔찍한 조언이다.

• 「100만 개의 레코드가 있어, 그 레코드에 동시에 액세스 하려고 하는 유저가 10만 명이라면」, 그 유저에게 필터링을 강요하는 것은 아무것도 없습니다.시스템에서는, 종말의 시나리오에 대응할 수 있을 것입니다.백엔드 필터링은 단순한 최적화일 뿐 솔루션이 아닙니다.
• 백엔드에서 필터링을 하면 페이지 번호도 지정할 수 있습니다.일관된 결과를 원한다면 이것은 간단한 기능이 아닙니다.
• 백엔드 필터링은 프런트 엔드 필터링보다 훨씬 더 복잡해질 수 있습니다.초기 구현뿐만 아니라 지속적인 유지 보수에도 상당한 시간이 소요된다는 것을 알고, 이것이 시기상조인 최적화가 아닌지 자문해 보아야 합니다.

TL/DR: 최적화를 시작할 때까지 안심하고 원하는 장소에서 작업을 수행할 수 있습니다.

지원서의 구체적인 요건에 따라 다르지만, 제 생각에는 백엔드가 더 안전할 것 같습니다.

우선 필터링이 필요한 것을 고려하면, 충분한 데이터를 가지고 있기 때문에, 그 데이터를 페이징 할 필요가 있다고 생각합니다.이 경우 백엔드 필터링이 필요합니다.

페이지 크기가 20이라고 가정해 보겠습니다.필터를 적용하면 UI의 특정 필터링 기준에 일치하는 20개의 엔티티 페이지가 나타납니다.20개의 엔티티를 가져와 프런트 엔드에 저장한 후 필터를 적용하면 이 작업을 수행할 수 없습니다.

또한 충분한 데이터가 있는 경우 메모리 제약으로 인해 프런트 엔드로 모든 데이터를 가져올 수 없습니다.

언급URL : https://stackoverflow.com/questions/52346685/filters-logic-should-be-on-frontend-or-backend