面向用户界面和外部方的单用途边缘服务
介绍随着web的出现和成功，交付用户界面的实际方式已经从厚客户端应用程序转变为通过web交付的界面，这一趋势也使基于SAAS的解决方案总体上得以发展。通过web提供用户界面的好处是巨大的——主要是因为发布新功能的成本大大降低了，因为客户端安装的成本（在大多数情况下）被完全消除了。
然而，这个简单的世界并没有持续太久，不久之后，手机时代就到来了。现在我们有麻烦了。我们有服务器端功能，我们希望通过桌面webUI和一个或多个移动UI公开这些功能。考虑到最初开发的系统是以桌面webUI为基础的，我们在适应这些新类型的用户界面时经常会遇到问题，因为桌面webUI和我们支持的服务之间已经有了紧密的耦合。
通用API后端容纳多种类型的UI的第一步通常是提供单一的服务器端API，并根据需要随时间增加更多功能以支持新类型的移动交互：
通用API后端
如果这些不同的ui想要进行相同或非常相似的调用，那么这种通用API很容易成功。然而，移动体验的本质往往与桌面web体验截然不同。首先，移动设备的价格非常不同。我们有更少的屏幕房地产，这意味着我们可以显示更少的数据。打开与服务器端资源的大量连接可能会耗尽电池寿命和有限的数据计划。其次，我们希望在移动设备上提供的交互的性质可能有很大的不同。想想一个典型的实体零售商吧。在桌面应用程序中，我可能允许您查看要出售的商品、在线订购或在商店中预订。不过，在移动设备上，我可能希望允许您扫描条形码进行价格比较，或者在商店中为您提供基于上下文的优惠。随着我们构建了越来越多的移动应用程序，我们逐渐意识到人们使用它们的方式非常不同，因此我们需要公开的功能也会有所不同。
因此，在实践中，我们的移动设备将要进行不同的呼叫，更少的呼叫，并将要显示不同的（可能更少）数据比他们的桌面对应。这意味着我们需要在我们的API后端添加额外的功能来支持我们的移动接口。
通用API后端的另一个问题是，根据定义，它们为多个面向用户的应用程序提供功能。这意味着，当推出新的交付时，单个API后端可能会成为瓶颈，因为许多更改都试图对同一个可部署工件进行。
通用API后端承担多个职责的趋势，因此需要大量工作，通常会导致专门创建一个团队来处理这个代码库。这会使问题变得更糟，因为现在前端团队必须与一个单独的团队进行交互以获得所做的更改—一个团队必须平衡不同客户团队的优先级，并且还必须与多个下游团队合作，在新的API可用时使用它们。可以说，在这一点上，我们刚刚在我们的体系结构中创建了一个智能的中间件，它并不