國立聯合大學

前後端的工作分配?

2020年9月6日 02:34
最近發生一些事情,說真的我很不高興啊 想問問大家這些真的是前端該做的嗎? 事情大致如下: 通常我會請後端把資訊整理好後再傳到前端來 簡單的格式例如:{ID:xxx,Value:xxx} 不久前公司來了新人,是目前後端的朋友,據說她曾經寫過半年的前端,後來都在寫後端,最近她覺得我都在欺負後端,她的意思是: “前端先用各種API取得對應的資訊列表,後端只要傳ID給前端,前端就能撈出相對應的value,不要什麼事情都丟給後端做” 這樣會變成進入某個頁面原本只要call 1~2隻API就能呈現畫面,為了取得不同種類的資訊列表可能要call 10隻以上的API,撈取對應ID的資訊後再做資料處理後才能呈現畫面,每個資訊列表可能上千上萬筆,PM又說顯示的資訊一定要最新,所以也不能用緩存,進入新的頁面就要全部重call一次,重點是這些資訊幾乎用來抓取對應的Value,完全沒其他作用,這樣到底為什麼不能把Value欄位一起給前端就好了呢?我實在無法理解 但她說這樣做才是對的,她跟後端同事又是好姐妹,沒跟主管討論過就擅自改成欄位都只傳ID,要我自己把名稱抓出來 在我眼裡這種做法效能簡直差到不行... 如果她真的是對的,誰能告訴我why?🤔
7
回應 23
文章資訊
Logo
每月有 14 則貼文
共 23 則留言
逢甲大學
他只是嫌關聯麻煩不想做吧 但不做關連,那好像也不需要她了 再換一個說法啦,我們不去計較她表現如何,今天公司後端會招這種比菜鳥還菜的公司,我覺得你要考慮一下了,你在這裡真的會學到東西嗎
原 PO - 國立聯合大學
我也打算明年尾牙後換工作 話說我們團隊成員不是菜鳥 都是國立大學或碩士畢業,也有相關工作經驗 但後端提出的操作我實在無法認同 我認為她們只是想把工作推給前端 而且讓我很不高興的點在於 這些事情竟然是兩個女生私下講好 都沒找前端討論,也沒告知主管 之前後端明明都很正常啊 怎麼同事朋友來以後就變了... 根本在搞事吧= =
等你遇到後端的資料格式是隨時變動的,你就知道你有多幸福了
南臺科技大學
資料量大的時候這樣繞會很慢 你就去測某一段效能啊 至少有個依據可以嘴砲
國立臺北科技大學
是沒學過 join 的後端工程師呢
國立臺灣師範大學 圖文傳播學系
同步跟非同步差異
逢甲大學
樓上來一個跑錯棚的 還是剛學 web api 腦袋充滿奇怪的詞彙 ?
國立臺灣師範大學 圖文傳播學系
前端同步多之api比少量之效率高
國立臺北科技大學
不是同步非同步的問題,先看懂人家問題
龍華科技大學
這就是前後端分離之後要面對的,api為了跨平台跟微服務使用,不可能為其中一個前端量身定做,只能靠前端自己轉成ViewModel 再來這樣做,效能負擔是在client端,假如是部署在雲端,這樣pods資源不用開這麼大,可以省不少錢
原 PO - 國立聯合大學
B10 哦?! 跨平台和雲部屬這件事 如今是大多數公司都會採用的吧 我們公司也是如此~ 這麼說後端在資料方面傳ID 前端再去想辦法撈出資訊 會是越來越普遍的作法嗎? 但這樣前端效能堪憂啊...QQ
逢甲大學
B10 為什麼不可能量身訂做 是哪家公司業務量這麼大到連關聯完再送到前端的時間都沒有 全部送給前端再自己搞搜尋不就全部資料被攔截光光 ?
國立臺北科技大學
B10 就算打算開發成第三方 RESTful API,也是要開出各式各樣的請求端口 而不是像內文跟屎一樣給你一堆沒意義的列表要你自己 mapping,這種沒 sense 的後端沒畢業都可以來 即使是 Facebook、Google...等,上千萬人使用的,也不會這麼做 更何況大多數公司根本沒有到需要做成第三方 RESTful API的需求
龍華科技大學
B12 Q1:為什麼不能量身訂做 A1:量身訂做,共用性就比較低 Q2:是哪家公司業務量大到連關聯完再送到前端的時間都沒有? A2:這問題的焦點放在關聯應該在前端處理或是後端處理,我覺得會比較恰當。 後端當然可以關聯,但十幾支不同種類的資訊列表api需要互相等待後在傳到前端,這樣查詢時間會被拉長,在等待的時候資料會佔用伺服器的資源,相較於在client端處理,在後端處理對伺服器負擔會比較大 Q3:全部送給前端在自己搞搜尋不就全部的資料被攔截光光? A3:有可能他在request,有做過初步的篩選,但沒看到傳入的參數,所以我覺得這部分比較沒辦法做討論
龍華科技大學
B11 我覺得那位後端的女同事這樣做才是正確的,因為前端可以先撈取部分的資料先呈現,剩餘的資料用非同步慢慢載入,這樣效能不會令人堪憂呀,而且使用者體驗會比較好 這種方式真的是看情況使用,不是一招就可以打天下,這就是寫程式有趣的地方
淡江大學
B8 你是不是弄錯同步非同步的意思
原 PO - 國立聯合大學
B15 你講的某些部分我認同 有些頁面我確實用你說的方式實作 但也有很多頁面不太行 假設我先呈現各區塊 因為大量非同步資訊還沒回來的關係 每個動態資訊欄位都必須有loaning狀態 UI可能會不美觀 UX的部分我覺得要看人 像是我的老闆看到網頁都呈現了 重點資訊還在慢慢載入他又要發飆了 然後效能真的不OK 我是覺得後端遇到什麼狀況可以討論 看看工作誰做會對專案比較好 不討論又把事情拼命往前端丟實在很糟糕
國立臺北科技大學
B17 我是你遇到這種後端,有兩種處理方式 一種是我就照她做,要爛一起爛,老闆問誰搞的就說她說的,誰用架構誰背鍋 至於你說的等待問題,就是 loading 加爆,被問丟給她就對了,問她怎麼處理 一種是我會直接辭職,她做她的爛扣我可以忍,有人搞事弄破架構我不能忍 寧願自己帶個 jr 後端都比她這種沒料的強 要進步去跟有高手的環境共事 如果一直跟著玩,小心自己也變沒 sense 的人 給你參考
嶺東科技大學 視覺傳達設計系
架構的東西不除非一人作業,不然一定要跟其他後端或主管討論,自己擅自改欄位無論重要性在小,都是白目行為,不可取。 另外欄位資料種不重要團隊說了算,自己才出來多久就自以為只會讓人覺得你自私自利罷了。
淡江大學
標準作法供參考 前端送 SQL查詢語句字串 後端執行後直接返回查詢結果
國立臺灣大學
留言比內文還有趣。。。 讓我想起最近學弟一個人在他實驗室幫老闆四天內架設好前後端跟建立好伺服器
朝陽科技大學
看完我覺得後端問題比較大,你們的需求感覺她後端join個幾張表撈就撈得出資料了,她會遇到後端效能問題搞不好是一行query可以撈出來的資料,她要分3個query撈,然後,前端其實也可以靠rxjs處理call多隻api的需求,但這樣取個資料還要走那麼多request進後端不太合理,以前後端分離的架構來說,她的作法反而更沒效能,推測她之前應該是做server side render(後端直接渲染網頁)的才會覺得資料段要在你那邊做。
輔仁大學 資訊工程學系
要玩這種架構 用GraphQL啊