摘要：然而扯淡的在前端前端要發(fā)請求，所以每個(gè)請求的都是，而生產(chǎn)環(huán)境服務(wù)器又是。前端方案因?yàn)槲沂窃谛Ｉ?，沒辦法了解到大公司的開發(fā)方式?？赡芎蠖司腿涡跃筒蛔袷兀敲催@個(gè)前端只能靠來調(diào)整，然而更多的情況是沒辦法調(diào)整的。

在一個(gè)中大型項(xiàng)目中，你不可能一邊寫著前端一邊寫后端。全棧太難 :)

像rails那樣的開發(fā)模式已經(jīng)很不適合當(dāng)前的環(huán)境了。所有的項(xiàng)目都嚷嚷著前后端分離，那就只能這么干

我之前在做大學(xué)狗們的時(shí)候，在mock數(shù)據(jù)這一塊曾經(jīng)特別難受

雖說整個(gè)前后端我都能掌控，但是因?yàn)檎麄€(gè)前端是一個(gè)repo，后端又是一個(gè)，我在開發(fā)的時(shí)候又不能開著兩個(gè)編輯器(有一段時(shí)間這么干過)，而且十分不想在自己電腦上安裝那么多東西。

一開始的解決方案很扯淡：

不想在自己電腦上安裝那就連遠(yuǎn)端服務(wù)器吧。反正學(xué)生優(yōu)惠的Server超級便宜，而且再開個(gè)二級域名沒有任何損失。

說干就干。

在遠(yuǎn)端開發(fā)服務(wù)器上先把后端拉下來，搞數(shù)據(jù)庫。是laravel做的，所以mock數(shù)據(jù)也還是挺輕松的。整個(gè)一套弄下來了。

然后給Nginx加上跨域的header。

好了，到這里服務(wù)端就完成了。

雖然很不舒服，但還是能忍受對吧。然而扯淡的在前端

前端要發(fā)請求，所以每個(gè)請求的url都是http://dev.foo.com/，而生產(chǎn)環(huán)境服務(wù)器又是http://www.bar.com/。

我想出了一個(gè)"聰明"的法子：在所有請求前面加上一個(gè)prefix，在dev環(huán)境就設(shè)置成http://dev.foo.com/, 生產(chǎn)環(huán)境就改過來。這樣所有請求的prefix就是個(gè)變量，在release之前替換一下就可以了！

天才！

就像是這樣

// release前修改
const prefix = "http://dev.foo.com/"

// 其他文件中
fetch(`${prefix}/api/users`).then(res => res.json()).then(data => todo(data))

然后我改字符串的時(shí)候就哭了? 如果你愿意讀一下源碼，你會(huì)體會(huì)到我當(dāng)時(shí)崩潰的心情，這里還殘留著這個(gè)方案的痕跡(要改太多地方了)

不過說真的，雖然這套方案問題相當(dāng)大，然而它確實(shí)是有用的，支撐了我好幾個(gè)月。

難以忍受這套方案的同時(shí)我也在尋找好的解決方案。

因?yàn)槲沂窃谛Ｉ?，沒辦法了解到大公司的開發(fā)方式。在這個(gè)痛點(diǎn)發(fā)生以后就一直關(guān)注這方面的內(nèi)容。

我一直想在webpack-dev-server這邊做個(gè)中間層，把這個(gè)server做成完整后端那種的，包含路由什么的，直接返回json。

因?yàn)橐恢笨紤]其他的事情，一直拖著沒做，另外也覺得webpack這套東西好像也有點(diǎn)兒復(fù)雜，不太愿意碰。

其實(shí)還有個(gè)問題，我相信mock這一塊大公司肯定碰到的比我早，為什么我沒有搜索到這樣的包？是他們不愿意這么做還是有更好的解決方案？

最近總算是找到了個(gè)還算靠譜的一套方案，流程是這樣的：

首先開一個(gè)mock server，只有路由功能，返回假數(shù)據(jù)。

在webpack-dev-server中加上proxy，把對server的請求都轉(zhuǎn)發(fā)給proxy，不存在跨域的東西，可以很逼真的模擬。

這套方案就很棒，完全不用修改請求url。

說干就干：

$ npm install --save faker
$ npm install -g json-server

在項(xiàng)目目錄下創(chuàng)建mock目錄，然后做路由和數(shù)據(jù)

// mock/db.js
"use strict"
const faker = require("faker")

module.exports = function() {
    let data = {
        "activity": [
            {
                id: 0,
                title: faker.lorem.words(),
                img: faker.image.image()
            }
        ]
    }
    return data
}

路由文件，主要把對/api/*的請求轉(zhuǎn)到/*，主要是簡單一些

{
    "/api/": "/"
}

然后把這個(gè)mock server 起一下吧

$ json-server mock/db.js --routes mock/routes.json --port 9999

剩下的是webpack那邊的配置了。核心是這些：

const config = require("./webpack.config")
config.devServer = {
    hot: true,
    inline: true,
    proxy: {
        "/api/*": {
            target: "http://127.0.0.1:9999",
            secure: false
        }
    }
}
module.exports = config

好了，配置也可以了。

$ webpack-dev-server --process --colors --hot --inline --devtool eval --config webpack.dev.config.js

所有的事情都做完了，只剩下測試了

找個(gè)入口文件測試一下：

fetch("/api/activity").then(res => res.json()).then(data => console.log(data))

ok。把我折騰了這么幾個(gè)月的前后端總算是徹底分開了

這套流程的最大問題在于json-server這么個(gè)東西，因?yàn)槭羌兇獾?strong>RESTful的server。同樣是上面的配置為例：

GET /api/activity
POST /api/activity {title: "foo", image: "/foo.jpg"}
PUT /api/activity/1 {title: "bar", image: "/bar.jpg"}
DELETE /api/activity/1

對RESTful有了解就明白了，分別對應(yīng)的是獲取, 創(chuàng)建, 更新, 刪除操作

當(dāng)然還有更多的json-server的設(shè)置，比如查詢，關(guān)系什么的，底下我會(huì)給鏈接。

這些東西可以說設(shè)計(jì)是很不錯(cuò)的。然而也是問題。

老系統(tǒng)完全不能用?；蛘咴O(shè)計(jì)不夠好的系統(tǒng)根本不能用。

可能后端就任性！就不遵守REST API，那么這個(gè)前端mock只能靠routes.json來調(diào)整，然而更多的情況是沒辦法調(diào)整的。

所以啊，這個(gè)mock server方案對后端要求很嚴(yán)格

你是如何構(gòu)建 Web 前端 Mock Server 的？

JSON Server

faker.js

Egghead.io free video tutorial - Creating demo APIs with json-server

原文：前端的 mock server