1.5 何时不应使用Jamstack #

Jamstack的一个前提假设是，网站内容在编译时是可用的，并且不会快速更改。 如果这个前提是不成立的，则Jamstack不能提供很多必要的支持。 以下各节提供了何时不应该使用Jamstack的场景。

1.5.1 当没有历史意义的动态数据时 #

如果我们正在构建一个具有不断变化数据的仪表板类型应用程序，那么预编译作为一个概念并不能提供很大的价值。 基于传感器的数据可以在几毫秒内改变。 在许多情况下，没有人阅读这些数据。 Jamstack不能很好地与这种类型的应用程序配合使用。 这里有一种例外是报告，其中一些数据需要保留很长时间，经常被阅读，并且很少更改(如果有的话)。 这种类型的报告是预先生成和保存的完美案例。 匆忙做这件事是没有意义的。 Jamstack完全符合报告场景。

1.5.2 基于用户生成的具有瞬态数据的内容构建 #

Twitter和Facebook等网站的帖子很小，我们很少将其作为单独的页面阅读。 这些被编译成提要，每个用户的提要是不同的，并且会随着时间的推移而变化。 用户可能在任何给定时间都不会阅读提要，因此预生成可能会浪费。 这些场景不适合Jamstack擅长的一次写入、多次读取的场景。 虽然理论上我们可以编译经常使用的页面，但传统的web技术栈也可以做到这一点。 这里需要记住的一件事是，如果数据具有永久性价值，故事就会发生很大变化。 如果我们有用户生成的博客帖子、产品页面或写作文章，这些文章写一次，读很多次，这就又回到了Jamstack擅长的写一次，读了很多次场景。

1.5.3 特定于用户的专属网页 #

在一些网站上，开发人员为用户个性化每个页面。 此数据不同，因为它基于用户ID。 因此，预编译可能没有意义。 大多数用户可能无法登录。 没有可以供公开访问的负载内容。 这是数据的多次读取和一次写入的整个理想是错误的。 一个例子是日历应用程序。 因为每个用户的日历都是不同的，所以预先生成每个人的日历是没有意义的。

1.5.4 当没有要编译的数据时 #

Web应用程序是用户既是创建者又是消费者的网站。 对于文档编辑器 (例如Google Docs)，没有数据可以显示。 在这些情况下，Jamstack开发路径无法提供帮助。

请注意，Jamstack在以上所有情况下都有助于构建网站的静态部分。 其中包括隐私政策页面和使用条款页面。 甚至可以使用Jamstack优化构建About Us页面和公司博客。 这些页面可以使用Jamstack方法设置，而不同的技术栈可以为网站或Web应用程序的其余部分提供服务。

Exercise 1.3

以下列表中的哪个网站最适合使用Jamstack构建？

• a. A search engine
• b. A shopping website
• c. A social network
• d. An image editor