產(chǎn)品規(guī)劃中的后端規(guī)劃,后端規(guī)劃中的API規(guī)劃
產(chǎn)品都在講用戶體驗,然而后端的優(yōu)化也很重要,不能光研究前端而忽略了后端的重要性,對于產(chǎn)品,產(chǎn)品經(jīng)理比任何人都要了解產(chǎn)品的方向,因此和后端技術(shù)人員共同奠基好后端,對于未來產(chǎn)品的擴展和業(yè)務(wù)的發(fā)展都會起到很大的作用。
今天我寫這篇文章主要是講講后端規(guī)劃中的API規(guī)劃,要講的API也并不是指空氣污染指數(shù)或PM2.5,我要講的API是應(yīng)用程序編程接口,談?wù)労蠖艘?guī)劃中如何看待API的規(guī)劃,并分享一下我的規(guī)劃思路。
隨著移動互聯(lián)網(wǎng)的發(fā)展,一個產(chǎn)品已經(jīng)不僅僅是Web或App形式了,隨著終端越來越多,產(chǎn)品的擴展也會越來越多。Web產(chǎn)品因為數(shù)據(jù)處理都在服務(wù)器端完成,因此還考慮不到版本迭代的遺留問題,然而需要客戶端處理數(shù)據(jù)請求的產(chǎn)品,例如軟件或移動App產(chǎn)品,由于版本的迭代而帶來的歷史版本接口問題就會出現(xiàn),從而影響平臺的發(fā)展,從中增加相應(yīng)的維護負擔(dān)。
在我的工作中,就出現(xiàn)過這樣的問題,我們公司的主要產(chǎn)品是移動應(yīng)用,隨著產(chǎn)品的迭代和數(shù)據(jù)的擴展,每次版本有大的更新都要重新設(shè)計并新建接口,然而舊版本仍在使用,因此也不能停掉,這樣便在無形中漸漸的增加了后端工作人員的維護負擔(dān)。并且隨著業(yè)務(wù)的發(fā)展和市場推廣的需要,產(chǎn)品也會擴展一些Web端的小型應(yīng)用,并與第三方平臺合作,等等原因都會為后端帶來了不小的問題,小到接口重寫,大到數(shù)據(jù)遷移重建。
對于這樣的問題和我們產(chǎn)品數(shù)據(jù)結(jié)構(gòu)的了解,我開始對后端重構(gòu),以O(shè)pne API的方式規(guī)劃,將產(chǎn)品分為兩個后端平臺:數(shù)據(jù)平臺、產(chǎn)品管理平臺。
數(shù)據(jù)平臺則是API平臺,為各個產(chǎn)品之間信息直接傳遞的一個橋梁,通過數(shù)據(jù)平臺可以無縫整合旗下系列產(chǎn)品和系列版本,甚至其它更多的第三方應(yīng)用程序,實現(xiàn)數(shù)據(jù)的統(tǒng)一管理。
產(chǎn)品管理平臺則是系列產(chǎn)品的私有數(shù)據(jù)的儲存和處理,通過產(chǎn)品管理平臺可以實現(xiàn)某個產(chǎn)品個性化獨有功能的配置管理。
圖注:應(yīng)用管理是驗證每個數(shù)據(jù)請求的合法性;用戶管理是用戶中心,統(tǒng)一管理用戶的通行證;數(shù)據(jù)管理是中心數(shù)據(jù)內(nèi)容的管理;插件擴展是特殊任務(wù)的擴展中心,負責(zé)任務(wù)的定期執(zhí)行或手動執(zhí)行。(對于我們公司的產(chǎn)品,由于數(shù)據(jù)特殊處理需求有很多,所以插件機制可以大大提升特殊需求的開發(fā)和執(zhí)行效率)
如上圖所示,對于特殊功能或數(shù)據(jù)的計算處理,可以通過單個可執(zhí)行的語言文件(.php或.aspx或.jsp)以插件的形式執(zhí)行相應(yīng)的數(shù)據(jù)處理任務(wù),每一個數(shù)據(jù)處理問題都通過單個任務(wù)文件執(zhí)行,大大的減少了數(shù)據(jù)平臺的維護工作。而產(chǎn)品的個性化需求則通過產(chǎn)品管理平臺進行配置管理,再通過SDK統(tǒng)一封裝整合,從而實現(xiàn)后端的統(tǒng)一管理,減輕后端的維護負擔(dān)。
通過這樣的規(guī)劃,我可以清晰的了解數(shù)據(jù)的結(jié)構(gòu),對于以后的數(shù)據(jù)處理也更加清晰。這樣就將接口問題留給了SDK,從而減少了后端的維護成本,同時也不影響前端人員的開發(fā),也減少了版本迭代帶來的數(shù)據(jù)同步問題。
來源:http://tangjie.me/blog/51.html
- 目前還沒評論,等你發(fā)揮!