Re: [問題] 這樣的功能 前端or後端做?

[TonyQ (自立而後立人。)]

※ 引述《mrbigmouth (拒絕崩潰的蒲公英)》之銘言：
: 在這種情況下，你需要的東西其實是Html產生器，一個幫你把資料變成Html頁面的東西
: 如果這個過程就是TonyQ大大所說的"以特定格式儲存再從伺服端取出"的"後端語言"
: 那我認輸，至少在這個情況下認輸
: 因為整個處理過程根本只有一次嘛！當然是給處理能力最好的電腦去做....
: 但是
: 如果你的行事曆至少需要多人編輯、依登入者身份可以隨意插入、刪除、變更工作內容
: 工作內容有分級、分塊、分類，可以drill down跟roll up等等等的時候
: （依在下的不幸工作經驗來看，所有一開始看來很簡單的程式在之後八成都會
: 　在老闆/使用者的要求下加東加西，最後變成這種萬能的樣子）
: 換句話說,資料進出資料庫的頻率很大的時候
: 前端就遠勝於後端了

        其實以上我們是有共識的

        也就是前端修改頻繁的狀況下，用 CLIENT 可以縮小更新的範圍，

        也可以有效的進行互動。所以我就不多談了。

        雖然我的表達應該讓你有誤會的地方，
        我想主要的誤會在於我是把整理資料切成兩段的。

        一段是純vo (json) ，另一段才是 vo => html。

        我相信你應該也有切這兩段，只是你沒有特別標明而已。


        另外 SEO 議題也只是 add-on 順便一提，你可以忽略這個子項沒差，
        他不是很重要的重點，也有別的方式可以補償。XD


        至於，我說的行事曆是主要用來顯示的狀況下，

        靠後端組html就好了，
        除非你有必要再畫面上點一點，日曆上就加個新項目（不換頁）。

        或者畫面上按一按，東西就少一項，（不換頁）。


        很多地方的作法是把新增刪除的表單往別的地方甚至別的系統扔，
        這種狀況行事曆就只會是撈出來顯示。

        這種情況，我不覺得非得要用前端不可啦，
        反正小量的字串工作對後端真的是不痛不癢。


: 為什麼？
: 因為在工作交由後端處理的情形下，使用者每執行一次此類操作，
: 伺服器就需要重新從DB撈一次資料、重新計算並且重新把資料傳遞給使用者
: 每次執行工作時,資料都需要跑一次DB->將原始資料編成適當格式->使用者的路程
: 而在前端處理的情況下，所有資料一進入記憶體就不太需要再從DB撈取，更不需要
: 再次經過網路傳輸的折磨
: 如下所示：
: 狀況：
: A.使用者登入並瀏覽此月行程
: B.使用者瀏覽下個月行程
: C.使用者在下個月插入新行程
: D.使用者返回瀏覽此月行程
: E.使用者重新整理
: F.使用者drill down瀏覽今日行程
: 後端處理情形：
: A.使用者資料傳輸給Server->驗證使用者建立Session->從DB撈屬於這個月的行程出來->
: 將原始資料編成固定格式->資料傳輸給使用者
: B.使用者資料傳輸給Server->確認使用者身份->從DB撈出下個月行程資料->
: 將原始資料編成固定格式->資料傳輸給使用者
: C.使用者資料傳輸給Server->確認使用者身份->將資料插進DB->從DB撈出新行程資料->
: 將原始資料編成固定格式->資料傳輸給使用者
: D.使用者資料傳輸給Server->確認使用者身份->從DB撈出這個月行程資料->
: 將原始資料編成固定格式->資料傳輸給使用者
: E.使用者資料傳輸給Server->確認使用者身份->從DB撈出這個月行程資料->
: 將原始資料編成固定格式->資料傳輸給使用者
: F.使用者資料傳輸給Server->確認使用者身份->從DB撈出今日行程資料->
: 將原始資料編成固定格式->資料傳輸給使用者
: 前端處理情形：
: A.使用者資料傳輸給Server->驗證使用者建立Session->從DB撈出所有使用者可見的行程
: 資料出來->以批次或者server-sent方式逐步傳遞給使用者->使用端將資料編成固定格式
: 展現
: B.使用端將資料編成固定格式展現
: C.使用者資料傳輸給Server->確認使用者身份->將資料插進DB->從DB撈出指定時間以後
: 有所異動的資料->資料傳輸給使用者->使用端將資料編成固定格式展現
: D.使用端將資料編成固定格式展現
: E.使用者資料傳輸給Server->確認使用者身份->從DB撈出指定時間以後有所異動的資料
: ->資料傳輸給使用者->使用端將資料編成固定格式展現
: F.使用端將資料編成固定格式展現
: 以上

        以上這些我同意，如果你需要頻繁操作，透過前端當然比較簡單，
        也可以只取你想要得部份。

: 最後
: 請不要把json說的好像不需要parse一樣...
: 無論是什麼格式的資料,從server端傳過來的時候就只是字串
: 不管你是用eval還是各瀏覽器內建的parser,
: 切CSV所花費的時間絕對小於轉換json的時間

        等等，我覺得你要不要說說你怎麼 parse CSV 的？

        就我所知 , csv 要嘛就是用regex , 要嘛就自己split "," .

        (不管split 或indexOf+substring)

        有比這更快更方便的方式嗎？
        我不是那麼常作csv，所以想確認一下。

        如果沒有，我覺得你的「絕對」要打個折扣。

: 使用資料的類別更是跟使用者體驗八竿子打不著關係
: 只要用熟了就一點麻煩也不會有


        這個前提是parse 需要花費時間，而花費時間動作多了

        browser 會「鈍鈍的」。

        當然我同意這種case底下，除非是ie6或ie7這種爛咖，
        不然一般狀況應該都沒這問題。


: 當然,無論如何,前端花費的資源永遠只是小case
: 重點在於後端要傳輸資料的時候
: 你要輸出json,就一定要先把所有資料存在記憶體裡才能一次轉換

        並沒這回事，你csv能怎麼做，json就能怎麼做。

        如果你嫌一次轉換一整個array太浪費資源，
        你一筆一筆自己翻 string 轉也可以，這是轉換方法的問題。


        沒有人規定你要「一次轉換」，事實上大量的資料我是不會這麼做，
        這也是效能調校上的重點項目之一。


: 比如要把從DB resource讀出的資料一筆筆全部存進陣列裡...這過程是要吃記憶體的
: 小量的資料沒感覺,如果是一千筆、一萬筆資料呢?一個留言板的全部文章這種呢?
: (特別是當使用語言是PHP陣列這種消費記憶體為實際N倍的怪物時)

        你csv 能怎麼產，我就能怎麼產json。

: 從Server輸出CSV就不會有這種問題

        我覺得這只是你用不對等的方式再比較這兩個東西。:P

: json當然好用,我自己寫ajax時也有超過一半是在用json
: 但json比csv好的優勢在於可以存進多層次、複雜的資料,而不是在效率
: 然後...從DB撈出來的原始資料,絕大多時候都是CSV能夠處理的

        這個我不認為，這可能跟資料操作的習慣有關係。

        csv 是扁平的，那意味著每次的資料都是獨一無二的，

        你很難重用相同的資料在其他 request ...


        json 有彈性一點，不過這點要看設計習慣，
        你覺得可以的話，我是不覺得有問題啦。


        另外 json 可以透過 jsonp 輕鬆支援跨網域，這個彈性也是沒話講得。

: 在我上面所說的例子,當後端完全只負責撈DB與傳輸的情形下
: 完全可以使用CSV取代json,殺雞焉用牛刀



        有關 csv 跟 json parsing 的部份，我想數字會說話。


        對 test case 或者測量方法有不滿意的，可以自己改我們再來討論，

        我因為一時想不到啥好例子，也真的是很懶得再找csv parser，
        所以找一個對 csv 來講相對單純的例子，
        實務上，csv 還要考慮 "" 跟 , 的差別，還會再慢一點。

        http://jsfiddle.net/jnAW3/1/


        這個我特地讓 json 放點水，加上 "" 。
        http://jsfiddle.net/jnAW3/2/


        本來想再測測 jsonp ，不過那個測試多少會被網路速度干擾，就算了。


        基本上，如果你的資料超過八萬筆，那真的已經算是很了不起的了，
        這就是為什麼我不太理解你所謂的解 csv 比 json 快的論述在哪。

        它在chrome跟firefox 的數字還蠻飄的，看不出明顯差異，
        在 IE 我的測試是相當明顯，另外可以比較 ie6,ie7,ie8 ,fx,chrome 的。


        在IE6,IE7 上的數字，那可不是小case，
        盡可能降低資料的操作量一直都是 performance tunning 上的重點。


        可能我的觀念也不見得是對得，特別在效能議題上，
        我們已經碰過很多次改個板，舊的觀念就大洗盤的狀況，

        不過這個議題上到目前為止，我的論述只有兩個：

        1.csv parser 你要引用外部類別或者自己寫複雜邏輯，
          不好維護，也需要額外成本。（這是重點）

          哪個是雞哪個是牛刀還很難說...

        2.效能上沒有顯著差異，所以我完全想不到，
          任何用csv parser取代 json parser的理由。


        當然，這可能是測試案例的問題，只是我的認知跟你的認知有出入，
        如果你可以有更好得例子，能說明 CSV 的好處，那也很歡迎。

--

      網頁上拉近距離的幫手              實現 GMail豐富應用的功臣   

        數也數不清的友善使用者體驗      這就是ｊａｖａｓｃｒｉｐｔ

                                                歡迎同好到 AJAX 板一同討論。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 198.203.175.175
※ 編輯: TonyQ           來自: 198.203.175.175      (12/23 00:42)
※ 編輯: TonyQ           來自: 198.203.175.175      (12/23 00:44)
※ 編輯: TonyQ           來自: 198.203.175.175      (12/23 00:44)
※ 編輯: TonyQ           來自: 198.203.175.175      (12/23 00:46)
※ 編輯: TonyQ           來自: 198.203.175.175      (12/23 01:08)
推 mrbigmouth:我不太清楚你說的切兩段是什麼意思
→ mrbigmouth:在很多情況下 我寫的程式就跟我舉的例子一樣
→ mrbigmouth:後端完全只負責身分認證跟取資料 其他全部給前端處理
→ mrbigmouth:在考慮SEO的狀況下 當然就是該怎麼做就怎麼做了
→ mrbigmouth:然後我對json沒偏見 上面也說過我常用
→ mrbigmouth:會把csv舉出來也只是舉例 我用的更像是你說的1 也就是
→ mrbigmouth:自訂複雜邏輯 用來切的基本上不是,跟\n啦(太常出現,置
→ mrbigmouth:換需求多) 至於為什麼會這樣做 是極端的背景原因啦
→ mrbigmouth:在做的後台在身分認證控管上很複雜 資料庫也分散 而且
→ mrbigmouth:重覆取用大量資料並且進行分析
推 mrbigmouth:總之json速度的確比我想像中要快 受教了
→ TonyQ:基本上我的操作習慣是這樣，從server來的東西叫data
→ TonyQ:他會是一個array或是object
→ TonyQ:會有一個renderer 或者是什麼的function 吃這個data
→ TonyQ:然後生成view。這兩個部份我是嚴格分開的。
→ TonyQ:所以對我來說 伺服器過來給我的data 盡可能的話
→ TonyQ:應該是view那邊我不太需要對data再做運算，（過濾日期..etc
→ TonyQ:而view那邊盡可能的就只針對ui相關的邏輯（切格子...etc）
→ TonyQ:好處是如果我要更換資料來源 處理不同資料 會比較好 而且
→ TonyQ:改邏輯時也可以清楚一致。
→ TonyQ:這是我所謂的切兩段。
※ 編輯: TonyQ           來自: 208.54.38.134        (12/23 04:25)
→ TonyQ:當然實務上幾乎不可能切乾淨啦，但至少 8:2 或 7:3 左右的
→ TonyQ:比例要維持住就是了。
推 nightspirit:推server來的是data~ 用json真的很方便阿
推 mrbigmouth:也許是因為我一向都前後端通包吧 所以習慣上不需要這樣
→ mrbigmouth:完全分開  前端也可以把資料運算跟view分得很開 兩個檔
→ mrbigmouth:案什麼的 維護上其實不會特別困難
→ mrbigmouth:說到底 "資料傳輸時的格式"其實並不是非常重要的東西
→ mrbigmouth:離開輸出入兩端就什麼都不是 不管是前後端都只有輸出入
→ TonyQ:我也是偏向前後端通包的啊 :) 不過把東西都扔到client 也是
→ mrbigmouth:時會接觸到這塊  我今天不想用CSV了也可以很快就換掉
→ TonyQ:限度的，大概是我早期browser發展還沒現在這麼好，client常
→ TonyQ:常玩太用力就 hang 住 。對client的效能比較敏感一點。:P
→ mrbigmouth:維護上的困難我想是幾乎沒有啦  這就看個人習慣了
→ TonyQ:不過這種東西只要自己做得習慣就好啦 有幾百種方法
→ TonyQ:沒有什麼是對的  只是不要變成漿糊混一起就好了
→ TonyQ:有的人用檔案分 有的人用函數命名區隔 ..etc
→ TonyQ:很多種方式的
→ chrisQQ:兔曹一下，如果資料超過8萬筆要一次秀出來，那就是
→ chrisQQ:設計問題，而不是效能問題了 XDDDD （飄走