前段時間組內搞代碼檢視，經常能看到一些 “掛着 RESTful 羊頭，賣的卻是 GraphQL 狗肉”的 API 設計。 舉個例子，假如後台有兩種資源用户 User 和 羣組 Group ，按照RESTful的規範，他們設計以下API端點： # 獲取用户列表 GET /users # 獲取指定用户 GET /user/{id} # 創建用户 POST /users # 修改用户 PUT /u
前不久組內的萌新用不知道從哪裏學來的技術，説要封裝一套 axios 庫供大家使用。 等他開發完，在 code review 環節，大家看到他寫的代碼都面面相覷，不知道該如何評價。 我一時間也不知道該如何評價，只能提醒他不要寫死代碼，目前 axios 還沒入選開源庫，後期有可能換成其他替代品。 會後我專門到網上搜一番，發現二次封裝 axios 的案例確實不少，但給我感覺其實都半斤八兩，不見得哪個更優
前情提要 一個月前，我基於React hook 實現前端組件的依賴注入，前文：useIoC：僅一百多行代碼實現前端的依賴注入。 同時也嘗試基於依賴注入實現一套UI庫，目的是驗證前端依賴注入的可行性，然後意外解鎖 React children 的全新用法：useIoC答疑 對children屬性的深入挖掘。 UI庫已在Github開源：https://github.com/zaoying/uiki
前言 對於一個從事7年Java的開發者來説，Spring依賴注入已經變成日常開發工作的一部分，尤其是最近三年切換Go技術棧更是懷念，儘管有些老員工總是忽悠我Go不是面向對象的語言，所以不需要依賴注入。 示例 為什麼説他們在忽悠？以下面代碼 demo_controller.go 為例： func NewDemoController(demoService DemoService) *DemoCont
