一、
最近服務端的同事分享了，他分享的目的就是要把我們與他們的數據庫隔離，這么做我們也求之不得。
我們組目前維護著一個后臺管理系統，會直接讀取數據庫中的表，如果能隔離的話，就不需要寫Model文件了。
后面再進一步了解后，明白了服務端推這個的用意，其實就是讓我們自己去維護服務，包括客戶端也去自己維護。
那這和我直接讀取數據庫做路由，區別不是很大了，無法解決當前我們的痛點，而且我在前端頁面中還需要制定數據結構，比之前還多了一步。
況且如果需要緩存的話，還不能直接調用的接口。如果我們人員充沛的話js讀取接口數據的方式js讀取接口數據的方式，這么分一點問題都沒有，但是現在人員非常緊張。
我們還要花大精力做數據整合和處理，而前端常規的工作諸如性能優化、頁面交互、組件化、工程化等都沒時間深入研究。基于此，還得另辟蹊徑。
二、通用接口
由于后臺管理系統大部分的操作都是增刪改查（數據庫基于MySQL，ORM基于），所以可以抽象出一套這類的通用接口，從而就能避免在 和 兩層中新增不必要的文件。
這套接口的研發受到了 這套開源項目的啟發。
數據庫表都是單表查詢，不支持聯表，若要聯表則單獨創建接口。查詢條件的語法直接參照 ，沒有做單獨的語法編譯。
由于接口的參數是一個JSON格式的對象，因此全部采用 post 的請求方式（-Type: /json）。
以 api/get 為例，基于KOA框架，在 層的方法是：
/**
* 數據庫查詢一條記錄
*/
async getOne(tableName, where={}) {
return this.models[tableName].findOne({
where,
raw: true
});
}
在 層的方法是：
/**
* 讀取一條記錄
* {
* TableName : { 查詢條件 }
* }
* TableName是Model文件的名稱，并非數據庫表名
*/
router.post('/get',
async (ctx) => {
const { body } = ctx.request;
const tableName = Object.keys(body)[0]; //表名
const where = body[tableName]; //查詢條件
// 將表名和查詢條件傳遞給數據庫方法
const data = await services.common.getOne(tableName, where);
ctx.body = { code: 0, data };
});
其中 是服務端中Model的文件名（并非數據庫中的表名），對象中的字段都是SQL的查詢條件。
粗略估算一下，如果將管理系統的接口替換成通用接口，那么可節省至少450個接口，占總接口的40%左右，并且 中的方法也會大大減少。
已將通用接口的前端代碼整合到 shin-admin 中，后端代碼整合到 shin- 中。