【问题标题】:What are the disadvantages of client-only routes?仅客户端路由的缺点是什么?
【发布时间】:2019-12-23 02:39:14
【问题描述】:

对于gatsbyjs 站点,我正在考虑是否使用仅限客户端的路由概念 (https://www.gatsbyjs.org/docs/building-a-site-with-authentication/) 从客户端提供来自服务器的受限页面(我会说是传统方法)

我想要的是一个static url,其内容根据身份验证状态显示或不显示,而不是只有该客户端当时可以访问的不同client-only url

我想知道这是否是没有服务器的“缺点”,或者不是这种情况,我不太了解它

而且,与基于服务器的方法相比,还有其他/任何缺点吗?

【问题讨论】:

  • static URL 到底是什么意思?可以在浏览器中输入的 URL?
  • @EliteRaceElephant 您不能在浏览器中输入哪个 URL?您的意思是应用路由 URL 与没有更改和/或历史记录的应用路由 URL 对比吗?
  • @DaveNewton 也许我对精英回答的评论更清楚(?)

标签: reactjs authentication react-router gatsby


【解决方案1】:

我可以提出两个缺点,它们实际上只是保护私有路由的其他方法:

  1. 服务器计算
  2. 提供用户特定数据
  3. Gatsby 不在服务器上动态呈现

1.服务器计算

一个缺点可能是客户端呈现页面而不是您的服务器。如果您想最小化服务器计算,这也是一个优势。除此之外没有任何缺点。这只是保护私有路由的另一种方式。

您可以通过您链接的文档中描述的仅限客户端的机制来定义仅限客户端的路由,例如 www.your-site.com/settings/account。此路由对已登录的用户进行保护。如果他们未登录,则不会呈现该站点,并且会将他们重定向到登录页面。

2。提供用户特定数据

我不确定您所说的静态 URL 是什么意思。只要您的用户登录,就会为他们呈现 URL www.your-site.com/settings/account。您可以通过 JSON Web 令牌、cookie、会话、各种 API 为用户提供正确的数据。

这又不是一个真正的缺点。对于服务器和客户端呈现的页面,您始终需要以仅将私有数据发送给经过身份验证的用户的方式构建 API。

3. Gatsby 不在服务器上动态渲染

这意味着您必须将服务器呈现的页面实现到静态站点中。我认为没有任何官方文档。当您再次动态渲染网站的一部分时,使用 Gatsby(一个 stic-site 生成器)毫无意义。

如果您承诺使用 Gatsby,我建议您使用仅限客户端的路线,因为这样它始终是一个静态站点,具有所有优势。

【讨论】:

  • 假设我有包含私人和公共内容的帖子,带有定义的 URL,例如 www.your-site.com/posts/1' ... www.your-site.com/posts/50' 并且所有 URL 都必须可以从非登录和已登录的用户,但已登录的用户将拥有所有内容。这可以通过仅客户端路由来完成吗?
  • @GWorking 不,它不能。 URL www.your-site.com/posts/50 可以是公共的/静态的或仅限客户端的。您可以创建一个公共 URL www.your-site.com/posts/50 并通过一个检查用户是否登录的 API 提供私有内容。引擎盖下的 React 应用程序并不关心它是呈现公共内容还是私有内容。这只是数据。 API 必须确保用户是否经过身份验证。
  • 是的,我就是这么想的,然后那个 API 需要一个服务器,所以一个仅客户端路由的缺点是它需要整个页面都是私有的,你不能用私有和构建混合页面那里的公共内容
  • 混合内容来自 API 的调用方式:登录用户获取私有和公共数据,因为他通过 JWT、cookie、会话等方法进行身份验证。未登录的用户只能获得公共数据。这就是 JAMstack 中的 A (API) 的全部意义所在。无论哪种方式,您都需要一个检查用户身份验证的后端服务器:在服务器上呈现页面或让安全的 API 调用访问私有数据,然后将其显示在静态站点上。仅客户端路由的用例非常具体,例如私人帐户设置或电子商务应用程序的结帐渠道。
猜你喜欢
  • 2015-12-06
  • 2019-06-14
  • 1970-01-01
  • 1970-01-01
  • 2012-04-28
  • 1970-01-01
  • 1970-01-01
  • 2014-09-05
  • 1970-01-01
相关资源
最近更新 更多