首頁  >  文章  >  後端開發  >  javascript - 討論個通知清單和詳情的API設計

javascript - 討論個通知清單和詳情的API設計

WBOY
WBOY原創
2016-10-17 09:30:071045瀏覽

想做一個通知元件,基於MVVM,所有資料走json。清單頁帶過濾和搜尋功能。通知詳情帶上一條下一條切換。

希望能實現在無過濾和搜尋條件下時,在詳情頁內直接做到全局的上一條下一條切換;而在有過濾條件或搜尋條件時,上一條下一條在搜尋結果列表中切換。

方案1:

這是我自己想出來的方案。
在整個組件初始化時,就把本用戶下的所有通知(ID)取到本地,記到全局[store.list.all],之後當點擊詳情頁時,前端把要點擊的條目id作為參數做ajax請求,這樣詳情頁就有當前通知id,所有通知id列表。這樣的話詳情頁就可以很輕鬆的知道上一條的id、下一條的id。
當有篩選或搜尋條件時,記到全域[store.list.filter],方法同上。

  • 優點:上一條下一條會變得非常容易實現,而且列表頁每次翻頁不需要請求資料。

  • 缺點:如果這個使用者的通知清單非常長,那麼初始化和搜尋的時候,需要請求並記錄到[store.list]中的資料就會非常大,首頁速度可能會非常慢,而且效能會變糟。

方案2:

公司以前產品的方案。
列表頁做分頁查詢,每次請求使用page+row做參數,以一頁row條,查詢第page頁的方式查詢(例如page=3,row=10,就表示查詢第31-40條)。過濾和搜尋功能同樣。
之前的產品未實現上一條下一條切換。
不過按照這個思路繼續搞下去的話,大概會這樣:
無過濾搜索條件下,發送當前id作為參數,並帶上next或previous參數,這樣數據庫查詢時可以依靠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作為參數做ajax請求,這樣詳情頁就有當前通知id,所有通知id列表。這樣的話詳情頁就可以很輕鬆的知道上一條的id、下一條的id。
當有篩選或搜尋條件時,記到全域[store.list.filter],方法同上。

  • 優點:上一條下一條會變得非常容易實現,而且列表頁每次翻頁不需要請求資料。

  • 缺點:如果這個使用者的通知清單非常長,那麼初始化和搜尋的時候,需要請求並記錄到[store.list]中的資料就會非常大,首頁速度可能會非常慢,而且效能會變糟。

方案2:

公司以前產品的方案。
列表頁做分頁查詢,每次請求使用page+row做參數,以一頁row條,查詢第page頁的方式查詢(例如page=3,row=10,就表示查詢第31-40條)。過濾和搜尋功能同樣。
之前的產品未實現上一條下一條切換。
不過按照這個思路繼續搞下去的話,大概會這樣:
無過濾搜索條件下,發送當前id作為參數,並帶上next或previous參數,這樣數據庫查詢時可以依靠select * from foo where id = ( select min(id) from foo where id > 4)這個方式去查詢。
有過濾搜尋條件下,這個就比較噁心了,自己沒想出什麼好主意,大概是從列表頁點進詳情頁時保存一下搜尋狀態(這個可以做到,返回按鈕就有保存這個狀態) ,之後上一條下一條時,除了id、next,也帶上搜尋條件做查詢。就是ajax請求api寫起來會比較噁心。

  • 優點:清單頁分頁,使用者有多少通知都不怕。

  • 缺點:列表頁翻頁時也要請求和查詢,查詢條件複雜,後端負擔大,詳情頁上一條下一跳的ajax請求會比較難寫。

目前就這兩種思路,各有優缺點。

大家還有沒有其他思路?

方案一的致命一擊: 如果一個使用者用10W條通知。

方案二的致命一擊:不停的增加查詢條件的複雜度,對儲存壓力增加。

======

中庸方案
一次讀取N天資料(前提是N天的資料量基本上可控,否則此方案不實現)。

可靠方案
使用Elasticsearch

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
上一篇:apache 假死下一篇:apache 假死