静态网站生成器
Two ideas, JAMStack and static website generators, are getting attention as a way to simplify website and web application development, while simultaneously being vague unclear marketing terms. Both talk about static assets for website, but what does that really mean? To help decode the vague marketing words, let’s examine the technologies, see how they differ, and try to figure out if there’s anything important to learn.
JAMStack和静态网站生成器这两个想法正在作为一种简化网站和Web应用程序开发的方法而受到关注，同时又模糊了不清楚的市场营销术语。 两者都谈论网站的静态资产，但这到底意味着什么？ 为了帮助解释模糊的营销词汇，让我们检查一下技术，看看它们有何不同，并尝试弄清楚是否有什么要学习的重要知识。
In the beginning (of the web) websites were HTML files (and images) you uploaded to a web server using FTP. That’s it. My first websites, in 1994–1995, were coded that way, and of course I used FTP. A big advance was finding a programmers editor, that handled HTML syntax coloring, and which could directly edit files in remote directory structures. That meant not having to upload using FTP, and the syntax coloring made it a little easier to edit the HTML. Another advance was a feature called Server Side Includes, letting one have sidebar or header or footer “widgets” loaded as HTML snippets from a shared directory. That simplified having a consistent look across the website. Then came the variety of pseudo-WYSIWYG HTML editors where we could edit web pages visually, rather than guessing what the page looked like while editing raw HTML. These editors didn’t support server side includes, but there was a similar feature in Dreamweaver allowing one to have shared HTML snippets.
在网站的开始，网站是HTML文件(和图像)，是您使用FTP上传到Web服务器的。 而已。 我的第一个网站(1994-1995)是用这种方式编码的，当然我使用的是FTP。 寻找程序员编辑器是一大进步，它可以处理HTML语法着色，并且可以直接在远程目录结构中编辑文件。 这意味着不必使用FTP上传，并且语法颜色使编辑HTML更加容易。 另一个进步是一项称为“ 服务器端包含”的功能，该功能使边栏或页眉或页脚“小部件”作为HTML片段从共享目录中加载。 这样简化了整个网站的外观。 然后是各种各样的伪WYSIWYG HTML编辑器，我们可以在其中可视化地编辑网页，而不必在编辑原始HTML时猜测页面的外观。 这些编辑器不支持服务器端包含，但是Dreamweaver中有一个类似的功能，允许一个人共享HTML代码段。
The point is that a website built with simple HTML files is not a new concept. We’ve been doing that since the beginning of the Web.
关键是用简单HTML文件构建的网站不是一个新概念。 自从网络开始以来，我们一直在这样做。
The story for both JAMStack and Static Website Generators is that there’s a big speed advantage with static HTML+CSS+JavaScript rather than deploying a dynamic content management system (CMS) or a custom server-side application. There’s no complex server-side code for rendering the pages.
对于JAMStack和静态网站生成器来说，静态HTML + CSS + JavaScript都具有很大的速度优势，而不是部署动态内容管理系统(CMS)或自定义服务器端应用程序。 没有用于呈现页面的复杂服务器端代码。
For me, both are a reaction to complicated dynamic CMS’s, or complex custom micro-services deployed to cloud hosting. Over the years of learning the intricacies of Drupal 6 and Wordpress, learning how to customize Blogger templates, and learning Docker and Docker Swarm, I came away with a distaste of the burden it is to host a complex content management system which dynamically generates pages. At one time I was maintaining 10 or so Drupal instances for different websites, managing multiple VPS’s, facing a never ending grind of updating modules on each site, and worrying how I would pay the hosting bill.
对我而言，两者都是对复杂的动态CMS或部署到云托管的复杂的自定义微服务的React。 在学习了Drupal 6和Wordpress的复杂性，学习如何自定义Blogger模板以及学习Docker和Docker Swarm的多年中，我摆脱了托管一个动态生成页面的复杂内容管理系统的负担。 一次我要为不同的网站维护10个左右的Drupal实例，管理多个VPS，面对每个站点上更新模块的永无止境的烦恼，并担心如何支付托管费用。
As a result of those experiences I developed my own static website generator, AkashaCMS. With it the hosting bill is minuscule, and the page load time for users of the websites is excellent.
基于这些经验，我开发了自己的静态网站生成器AkashaCMS。 有了它托管费用很小，并且网站用户的页面加载时间非常好。
The JAMStack and static website generator proponents are preaching a similar vision — modern HTML+CSS+JS — static assets for speed — simplified deployment — eliminating complexity — so let’s start with this question…
JAMStack和静态网站生成器的支持者正在宣扬类似的愿景-现代HTML + CSS + JS-静态资产以提高速度-简化部署-消除复杂性-因此，让我们从这个问题开始吧……
什么是JAMStack？ (What is JAMStack?)
The JAMStack concept is defined as “ Fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.” To drive the point home the acronym, JAM, means:
JAMStack的概念定义为“ 通过预渲染文件并直接从CDN直接提供文件来交付快速安全的站点和应用程序，从而消除了管理或运行Web服务器的需求。 ”缩写“ JAM”是指：
(J) JavaScript executed in a web browser page as the client tier
( J )在Web浏览器页面中作为客户端层执行JavaScript
(A) API’s hosted on servers are accessed by client-side JavaScript to retrieve data
( A )客户端JavaScript访问服务器上托管的API以检索数据
(M) Markup, both as HTML and HTML templates, are used to dynamically update pages using the JavaScript and retrieved data
( M )作为HTML和HTML模板的标记，用于使用JavaScript和检索到的数据动态更新页面
(STACK) Because, well, every software product is described as a Stack, right?
( 堆栈 )因为，每个软件产品都被描述为一个堆栈，对吗？
That’s simple enough, static assets and fast page load times. But the JAMStack definition says “ sites or apps” and requires deployment to a CDN. Why do they explicitly call out those points? Is there a real difference between JAMStack and a static website generator?
这非常简单，静态资产和快速的页面加载时间。 但是JAMStack的定义是“ 站点或应用程序 ”，需要部署到CDN。 他们为什么要明确指出这些要点？ JAMStack和静态网站生成器之间有真正的区别吗？
In a system like AkashaCMS, the user edits Markdown or AsciiDoc files, then runs a tool to render those files to HTML+CSS+JS, and uses rsync to deploy to a web server. This is the JAMStack and statically generated website model, uploading static HTML+CSS+JS assets to a hosting system. A couple observations:
在像AkashaCMS这样的系统中，用户编辑Markdown或AsciiDoc文件，然后运行工具将这些文件呈现为HTML + CSS + JS，并使用rsync部署到Web服务器。 这是JAMStack和静态生成的网站模型，可将静态HTML + CSS + JS资产上载到托管系统。 一些观察：
A statically generated website does not require backend API’s or DOM manipulation, but can include JS that calls backend API’s and performs DOM manipulation, if needed
静态生成的网站不需要后端API或DOM操作，但可以包含调用后端API并执行DOM操作(如果需要)的JS。
- We can use modern HTML+CSS+JS in a statically generated website 我们可以在静态生成的网站中使用现代HTML + CSS + JS
- The statically generated website can be hosted on cheap shared web hosting that uses Apache or NGINX web-servers 静态生成的网站可以托管在使用Apache或NGINX Web服务器的廉价共享Web托管上
- Such websites can be hosted to a CDN to aid delivery to readers around the world 这样的网站可以托管在CDN上，以帮助将其交付给世界各地的读者
- Why is there an insistence on deployment to a CDN? 为什么坚持要部署到CDN？
In other words — a JAMStack site is a subset of the statically generated websites, since JAMStack is a statically generated website with additional constraints. In both cases pre-rendered HTML+CSS+JavaScript are deployed to a hosting location, and the hosting location does nothing other than deliver the files to web browsers. The difference is the reliance on JavaScript and API’s and DOM Manipulation.
换句话说，由于JAMStack是具有附加约束的静态生成的网站，因此JAMStack站点是静态生成的网站的子集。 在这两种情况下，都将预渲染HTML + CSS + JavaScript部署到托管位置，并且托管位置除了将文件传送到Web浏览器外没有任何作用。 区别在于对JavaScript和API以及DOM操作的依赖。
With both, we skip a bunch of complexity and cost arising from using dynamically executed services to dynamically generate websites (e.g. Drupal or Wordpress).
两者都避免了使用动态执行的服务来动态生成网站(例如Drupal或Wordpress)所带来的复杂性和成本。
But, why do JAMStack proponents insist on using a CDN? What is a CDN? A CDN, a.k.a. Content Delivery Network, is a cloud based service for distributing assets to remote servers around the world. The promise is high performance, in part to automatically distribute content to CDN endpoints around the world.
但是，为什么JAMStack支持者坚持使用CDN？ 什么是CDN？ CDN(又称内容交付网络)是一种基于云的服务，用于将资产分发到世界各地的远程服务器。 承诺是高性能，部分是自动将内容分发到世界各地的CDN端点。
为什么要坚持CDN？ (Why insist on a CDN?)
In the JAMStack literature the task of “managing a webserver” is described as a huge burden. The CDN is described as being “serverless”, which is described as a huge advantage. Of course serverless is rather silly because of course CDN’s are built from zillions of servers. What that really means is that the person deploying the code isn’t involved with the overhead of provisioning and managing servers. The customer doesn’t have to configure the servers. We just deploy our code, and the serverless service takes care of the rest. With a CDN, you upload the files, and the CDN takes care of both the servers and distributing your HTML+CSS+JS assets around the world.
在JAMStack文献中，“管理Web服务器”的任务被描述为巨大的负担。 CDN被描述为“无服务器”，这是一个巨大的优势。 当然， 无服务器是很愚蠢的，因为CDN是由无数服务器构建而成的。 真正的含义是，部署代码的人员不会参与配置和管理服务器的开销。 客户不必配置服务器。 我们只是部署我们的代码，而无服务器服务则负责其余的工作。 使用CDN，您可以上传文件，CDN可以同时管理服务器并在全球范围内分发HTML + CSS + JS资产。
CDN’s primary stated advantage is that the CDN guarantees similar performance anywhere in the world. With traditional hosting from a single web server — my sites are hosted on shared hosting rented from Dreamhost whose servers are in southern California — the distance from that server affects speed of accessing the website.
CDN的主要优势是CDN可以确保在世界任何地方都具有类似的性能。 使用来自单个Web服务器的传统托管-我的网站托管于从Dreamhost租用的共享托管中，Dreamhost的服务器位于加利福尼亚南部-与该服务器的距离影响访问网站的速度。
According to Google Analytics the page load speed for my websites (all hosted on simple shared Apache web hosting) is under 20 milliseconds. Seems to me that 20 milliseconds is pretty close to blazingly fast. I haven’t tried hosting a site on a CDN and don’t know if CDN’s deliver content even more blazingly fast. A reader of my sites in Uganda might see slower page loading times than a reader in Huntington Beach California. Hosting on a CDN is supposed to equalize the two.
根据Google Analytics(分析)，我的网站(所有网站都托管在简单的共享Apache网络托管中)的页面加载速度不到20毫秒。 在我看来，20毫秒几乎快得惊人 。 我还没有尝试过在CDN上托管网站，也不知道CDN是否能以更快的速度交付内容。 我在乌干达的网站的读者看到的页面加载时间可能比加州亨廷顿海滩的读者慢。 在CDN上托管应该使两者相等。
Additionally, CDN providers truly offer unlimited bandwidth (at a fee). The traditional shared hosting providers, like Dreamhost, offer unlimited bandwidth, but there is often an unstated usage level beyond which the hosting provider will start sending emails demanding your site move somewhere else. CDNs have performance guarantees that cannot be made by the traditional Apache-based web hosting provider.
此外，CDN提供商真正提供无限带宽 (收费)。 传统的共享托管服务提供商(例如Dreamhost)提供无限带宽，但是通常存在未说明的使用级别，超出该级别时，托管服务提供商将开始发送电子邮件，要求您将网站移至其他地方。 CDN具有性能保证，这是传统的基于Apache的虚拟主机提供商无法提供的。
JAMStack来自哪里？ (Where did JAMStack come from?)
It seems that JAMStack came from Front End Engineers who had been roped into the unnatural thing of writing back-end code. Management might think that JavaScript is JavaScript, so a front engineer should surely be able to stand up Node.js services as the back end of their web application. But the skillset of creating visual experiences with HTML, CSS and JavaScript is very different from the skillset of back-end deployment tools like Docker, Databases and Node.js.
看来JAMStack来自前端工程师 ，他们被卷入编写后端代码的不自然之举。 管理层可能会认为JavaScript是JavaScript，因此前端工程师肯定应该能够将Node.js服务作为其Web应用程序的后端。 但是，使用HTML，CSS和JavaScript创建视觉体验的技能与Docker，数据库和Node.js等后端部署工具的技能有很大不同。
Front-end engineering is oriented to visual and interactive effects, whereas back-end coding is about server deployments, service scaling, and the like. It stands to reason a front-end engineer would balk at doing server deployments.
前端工程面向视觉和交互效果，而后端编码与服务器部署，服务扩展等有关。 可以肯定的是，前端工程师会拒绝进行服务器部署。
The folks talking about JAMStack focus on the ease of deploying applications. The folks using static website generators, like me, are looking for a slightly different thing. We have websites (blogs etc) to deploy, don’t see the point of dynamically generating the content on every page view, and want a lower hosting cost.
谈论JAMStack的人们关注于易于部署应用程序。 像我一样，使用静态网站生成器的人们正在寻找稍微不同的东西。 我们有要部署的网站(博客等)，看不到在每个页面视图上动态生成内容的意义，并且希望降低托管成本。
避免复杂性可能是最大的收获 (Avoiding complexity may be the biggest gain)
This image demonstrates the advantage of both JAMStack and the websites rendered using a Static Website Generator. The far simpler system is lower cost and lower resource impact and lower overhead to maintain and faster.
该图像展示了JAMStack和使用静态网站生成器呈现的网站的优势。 更简单的系统是更低的成本和更低的资源影响以及更低的维护成本和更快的维护成本。
On the left (blue arrows and text) we have the model of deploying static assets. They can be deployed to a CDN, as the JAMStack proponents insist, or to a simple Apache or NGINX server. In both cases the user’s web browser makes a request to a web server, and the web server simply sends back the file, and that’s that.
在左侧(蓝色箭头和文本)，我们有部署静态资产的模型。 正如JAMStack支持者所坚持的那样，它们可以部署到CDN，也可以部署到简单的Apache或NGINX服务器。 在这两种情况下，用户的Web浏览器都向Web服务器发出请求，然后Web服务器仅发送回文件，仅此而已。
On the right (with green text and arrows) we have a complex system deployed on cloud hosting infrastructure. A cloud hosting platform like AWS has close to a zillion features, giving technologists lots of things to get excited about. Global scale custom services of the type driving all kinds of websites are possible by configuring and using cloud hosting platforms. It’s a compelling model, because anyone can rent service that can scale from a small deployment to a globe spanning service at the click of a few buttons. But trust me when I say that it is complex to learn, complex to understand, complex to grok how to minimize the costs, complex to manage, etc.
在右侧(带有绿色文本和箭头)，我们在云托管基础架构上部署了一个复杂的系统。 像AWS这样的云托管平台具有近乎无数的功能，使技术人员兴奋不已。 通过配置和使用云托管平台，可以驱动各种类型的网站的全球规模的定制服务。 这是一个引人注目的模型，因为任何人都可以租用只需单击几个按钮即可从小型部署扩展到全球范围服务的服务。 但是，当我说学习复杂，理解复杂，如何降低成本，管理复杂等时，请相信我。
无服务器是消除复杂性的真正方法 (Serverless is the real method for eliminating complexity)
The JAMStack proponents praise CDN deployment, but what they should be praising is the serverless concept.
JAMStack的支持者赞扬CDN的部署，但是他们应该称赞的是无服务器的概念。
There are a lot of hugely complex systems available in today’s computing world. Some kinds of websites require that complexity, because of the intense number of services to manage.
在当今的计算机世界中，有许多非常复杂的系统可用。 由于要管理大量服务，某些类型的网站需要这种复杂性。
To build and maintain a system that works across multiple availability zones, automatically handles service failure, that handles automatic localization and internationalization, and much more, requires multiple teams of highly skilled engineers. Not everyone can afford the cost of hiring such a deep talent base.
要构建和维护可在多个可用区域中工作的系统，自动处理服务故障，处理自动本地化和国际化等，还需要多个由高技能工程师组成的团队。 不是每个人都能负担得起雇用如此深厚的人才库的成本。
The serverless approach offers a different route. The service provider hires the engineering talent required to deploy a cloud based service, and we simply rent their service. Whether it’s a database service, a content distribution service, a cloud functions service, or any other service, we simply use the service providers website to rent the service. The service provider’s engineering team takes care of scaling to meet traffic, multi-zone availability, backups, reliability, and more. Our task is simple — we configure the application stack with service access particulars, and get on with the business of writing application code.
无服务器方法提供了不同的途径。 服务提供商雇用了部署基于云的服务所需的工程技术人才，而我们只是出租他们的服务。 无论是数据库服务，内容分发服务，云功能服务还是任何其他服务，我们都只需使用服务提供商的网站来租用该服务。 服务提供商的工程团队负责扩展以满足流量，多区域可用性，备份，可靠性等方面的需求。 我们的任务很简单-我们使用服务访问详细信息配置应用程序堆栈，然后继续编写应用程序代码。
It’s so simple that an individual (or small team) can:
如此简单，个人(或小团队)可以：
- Create an application using front-end JavaScript 使用前端JavaScript创建应用程序
- Deploy any custom back-end services to functions-as-a-service system 将任何自定义后端服务部署到“功能即服务”系统
- Utilize database-as-a-service 利用数据库即服务
- Utilize other 3rd party cloud services 利用其他第三方云服务
All with no complexity, and the ability to quickly develop/deploy a website or web application. All the complexity is handled by serverless service providers.
所有这些都没有复杂性，并且具有快速开发/部署网站或Web应用程序的能力。 所有复杂性都由无服务器服务提供商处理。
However, not all serverless services are equally simplified. AWS Fargate is billed as a serverless version of AWS ECS or AWS EKS. ECS is an AWS cloud service for hosting Docker containers, and EKS is the AWS service for running Kubernetes. Fargate is serverless in that you do not provision the servers involved in hosting the Docker containers, which does slightly simplify the task of hosting a Docker service. But Fargate is still extremely complex.
但是，并非所有无服务器服务都得到同等简化。 AWS Fargate被定为AWS ECS或AWS EKS的无服务器版本。 ECS是用于托管Docker容器的AWS云服务，而EKS是用于运行Kubernetes的AWS服务。 Fargate是无服务器的 ，因为您无需预配置托管Docker容器所涉及的服务器，这确实简化了托管Docker服务的任务。 但是Fargate仍然非常复杂。
In the next section let’s talk more concretely about JAMStack implementation.
在下一节中，我们将更具体地讨论JAMStack的实现。
这是一个很好的理论，但是真正的JAMStack或静态网站是什么？ (That’s nice theory, but what are JAMStack or static websites for real?)
All of that was rather abstract, so let’s look at some concrete examples of JAMStack.
所有这些都是相当抽象的，因此让我们看一下JAMStack的一些具体示例。
At the simplest, JAMStack is an HTML page, containing JavaScript, where it makes API calls to services, using retrieved data to make changes to the HTML. Let’s take a look at some examples …
最简单的说，JAMStack是一个HTML页面，其中包含JavaScript，它在其中对服务进行API调用，使用检索到的数据对HTML进行更改。 让我们看一些例子……
静态HTML或JAMStack网站上的评论系统 (Commenting systems on static HTML or JAMStack websites)
There were advantages to those dynamic CMS’s. For instance Wordpress and Drupal both integrate a native commenting system, and allow users to register with the website in order to leave comments. It is possible to build a community via a website by allowing your readers to leave comments. Why should we leave that and other features behind?
这些动态CMS具有很多优势。 例如，Wordpress和Drupal都集成了本机评论系统，并允许用户向网站注册以便发表评论。 通过允许您的读者发表评论，可以通过网站建立社区。 我们为什么要抛弃那些功能？
The first step is to render the content of the website using a static website generator. There are many such systems each with different behaviors. In most cases content is written in Markdown and rendered through templates to create the static HTML site.
第一步是使用静态网站生成器呈现网站内容。 有许多这样的系统，每个系统都有不同的行为。 在大多数情况下，内容是用Markdown编写的，并通过模板进行渲染以创建静态HTML网站。
Then, for each page where you want comments, add some JavaScript containing a commenting UI. The JavaScript should be added to the template rather than the Markdown content, to simplify implementing comments across the website. The commenting UI would make calls to a back-end commenting system, and also render a user interface in a given location in the web page. For example:
然后，对于要评论的每个页面，添加一些包含评论UIJavaScript。 应该将JavaScript添加到模板中，而不是Markdown内容中，以简化整个网站中的注释实现。 注释UI会调用后端注释系统，并且还会在网页的给定位置呈现用户界面。 例如：
This is (more or less) the JavaScript provided by Disqus, a large scale commenting service. It handles comments on websites, and has many useful tools for managing spammers and user authentication.
这是(或多或少)由Disqus提供JavaScript，这是一种大规模的评论服务。 它处理网站上的评论，并具有许多用于管理垃圾邮件发送者和用户身份验证的有用工具。
The Disqus UI integrates a number of back-end services. For example users can sign up as a Disqus user without leaving the web page, and it can also authenticate people using 3rd party services like Facebook or Twitter. Once a reader is authenticated, they can leave comments and the comments area is dynamically updated as others leave comments.
Disqus UI集成了许多后端服务。 例如，用户可以在不离开网页的情况下注册为Disqus用户，也可以使用Facebook或Twitter等第三方服务对用户进行身份验证。 读者通过身份验证后，就可以留下评论，并且评论区域会随着其他人留下评论而动态更新。
When I installed Disqus on a Blogger blog, or on a Drupal blog, that was not a JAMStack situation. Simply using a JavaScript UI to a 3rd party service does not make it JAMStack. That Drupal blog is its own complexity. What makes it JAMStack is to use a static website generator so that you’re deploying HTML+CSS+JS.
当我在Blogger博客或Drupal博客上安装Disqus时，这不是JAMStack的情况。 仅仅将JavaScript UI应用于第三方服务并不能使其成为JAMStack。 Drupal博客是其自身的复杂性。 JAMStack的使用在于使用静态网站生成器，以便您部署HTML + CSS + JS。
There are plenty of services like Disqus offering many services. For example, a weather site might offer a widget displaying the current weather for the locale of the visitor. And the embed widgets supplied by Facebook, Twitter, YouTube and other sites, are also examples of JavaScript UI’s that call an API and modify the DOM.
有很多服务，例如Disqus提供许多服务。 例如，一个天气站点可能会提供一个小部件，以显示访问者所在地区的当前天气。 Facebook，Twitter，YouTube和其他站点提供的嵌入窗口小部件也是调用API并修改DOMJavaScript UI的示例。
静态HTML或JAMStack网站中的自定义后端服务 (Custom back-end services in static HTML or JAMStack websites)
Many websites have custom services as well. Not every need fits into what a 3rd party service can provide, after all.
许多网站也提供自定义服务。 毕竟，并非所有需求都适合第三方服务所提供的服务。
To take an example, one of my websites is a proper static HTML site, where one section has a service implemented in old school PHP. The original version of that service was implemented in TCL in 1997, and sometime in the 00’s I rewrote it to simplistic old-CGI-style PHP. Today, the PHP scripts are rendered from templates by AkashaCMS and deployed with the HTML+CSS+JS of that website, but it’s still the old-school PHP.
举个例子，我的一个网站是一个正确的静态HTML网站，其中一个部分提供了使用旧式PHP实现的服务。 该服务的原始版本于1997年在TCL中实现，在00年代的某个时候，我将其重写为简单的老式CGI风格PHP。 今天，PHP脚本是由AkashaCMS从模板呈现的，并与该网站HTML + CSS + JS一起部署，但是它仍然是老式PHP。
That website is therefore not pure static HTML, nor is it a JAMStack site. According to JAMStack proponents, this has complexity and is something to avoid. In this case the PHP implementation requires extra security measures.
因此，该网站不是纯静态HTML，也不是JAMStack网站。 支持JAMStack的人认为，这很复杂，应该避免。 在这种情况下，PHP实现需要额外的安全措施。
There are close to a zillion reasons any given site might have custom dynamic services. Not every need is satisfied by a prebaked third party service. Since the JAMStack approach is not just about performance, but simplicity and security, that leads us to a question: What’s the simplest, highest performance, and most secure way to use a custom dynamic service on a JAMStack site?
任何给定的站点都可能具有自定义动态服务的原因近千亿。 预先烘焙的第三方服务并不能满足所有需求。 由于JAMStack方法不仅与性能有关，而且与简单性和安全性有关，这使我们想到一个问题：在JAMStack站点上使用自定义动态服务的最简单，最高性能和最安全的方法是什么？
My mind turns immediately to a function-as-a-service platform like AWS Lambda, and the promises of scalability, performance, and baked-in security.
我立即想到AWS Lambda这样的功能即服务平台，以及对可扩展性，性能和内置安全性的承诺。
The JAMStack proponents would probably say to implement a custom service as:
JAMStack的支持者可能会说实现自定义服务的方式如下：
- A back-end offering a JSON/REST API 提供JSON / REST API的后端
- A JavaScript UI doing browser-side rendering of HTML for the user interface 一个JavaScript UI，用于在浏览器端呈现HTML的用户界面
It is easy to generate a static bundle for the JavaScript UI for deployment through a CDN. On
为JavaScript UI生成静态捆绑包以通过CDN进行部署很容易。 上
one of my other sites I wrote a tutorial about doing just that with Vue.js. Using Webpack to build the Vue.js application bundle gives a directory containing static assets that can be deployed with the rest of the static website. You then include it in the HTML like so:
在我的另一个网站中，我写了一篇有关使用Vue.js做到这一点的教程。 使用Webpack生成Vue.js应用程序捆绑包将提供一个目录，其中包含可以与静态网站的其余部分一起部署的静态资产。 然后将其包含在HTML中，如下所示：
The JS code at the URL, in this case /dist/build.js, must be written to target the div#app element where it will initialize the application.
URL上的JS代码(在本例中为/dist/build.js )必须编写为以div#app元素为目标，它将在此处初始化应用程序。
搜索引擎索引JavaScript UI的索引 (Search engines indexing JavaScript UI’s)
One thing which stops me from doing this on my site is whether that would be indexable by search engines. The HTML of the corresponding pages would have the JavaScript application, rather than the currently shown information. How will search engines index the information supplied by that service? In many cases, like mine, that information is a big value point of that website and many of the visitors are drawn to the site because of that information.
使我无法在自己的网站上执行此操作的一件事是，搜索引擎是否可以将其编入索引。 相应页面HTML将具有JavaScript应用程序，而不是当前显示的信息。 搜索引擎将如何索引该服务提供的信息？ 在许多情况下，例如我的信息，该信息是该网站的重要价值所在，许多访问者都因为该信息而吸引了该网站。
Over on the JAMStack website is a corresponding issue. Namely, the list of factors that are NOT JAMStack websites includes:
JAMStack网站上的相应问题。 即， 不是 JAMStack网站的因素列表包括：
A single page app that uses isomorphic rendering to build views on the server at runtime.
使用同构渲染在运行时在服务器上构建视图的单页应用程序。
I’m not certain what that phrase means, but it’s clearly talking about server-side rendering. The
我不确定这句话的意思，但显然是在谈论服务器端渲染。 的
Wikipedia page on Isomorphic JavaScript talks about a hybrid situation with both server-side and client-side rendering. Possibly the JAMStack website is saying it is best for all rendering to occur on the client side using data retrieved from servers.
同构JavaScript的Wikipedia页面讨论了服务器端和客户端渲染的混合情况。 JAMStack网站可能会说，最好使用从服务器检索的数据在客户端进行所有渲染。
On that Wikipedia page, there is a discussion of the problem of search engines indexing sites that have client side rendering. Rather, since that page presents Isomorphic Rendering as a good thing, it gives this as one of the benefits:
在该Wikipedia页面上，讨论了搜索引擎索引具有客户端呈现的网站的问题。 相反，由于该页面将同构渲染呈现为一件好事，因此它具有以下优点之一：
More predictable SEO and Site Indexing: In order to index content that JavaScript apps render on client-side, Googlebot must run those JavaScript apps inside a full browser environment and capture the rendered DOM. This involves complex browser compatibility issues. Also, because JavaScript apps can make AJAX requests for further rendering, Googlebot must have a policy that controls apps’ network access. These are why getting your JavaScript app indexed properly by Googlebot is still challenging.
更可预测的SEO和网站索引编制：为了对JavaScript应用程序在客户端呈现的内容编制索引，Googlebot必须在完整的浏览器环境中运行这些JavaScript应用程序并捕获呈现的DOM。 这涉及复杂的浏览器兼容性问题。 另外，由于JavaScript应用程序可以发出AJAX请求以进一步渲染，因此Googlebot必须具有控制应用程序网络访问的策略。 这就是为什么要让Googlebot正确索引JavaScript应用仍然具有挑战性的原因。
Hence, I am justified in my concern about whether this would impact search engine visibility of my site. FWIW Vue.js claims to be indexable by search engines, so I might be overstating the issue.
因此，我有理由担心这是否会影响我网站的搜索引擎可见性。 FWIW Vue.js声称可以被搜索引擎索引，所以我可能夸大了这个问题。
网站作为应用程序 (Websites as applications)
Unlike the sites I normally create, some folks use a website as the location for an application. Some examples are Slack, Discord, Google Mail, Canva, all of which are websites with a small amount of public content, and an area where you access an application. Instead of the primary purpose being presenting written content like this, it is the application.
与我通常创建的网站不同，有些人将网站用作应用程序的位置。 一些示例是Slack，Discord，Google Mail，Canva，它们都是具有少量公共内容的网站，并且是您可以访问应用程序的区域。 并不是像这样呈现书面内容的主要目的，而是应用程序。
Clearly such a site is very similar to what I just described. We’d use a static website generator to build the few normal web pages, plus the page(s) containing the JavaScript user interface. As discussed in the previous section we’d build a code bundle for the JavaScript UI, and deploy it with the static website.
显然，这样的网站与我刚刚描述的非常相似。 我们将使用静态网站生成器来构建一些普通的网页，以及包含JavaScript用户界面的页面。 如上一节所述，我们将为JavaScript UI构建代码包，并将其与静态网站一起部署。
For back-end services, the UI would likely use a variety of 3rd party and custom services. For the custom services you again are recommended to host on a serverless platform in order to keep it simple.
对于后端服务，UI可能会使用各种第三方和自定义服务。 对于自定义服务，再次建议您将其托管在无服务器平台上，以使其保持简单。
Following those recommendations would make this a JAMStack site.
遵循这些建议将使它成为JAMStack网站。
Such a site probably does not desire search engines to index the application. Would a search engine find any indexable anything in a wordprocessor application UI like what we get on Google Docs?
这样的站点可能不希望搜索引擎为应用程序编制索引。 搜索引擎会在字处理器应用程序用户界面中找到任何可索引的内容，就像我们在Google文档中看到的一样吗？
摘要 (Summary)
What we’ve learned is that a JAMStack site is similar to a static HTML website, but with a couple specific requirements. Since the goal is simple system management, JAMStack sites are best hosted on serverless platforms.
我们了解到，JAMStack网站类似于静态HTML网站，但是有一些特定的要求。 由于目标是简单的系统管理，因此JAMStack站点最好托管在无服务器平台上。
Otherwise, JAMStack is little different than what we’ve called static HTML websites for some time. Both involve static bundles of HTML, JavaScript and CSS, with the goal of improving speed and user experience for the folks reading our websites.
否则，JAMStack与一段时间以来我们称为静态HTML网站的内容几乎没有什么不同。 两者都包含静态捆绑HTML，JavaScript和CSS，目的是为阅读我们网站的人们提高速度和用户体验。
But there’s this issue about insisting JAMStack sites/applications must be on a CDN. I fully understand the goal of “ Jamstack projects don’t rely on server-side code” since that eliminates a bottleneck to delivering blistering performance. Clearly the JAMStack website insists on CDN deployment, but is that the only rational choice?
但是存在一个问题，就是要求JAMStack站点/应用程序必须位于CDN上。 我完全理解“ Jamstack项目不依赖服务器端代码 ”的目标，因为这消除了提供出色性能的瓶颈。 显然，JAMStack网站坚持CDN部署，但这是唯一合理的选择吗？
In my experience, for the traffic level I deal with, Apache on a simple shared web hosting provider is sufficient for excellent page load times. One thing the JAMStack site says is:
根据我的经验，对于我所处理的流量级别，简单共享Web托管提供程序上的Apache足以实现出色的页面加载时间。 JAMStack网站说的一件事是：
The thing that they all have in common is that they don’t depend on a web server.
它们的共同点是它们不依赖于Web服务器。
Instead we’re supposed to depend on serverless services, which of course are built from servers. What serverless means is other peoples servers, and the advantage to that is a simplified management experience. That’s what JAMStack means by not depending on a web server.
相反，我们应该依赖无服务器服务，这些服务当然是从服务器构建的。 无服务器意味着其他人的服务器 ，其优点是简化了管理体验。 这就是JAMStack意味着不依赖Web服务器的意思。
I guarantee that with Dreamhost I’m not involved with server management either. I have a half dozen static HTML sites on a simple shared Apache account on Dreamhost, and have zero involvement with managing the server. I simply use rsync to upload the HTML+CSS+JS to the server and everything is hunky dory. I wish the JAMStack site weren’t so stuck on this anti-server stance.
我保证使用Dreamhost也不参与服务器管理。 我在Dreamhost上的一个简单共享Apache帐户上有六个静态HTML站点，并且对服务器的管理几乎没有参与。 我只是简单地使用rsync将HTML + CSS + JS上载到服务器，并且一切都很顺利。 我希望JAMStack网站不会被这种反服务器立场所困扰。
Originally published at https://akashacms.com.
最初发布在 https://akashacms.com 。
静态网站生成器
291
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
