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

一、前言

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

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

效果预览:

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

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

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

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

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

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

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

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

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

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

二、前后端共用一份配置

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

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

三、配置文件设计

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

四、配置服务实现

• 配置服务

  

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

• 配置基类

  

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

  

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

  

  

  
  

五、前端调用方式

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

五、服务端调用方式

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

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