Web 应用程序架构:1 个或 n 个 API [英] Web apps architecture: 1 or n API

问题描述

背景:我正在考虑网络应用程序组织.我会将前端(浏览器的网站)与后端(API)分开:2 个应用程序、2 个存储库、2 个托管.Front 会为几乎所有内容调用 API.

Background: I'm thinking about web application organisation. I will separate front (web site for browser) from back (API): 2 apps, 2 repository, 2 hosting. Front will call API for almost everything.

因此，如果我的 API 有两个单独的域服务(例如:学习上下文和预订上下文)而它们之间没有直接链接，我是否应该构建 2 个 API(带有 2 个存储库、2 个构建过程等)?为 n 需求或一个大"API 构建 n API 是一种好习惯吗?我说的是一个具有流量的强大网络应用.

So, if I have two separate domain services with my API (example: learning context and booking context) with no direct link between them, should I build 2 API (with 2 repository, 2 build process, etc.) ? Is it a good practice to build n APIs for n needs or one "big" API ? I'm speaking about a substantial web app with trafic.

(我希望这个问题不会因为没有建设性而被关闭......我认为这是一个具体案例的真正问题，如果没有，抱歉.这个问题和其他一些关于架构的问题没有关闭，所以我的还有希望)

(I hope this question will not be closed as not constructive... I think it's a real question for a concrete case, sorry if not. This question and some other about architecture were not closed so there is hope for mine)

推荐答案

这完全取决于您正在处理的应用程序、其业务需求、您拥有的优先级等等.通常你有几个选择:

It all depends on the application you are working on, its business needs, priorities you have and so on. Generally you have several options:

• 坚持使用单一应用程序
• 继续使用单一的应用程序，但将域模型跨单独的模块/捆绑包/库分离
• 创建分布式架构(如面向服务的架构 (SOA) 或事件驱动的架构 (EDA))

一个单体应用

这是在开始阶段开发应用程序的最简单、最便宜的方式.您不必担心复杂的架构、复杂的部署和开发过程.如果周围没有很多开发人员，它也能更好地工作.

It's the easiest and the cheapest way to develop application on its beginning stage. You don't have to worry about complex architecture, complex deployment and development process. It also works better if there are no many developers around.

一旦应用程序长大，这个模型就开始出现问题.您不能单独部署模块，应用程序更容易受到反模式、意大利面条式代码/设计的影响(尤其是当很多人都在处理它时).QA 过程花费的时间越来越长，这可能使其在 CI 基础上无法使用.引入持续集成/交付/部署等方法也困难得多.

Once the application is growing up, this model begins to be problematic. You can't deploy modules separately, the app is more exposed to anti-patterns, spaghetti code/design (especially when a lot people working on it). QA process takes more and more time, which may make it unusable on CI basis. Introducing approaches like Continuous Integration/Delivery/Deployment is also much much harder.

在这种方法中，您有一个适用于所有 API 的存储库/构建过程，

Within this approach you have one repo/build process for all your APIs,

一个单体应用，但解耦领域模型

在这种方法中，您仍然拥有一个大平台，但您可以在第 3 方的基础上连接逻辑上独立的模块.例如，您可以提取一个模块并从中创建一个库.

Within this approach you still have one big platform, but you connect logically separate modules on 3rd party basis. For example you may extract one module and create a library from it.

因此，您可以为不同的库引入单独的流程(QA、开发)，但您仍然必须一次部署整个应用程序.它还可以帮助您避免反模式，但可能很难在应用程序生命周期内保持跨库的向后兼容性.

Thanks to that you are able to introduce separate processes (QA, dev) for different libraries but you still have to deploy whole application at once. It also helps you avoid anti-patterns, but it may be hard to keep backward compatibility across libraries within the application lifespan.

关于您的问题，通过这种方式，您可以为每种类型的操作"拥有单独的 API、开发流程和存储库；只要你把它的领域逻辑移到单独的库中即可.

Regarding your question, in this way you have separate API, dev process and repository for each "type of actions" as long as you move its domain logic to separate library.

分布式架构(SOA/EDA)

SOA 利润丰厚.您可以为每个服务引入完全不同的流程:开发、QA、部署.您一次只能部署一项服务.您还可以将不同的技术用于不同的目的.QA 过程变得更加可靠，因为它涉及较小的项目.您可以在服务之间进行版本通信 (API)，这使它们更加独立.此外，您还有更好的水平扩展能力.

SOA has a lot profits. You can introduce completely different processes for each service: dev, QA, deploying. You can deploy just one service at once. You also can use different technologies for different purposes. QA process gets more reliable as it involves smaller projects. You can version communication (API) between services which makes them even more independent. Moreover you have better ability to scale horizontally.

另一方面，高层架构的复杂性在增加.您需要注意更多不同的组件:服务之间的身份验证/授权、安全性、服务发现、分布式事务等. 如果您的应用程序是数据驱动的(使用 API 来消费数据的单独前端)并且不需要特定服务相互沟通 - 这可能没有那么复杂(但这种假设对于 IMO 来说非常危险，您需要尽快或通过信函与他们沟通).

On the other hand complexity of the high level architecture grows. You have much more different components you have to take care: authentication / authorisation between services, security, service discovering, distributed transactions etc. If your application is data driven (separate frontend which use APIs for consuming data) and particular services don't need to communicate to each other - it may be not as much complicate (but such assumption is IMO quite risky, sooner or letter you will need to communicate them).

在这种方法中，您有单独的 API，每个类型的操作"都有单独的存储库和单独的流程.(我理解 ss 单独的域模型/服务).

In that approach you have separate API, with separate repositories and separate processes for each "type of actions" (which I understand ss separate domain model / services).

正如我在开头所写，您选择的方式取决于应用程序及其需求.无论如何，回到您最初的问题，我的建议是尽可能将 API 分开.即使您有一个整体式应用程序，您也应该能够单独对 API 进行版本控制并保持它们的域逻辑分开.分离存储库和/或进程取决于您选择的方法(例如我之前提到的方法).

As I wrote on the beginning the way you choose depends on the application and its needs. Anyway, back to your original question, my suggestion is to keep APIs as separate as you can. Even if you have one monolithic application you should be able to version APIs separately and keep their domain logic separate. Separating repositories and/or processes depends on the approach you choose (eg. among these I mentioned before).

如果我错过了你的观点，请更详细地描述你希望得到什么答案.

If I missed your point, please describe in more detailed way what answer do you expect.

最好！

这篇关于Web 应用程序架构:1 个或 n 个 API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！