Flutter+FaaS一体化技术体系下的开发形态思考
也许只有到了最后一刻我们才能最终回答这个问题，但是技术总是带着疑问前行，我们先从尝试做顶层做抽象定义开始，然后落地实践，在实践后总结提炼，完善顶层抽象，迭代往复，最终将概念变清晰。
数据处理：泛指传统的服务端REST API这部分，在一体化的场景下，这部分会由FaaS函数来实现，其实这一部分的职责和定位并没有改变，只是开发的组织沟通形式变了。传统开发页面会由服务端和客户端同学合力完成，后面可能由一位同学前后一体化开发完成。康威定律指出，软件的设计和开发人员的组织沟通结构是息息相关的，所以这一部分可能有较大的变化，但首先是他与客户端的交互方式上的变化，即网络通信。
网络通信：在一体化场景下，前后端都由一人实现，代码也会是一个工程中的同种语言，网络通信会加轻量安全，使用起来也会更加自然，接近于普通的函数调用。一个可能的变化是，通信模式可能会突破CS模式，在一次通信“会话”中，Client端和Server端能更加自然的相互调用，实现“对等对话”，而不是传统的客户端请求，服务端响应。随着网络硬件升级，网速在变快，通信成本在下降，创新的空间很大。
状态管理：应用状态很大程度上是缓存在客户端上的数据，受技术体系隔离，开发沟通成本，网络通信成本的影响，在客户端上缓存状态是有必要的。但在一体化的场景中，这些因素的影响在减小和消失，所以我们想进一步的消灭状态，将状态管理将至最小，尽可能的由底层管理。
界面绘制：也许是受Flutter的影响，响应式风格结合数据驱动的UI理念非常契合我们的思路，这也是业界UI开发框架的潮流。
