前段時間從前到後完整地做完了一個簡單的釘釘上的 isv 應用 —— 猿活動。
最開始想做這麼一個小工具，是想到，平時部門中經常會組織一些分享活動，但是這些分享活動卻沒有一個比較直覺的“站點”來記錄一次又一次的，很多人的努力的付出，這是很可惜的事。同時，在做這些活動的時候，也缺少一些互動的手段，比如現場簽到，打賞什麼的。
好吧，剛開始的時候是這樣想的，當然，在做的過程中，也發現釘釘的基于“組織”的應用場景，在某些情況下限制挻大的（比如現場的互動，因為到現場的人并不一定是某個“企業”的成員），是以功能上也簡化了很多。（其實真相是隻有 3 個周末時間，隻能先搞出目前這些簡單功能了）
中間在做的過程中碰到了另一個朋友，他有一些想法，并且自己也盡力做了很多工作，就差個程式員。我見功能很簡單（就是最簡單的文章呈現功能），就幫他做出來了。之後，我也随便把他的這塊内容管理功能，及我之前想的活動相關的功能，合在一起，變成了現在這個應用的樣子了。
技術方面，前後端是完全分離的。
後端用 python 寫的，一套東西是 tornado 和 sqlalchemy 。代碼在：（附件）
前端是 angularjs 那套，代碼在：todo （前端代碼目前跟我工作上的業務代碼是一起的，對外就不友善了哈，以後有機會拆出來我再回來補吧）
其實還有另外一套東西，掃碼登入的那個簡單背景，也是一個單獨的前端項目（配合約定的後端服務的格式工作），代碼在：todo （代碼目前跟我工作上的業務代碼是一起的，對外就不友善了哈，以後有機會拆出來我再回來補吧）
<a></a>
先說第一點心得。這方面你應該已經了解 isv 中的套件是如何工作的了，如果不清楚，可以先看看：
一般我們最開始來做一個套件時，會習慣性地把套件相關資訊（ <code>suite_key</code>, <code>suite_secret</code>,<code>token</code> 等）作為配置寫到配置檔案當中。最開始我也是這樣幹的。但是在對接流程時，這樣我經常會有非常别扭的感覺。原因是，除了套件本身的資訊，在 isv 的授權流程當中，企業相關的資訊，你還是得作一般化的，比較正式的持久化處理，因為會有 n 個企業用到你的套件，每個企業都有自己的一套“配置資訊”。簡單來說，企業這套資訊你要放到關系資料庫的表中儲存。
再者釘釘的應用場景一般是基于“組織”的，也就是說你的業務資料模型中，“企業”一定是一個獨立的實體（很多業務的實體表中，都會有一個“企業”的外鍵）。
現在，“企業”已經是一個連接配接業務流程，跟釘釘授權流程的一個中間角色了。再細想釘釘的授權流程，企業的授權對象，是“套件”，而企業的授權狀态本身有多種，這也是一個需要在記錄的東西。到這裡，其實已經能看出來，如果在資料模型中沒有“套件”這個實體，已經會讓人不舒服了。
更進一步，套件本身還有近 10 個屬性，而且有幾個屬性還是動态的。（這跟你接一個統一的使用者系統，隻在相關表中記一個使用者 id 完全不是一回事了）
與其在配置檔案中寫死套件的幾屬性，再搞個緩存系統什麼的去維護這個套件另外幾個屬性，同時忍受資料模型中因為沒有“套件”這個實體的不完整感：
你就專門為套件建一個表，每個套件作為一條記錄來維護相關資訊，是一個更直覺，更經濟，更靈活的處理方式。
而多出“套件”這個次元的代價，僅僅受限在 isv 授權流程中，并不會蔓延到你的業務流程中去，因為你的業務流程隻關注這是哪個企業的資料，而不關心它到底是從哪個應用來的。
我用 6 張表處理 isv 授權的流程資料：
<code>dingding_isv_corp_relieve</code> 是企業取消授權時的一個曆史記錄。
<code>dingding_isv_corp_app_agent</code> 是 <code>app_id</code> 與 <code>agent_id</code> 的對應關系，這在擷取企業授權之後，通過服務端服務可以查詢到，并且在激活應用時需要用到相關資訊，在 jsapi 簽名響應時也需要響應 <code>agent_id</code> 資訊。
<code>dingding_isv_agent</code> 這個記錄企業中的 <code>agent</code> 的狀态。
把套件作為單獨是的實體在系統中處理之後，建立套件本身就是一個随手的事了。
建立一條記錄，填上建立套件的 <code>token</code> 和 <code>aes_key</code> 。
成功建立套之後，再把 <code>suite_key</code> 等資訊補到資料庫中就好了。
這一步開發出的，随時随手建立套件的能力，為之後我們的調試提供了巨大的友善。
整個流程的視訊示範：
這算是所有跟公網回調相關的場景的标準處理方式了吧，以前做微信的公衆号開發時就這樣幹的。
簡單來說，像釘釘的推送這種，它需要通路公網機器，并且之後的調試你也不友善在手機上作靜态的 dns 設定，這在開發時是比較不友善的，直接登入伺服器寫代碼畢竟沒有自己本地機器舒服。
是以我們想到的一個辦法，就是通過代理把遠端伺服器上的通路導到本機。而這種遠端轉發的能力，是 ssh 自帶的。兩步就可以了：
在 <code>sshd</code> 的配置中（比如 <code>/etc/ssh/sshd_config</code>）添加：
這讓用戶端可以指定轉發端口。
然後本機啟：
就是把到達遠端任意網卡的 9000 端口通路都轉到本機的 8888 端口上來。這樣我們本機服務啟到 8888 上就可以正常響應釘釘伺服器對公網機器的通路了。
因為是前後端代碼完全分離的結構，是以前端的調試上需要稍微單獨設計一下。前後完全分離，就是後端除了渲染一個頁面（裡面會加載前端資源）之外，剩下的全是響應 json 的服務。
之前開發 pc 上的頁面是，我們的做法是本地啟一個靜态 web 服務就好了，後端資源的位址前端随意控制的。這樣我改前端代碼，直接在浏覽器重新整理就能看到效果，調試很友善。
但是換到做釘釘的移動端頁面時，情況有點不同，就是登入流程及釘釘的 jsapi 部分。業務上的登入流程需要在釘釘環境才能完成，單獨的浏覽器環境無法登入（當然你可以單獨做另一套登入機制）。釘釘的 jsapi 部分在單獨的浏覽器上更沒辦法。
是以，我們需要在釘釘上調試。這方面，最簡單直接的辦法就是讓釘釘掃二維碼來打開指定頁面（同網内部位址都可以）。不過在登入上有個小問題，就是 <code>corp_id</code>, <code>app_id</code> 這些參數，為了登入流程正常完成，你可能總是需要自己把這些參數寫死加上之後，再生成二維碼讓釘釘來掃。（而為了找這些參數，可能你總是需要多次登入管理背景，相信我，這事一點也不有趣）
“開發體驗”對心情的影響是很重要的，也效率的影響也是極大的，我希望的環境是打開電腦寫完代碼就能看到結果，還要去找參數，還去拼位址，還去生成二維碼，還去掃碼，太麻煩。
我現在的作法是，直接建立一個為開發調試而用的套件，裡面又為各個前端環境建立不同的應用（比如cdn測試環境，公司時的本機環境，家裡時的本機環境）。這樣，我隻需要本機啟一個靜态 web 伺服器（本機 ip 相對是固定的），改完前端代碼，在釘釘中直接打開相應的應用就可以了，其它事都不用管，世界清靜了。