TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 3、《配置服务》

1、前言

在实际业务开发中，会遇到这样一种需求，使用VUE的页面须要支持SEO，同时对首屏有指标性要求，目前市面上广泛使用的是Nuxt.js解决方案，在引入的同时还须要考虑与现有的全栈工程结合，本系列文章探讨的是此类全栈工程的解决方案，同时使用的是TypeScript应用于先后端编程，文章中介绍的工程与技术要点源码已上传至Github，有须要的朋友可自行下载：
Nuxt.js和Nest.js同构工程

复制代码

文章意在抛砖引玉，先后端使用同一种语言TypeScript编写，示例已包含基本接口请求，数据库链接应用，公用模块封装等实际开发中使用到的内容。

效果预览:

如下为该系列文章入口列表:
TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 1、《简介》

TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 2、《框架融合》

TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 3、《配置服务》

TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 4、《UI系统》

TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 5、《API服务设计》

TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 6、《SEO功能实现》

TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 7、《Vuex使用》

TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 8、《接入Mongo DB服务》

TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 9、《TypeScript》

TypeScript全栈工程实战-(Nuxt. js & Nest. js) - 10、《工程化部署》

2、先后端共用一份配置

同构化工程常常会遇到一种问题：即先后端配置须要维护2份或者配置重复问题，在本示例工程中，将创建配置服务，从框架剥离的角度，让先后端使用同一份配置。

这里指的框架剥离：指的是配置服务不能导入任何先后端框架类或接口，这样作的目的是避免先后端在调用时遇到各自运行环境不支持的类，好比：服务端支持mongoose但前端不支持运行。因此服务配置必须是纯净的，纯TypeScript文件，与框架无关。

3、配置文件设计

基本实现原理为：创建中间服务-配置服务，而且是单例形式，确保全部获取对象同一份配置，服务中加入环境区分，同时加入AXIOS快捷方式，方便调用，前端（ Nuxt.js）后端(Nest.js)引用同一服务，经过环境区分获取对应的环境，环境区分以启动时传入 NODE_ENV=xx进行为准。

4、配置服务实现

• 配置服务

  

  在单例创建的构造体中首先读入环境配置变量，依据环境配置变量决定惟一配置内容为当前标记的哪一个环境，依据标记分别实例化不一样的环境配置。

• 配置基类

  

  配置基类中定义各个环境共同的配置，差别化配置则由各环境子类自已实现，例如：

  

• 环境标记写入
  前面提到，配置服务在实例化前先读入了环境配置标记，该环境配置标记应在服务器启动以前完成，在这里封装到单独JS文件中，而且在启动前经过命令行方式写入，确保先后端读取的是同一份配置。

  

  

  
  

5、前端调用方式

• 导入配置服务
• 从配置服务中直接调用方法获取配置
  

5、服务端调用方式

• 与前端同样，一样是导入配置服务
• 从配置服务中直接调用方法获取配置

至此，完成先后端调用同一份配置内容。