不同类型的全栈体系结构

Question

作为一个自学成才的全堆栈开发人员，我在我的时代建立了几个堆栈，但我认为我的知识中可能有一个漏洞，希望您可以填补我的空白。我已经构建了几个堆栈，它们都有这样的核心架构：

• 后台Go，与Postgres数据库接口或执行一些核心逻辑
• HTTPS上服务的RESTful API服务器(也用Go编写)，该服务器触发数据库方法/后端逻辑
• 在JavaScript中使用ReactJS或其他框架的前端。每当需要数据/在后端执行逻辑时，前端都会调用API服务器(使用fetch())。

我发现这是一个非常好的、通用的架构，可以在许多不同的用例中工作。但是，我想知道是否还有其他类型的核心架构与此不同。我听说过GraphQL，我发现这与这种传统的类似REST的体系结构有多么不同，但我想知道是否还有其他类型的体系结构用于构建不围绕REST/SOAP/GraphQL的web应用程序。我听说过WebSockets，我认为它们符合我在这里询问的内容，那么它们与调用JavaScript的fetch()来调用REST (或者使用类似于axios的第三方库)有什么不同呢？

Answer 1

您的应用程序的架构是您决定它是什么。你在问题中提到的字母表汤就是那些比较有名的汤。每种方法都有自己的特点和优点。

websockets的不同之处在于它更“实时”。有一个REST体系结构并辅以websockets来提供诸如实时仪表板之类的东西，或者“这个帖子已经被编辑了，点击这里重新加载”横幅，你有时会在Stack Exchange站点上看到，这并不少见。

创建websocket时，您将打开双向通信通道。这与您提到的其他体系结构有明显的不同，因为这些体系结构是基于查询端点以获得一些数据。这是每次打电话和说话时不接电话之间的区别。

Answer 2

您正在广泛地询问web应用程序体系结构，但只关注客户机-服务器通信，即应用层。通信的风格并没有真正改变整个体系结构模式；这些只是不同的数据类型或协议。这是架构的实现细节，而不是架构模式本身。

您可以为应用程序架构模式找到一些有用的入门.，但以下是一些最常见的快速列表(以及超级基本描述)：

• 客户机-服务器，这就是您所描述的。
• Microservices，其中UI与几个具有专门域的后端服务器交互。
• 分层，其中后端的关注点(有时是前端，比如健壮的Redux服务)被分解成不同的关注点--有利于测试性。
• 点对点，其中客户既是资源的消费者，也是资源的提供者。

这些并不一定是相互排斥的。所有这些都可以根据应用程序的需要以不同的方式组合。