wechat-admin：項目設計篇

wechat-admin：項目設計篇

轉自 https://www.dongwm.com/post/114/

相信讀者同窗們都瞭解wechat-admin，甚至在本地運行過了。今天是wechat-admin項目系列文章的第一篇：項目設計。

在你技術學習的過程當中或者已經具有了開發所須要的知識時，某一天靈光一閃決定去作一個（web）項目。那麼一般前期分這麼幾步：

1. 需求確認。切忌一上來就寫代碼，先得在心中能把一個項目能清晰的拆分紅一條條的需求，另外也要不斷地和需求方確認你的理解是否是正確。
2. 技術確認。首先是肯定你能不能hold得住，別攤子鋪的太大最後摟不住，或者在預約時間內沒法完成。
3. 用較短期對技術實現難點確認。熟悉的寫出來只是時間問題，那些未知不可控的纔是你須要首先確認的，若是發現一開始的技術選型有問題，那麼就要儘早的中止改其餘方案。

我但願你們在向下看以前，（閉上眼）思考一下：

假如如今讓你來寫這個項目，你用什麼技術方案，你準備如何的實現？

好的，思考以後。來看看我是怎麼作的，爲何這樣作，以及這個過程當中有什麼調整和故事吧。

需求 & 選型

你們能夠看到我在「特性」中的功能列表，其實一開始的需求只有：

1. 微信掃碼登陸
2. 拉取和存儲聯繫人、羣列表、羣成員等信息
3. 自動建羣，加人
4. Web管理頁面展現這些信息
5. Web頁面上可設置一些須要的功能參數
6. 消息提醒
7. 自動回覆機器人

那麼接着拆分這些需求。因爲我主要是在週末和晚上這種閒暇零散時間，因此我但願讓這個拆分粒度儘可能的小，控制在一個點1-2小時，最多半天這個標準上。有些需求能夠同時作（防止長時間作一件事無聊），有些是其餘的需求完成才能夠開始的。因此，需求和選型是這樣：

微信掃碼登陸

這個是一開始要作的，我對ItChat/wxpy並不熟悉，這個是整個項目惟一的感受「不安全」的點了：微信登陸和其餘常規登陸的體驗是徹底不同的。別的都是帳戶/密碼、手機號、第三方登陸，案例不少，很好作。可是微信是要用手機掃碼，因此我要解決2個問題：

1. 加「鉤子」，把登陸微信的狀態（等待掃碼/掃碼完成等待確認/確認完成）及時的通知我，讓我在Web頁面上進行對應的步驟
2. 須要經過某種方式和服務端實現保持一個長的鏈接，收到這個通知能夠推送數據到瀏覽器

進一步去確認需求啦。首先閱讀ItChat/wxpy源碼，發現它能拿到這種通知，可是設計的是在終端用log的方式打印出來，不過自己支持callback函數也能實現鉤子函數。不過我仍是fork了他倆。解釋下緣由：

1. 我不喜歡callback的方式，這會提升項目的複雜程度，高聚合。因此我要使用信號解耦這部份內容。
2. 給ItChat提交過代碼，好幾天沒人理，索性本身維護fork版本，遇到不知足須要就能夠快速改，提升效率

另外後來還踩了一個坑兒，就是頁面動態改掃碼圖片的src會有緩存。因此在信號中把掃碼圖片變成Data URL協議的方式傳遞回來。

向瀏覽器推送數據更知名的方案是Websockets，它能夠雙向的數據推送，不過過重了用不到，我須要一個輕量級的方案。因爲豆瓣有一些場景也是SSE(Server Sent Events)，爲了學習它，我也選擇了SSE。

拉取和存儲聯繫人、羣列表、羣成員等信息

wxpy提供了直接的API拉取這些信息，可是爲何要本地存呢？

1. 最主要的，爲了下降調用微信接口的次數，下降被封的風險。當我用正確的方式存下來，再加上我改良的wxpy的puid方案，一樣能夠實現對這些信息進程展現、篩選等查詢內容
2. 開源嘛，就是爲了多給你們一個學習的源碼項目的機會，想展現SQLAlchemy的更多用法

另外掃碼登陸以後，拉取和存儲的過程可能會比較長，另外在Web頁面上還有「強制刷新」的功能，這些若是讓頁面等待用戶體驗不好，都須要異步執行，因此用Celery異步的執行。

有個插曲，其實一開始以爲這種小項目用Celery小題大作了，選擇了rq，可是隨着個人需求變多變複雜（以後的文章會提到），rq的侷限性就愈來愈凸顯了。之前我對rq、huey這種框架都是「小項目不妨用用」的態度，不過如今我真的用過了以後才發如今Python圈 Celery永遠是首選，請相信我。

自動建羣，拉人

操做都是由wxpy封裝的（wxpy封裝了ItChat），它不支持一般說明Web微信沒有這個功能。須要注意的是，建羣時還須要至少2我的，要否則不能建羣，建羣接口當天也會被封。因此「自動建羣」須要點技術選型，那就是在設置頁面有一個項，包含默認拉的人都有誰，那麼須要存起來，我在這個項目把這樣的內容都存在了Redis裏面。

因爲公司基本設施的問題，我Redis用的不多，常見也很簡單，一直沒有用過Redis的ORM，此次項目實際上是爲了嘗試一下。不過一開始使用的是我fork的redisco，我給它增長了Python 3的支持。不事後來幹掉換成了如今用的Walrus，由於在使用過程發現太難用了。

這種早期的新技術選型失敗是不可避免的，不過仍是在我可控制的範圍。

Web管理頁面展現這些信息，而且可設置功能參數，消息提醒

這也是本文的重點之一了。Python Web開發者一般都不是單純的後端開發，因此前端的知識、框架、工具也是要熟練使用。網上這種先後端結合的項目和經驗比較少，本文也來談一談：

爲何選擇了Vue？

若是你不是一個專職前端工程師，而且也沒有打算將來轉成前端開發者，可是因爲工做或者興趣須要寫HTML、JS時，使用框架是一個正確的選擇。過去純手寫JS或者用jQuery的方式寫代碼效率是很低下，尤爲在頁面交互複雜時，而如今有React、Vue這些框架，幫助你省太多的事情了。去年的網易雲音樂精彩評論使用的是 React + Mobx + Fetch + Material-UI + ES6 + Webpack + Babel，對應的技術選型文章能夠看commentbox用到了那些前端技術。

最近工做中都在使用Vue，好比豆瓣電影「選影視」以及新的電影管理後臺(Vue+Vue-Material)，我在這裏向各位Python開發者極力推薦它，理由以下：

1. 最大程度的下降了初學者的學習曲線

2. 數據雙向綁定。實現一個相對複雜的頁面須要的代碼量不多。更多MVVM和前端發展歷史能夠看我以前寫的 淺談MVC、MTV和MVVM

3. 單文件組件化和它的語法對於寫模板的同窗來講最易接受

4. 文檔和周邊生態都相對完善
5. Vue-cli這個命令行腳手架包含了豐富的模板，能夠很是快的初始化出來一個項目，極爲方便

爲何選擇Element-UI

我嘗試過Vue下的各類UI庫，Element是其中功能最全，API和文檔最完善和最易於使用的。舉個例子，我用Vue-Material時常常須要翻源碼瞭解用法，貨比貨得扔啊。可是它也是個人選型(也是爲了配合廠內其它的Material-UI)，含着淚也要用下去...

另外，若是你想開啓一個使用Material Design的新項目，建議使用Muse-UI

如何實現先後端的交互？

不止一個同窗問過我這個問題。三點來歸納吧：

1. 前端是一個單頁面應用，路由由vue-router來實現，對於後端來講，只須要渲染一個index.html就行了。
2. 後端提供API，對Flask進行一些定製，讓它返回的內容mimetype就是application/json，而且統一封裝了返回的格式
3. 前端再打開頁面或者在事件中經過Axios這個HTTP客戶端庫發出請求到後端，後端接口接收並返回對應的內容

自動回覆機器人

在我念書的年代，也上過人人網，當時小黃雞很是知名，以爲很神奇。當我工做，尤爲是作了開發以後，發現其實對於API調用者來講是沒有技術含量的。如今市面上有不少知名的機器人，使用它們的每日限額的免費接口就能夠。另外我也用到了一些機器學習的ChatterBot。

我改了wxpy的源碼，用插件的方式讓這些額外的功能可插拔。

其餘需求

剩下的那些功能，都是在現有的技術選型基礎上去實現的。有些是過程當中產生的靈感，有的是閱讀源碼的時候發現的。