PTT數位生活區 / Ajax

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

看板Ajax作者 (阿川)時間12年前 (2011/12/21 14:22), 編輯推噓7(7推 0噓 73→)
留言80則, 3人參與, 最新討論串1/4 (看更多)
大家好 小弟現要撰寫一個網站 功能如下: 這個網站有一個用html table做成的行事曆 所有使用者可以上來看本月的行事曆 也可以新增事項上去 這樣的功能 需要把資料整理成table易處理的形式 也就是大概要4~5個陣列 每個陣列有7個data 這樣就可以用迴圈去做出多個<tr>以及其內的<td> 就做出行事曆的樣貌了 小弟想問的是 整理資料這件事 應該由前端還是後端來做? 用後端做 怕server loading太大 用前端做 怕client端會跑太久 請問各位大大高見? 謝謝! -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.106.65
推
12/21 14:28, , 1F
前端 client端都會跑太久的東西 server肯定吃不下
12/21 14:28, 1F
→
12/21 14:28, , 2F
而前後端在跑的時後前端還不是一樣要等?
12/21 14:28, 2F
→
12/21 14:29, , 3F
分功上 後端要作的在於有安全需要的東西 比如說帳號
12/21 14:29, 3F
推
12/21 15:53, , 4F
肯定是前端 你試想假設同時有幾萬人做同樣的指令 要放哪好?
12/21 15:53, 4F
→
12/22 01:46, , 5F
資料整理聽起來是server side , data provider 該負責產出
12/22 01:46, 5F
→
12/22 01:46, , 6F
的 json ，這個應該是歸類在server side 。
12/22 01:46, 6F
→
12/22 01:47, , 7F
我的看法是「提供資料」=> server side的責任
12/22 01:47, 7F
→
12/22 01:47, , 8F
界面、事件、互動=> client side的責任
12/22 01:47, 8F
→
12/22 01:47, , 9F
另外我不同意mrbig 說client端跑太久的東西 server吃不下
12/22 01:47, 9F
→
12/22 01:47, , 10F
client 的 performance 相對於 server 是超級弱的。
12/22 01:47, 10F
→
12/22 01:48, , 11F
同樣一個xml parsing , server 只要1s , client 可能要2~4s
12/22 01:48, 11F
→
12/22 01:48, , 12F
只是client用的是使用者的資源，server用的是server的資源
12/22 01:48, 12F
→
12/22 01:48, , 13F
考慮到資源的運用上，能盡量轉嫁給user的就盡量凹。
12/22 01:48, 13F
→
12/22 01:49, , 14F
但 server 是不是吃不下，要視狀況決定。
12/22 01:49, 14F
推
12/22 10:41, , 15F
假設server的速度是client的4倍 同時有4人以上使用serv
12/22 10:41, 15F
→
12/22 10:41, , 16F
er的機率有多少? 如果很少甚至通常只有一人的話當然可
12/22 10:41, 16F
→
12/22 10:41, , 17F
以全丟給server...
12/22 10:41, 17F
→
12/22 10:42, , 18F
但還要考慮網路傳輸的問題 通常情況,未經過處理的原始
12/22 10:42, 18F
→
12/22 10:42, , 19F
資料會比經過處理格式化的資料要小 傳輸速率也會快
12/22 10:42, 19F
→
12/22 10:44, , 20F
再怎考慮各種情形 我還是覺得能轉嫁給user的就全給user
12/22 10:44, 20F
→
12/22 10:44, , 21F
server只要考慮"應該丟給使用者什麼資料才安全"即可
12/22 10:44, 21F
推
12/22 11:07, , 22F
除非你的主機已經強大到跟google一樣的可當雲端層級...
12/22 11:07, 22F
→
12/22 11:09, , 23F
而且還到處都有分支主機保證傳輸速率在一定之內...
12/22 11:09, 23F
→
12/22 11:10, , 24F
雲端計算的模式才會有比較快的可能
12/22 11:10, 24F
→
12/22 14:11, , 25F
我覺得你想的有點多 如果是預先處理好的資料 在存檔時就可以
12/22 14:11, 25F
→
12/22 14:11, , 26F
先按照他要輸出的資料格式先做好。我用1:4 是很客氣的假設
12/22 14:11, 26F
→
12/22 14:12, , 27F
他輸出時還要經過處理，正常來講作為資料提供通常都已經先
12/22 14:12, 27F
→
12/22 14:12, , 28F
做好該作得資料格式轉換甚至是cache 。而且server橫豎是需要
12/22 14:12, 28F
→
12/22 14:12, , 29F
提供資料的。而且未經過處理的資料怎麼可能比格式化還小，
12/22 14:12, 29F
→
12/22 14:12, , 30F
真的是這樣那根本是格式有問題吧。
12/22 14:12, 30F
→
12/22 14:13, , 31F
再加上server 還可以作gzip，比起丟一堆大量的原生資料進行
12/22 14:13, 31F
→
12/22 14:14, , 32F
分析，當然是先搞定資料啊。Orz
12/22 14:14, 32F
→
12/22 14:16, , 33F
他的這個需求計算的部份很小，倒是資料怎麼儲存怎麼最低成本
12/22 14:16, 33F
→
12/22 14:16, , 34F
轉換成VO的多，幾乎都可以將運算量壓到最低的case。
12/22 14:16, 34F
→
12/22 14:17, , 35F
應該要討論的是怎麼儲存資料跟怎麼轉換成Json最有效率，
12/22 14:17, 35F
→
12/22 14:17, , 36F
client跟server 的效能根本不是這個問題的重點。
12/22 14:17, 36F
→
12/22 14:20, , 37F
我不是不同意可以轉嫁成本給 client ，但是幹嘛要先把成本弄
12/22 14:20, 37F
→
12/22 14:21, , 38F
得很高再讓client 收尾巴，一開始就讓成本很低就好啦...
12/22 14:21, 38F
推
12/22 14:42, , 39F
做gzip也需要主機端的資源 預先以需要輸出的資料格式儲
12/22 14:42, 39F
→
12/22 14:42, , 40F
存也只是把運算時花的時間移到儲存時
12/22 14:42, 40F
→
12/22 14:43, , 41F
我相信這樣搞之後 也許最後加起來的總消耗時間或許真的
12/22 14:43, 41F
→
12/22 14:45, , 42F
比"全部丟給client端就好"加總再平均之後來得快啦...
12/22 14:45, 42F
→
12/22 14:45, , 43F
但你確定原po需要的是這種答案?||
12/22 14:45, 43F
→
12/22 14:48, , 44F
我所謂"處理過後的資料"指得是"已經確定必須的資料"再
12/22 14:48, 44F
→
12/22 14:48, , 45F
上"格式"後的結果,即使是json都要加上一堆{}"": 更何況
12/22 14:48, 45F
→
12/22 14:49, , 46F
是html...原始資料肯定比較小啊...
12/22 14:49, 46F
→
12/22 14:51, , 47F
至於server端的資料從何而來...我一直以為大部分初學者
12/22 14:51, 47F
→
12/22 14:52, , 48F
都是直接從DB撈啦...如果原po是那種是先按輸出做好格式
12/22 14:52, 48F
→
12/22 14:52, , 49F
外加視情況寫好快取的人...千萬不要聽我的話 我是小咖
12/22 14:52, 49F
→
12/22 14:56, , 50F
你原始資料還不是要有separator 要有escaping
12/22 14:56, 50F
→
12/22 14:57, , 51F
不然你怎麼分段切割
12/22 14:57, 51F
→
12/22 14:57, , 52F
{} "" 那都是判斷資料格式中的必須 你省他只是找自己麻煩
12/22 14:57, 52F
→
12/22 14:58, , 53F
從db撈出來也不過就是一堆RecordSet 你還是要output啊
12/22 14:58, 53F
→
12/22 14:58, , 54F
我很確定這個需求不可能產生你說的這種情況，這種需求我
12/22 14:58, 54F
推
12/22 14:58, , 55F
所以你的意思是 json比CVS還小? 從DB撈出來的資料轉為
12/22 14:58, 55F
→
12/22 14:59, , 56F
CVS花的資源比轉為json還大?
12/22 14:59, 56F
→
12/22 14:59, , 57F
做過沒有二三十次也至少有十次以上，很基本的需求啊。
12/22 14:59, 57F
→
12/22 15:00, , 58F
更正 是CSV
12/22 15:00, 58F
→
12/22 15:00, , 59F
我覺得如果你output 是 cvs ，1.除非你db就是存cvs字串
12/22 15:00, 59F
→
12/22 15:00, , 60F
不然轉csv 跟轉json來講，效能上幾乎是一樣的。
12/22 15:00, 60F
→
12/22 15:01, , 61F
但是前者可以避免client side 的多餘邏輯跟運算效能。
12/22 15:01, 61F
→
12/22 15:01, , 62F
2.csv 跟json 來講 誰大誰小 以array來講 ok 他的確有機會
12/22 15:01, 62F
→
12/22 15:01, , 63F
小一點，但是那個差距幾乎可說是小於可忽略的。
12/22 15:01, 63F
→
12/22 15:02, , 64F
*我的意思是轉json
12/22 15:02, 64F
→
12/22 15:03, , 65F
而且你說csv，那他就限定不能有多層結構，一有多層結構csv
12/22 15:03, 65F
→
12/22 15:03, , 66F
絕對沒有json經濟。
12/22 15:03, 66F
→
12/22 15:07, , 67F
當然 我也不是建議原po輸出html ，如果你以為我說的資料提供
12/22 15:07, 67F
推
12/22 15:07, , 68F
問題就在於從DB撈出來的資料不會有多層結構啊...
12/22 15:07, 68F
→
12/22 15:07, , 69F
是html，那的確是誤會。因為單就產html這件事情而言，我是
12/22 15:07, 69F
→
12/22 15:07, , 70F
你有多層結構就肯定經過"在處理=花資源"了
12/22 15:07, 70F
→
12/22 15:07, , 71F
能接受client產html的。
12/22 15:07, 71F
→
12/22 15:08, , 72F
是嗎？你今天有一個日期有多個事件，這就是一個層次了。
12/22 15:08, 72F
→
12/22 15:08, , 73F
這些日期可能又會有跨日期的事件，也是層次。而且一樣為什麼
12/22 15:08, 73F
→
12/22 15:09, , 74F
client 可以直接吃的json 不用，要弄個csv，然後client還要
12/22 15:09, 74F
→
12/22 15:09, , 75F
我覺得我們這樣講滿亂的 你先講吧 我晚上有空再po一篇
12/22 15:09, 75F
→
12/22 15:09, , 76F
再稿支 csv parser ，量大還會lag(client 效能差)
12/22 15:09, 76F
→
12/22 15:09, , 77F
我不覺得server產csv跟產json 有量上的差別，你說產xml或
12/22 15:09, 77F
→
12/22 15:10, , 78F
html會肥 我很同意，但是json 沒有這個問題。
12/22 15:10, 78F
→
12/22 15:10, , 79F
我覺得我們直接舉實例來討論可能比較快。
12/22 15:10, 79F
→
12/22 15:14, , 80F
我回文啦 剩下的交給你回吧
12/22 15:14, 80F
‣ 更多 poopoo888888 的文章
文章代碼(AID): #1EyNinCZ (Ajax)
Ajax 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 poopoo888888 的文章
文章代碼(AID): #1EyNinCZ (Ajax)