由阿里经济体前端大学主办的serverless挑战赛已于2020.09.02落下帷幕
同城零售前端团队出于对自身 业务发展 和 技术探索 的考量，积极响应前端大学号召，投身到本次的severless挑战赛之中。项目介绍了一种代码开发方面的探索的演示。
目前中后台项目，越来越流行大前端一体化项目，项目内部包含Api接口逻辑，包含展示模块，以达到一个人就可以维护项目，避免独立后端开发人员排期冲突。
目前比较流行的框架有
阿里的飞冰：ice.work/docs/guide/…
虽然前后端都在一个项目里，但是这类项目总会有独立的目录，来分别放View和Api逻辑。两部分也是分别用独立的框架来实现，例如 Koa 和 React。
一个目录提供Api接口，View项目提供展示，两者之间通过Api地址链接。就像下图这样。
还有一点要注意，中后台项目的这种接口调用映射关系，有一个特点，就是提供的接口一般并不具备复用性，通过对大量项目的统计，超过60%的接口只被一个功能点使用。所以接口和调用者是高度耦合的。
这从逻辑上讲，具有必然性，如果某个一体化项目里的接口，被其他项目引用，想必也是一个逻辑上很奇怪的事情。因为复用性高、通用性强的逻辑，也不会放到前后端一体化项目里，必然以独立的服务对外提供。所以整体结构就像下图这样。Node提供紧耦合的Api，但是会去调用其他通用的服务。
接下来我们针对一个接口，我们来看一下每一个具体的例子，左侧是view项目，期间会调用/api/data接口，右侧是Node项目提供/api/data的后端逻辑。
这样我们会发现，一个完整的产品逻辑，被隔断成了两部分。而且刚才我们总结了，中后台的接口不具备复用性，功能和展示层高度耦合的。所以是不是可以说，一个高度耦合的事件，某些步骤需要独立写在另一个地方，而且还需要用另外的框架？
这就是整个故事的来由，能不能把前后代码写在一起，方便开发，方便阅读，运行时通过编译脚本，把需要远端执行的逻辑自动提取成ajax调用。
Lix引擎对开发方式进行了重新设计，通过特殊的__service__作用域，可以将两者代码写在一起。所有在__service__内部的代码表示会在服务器端执行
这样，整个过程，在代码层面变成了顺序结构
实现方式
实现方式是开发了一个webpack插件，通过插件编译的时候，将源码___service___内部的代码进行拆分，然后这一段替换成一个ajax请求代码。也就是说开发代码是一起的，但是运行时是两套环境
开发模式的改变
1、没有API
我们不在需要api，连http的路径都是随机的（当然也可以指定一些sign方便调试），开发过程基于函数，为了方便调试lix做了一个改动，就是__service__内部的代码如果有console.log，虽然它是在服务器端执行，但是它会输出到浏览器端的控制台里，统一了了两端的调试。
2、后端逻辑复用
如果后端某些逻辑是复用逻辑那么lix如何开发呢？过去后端的复用是基于api地址的复用，所有页面使用一个http地址。那么lix如何处理复用呢？
答案是基于函数
我举了一个例子，有一个常用的删除功能，那么我们提取一个函数，函数里面有远端调用。所有使用方，调用这个函数即可。用这种方式，我们很方便的把跟这个事件相关的前后端逻辑，都封装到里面，我们重新组织了复用，我们的复用是基于前后端一体的复用，参数前端校验、远端调用、后续状态修改，这些组成了一个完整的逻辑复用。
3、作用域
因为__service__内部的执行是物理隔离的，所以不要试图通过作用域链获取外部的变量，例如这样：
这样服务端执行的时候，会报错获取不到变量，因为___service___内外是独立的运行环境，所有要传递的数据，通过参数传递，例如这样映射：
4、上下文
服务器端执行的部分需要上下文，lix开发方式，通过this对象来绑定所有要执行的变量和方法，例如这样：
上下文变量，this.user和上下文方法this.runSql()，过去node开发中的中间件，都需要用代码来代替，例如例子中的this.user.type==='admin'，代表管理员用户。
上下文的扩展，主要通过扩展this对象来实现，当然也可以继续使用require方法引用基础包。但是官方并不建议这样做。
那么我的项目如何改造才能使用lix的一体化开发方式呢。首先要求你的项目有一个伴随的Node项目，最好是midway、ice这样的既有node又有web的框架。
下一篇文章，我们将介绍如何在你的项目里使用Lix一体化开发
