javascript - 알림 목록 및 세부정보를 논의하기 위한 API 디자인

MVVM을 기반으로 알림 구성 요소를 만들고 싶습니다. 모든 데이터는 json에 저장됩니다. 목록 페이지에는 필터링 및 검색 기능이 있습니다. 알림 세부정보는 이전 항목을 불러오고 다음 항목으로 전환합니다.

필터링 및 검색 조건이 없는 경우 전체 이전 및 다음 전환은 세부정보 페이지에서 직접 수행할 수 있고, 필터링 조건 또는 검색 조건이 있는 경우 검색에서 이전 및 다음 전환이 수행될 수 있기를 바랍니다. 결과 목록.

옵션 1:

제가 직접 생각해낸 계획이에요.
전체 구성 요소가 초기화되면 이 사용자의 모든 알림(ID)이 로컬로 가져와 전역 [store.list.all]에 기록됩니다. 나중에 세부 정보 페이지를 클릭하면 프런트 엔드가 ID를 가져옵니다. 클릭할 항목의 매개변수를 사용하여 Ajax 요청을 수행하면 세부정보 페이지에 현재 알림 ID와 모든 알림 ID 목록이 표시됩니다. 이런 식으로 세부정보 페이지에서는 이전 항목의 ID와 다음 항목의 ID를 쉽게 알 수 있습니다.
필터링이나 검색 조건이 있는 경우 전역 [store.list.filter]를 기억해두시면 방법은 위와 동일합니다.

• 장점: 이전 항목과 다음 항목을 구현하기가 매우 쉽고, 목록 페이지를 넘길 때마다 데이터를 요청할 필요가 없습니다.

• 단점: 사용자의 알림 목록이 매우 길면 초기화 및 검색 시 [store.list]에 요청하고 기록해야 하는 데이터가 매우 많아지고, 홈페이지가 매우 커질 수 있습니다. 느려지고 성능이 저하됩니다.

옵션 2:

회사의 이전 제품에 대한 제안.
목록 페이지에 대한 페이징 쿼리를 수행하기 위해 각 요청은 페이지+행을 매개변수로 사용하며, 행의 페이지를 쿼리하여 쿼리를 수행합니다(예: 페이지=3, 행=10, 31번째부터 40개 항목). 필터링과 검색 기능은 동일합니다.
이전 상품은 이전 상품과 다음 상품 간 전환을 구현하지 않았습니다.
그러나 이 아이디어를 계속 따르면 아마도 다음과 같을 것입니다.
필터 없는 검색 조건에서는 현재 ID를 매개변수로 보내고 다음 또는 이전 매개변수를 가져오므로 신뢰할 수 있습니다. 데이터베이스를 쿼리할 때 이 방법을 사용하세요. select * from foo where id = (select min(id) from foo where id > 4)필터링된 검색 조건이 있으면 오히려 역겨운 일입니다. 아마도 목록 페이지에서 세부 정보 페이지를 클릭할 때 검색 상태를 저장했을 것입니다. (이렇게 할 수도 있습니다. 돌아가기 버튼) 이 상태를 저장)한 후 이전 또는 다음 항목으로 이동 시 id, next 외에 검색 조건도 포함되어 조회됩니다. 단지 Ajax 요청 API를 작성하는 것이 역겨울 뿐입니다.

• 장점: 목록 페이지에 페이지가 매겨져 있으며 사용자는 알림 수에 대해 걱정하지 않습니다.

• 단점: 목록 페이지 넘길 때 요청 및 쿼리가 필요하며, 쿼리 조건이 복잡하고 백엔드 부담이 크다. 세부정보 페이지에서 다음 홉에 대한 Ajax 요청이 더 어려워진다. 쓰다.

현재는 두 가지 아이디어만 있으며 각각 장점과 단점이 있습니다.

다른 아이디어가 있으신가요?

답글 내용:

MVVM을 기반으로 알림 구성 요소를 만들고 싶습니다. 모든 데이터는 json에 저장됩니다. 목록 페이지에는 필터링 및 검색 기능이 있습니다. 알림 세부정보는 이전 항목을 불러오고 다음 항목으로 전환합니다.

필터링 및 검색 조건이 없는 경우 전체 이전 및 다음 전환은 세부정보 페이지에서 직접 수행할 수 있고, 필터링 조건 또는 검색 조건이 있는 경우 검색에서 이전 및 다음 전환이 수행될 수 있기를 바랍니다. 결과 목록.

옵션 1:

제가 직접 생각해낸 계획이에요.

전체 구성 요소가 초기화되면 이 사용자의 모든 알림(ID)이 로컬로 가져와 전역 [store.list.all]에 기록됩니다. 나중에 세부 정보 페이지를 클릭하면 프런트 엔드가 ID를 가져옵니다. 세부정보 페이지에 현재 알림 ID와 모든 알림 ID 목록이 포함되도록 매개변수를 사용하여 Ajax 요청을 수행합니다. 이런 식으로 세부정보 페이지에서는 이전 항목의 ID와 다음 항목의 ID를 쉽게 알 수 있습니다.
필터링이나 검색 조건이 있는 경우 전역 [store.list.filter]를 기억해두시면 방법은 위와 동일합니다.

• 장점: 이전 항목과 다음 항목을 구현하기가 매우 쉽고, 목록 페이지를 넘길 때마다 데이터를 요청할 필요가 없습니다.

• 단점: 사용자의 알림 목록이 너무 길면 초기화 및 검색 시 [store.list]에 요청하고 기록해야 하는 데이터가 매우 많아지고, 홈 페이지가 매우 커질 수 있습니다. 느려지고 성능이 저하됩니다.

옵션 2:

회사의 이전 제품에 대한 제안.
목록 페이지에 대한 페이징 쿼리의 경우 각 요청에 대한 매개변수로 페이지+행을 사용하고 한 페이지의 행으로 페이지를 쿼리합니다(예: 페이지=3, 행=10, 이는 31번째부터 40번째 항목을 쿼리한다는 의미) ). 필터링과 검색 기능은 동일합니다.
이전 상품은 이전 상품과 다음 상품 간 전환을 구현하지 않았습니다.
그러나 이 아이디어를 계속 따르면 아마도 다음과 같을 것입니다.
필터링되지 않은 검색 조건에서 현재 ID를 매개변수로 보내고 다음 또는 이전 매개변수를 가져오므로 신뢰할 수 있습니다. 데이터베이스를 쿼리할 때 이 방법을 사용하세요. select * from foo where id = (select min(id) from foo where id > 4)필터링된 검색 조건이 있으면 오히려 역겨운 일입니다. 아마도 목록 페이지에서 세부 정보 페이지를 클릭할 때 검색 상태를 저장했을 것입니다. (이렇게 할 수도 있습니다. 돌아가기 버튼) 이 상태를 저장)한 후 이전 항목이나 다음 항목으로 이동할 때 id, next 외에 검색 조건도 포함되어 조회됩니다. 단지 Ajax 요청 API를 작성하는 것이 역겨울 뿐입니다.

• 장점: 목록 페이지에 페이지가 매겨져 있으며 사용자는 알림 수에 대해 걱정하지 않습니다.

• 단점: 목록 페이지 넘길 때 요청 및 쿼리가 필요하며, 쿼리 조건이 복잡하고 백엔드 부담이 크다. 세부정보 페이지에서 다음 홉에 대한 Ajax 요청이 더 어려워진다. 쓰다.

현재는 두 가지 아이디어만 있으며 각각 장점과 단점이 있습니다.

다른 아이디어가 있으신가요?

옵션 1의 치명타: 사용자가 알림을 100,000개 사용하는 경우.

옵션 2의 치명적인 타격: 쿼리 조건의 복잡성이 지속적으로 증가하면 스토리지 부담이 커집니다.

======

중간 솔루션

한 번에 N일의 데이터를 읽습니다(N일의 데이터 양이 기본적으로 제어 가능하다면 이 솔루션은 구현되지 않습니다).

신뢰할 수 있는 솔루션

Elasticsearch 사용