关于前端:我们需要怎样的-Service

14 世纪，英格兰的逻辑学家奥卡姆在他的《箴言书注》中说「不要节约过多的货色，去做那些用较少的货色同样能够做好的事件」。起初这句话被简化为「奥卡姆剃刀原理」，即：如无必要，勿增实体。奥卡姆剃刀在各个领域都有他的使用，他不是一个公理，没有谨严的推导过程，但他却是一个在实践中被证实十分无效的解决问题的伎俩。

在编程世界里，有太多咱们司空见惯的货色，我置信存在即正当，同时我也置信存在都有前提，而前提会随着工夫变动甚至隐没。上面我想跟大家探讨下，咱们前端我的项目中那些应该被剃刀剃掉的货色。

在一个前端我的项目中，个别蕴含以下文件目录：

containers：页面
components：组件
utils：工具办法
routes：路由
services：数据服务
index.js 入口文件

咱们的业务代码根本都在 containers components 里，utils 和 routes 也是必不可少的，但认真思考咱们就会发现，这里有个 services 文件夹，他被称为数据服务层，是咱们跟后端打交道的。这一层真的须要吗？
咱们来看看大家是怎么应用 service 的。

// services  文件夹下的 accoutService.js

import {post} from '@/utils/request';

// 获取账号列表
export const getAccountsList = params => post('/api/accounts.json', params);
// 新增账号
export const insertAccount = params => post('/api/insertAccount.json', params);
// 更新状态
export const updateAccount = params => post('/api/updateAccount.json', params);
// 校验账号查问
export const checkAccount = params => post('/api/checkAccount.json', params);

-------- 应用 ---------

import {getAccountsList} from '@/services/accountService'

const App = () => {const [name, setName] = useState('');
    useEffect(() => {getAccountsList().then((res) => {setName(res.name);
    });
  }, [])
  return <div>{name}</div>;
};

从下面的代码咱们能够看出，services 文件下根本是一些模板代码，偶然有少见的一些数据转换。这些内容对于咱们的业务代码来说，都是非业务相干的，写这些模板性的控制代码真的有必要吗？

数据转换逻辑 converHandler
数据申请工具 request
申请地址定义 url
全局拦截器 interceptor
附加性能 openApi

数据转换逻辑 converHandler：并不通用，有的一个申请在不同的页面须要走不同的转换逻辑，这些转换逻辑个别会写在调用地位的代码里，我也倡议这么做，因为数据转换也是这块某个 container 的性能，而且为了不便测试，倡议增加 handler.js 将转换逻辑抽离进去。

数据申请工具 request：次要是封装各种申请，这部分须要对立。非业务相干，能够提出来。

申请地址定义 url：这部分是强业务相干的，不应该放到 service 里，而是作为 service 的一个配置，由内部输出。

全局拦截器 interceptor：解决一些通用的业务状态码，比方编辑胜利 10001，这部分也是强业务相干的，而且绝对比较复杂，然而能够通过配置 schame 来形容，前面再讲。

附加性能 openAPI：如果你零碎的接口想让别的零碎复用，比方 MTEE 根底平台的接口须要复用给经营平台，那么前端须要提供畛域物料，畛域物料里会发申请，发申请要解决跨域、登陆、受权的问题，openAPI 应运而生。

综上能够看出，service 层只须要一些对立的逻辑解决和配置文件就能形容分明，甚至咱们能够把 Service 层简化为

$$service = request + config$$

由此，我心愿能设计这样一个 service 包，他须要蕴含上面的性能：

反对常见的 get post jsonp 申请，以及对于这些申请的附加办法，比方 debounce、throttle、缓存、loading 等性能。也能够提供大家比拟喜爱的 hooks API。

一个接口蕴含域名 domain，地址门路 path，申请办法 method，参数 params，一些常见性能的开关，比方开启防抖 {debounce:true}。参数的配置里，能够增加该参数的根本属性，比方是否必选 {require: true}，这样包内能够对参数做必要的校验，这样能够保障非法数据传入后盾。

环境切换是一个非业务相干的性能，他不应该硬编码到代码里，带到线上。他应该只是一个配置，尽量与代码脱离，因而是用浏览器插件来切换，就是一个很好的办法。能够设计 service 包接管一个 domainMap，这个 domainMap 来自 window.GlobalConfig 下的某个变量，浏览器插件能够动静扭转这个变量，就能够做到环境的切换了。

咱们写代码谋求复用，从代码块的复用到组件复用，再到业务能力的复用，而业务能力复用的一个载体就是畛域物料。一个畛域物料里很有多个接口申请，如果咱们把原来在业务代码里的组件拆出来作为畛域物料的话，就不得不把我的项目里的 service 层也要打包进去，这样能力发送申请和解决一些对立的异样。下面的我提到的把是 service 层做成一个包，他人在应用的时候，只须要传配置进来，也是出于畛域物料这个场景。
这之后，咱们还要解决一个问题：畛域物料在不同站点应用带来的接口跨域问题。咱们当初的解决办法是，前端搭建一套基于 node 的网关，用于做接口转发和鉴权。service 包里会集成这个过程，内部使用者只须要配置开不开启网关就能够了。他齐全不须要晓得网关是如何转发的，就像在本人的站点下写组件一样。

咱们在接手别的我的项目的时候，总是不容易找到他的接口文档，因为文档和代码是割裂的，文档的保护也有滞后性，甚至缓缓文档的链接也找不到了。因而，代码和文档应该在一起，最好是代码即文档。大家可能感觉用正文就能够了，但程序员总是要求他人写正文，但本人却不爱写。写正文如果能够像写代码一样，或者能标准这部分的行为。例如：

{
    name: '获取账号',
    domain: DOMAIN.TAOBAO,
    url: '/api/getAccount.json',
    method: METHOD.GET,
    params: {
      userId: {
        name: '策略包 id',
        type: PARAM_TYPE.STRING,
        required: true,
      },
    },
    response: {name: '账户名字'},
  },

这里用配置文件的形式标准了文档的模式，还能够与浏览器插件相结合，通过插件来查看以后用的接口文档。

异样分为服务器异样和业务异样，服务器异样个别是用 http 状态码，400、500 等；业务异样则须要是用 body 里的 code 来示意。在实在的业务实际中，咱们发现对于服务器异样咱们是很容易写出通用的拦截器做一些解决的，然而对于业务异样，就绝对比较复杂了，这外面存在几个问题：

很多后端不习惯应用 code 返回相应的业务编码来示意不同的状态。
前端间接应用后端返回的 message 展现给用户，这里有两个问题，① 后端的须要引入第三方库对 message 做国际化 ② 后端定义的 message 不是用户语言，用户个别是看不懂的。因而这里就须要一个第三方零碎的参加，他提供业务 code 和前端动作的映射关系表，比方：后端返回 code:10000，前端应该弹窗并展现 message，定义的 json 如下：

{
  code: 10000,
  message: '编辑失败',
  debug: '后端数据库读写异样，堆栈信息：',
  showType: 'openDialog'
}

这里的 message 是能够依据不同语言环境返回不同语言文字的，showType 示意了前端的动作类型，这个是可枚举的，其中必定有一种动作是，不做动作，间接透传。这个第三方零碎，就能够配置不同编码的动作，有利于精细化的治理异样，给用户更好的体验。

实际是测验真谛的唯一标准，基于下面的现实，我的 service 包也曾经成型，应用他非常简单。只须要两步：
① 配置文件
② 引入包
③ 业务代码里调用

// 配置文件 account.js

import {METHOD, PARAM_TYPE} from '@ali/hulu-service';

export const DOMAIN = {
   TAOBAO: '//taobao.com',
   ALIPAY: '//alipay.com',
};

export default {
  getAccount: {
    name: '获取账号',
    domain: DOMAIN.TAOBAO,
    url: '/api/getAccount.json',
    method: METHOD.GET,
    params: {
      userId: {
        name: '策略包 id',
        type: PARAM_TYPE.STRING,
        required: true,
      },
    },
    response: {name: '账户名字'},
  },
};

import HService from '@ali/hulu-service';
import account from './account';

// 初始化 service
const service = HService.init({
  urls: [account,]
});

export default service;

import Service from './service';

const App = () => {const [name, setName] = useState('');
    useEffect(() => {Service.getAccount().then((res) => {setName(res.name);
    });
  }, []);
  return <div>{name}</div>;
};

export default App;

同时基于浏览器插件，能够疾速的切换环境，查看接口文档等。

结尾，咱们说到奥卡姆剃刀，如无必要，勿增实体，这个的前提是，有清晰独立的实体，如果咱们的实体之间互相勾连耦合，那又如何剃掉不必要的实体呢。
其实，无论做任何软件构架，都要分分明边界，也就是一个模块他的定位是什么，哪些性能是他该做的，哪些不是。这外面一个十分重要的根据就是是否易于变更。哪些是业务的、常变动的，哪些是非业务的、个别不变的。咱们的代码经常，坏就坏在边界不清晰，或者是边界准则没有一以贯之。工程代码里耦合了业务，业务代码里掺杂着工程（比方环境判断）。代码的坏滋味是一点一点积攒而成的，而这个坏的开始，就是初始的架构设计边界不清晰，没有用代码定义标准。
抵制代码的糜烂，这是一个漫漫长路，没有银弹，但的确能够精进一个人的零碎思维。

作者：ES2049 / 黑石

文章可随便转载，但请保留此原文链接。
十分欢送有激情的你退出 ES2049 Studio，简历请发送至 caijun.hcj@alibaba-inc.com。

关于前端:我们需要怎样的-Service

前端我的项目里的 service 层

service 里蕴含什么？

我的 service 包

申请

接口配置

环境切换

网关转发

接口文档

异样拦挡

落地

配置

引入包

调用 API

想想边界