Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle HTTP route by our own? #7

Open
mkfsn opened this issue Jan 23, 2021 · 23 comments
Open

Handle HTTP route by our own? #7

mkfsn opened this issue Jan 23, 2021 · 23 comments

Comments

@mkfsn
Copy link
Contributor

mkfsn commented Jan 23, 2021

現在是我們自行處理 HTTP route,但是或許可以考慮使用:

  1. https://github.com/gorilla/mux
  2. https://github.com/bmizerany/pat
  3. https://github.com/go-chi/chi
  4. https://github.com/gin-gonic/gin
@asymptoter
Copy link

asymptoter commented Jan 23, 2021

現在是我們自行處理 HTTP route,但是或許可以考慮使用:

  1. https://github.com/gorilla/mux
  2. https://github.com/bmizerany/pat
  3. https://github.com/go-chi/chi

不考慮 https://github.com/gin-gonic/gin 嗎?

@mkfsn
Copy link
Contributor Author

mkfsn commented Jan 23, 2021

我覺得要看需求耶, Gin 會不會太 overkill?

@asymptoter
Copy link

我覺得要看需求耶, Gin 會不會太 overkill?

我會想要從效能及熟悉程度的方面去考慮,效能上面 gin 有提供各 library 的比較,他敢寫出來就是因為他排前幾名XD,熟悉程度的話就看大家習慣用哪個開發起來比較快,但感覺都大同小異就是了。

@mkfsn
Copy link
Contributor Author

mkfsn commented Jan 23, 2021

沒記錯的話 Gin 有因為包太多東西導致效能有逐漸下降的趨勢,當然也有可能是我誤會了什麼 XD

https://www.techempower.com/benchmarks/

我自己是比較習慣 Gin,但如果只是要用到 routing 的話我會考慮其他的選項,不過要用 Gin 我也是歡迎就是了 XD

另外補充一點, Gin 用的 HTTP routing 如果用 wildcard 的話蠻容易 conflict 的,這部分要留意一下。(其他 framework 也要就是了)

但總是個選項,讓我加上去,感謝!

@Markogoodman
Copy link
Contributor

Markogoodman commented Jan 23, 2021

應該滿難預測之後會加入什麼功能,像是README的視訊就不知道是什麼XDD
我覺得選個使用的人多也有在維護的就OK了,像是gin或chi他們兩個之間效能應該不差到多少(?
pat和mux不太熟

@Markogoodman
Copy link
Contributor

應該滿難預測之後會加入什麼功能,像是README的視訊就不知道是什麼XDD
我覺得選個使用的人多也有在維護的就OK了,像是gin或chi他們兩個之間效能應該不差到多少(?
pat和mux不太熟

那就交給 @mkfsn@PichuChen 兩個元老決定囉(?

@PichuChen
Copy link
Member

我不小心在路上踢到對 mux 有力的理由,因為在 pttweb 上面使用了 mux, 所以我認為對 ptt app 這塊有興趣的人他對 pttweb 專案有興趣的機會不低,因此可以降低套件的學習成本。

另外實際上要修改的方向可能要請 @mkfsn 用原本的程式碼寫一點範例,這樣才會比較容易想像。

@Markogoodman
Copy link
Contributor

Markogoodman commented Jan 25, 2021

剛剛估狗了一下之前說不熟的mux

https://github.com/smallnest/go-web-framework-benchmark

好像會有 roting 效能上的問題(?

看起來是和chi gin有 二三十趴的差距,主要是用 tree 和 slice 實作的差別

但我猜要應該要很多path或流之後才會有感覺,不確定這個專案會長多大或是流量多少

至於範例這邊有 可以按看 https://github.com/BrunoScheufler/blog-code-examples/tree/master/choosing-go-web-framework

@Julian-Chu
Copy link
Contributor

純http router可以參考 https://github.com/julienschmidt/go-http-routing-benchmark
目前討論有點把webframework跟http router混在一起了,像是gin是framework,gin的router是用 http router
可能要先確定一下 有沒有要用到framework的其他組件,如果不用framework的話 可能要手刻一些基本component
framework(含router) vs router + 自製component

@Markogoodman
Copy link
Contributor

純http router可以參考 https://github.com/julienschmidt/go-http-routing-benchmark
目前討論有點把webframework跟http router混在一起了,像是gin是framework,gin的router是用 http router
可能要先確定一下 有沒有要用到framework的其他組件,如果不用framework的話 可能要手刻一些基本component
framework(含router) vs router + 自製component

如果沒辦法確定會不會用到其他組建的話要怎麼選啊XDD 直接選功能最多的嗎(X

我公司也是用 https://github.com/julienschmidt/httprouter 外面再包一點自己用的 middleware 而已

@mkfsn
Copy link
Contributor Author

mkfsn commented Jan 27, 2021

@Julian-Chu 對,原先我只是想用個 http route 這樣我們就不用自己在那邊刻 parsing 的邏輯。不過既然有人提了 Gin 我覺得也可以一起放進來討論這樣 XD

@Markogoodman 就目前我覺得(個人淺見)應該是需要 http router 而已,所以應該就先看哪個 library 效能比較好、易讀跟易維護嗎? 再不然就是開投票了XD

@Markogoodman
Copy link
Contributor

Markogoodman commented Jan 27, 2021

@Julian-Chu 對,原先我只是想用個 http route 這樣我們就不用自己在那邊刻 parsing 的邏輯。不過既然有人提了 Gin 我覺得也可以一起放進來討論這樣 XD

@Markogoodman 就目前我覺得(個人淺見)應該是需要 http router 而已,所以應該就先看哪個 library 效能比較好、易讀跟易維護嗎? 再不然就是開投票了XD

同意覺得可以先用 http router XD

我找時間把route那邊先改一下

@Julian-Chu
Copy link
Contributor

Julian-Chu commented Jan 27, 2021

如果沒辦法確定會不會用到其他組建的話要怎麼選啊XDD 直接選功能最多的嗎(X

看不同語言社群,gopher大概會說make it simple, 手刻吧(大誤 XD

@Julian-Chu
Copy link
Contributor

Julian-Chu commented Jan 27, 2021

gin-gonic/gin#2016
httprouter在路由設計上好像有某些限制,看到不少抱怨,httprouter也說v2會改正(不過不知道v2何時才來...)
@Markogoodman @asymptoter 你們用起來有感覺嗎(我沒用過httprouter)

@mkfsn
Copy link
Contributor Author

mkfsn commented Jan 28, 2021

gin-gonic/gin#2016
httprouter在路由設計上好像有某些限制,看到不少抱怨,httprouter也說v2會改正(不過不知道v2何時才來...)
@Markogoodman @asymptoter 你們用起來有感覺嗎(我沒用過httprouter)

我撞到這個很多次 ... XD
不過我感覺滿看 API 設計的,說不定在這個 project 不會撞到

@PichuChen
Copy link
Member

@Julian-Chu @mkfsn
限制的部分可以在這個 ISSUE 在重提一次嗎? 這樣比較好讓其他人進入狀況

@Markogoodman
Copy link
Contributor

Markogoodman commented Jan 28, 2021

自己比較常遇到的是
/account/:user_id
/account/me
這種會撞

處理的方法就是換路徑或是只留第一個然後在code裡面處理
if user_id == "me"{XXX}
else {OOO}
不知道有沒有其他情況

這種解法其實很醜XDD
gorilla mux因為是用 slice 所以可能不會有問題(?

@mkfsn
Copy link
Contributor Author

mkfsn commented Jan 28, 2021

FYR: https://yushuanhsieh.github.io/post/2020-01-21-golang-router/

這篇有提到:

gin 不允許這樣的 path 設計,其原因 node 中有一個 wildChild member 是用來進行搜尋判斷,而當插入含有 params path 時,這個 wildChild 會被設定成 true,進而導致同一層的 static path child 會變成 unreachable 狀態。

@Julian-Chu
Copy link
Contributor

我看了一下 api文件 ,目前沒有會衝突到的設計,列一下目前想到的例子,以看板跟文章為例

from api doc
/v1/boards/{{board_id}}
/v1/boards/{{board_id}}/information
/v1/boards/{{board_id}}/articles
/v1/boards/{{board_id}}/articles/{{filename}}

轉成gin的語法 :表示wildcard route

ok
/v1/boards/:board_id
/v1/boards/:board_id/information
/v1/boards/:board_id/articles
/v1/boards/:board_id/articles/:filename

假設在boards底下新增路由
以下會跟/v1/boards/:board_id 和 /v1/boards/:board_id/.....衝突

conflict
/v1/boards/info
/v1/boards/info/more_info
/v1/boards/:info_id/more_info
/v1/boards/:info_id/:more_info_id

在board_id底下新增路由
以下跟/v1/boards/:board_id/articles 和 /v1/boards/:board_id/information衝突

conflict
/v1/boards/:board_id/:article_id
/v1/boards/:board_id/:article_id/:filename

在articles底下新增路由
跟 /v1/boards/:board_id/articles/:filename 衝突

/v1/boards/:board_id/articles/info

path prefix來決定是否同一層
同一層有wildcard route的話 那麼只能有一個route而且是同一個命名的wildcard route
同一層都是static route的話可以有多個
同一層混用wildcard跟static會衝突

有錯的話 幫忙糾正一下

@PichuChen PichuChen added this to To do in PTT 後端主要 Jan 28, 2021
@Julian-Chu
Copy link
Contributor

Julian-Chu commented Jan 29, 2021

我評估後的想法是 只要隔開一層的話 後續萬一要抽換的範圍影響不大,
其他人遇到的問題是gin無法單獨抽換router又跟gin綁很緊, 如果只用router加上以可能抽換為前提去設計coding的話應該不會有遇到相同的問題

@Markogoodman
Copy link
Contributor

分層之後應該要換router不難
現在就是要看大家接不接受這個路徑容易撞的事情XD
或著是要換其他不會撞的譬如 chi or mux

@PichuChen
Copy link
Member

這個 ISSUE 目前還有在更新嗎? 不然兩週後要把他先關掉了喔?

@appleboy
Copy link
Contributor

Gin V1.7 修正了全部 httpd router wildcard 問題,如果要用 Gin 的話,建議升級到 v1.7.3 版本會比較適合。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

6 participants