我最近开始探索微服务和API网关的概念，尤其对应该如何托管前端端点感到困惑。
如果我有一个API网关充当对我所有服务的请求之间的中间人，那么前端应在何处托管？如果我请求/ api / example，我知道我的API网关应将其路由到适当的服务并转发该服务响应。但是，我不了解API网关应如何在微服务上下文中处理/ home /。在这种情况下，我们希望将与/ home /相对应的html / css / javascript传递给发出GET请求的客户端。这是否意味着我们应该拥有某种前端服务？因为我们真正需要做的只是立即返回与我们的前端相关联的HTML / CSS / JS，所以创建仅返回HTML / CSS / JS的服务是多余的并且不会增加延迟吗？
我正在考虑的另一种选择是让API网关本身提供端点，这些端点返回客户端呈现前端所需的HTML / CSS / JS。换句话说，当接收到对/ home /的GET请求时，API网关可以立即使用与/ home /相对应的HTML进行响应，而不是调用服务。但是，我在网上阅读到API网关实际上不应该服务于端点，而应该将它们代理到服务。
这是我的主要问题：使用微服务架构构建后端时，前端代码应该放在哪里？
答案 0 :(得分：3)
我认为您的前端是“单页应用程序”。 SPA具有静态内容，例如HTML，CSS，图像，字体等。它是部署为静态网站的理想选择，可以使用REST API从后端获取数据。
在AWS，GCP等云环境中，建议将SPA应用程序与REST API分开托管。例如可以将AWS SPA中的SPA部署在Amazon S3中，并且无需通过API网关即可直接访问它。
API网关应该仅用于路由REST API调用和执行诸如验证等交叉性问题。但是，此方法的问题是，从前端访问REST API时，您会遇到CORS错误，因为SPA和API网关将托管在不同的域中。为了解决此问题，需要在API网关上启用CORS。
如果您正在寻找更简单的解决方案，则可以通过API网关从服务中提供前端。由于静态内容仅在SPA中提供一次，因此对于更简单的应用程序，可以从这种方法开始。
https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
答案 1 :(得分：3)
API网关应以最少的逻辑充当代理/路由器。顾名思义，其主要目的是公开API，而不公开different types of clients的GUI组件/页面，并解决某些非功能性方面，例如安全。根据请求的客户[basically BFF/Backend for Frontend approach]提供高级的API（由用例驱动）。
在使前端/ GUI适合微服务时，您可以考虑使用由Micro FrontEnds支持的UI Gateway / Container。另外，有关micro frontends的详细信息，请访问MF网站。
因此，遵循前端的微服务体系结构，您的前端代码应与其他微服务一起驻留在微前端中。
答案 2 :(得分：2)
在回答您的问题之前，让我先介绍一下不同的渲染策略：
如今非常罕见。您不需要任何API网关，因为所有内容都是在服务器中计算和呈现的，因此您可以在其中执行对其他微服务的必要调用。
优点：简单；用户在页面加载时的即时交互性； SEO
缺点：每次都完全重新加载
最近几年最受欢迎的选项。您提供了一个基本的静态HTML / CSS / JS包，对API执行请求以检索一些数据，并使用某种模板引擎来呈现新页面和组件。
优点：没有完全重新加载；延迟加载；更丰富的互动； CDN带来的好处
缺点：SEO；页面在加载时不互动；第一次加载较慢
由于呈现是在浏览器中进行的，因此您无需从服务器提供静态HTML / CSS / JS文件。相反，您应该使用CDN来更快地交付它们。
对非静态资源的其他请求将通过API网关执行，API网关负责将请求转发到其他服务（或进行某种编排/聚合）。
由于Next.js之类的框架，如今这种方法越来越受关注。该页面最初是使用将在浏览器中使用的模板引擎在服务器中呈现的，因此您可以在保持客户端呈现的功能和优点的同时，更快地发送交互式页面。
在这种情况下，所有静态页面都可以通过CDN进行预渲染，缓存和服务。对于动态页面，您仍然可以发送部分缓存/渲染的页面，该页面稍后会从API网关中获取其他必要信息。
TL; DR：您不需要从API网关或服务器提供静态HTML / CSS / JS。您应该通过CDN交付它们，以缩短加载时间。
否则，静态文件不应通过API网关恕我直言提供。您可以使您的/api/{resource}请求通过它，然后将所有/{page}请求转发到静态资源。
答案 3 :(得分：0)
如您指出的那样，如果要返回Frontle的整个正文，则对Frontend应用使用API响应是没有意义的。
但是，您可以（最初）加载一个前端，它包含一个标题，例如菜单，页脚和一个主体部分，其中包含一些元素（如文章）。
与该前端进行交互时，可以对该API触发一个操作（通常通过JS Ajax调用），该操作将从API请求新数据的特定部分，并且一旦接收到，JS将仅更新上的相关部分该网页，而不是重新加载或替换（或刷新）整个页面。
如果操作正确，可以节省大量网络流量，从而使网站更灵活，而无需在每次需要可视化新数据时都将其完全重新加载。
一个简单的例子： 当您单击菜单中的链接以加载联系人表格时，API将仅返回联系人表格的原始HTML，或者将返回（通常）JSON对象/数组，以用于进一步生成/替换您主体的一部分，现在就成为联系表格。
答案 4 :(得分：0)
前端应在何处托管？
使用a.net构建后端时，前端代码应该放在哪里？ 微服务架构？
您的前端（网络）应用程序通常位于API网关 之前 。对诸如 HTML / CSS / JS 之类的资源的请求是直接从前端应用程序本身提供的，因此这里没有任何API-网关参与。如果页面包含对后端（Micro）服务的（AJAX）调用，则可能（应该）通过API网关。从托管角度来看，它们作为单独 Web应用程序托管。
API网关应如何在微服务环境中处理/ home /？
不会（即完全不会被API Gateway拦截）。诸如/home之类的请求是由前端应用程序本身直接服务的页面请求（当然，它将具有其自己的缩放机制，例如集群，缓存等）