边缘服务的一致性、耦合和复杂性( 四 )

文章图片
现代Web应用程序几乎都是SPA（单页应用），而在以前，用户用Web浏览器加载HTML页面，这些页面可能是由服务器端的Web应用程序生成的。当用户单击页面上的一个链接，浏览器会渲染一个全新的HTML页面，这个页面也是由服务器端的Web应用程序生成的。在使用SPA时，用户用Web浏览器加载一个Web页面，这个页面只包含最基本的HTML元素，同时也会下载很多JavaScript和CSS文件。 API调用是通过执行JavaScript代码来完成的，然后生成很多DOM元素，浏览器再用这些DOM来渲染GUI 。当用户单击一个链接，页面上的JavaScript会销毁旧的DOM元素，并生成一些新的DOM元素。页面看起来发生了变化，但浏览器并没有加载全新的页面。
现如今，大多数前端开发人员使用TypeScript（具备类型检查特性的JavaScript变种）编程，以及Angular或React等框架。 TypeScript被转译为JavaScript和CSS ，这个过程成为项目构建的一部分。在进行本地开发时，开发人员将Node.js作为JavaScript和CSS文件的服务器，也用它将请求路由给目标API 。但如果不是在本地开发，我建议使用Nginx 。这样可以将配置了同源策略的文件与应用程序代码放在一起。构建出来的Docker镜像包含应用程序编译后的文件以及与CORS或缓存控制问题相关的配置文件。如果你采用了这种方式，可能需要调整CDN的配置。
现如今大多数移动应用程序都是运行在iOS或安卓系统上。这些操作系统都有各自的技术要求，这里就不赘述了。你可以选择为不同的操作系统单独开发应用程序，也可以使用Ionic或ReactNative框架来开发同一套应用程序，然后为不同的操作系统分别生成各自的二进制包。你可以为分别为iOS和安卓开发单独的BFF ，也可以简单一点，开发一个移动BFF来满足两个平台。
结论
你不必纠结于是选择REST还是GraphQL 。 REST更适合面向平台的数据服务， GraphQL更适合面向GUI的边缘服务。如果你的数据服务和边缘服务位于不同的层，那么完全可以同时保留REST和GQL ，把二者的好处尽收囊中。
理清不同类型组件之间的关注点分离，有助于降低意外复杂性。有时候，你会为了达成短期目标而模糊了这些关注点。架构师需要努力满足各方的需求。为了满足紧急需求，考虑应用一些短期的解决方案，允许暂时模糊关注点边界，提高意外复杂性。但后续需要马上跟进（需要各方的参与），进行长期必要的重构工作，让系统重新具备清晰的关注点分离，并从整体上降低意外复杂性。这就是技术负债给我们带来的教训。
如果可能的话，降低跨组件的耦合性。紧密耦合的组件应该由相同的团队负责开发维护，并采用相似或互补的开发技术。你不需要为此大幅改变团队的结构。
作者简介：
GlennEngstrand是RallyHealth的软件架构师。他的工作重点是与工程师合作，交付符合12Factor标准的可扩展服务器端应用架构。在2017年和2018年的Adobe内部广告云开发者大会以及2012年在波士顿举行的LuceneRevolution大会上， Glenn进行了突破性的演讲。他擅长将单片应用分解为微服务，并与实时通信基础设施进行深度集成。
原文链接：
Consistency,Coupling,andComplexityattheEdge