您是否真的需要实现前后端分离的API? -DEV社区

21-04-05 banq

“低耦合高凝聚”,“信息隐藏”:众所周知的设计原则。尽管如此,它们在许多软件体系结构中并未得到重视,尤其是在前端和后端之间的交互方面。

 

API对于隐藏信息很有价值

通过提供API系统,可以确定将哪些信息公开给外界以及将哪些信息保密(信息隐藏)。

为什么这么重要?因为API越广泛,维护起来就越昂贵。考虑一下公开每个实现细节的极端情况。系统中的每个更改都可能破坏使用该代码的客户端。这就是我们努力拥有小型API的原因。

但是,API都会阻止我们自由开发系统。我们始终必须仔细记录API,并考虑不要破坏我们的客户。必须以向后兼容的方式引入更改,否则我们必须调整我们的系统的部署,而这些部署很快就会变成一个庞大的部署地狱。

 

API作为产品

但是,如果很难维护它们,为什么系统会提供这么多的API?原因之一可能是API是系统的唯一卖点。API是赚钱的产品。在这种情况下,使用诸如超媒体之类的技术并关注向后兼容性。您的客户将不胜感激,并且您的API产品大放异彩。

 

前端和后端的分离的API

后端和前端之间的凝聚很自然,因为每当需要在前端显示一些新数据时,都需要调整后端。那么,为什么我们要通过在它们之间放置一堵墙(API)来使它们分离呢?

在大多数情况下,这种设计是由组织或技术环境决定的。有专门的后端和前端团队,但是我想知道在决定分离团队时是否总是考虑维护API的开销。

 

使用客户端渲染的愿望

另一个驱动使用API因素是希望使用现代Javascript UI库(例如Angular,React或Vue.js)来实现前端。与服务器端呈现(SSR)方法相反,这些库在浏览器中的客户端(CSR)处呈现视图,并依赖于后端提供的服务(REST,GraphQL等)来检索数据并执行操作。

尽管我认为SSR现在被大大忽视低估了,但是...使用现代javascript库库并不一定需要API!由于后端代码是在服务器端执行的,而前端代码是在用户的浏览器中执行的,因此您在技术和环境方面都遇到了麻烦。此中断需要使用REST或GraphQL才能同步两个环境。

我称其为桥梁而不是API,因为您可以与前端携手发展后端服务。无需仔细记录API或处理重大更改,因为那里只有一个客户端。这个客户端是众所周知的,因为它位于同一系统中。结果是后端和前端始终部署为一个整体,而这些文档和兼容性方面的挑战就消失了。

 

结论

技术不应成为系统设计的驱动力。关于后端和前端之间的交互,请考虑需求,并确定是要使用整体式前端还是独立式系统。“低耦合-高凝聚力”是有力的指导方针!

如果您决定使用一个独立的系统,则取决于您选择服务器端还是客户端渲染方法。尽管CSR和SPA(单页应用程序)经常被合并在一起,但是您仍可以使用CSR,同时仍具有每个模块的前端。

banq:该文观点有点偏颇,前端有安卓app 苹果app和html app等各种客户端,如何降低这些不同客户端对后端的耦合,这是需要松耦合,而不是考虑它们的高凝聚,松耦合高凝聚不能只从一个角度考虑,该文只从业务角度考虑,但是在业务领域的聚合是存在上下文边界之内,不是跨上下文边界,API是前端和后端的DDD防腐层。

 

1
猜你喜欢