在当今编程领域，函数即服务（FaaS）与Flutter的结合正逐步成为新的探索方向，这其中蕴含着提升开发效率、解决传统业务开发痛点等诱人的价值点。
当前业务开发形态
当前业务开发存在数据处理、网络通信、状态管理和界面绘制这几个主要关注点。不同业务场景下，开发人员需要在这些环节花费大量精力。例如在传统的APP开发项目中，前端工程师专注于界面绘制，而后端工程师则负责数据处理和网络通信。这往往导致前后端在沟通协作上存在一定的成本，尤其是在涉及到数据交互和状态同步的时候。在这种开发形态下，业务逻辑也容易分散在前后端的不同模块中，增加了代码维护的难度。
另一个方面是不同业务规模下，开发模式会受到很大影响。对于小型项目，可能前后端分离的弊端还不明显，但在大型项目中，可能会因为沟通不畅，甚至导致开发进度的延误。
技术体系演进规律
技术的发展是不断抽象、总结和提炼的过程。以互联网技术为例，在早期开发中，从繁琐的代码编写到逐渐形成框架，这就是一个抽象的过程。在这个过程中，业务需求是推动技术演进的动力。开发过程中随着分层的出现，基础设施逐渐沉淀下来。如数据库管理系统，从简单的文件存储发展到如今复杂的关系型和非关系型数据库管理系统，就是这种规律的体现。
在这样的规律下，我们可以看到当把FaaS和Flutter相结合，这种技术的结合也符合技术演进规律。在FaaS+Flutter的一体化探索中，从当前的开发形态向一体化形态转变，也是一种新的技术抽象与创新。
FaaS+Flutter一体化优势
当进入FaaS+Flutter一体化开发场景时，开发变得更加简单。前端和后端之间的差异变小，这意味着开发人员不需要过多地进行角色切换就可以处理前后端的工作。在通信方面更加轻量自然，以前可能需要复杂的接口调用或者数据格式转换，而在一体化场景下变得简洁高效。
以一个电商APP的商品模块为例，如果按照一体化的方式开发，一个开发人员可以同时负责商品相关的前后端逻辑。他在处理商品详情页面时，不必像以前一样分别和前后端不同的团队或者人员协调数据接口、页面布局等问题，可以更加聚焦具体的业务逻辑。
协作方式的转变
在一体化的业务开发场景下，业务可以由一个同学负责前后端的开发，最大程度地减小沟通协作成本。在传统情况下，大型项目可能会把前后端按照各自的职能横向划分任务，前后端仿佛是两个独立的部门。但在FaaS+Flutter在这种一体化场景下，划分方式变为前后一体的垂直划分。
比如一家互联网企业在开发一个新的社交功能的时候，按照新的垂直划分方式，一个小团队负责一个完整的功能模块，这个小团队中的成员就不需要像以前那样和前后端不同团队反复的沟通需求、接口等内容，自己就能完成从功能逻辑到界面呈现的全流程工作。
一体化框架设计
在一体化的框架设计中，将业务命名为Story代表一个产品业务，Story按照垂直划分的方式划分为一系列的Scene。Scene相比于传统意义上的"页面"概念更加灵活。例如在一个新闻资讯类APP中，虽然有各种不同类型的新闻页面，但通过Story - Scene的划分可以更加合理地规划业务逻辑。
在逻辑处理方面以事件为核心的设计也很巧妙。事件优先在本端处理，如果本端无法处理就路由到另一端，若都无法处理就丢弃。这种逻辑处理方式可以有效的协调前端与后端的处理能力，让整个业务流程清晰明了。
实践中的挑战与借鉴
建设完善一体化技术体系并不容易。在实践过程中会面临诸多挑战，首先技术的匹配性就存在问题。例如Flutter与FaaS的一些技术细节方面可能存在兼容性的问题。同时，对于开发人员的能力要求也变得更高，开发人员需要同时熟悉前后端技术。
同时，在探索实践中可以借鉴已有的相关经验。像阿里的前端同学就已经比较深入的实践了Serverless，虽然不是基于一体化理念，但其中的很多思路是可以用于FaaS+Flutter一体化实践的。比如在资源分配、性能优化等方面的经验就有很大的借鉴意义。
你是否看好FaaS+Flutter这种编程形态在未来的发展？欢迎点赞、分享并留言。
