From 59f1389c6023be8ec1435f8f7e55d7de5a302b5b Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Mon, 8 Mar 2021 22:37:08 +0100 Subject: sync translated content --- files/zh-cn/_redirects.txt | 2 + files/zh-cn/_wikihistory.json | 30 +-- .../conflicting/web/api/beacon_api/index.html | 105 +++++++++ .../installing_on_pws_cloud_foundry/index.html | 242 -------------------- .../installing_on_pws_cloud_foundry/index.html | 243 +++++++++++++++++++++ .../api/beacon_api/using_the_beacon_api/index.html | 104 --------- 6 files changed, 365 insertions(+), 361 deletions(-) create mode 100644 files/zh-cn/conflicting/web/api/beacon_api/index.html delete mode 100644 files/zh-cn/learn/server-side/express_nodejs/installing_on_pws_cloud_foundry/index.html create mode 100644 files/zh-cn/orphaned/learn/server-side/express_nodejs/installing_on_pws_cloud_foundry/index.html delete mode 100644 files/zh-cn/web/api/beacon_api/using_the_beacon_api/index.html (limited to 'files/zh-cn') diff --git a/files/zh-cn/_redirects.txt b/files/zh-cn/_redirects.txt index 47924845a6..46943b1804 100644 --- a/files/zh-cn/_redirects.txt +++ b/files/zh-cn/_redirects.txt @@ -1452,6 +1452,7 @@ /zh-CN/docs/Web/API/AudioContext/sampleRate /zh-CN/docs/Web/API/BaseAudioContext/sampleRate /zh-CN/docs/Web/API/AudioContext/state /zh-CN/docs/Web/API/BaseAudioContext/state /zh-CN/docs/Web/API/AudioNode/connect(AudioParam) /zh-CN/docs/orphaned/Web/API/AudioNode/connect(AudioParam) +/zh-CN/docs/Web/API/Beacon_API/Using_the_Beacon_API /zh-CN/docs/conflicting/Web/API/Beacon_API /zh-CN/docs/Web/API/Blob.size /zh-CN/docs/Web/API/Blob/size /zh-CN/docs/Web/API/Blob.slice /zh-CN/docs/Web/API/Blob/slice /zh-CN/docs/Web/API/Blob.type /zh-CN/docs/Web/API/Blob/type @@ -2691,6 +2692,7 @@ /zh-CN/docs/learn/Server-side/Django/主页构建 /zh-CN/docs/Learn/Server-side/Django/Home_page /zh-CN/docs/learn/Server-side/Django/开发环境 /zh-CN/docs/Learn/Server-side/Django/development_environment /zh-CN/docs/learn/Server-side/Django/管理站点 /zh-CN/docs/Learn/Server-side/Django/Admin_site +/zh-CN/docs/learn/Server-side/Express_Nodejs/Installing_on_PWS_Cloud_Foundry /zh-CN/docs/orphaned/learn/Server-side/Express_Nodejs/Installing_on_PWS_Cloud_Foundry /zh-CN/docs/learn/WebGL/By_example /zh-CN/docs/Web/API/WebGL_API/By_example /zh-CN/docs/learn/WebGL/By_example/Basic_scissoring /zh-CN/docs/Web/API/WebGL_API/By_example/Basic_scissoring /zh-CN/docs/learn/WebGL/By_example/Boilerplate_1 /zh-CN/docs/Web/API/WebGL_API/By_example/Boilerplate_1 diff --git a/files/zh-cn/_wikihistory.json b/files/zh-cn/_wikihistory.json index b214171611..31836b726e 100644 --- a/files/zh-cn/_wikihistory.json +++ b/files/zh-cn/_wikihistory.json @@ -6704,14 +6704,6 @@ "c1er" ] }, - "Web/API/Beacon_API/Using_the_Beacon_API": { - "modified": "2020-04-23T03:45:20.732Z", - "contributors": [ - "biqing", - "April421", - "xgqfrms" - ] - }, "Web/API/BeforeInstallPromptEvent": { "modified": "2020-08-04T05:58:35.403Z", "contributors": [ @@ -45032,13 +45024,6 @@ "edgar-chen" ] }, - "learn/Server-side/Express_Nodejs/Installing_on_PWS_Cloud_Foundry": { - "modified": "2020-09-24T11:45:05.090Z", - "contributors": [ - "Mdreame", - "edgar-chen" - ] - }, "learn/Server-side/Express_Nodejs/Introduction": { "modified": "2020-07-16T22:38:13.912Z", "contributors": [ @@ -50798,5 +50783,20 @@ "contributors": [ "Arktische" ] + }, + "orphaned/learn/Server-side/Express_Nodejs/Installing_on_PWS_Cloud_Foundry": { + "modified": "2020-09-24T11:45:05.090Z", + "contributors": [ + "Mdreame", + "edgar-chen" + ] + }, + "conflicting/Web/API/Beacon_API": { + "modified": "2020-04-23T03:45:20.732Z", + "contributors": [ + "biqing", + "April421", + "xgqfrms" + ] } } \ No newline at end of file diff --git a/files/zh-cn/conflicting/web/api/beacon_api/index.html b/files/zh-cn/conflicting/web/api/beacon_api/index.html new file mode 100644 index 0000000000..c208786a53 --- /dev/null +++ b/files/zh-cn/conflicting/web/api/beacon_api/index.html @@ -0,0 +1,105 @@ +--- +title: 使用 Beacon API +slug: conflicting/Web/API/Beacon_API +tags: + - Web 性能 + - 指南 +translation_of: Web/API/Beacon_API/Using_the_Beacon_API +original_slug: Web/API/Beacon_API/Using_the_Beacon_API +--- +
{{DefaultAPISidebar("Beacon")}}{{SeeCompatTable}}
+ +

Beacon 接口用来调度向 Web 服务器发送的异步非阻塞请求。

+ + + +

这篇文档包含了 Beacon 接口的一些例子，可以在 {{domxref("Beacon_API","Beacon API")}} 查阅对应的 API。

+ + + +

Beacon API 的 {{domxref("Navigator.sendBeacon()")}} ，会在全局上下文中向服务器发起一个 beacon 请求。这个方法需要两个参数:  URL 以及要发送的数据 data 。其中 data 参数是可选的，它的类型可以为 {{domxref("ArrayBufferView")}}, {{domxref("Blob")}}, {{domxref("DOMString")}}, 或者 {{domxref("FormData")}}.

+ +

如果浏览器成功地将 beacon 请求加入到待发送的队列里，这个方法将会返回 true ，否则将会返回 false 。

+ +

下面的例子注册了 {{event("load")}} 事件和  {{event("beforeunload")}} 事件的回调函数， 并且在回调函数里面调用了 sendBeacon() 方法。

+ +
window.onload = window.onunload = function analytics(event) {
+  if (!navigator.sendBeacon) return;
+
+  var url = "https://example.com/analytics";
+  // 创建待发送数据
+  var data = "state=" + event.type + "&location=" + location.href;
+
+  // 发送beacon请求
+  var status = navigator.sendBeacon(url, data);
+
+  // 打印数据以及结果
+  console.log("sendBeacon: URL = ", url, "; data = ", data, "; status = ", status);
+};
+
+ +

接下来的例子创建了一个 {{event("submit")}} 事件的回调函数，并且当submit事件触发时，调用 sendBeacon()方法。

+ +
window.onsubmit = function send_analytics() {
+  var data = JSON.stringify({
+    location: location.href,
+    time: Date()
+  });
+
+  navigator.sendBeacon('/analytics', data);
+};
+
+ +

WorkerNavigator.sendBeacon()

+ +

Beacon API 的 {{domxref("WorkerNavigator.sendBeacon()")}} 的使用方法，跟平常的使用方法完全相同，区别仅在与这个方法存在 {{domxref("WorkerGlobalScope","worker 全局作用域")}} 中

+ +

接下来的例子展示了，使用  {{domxref("Worker")}} 发送了一个 beacon 请求，使用了全局上下文的 URL 和数据。

+ +

这是全局上下文的代码片段:

+ +
function worker_send(url, data) {
+  // 创建 worker 对象
+  var myWorker = new Worker("worker-using.js");
+
+  // 向 worker 发送 URL 以及 data
+  myWorker.postMessage([url, data]);
+
+  // 注册回调函数接收来自 worker 的成功或失败信息
+  myWorker.onmessage = function(event) {
+    var msg = event.data;
+    // 打印 worker 的发送状态
+    console.log("Worker reply: sendBeacon() status = " + msg);
+  };
+}
+
+ +

这是 worker 中的代码片段 (worker-using.js):

+ +
onmessage = function(event) {
+  var msg = event.data;
+  // 从 msg 中分离 URL 和 data
+  var url = msg[0];
+  var data = msg[1];
+
+  // 如果浏览器支持在 worker 里面调用 sendBeacon()， 那就发送beacon请求
+  // 否则返回失败信息给全局上下文
+  if (self.navigator.sendBeacon) {
+    var status = self.navigator.sendBeacon(url, data);
+    postMessage(status ? "success" : "fail");
+  } else {
+    postMessage("Worker: self.navigator.sendBeacon is unsupported");
+  }
+}
+
+ +

查看更多

+ + diff --git a/files/zh-cn/learn/server-side/express_nodejs/installing_on_pws_cloud_foundry/index.html b/files/zh-cn/learn/server-side/express_nodejs/installing_on_pws_cloud_foundry/index.html deleted file mode 100644 index e3f321e83a..0000000000 --- a/files/zh-cn/learn/server-side/express_nodejs/installing_on_pws_cloud_foundry/index.html +++ /dev/null @@ -1,242 +0,0 @@ ---- -title: 在 PWS/Cloud Foundry 上，安装 LocalLibrary -slug: learn/Server-side/Express_Nodejs/Installing_on_PWS_Cloud_Foundry -translation_of: Learn/Server-side/Express_Nodejs/Installing_on_PWS_Cloud_Foundry ---- -
{{LearnSidebar}}
- -

本文提供了如何在 Pivotal Web Services PaaS cloud 云上安装 LocalLibrary的实际演示 - 这是 Heroku 的全功能，开源替代品，Heroku 是我们教程第 7 部分中使用的 PaaS 云服务。如果您正在寻找 Heroku（或其他 PaaS 云服务）的替代方案，或者只是想尝试不同的东西，PWS / Cloud Foundry 绝对值得一试。

- -

为什么是 PWS?

- -

Pivotal Web Services 是开源云代工平台的公共实例。它是一个多语言平台，支持许多不同的语言，包括Node.js，Java，PHP，Python，Staticfiles 和 Ruby。它有一个免费试用版，对于运行 Node 应用程序非常有效！由于 Node 和 Express 是开源项目，因此与使用 Cloud Foundry 等开放式部署平台保持一致。您可以深入了解应用程序的托管方式。

- -

使用PWS有多种原因！

- - - -

PWS 是如何工作的？

- -

PWS通过容器来运行网站和应用已经有些年头了。Cloud Foundry一开始采用的容器技术名为Warden，现在使用的是名为Garden的容器系统。这些技术与流行的Docker容器很相似，而且事实上Cloud Foundry云平台的很多设施都支持部署Docker容器。

- -

使用Cloud Foundry云平台的好处之一是您不需要创建容器规范，因为Cloud Foundry的构建包会基于最新的组件来生成它们。由于容器是临时部署的，而且可能随时被清理并部署到云中的其他位置，所以Cloud Foundry云平台上的应用需要遵循十二要素准则。如此可以确保您的应用和平台使用最新的软件。一个应用程序可以包含多个实例，在这些实例中，应用程序被放置到冗余容器中，从而实现应用程序的高可用性。Cloud Foundry会自动处理相同实例之间的所有负载平衡。这允许您扩展应用程序的性能和可用性。

- -

由于文件系统是临时的，所以任何临时存储或服务都应该使用备份服务放置到其他地方。这可以通过使用不同提供商提供的市场服务或通过用户自己提供的服务来实现。

- -

What do we cover below?

- -

This post covers how to modify the LocalLibrary application from the tutorial for deployment on PWS and Cloud Foundry. In doing so, it covers the basics of deploying any node.js application to PWS with the following steps.

- - - -

So let's get started. You have two options, you can go through the tutorial from the beginning or you can just download the completed project and modify it from there for use on PWS. To do the latter, you can do the following from a terminal:

- -
git clone https://github.com/mdn/express-locallibrary-tutorial
- -

You'll then need to follow the preparation steps listed in the Getting your website ready to publish section of Express Tutorial Part 7: Deploying to production, before then following the steps listed below.

- -
-

Note: This work flow is based on the Mozilla Heroku work flow in the main Express/Node tutorial series for consistency, to help readers compare and contrast. 

-
- -

Modifying the LocalLibrary for PWS

- -

Deployment of a Node application on Cloud Foundry takes the following steps. Using the downloaded 'cf' CLI tool on your environment, your source code and supporting metadata files are uploaded to Cloud Foundry which will assemble and package the components of your application. Note that your files need to be located on your system to deploy or as a zip archive somewhere accessible on the internet. We'll assume the former.

- -

This means, no assumptions about which source control system is used. As long as you have a complete source tree in your local file system you can deploy the app. There are some things you have to make available to ensure the correctly assembly of your Node application. First Cloud Foundry cf CLI will look for the presence of the 'package.json' file to determine the dependencies and download the necessary components. The rules of this assembly are defined in Cloud Foundry's nodejs buildpack. An optional cloud foundry manifest file can specify information about your application such as name, size and start command if non-standard. In addition to deploying the application, the cf CLI tool can also configure services, set environment variables and view logs. That's all the overview you need in order to get started (see Getting Started on Pivotal Web Services for a more comprehensive guide). Let's start making the changes so you'll need to deploy the LocalLibrary application to  PWS.

- -

Set node version

- -

The package.json contains everything needed to work out your application dependencies and what file should be launched to start your site. Cloud Foundry and PWS detects the presence of this file, and will use it to provision your app environment. The only useful information missing in our current package.json is the version of node. We can find the version of node we're using for development by entering the command:

- -
node --version
-# will return version e.g. v6.10.3
- -

Open package.json with a text editor, and add this information as an engines > node section as shown (using the version number retrieved above).

- -
{
-  "name": "express-locallibrary-tutorial",
-  "version": "0.0.0",
-  "engines": {
-    "node": "6.10.3"
-  },
-  "private": true,
-  ...
-
- -

Database configuration

- -

So far in this tutorial we've used a single database that is hard coded into the app.js file. Normally we'd like to be able to have a different database for production and development, so next we'll modify the LocalLibrary website to get the database URI from the OS environment, and otherwise use our development database that we added manually earlier. Cloud Foundry has a very flexible services model that enables multiple services of the same type to exist in the environment. It stores all services related configurations in a single parseable JSON object called VCAP_SERVICES. A typical VCAP_SERVICES variable looks like this:

- -
{
- "VCAP_SERVICES": {
-  "mlab": [
-   {
-    "credentials": {
-     "uri": "mongodb://CloudFoundry_test_dev:somecr8zypassw0rd@dbhost.mlab.com:57971/CloudFoundry_dbname"
-    },
-    "label": "mlab",
-    "name": "node-express-tutorial-mongodb",
-    "plan": "sandbox",
-    "provider": null,
-    "syslog_drain_url": null,
-    "tags": [
-     "Cloud Databases",
-     "Developer Tools",
-     "Web-based",
-     "Data Store",
-    ],
-    "volume_mounts": []
-   }
-  ]
- }
-}
-
-
- -

Writing the code to extract and parse this environment variable is not hard, but it doesn't add a lot of value when others have written libraries to do this. In this case, there is a node.js package we can use called cfenv.

- -

This will download the cfenv module and its dependencies, and modify the package.json file as required. Open app.js and find the block with all the 'requires' that load the modules into your application. In this example look for the line that looks something like this:

- -
var expressValidator = require('express-validator');
- -

If you cannot find that exact line, look for the blocks of 'requires' and look for the last one. Add the following text after it:

- -
var cfenv = require('cfenv');
- -
    -
  1. -

    To install the package, go to your terminal and make sure you are in the directory where the package.json file for LocalLibrary is. From the command line, type:

    - - 
    npm install cfenv
    -
    2. -
  2. -

    Now that you have loaded the module, this next line will instantiate an object that will contain the app and services information required for deployment. Add the following after the line that contains app.use(helmet());

    - - 
    // Set up CF environment variables
-var appEnv = cfenv.getAppEnv();
-
    - -

    When this line executes, all the Cloud Foundry application environment information will become available to the application in the appEnv object.

    -
    3. -
  3. -

    Now it is time to update the application to use the database configured by the platform. Find the line that sets the mongoDB connection variable. It will look something like this:

    - - 
    var mongoDB = process.env.MONGODB_URI || dev_db_url;
    -
    4. -
  4. -

    You will now modify the line with the following code  appEnv.getServiceURL('node-express-tutorial-mongodb') to get the connection string from an environment variable that is being managed by the cfenv  module. If no service has been created and bound it will use your own database URL you created as part of the tutorial instead of the one from the environment. So replace the line above with the following:

    - - 
    var mongoDB = appEnv.getServiceURL('node-express-tutorial-mongodb') || dev_db_url;
-
    -
    5. -
  5. -

    Now run the site locally (see Testing the routes for the relevant commands) and check that the site still behaves as you expect. At this point your app is ready to use with Cloud Foundry and Pivotal Web Services.

    -
    6. -
- -

Get a Pivotal Web Services account

- -

To start using Pivotal Web Services you will first need to create an account (skip ahead to Create and upload the website if you've already got an account and have already installed the PWS cf CLI client).

- - - -

Install the cf CLI client

- -

The cf CLI client is a software tool for managing and deploying your application. Download and install the PWS cf CLI client by following the instructions on Pivotal Web Services or downloading directly from GIthub. Be sure to download the correct version for your computer. After the client is installed you will be able run commands, for example to get help on the client:

- -
cf help
-
- -

We'll now go through the steps to login to PWS using the CLI and deploy — or in Cloud Foundry parlance "push" your app.

- -

Create and upload the website

- -

To create the app we navigate to the directory where our modified files are. This is the same directory where the LocalLibrary package.json file is located. First, let's tell the cf CLI which Cloud Foundry instance you want to use. We need to do this, since the cf CLI tool can be used with any standard Cloud Foundry system, so this command indicates which specific Cloud Foundry you are using. Enter the following terminal command now:

- -
cf api api.run.pivotal.io
- -

Next login using the following command (enter your email and password when prompted):

- -
cf login
-Email: enter your email
-Password: enter your password
- -

We can now push our app to PWS. In the below example. replace 'some-unique-name' with something you can remember that is likely to be unique. If it isn't unique, the system will let you know. The reason this name has to be unique to the PWS system is it is the address we will use to to access your LocalLibrary application. I used mozilla-express-tutorial-xyzzy. You should use something else.

- -
cf push some-unique-name -m 256MB
- -

Note the -m flag we added is not required. We just included it so that we only use 256MB of memory to run the app. Node apps typically can run in 128 MB, but we are being safe. If we didn't specify the memory, the CLI would use the default 1 GB of memory, but we want to make sure your trial lasts longer. You should now see a bunch of text on the screen. It will indicate that the CLI is uploading all your files, that it's using the node buildpack, and it will start the app. If we're lucky, the app is now "running" on the site at the URL https://some-unique-name.cfapps.io. Open your browser and run the new website by going to that URL.

- -
Note: The site will be running using our hardcoded development database at this time. Create some books and other objects, and check out whether the site is behaving as you expect. In the next section we'll set it to use our new database.
- -

Setting configuration variables

- -

You will recall from a preceding section that we need to set NODE_ENV to 'production' in order to improve our performance and generate less-verbose error messages.

- -
    -
  1. -

    Do this by entering the following command:

    - - 
    cf set-env some-unique-name NODE_ENV production
-
    -
    2. -
  2. -

    We should also use a separate database for production. Cloud Foundry can take advantage of a marketplace to create a new service and automatically bind it to your app. Bind means place the service database credentials in the environment variable space of the container running your application for you to access. Enter the following commands:

    - - 
    cf create-service mlab sandbox node-express-tutorial-mongodb
-cf bind-service some-unique-name node-express-tutorial-mongodb
-
    -
    3. -
  3. -

    You can inspect your configuration variables at any time using the cf env some-unique-name command — try this now:

    - - 
    cf env some-unique-name
-
    -
    4. -
  4. -

    In order for your applications to use the new credentials you will have to restage your application, meaning that it will restart and apply the new environment variables. This can be done using the following — enter this command now:

    - - 
    cf restage some-unique-name
-
    -
    5. -
  5. -

    If you check the home page now it should show zero values for your object counts, as the changes above mean that we're now using a new (empty) database.

    -
    6. -
- -

Debugging

- -

The PWS cf client provides a few tools for debugging:

- -
>cf logs some-unique-name --recent  # Show current logs
->cf logs some-unique-name # Show current logs and keep updating with any new results
- -

Summary

- -

If you followed the above steps, you should have now deployed the LocalLibrary app to PWS. Well done! If the deployment wasn't successful, double check all the steps.

diff --git a/files/zh-cn/orphaned/learn/server-side/express_nodejs/installing_on_pws_cloud_foundry/index.html b/files/zh-cn/orphaned/learn/server-side/express_nodejs/installing_on_pws_cloud_foundry/index.html new file mode 100644 index 0000000000..125d31931d --- /dev/null +++ b/files/zh-cn/orphaned/learn/server-side/express_nodejs/installing_on_pws_cloud_foundry/index.html @@ -0,0 +1,243 @@ +--- +title: 在 PWS/Cloud Foundry 上，安装 LocalLibrary +slug: orphaned/learn/Server-side/Express_Nodejs/Installing_on_PWS_Cloud_Foundry +translation_of: Learn/Server-side/Express_Nodejs/Installing_on_PWS_Cloud_Foundry +original_slug: learn/Server-side/Express_Nodejs/Installing_on_PWS_Cloud_Foundry +--- +
{{LearnSidebar}}
+ +

本文提供了如何在 Pivotal Web Services PaaS cloud 云上安装 LocalLibrary的实际演示 - 这是 Heroku 的全功能，开源替代品，Heroku 是我们教程第 7 部分中使用的 PaaS 云服务。如果您正在寻找 Heroku（或其他 PaaS 云服务）的替代方案，或者只是想尝试不同的东西，PWS / Cloud Foundry 绝对值得一试。

+ +

为什么是 PWS?

+ +

Pivotal Web Services 是开源云代工平台的公共实例。它是一个多语言平台，支持许多不同的语言，包括Node.js，Java，PHP，Python，Staticfiles 和 Ruby。它有一个免费试用版，对于运行 Node 应用程序非常有效！由于 Node 和 Express 是开源项目，因此与使用 Cloud Foundry 等开放式部署平台保持一致。您可以深入了解应用程序的托管方式。

+ +

使用PWS有多种原因！

+ + + +

PWS 是如何工作的？

+ +

PWS通过容器来运行网站和应用已经有些年头了。Cloud Foundry一开始采用的容器技术名为Warden，现在使用的是名为Garden的容器系统。这些技术与流行的Docker容器很相似，而且事实上Cloud Foundry云平台的很多设施都支持部署Docker容器。

+ +

使用Cloud Foundry云平台的好处之一是您不需要创建容器规范，因为Cloud Foundry的构建包会基于最新的组件来生成它们。由于容器是临时部署的，而且可能随时被清理并部署到云中的其他位置，所以Cloud Foundry云平台上的应用需要遵循十二要素准则。如此可以确保您的应用和平台使用最新的软件。一个应用程序可以包含多个实例，在这些实例中，应用程序被放置到冗余容器中，从而实现应用程序的高可用性。Cloud Foundry会自动处理相同实例之间的所有负载平衡。这允许您扩展应用程序的性能和可用性。

+ +

由于文件系统是临时的，所以任何临时存储或服务都应该使用备份服务放置到其他地方。这可以通过使用不同提供商提供的市场服务或通过用户自己提供的服务来实现。

+ +

What do we cover below?

+ +

This post covers how to modify the LocalLibrary application from the tutorial for deployment on PWS and Cloud Foundry. In doing so, it covers the basics of deploying any node.js application to PWS with the following steps.

+ + + +

So let's get started. You have two options, you can go through the tutorial from the beginning or you can just download the completed project and modify it from there for use on PWS. To do the latter, you can do the following from a terminal:

+ +
git clone https://github.com/mdn/express-locallibrary-tutorial
+ +

You'll then need to follow the preparation steps listed in the Getting your website ready to publish section of Express Tutorial Part 7: Deploying to production, before then following the steps listed below.

+ +
+

Note: This work flow is based on the Mozilla Heroku work flow in the main Express/Node tutorial series for consistency, to help readers compare and contrast. 

+
+ +

Modifying the LocalLibrary for PWS

+ +

Deployment of a Node application on Cloud Foundry takes the following steps. Using the downloaded 'cf' CLI tool on your environment, your source code and supporting metadata files are uploaded to Cloud Foundry which will assemble and package the components of your application. Note that your files need to be located on your system to deploy or as a zip archive somewhere accessible on the internet. We'll assume the former.

+ +

This means, no assumptions about which source control system is used. As long as you have a complete source tree in your local file system you can deploy the app. There are some things you have to make available to ensure the correctly assembly of your Node application. First Cloud Foundry cf CLI will look for the presence of the 'package.json' file to determine the dependencies and download the necessary components. The rules of this assembly are defined in Cloud Foundry's nodejs buildpack. An optional cloud foundry manifest file can specify information about your application such as name, size and start command if non-standard. In addition to deploying the application, the cf CLI tool can also configure services, set environment variables and view logs. That's all the overview you need in order to get started (see Getting Started on Pivotal Web Services for a more comprehensive guide). Let's start making the changes so you'll need to deploy the LocalLibrary application to  PWS.

+ +

Set node version

+ +

The package.json contains everything needed to work out your application dependencies and what file should be launched to start your site. Cloud Foundry and PWS detects the presence of this file, and will use it to provision your app environment. The only useful information missing in our current package.json is the version of node. We can find the version of node we're using for development by entering the command:

+ +
node --version
+# will return version e.g. v6.10.3
+ +

Open package.json with a text editor, and add this information as an engines > node section as shown (using the version number retrieved above).

+ +
{
+  "name": "express-locallibrary-tutorial",
+  "version": "0.0.0",
+  "engines": {
+    "node": "6.10.3"
+  },
+  "private": true,
+  ...
+
+ +

Database configuration

+ +

So far in this tutorial we've used a single database that is hard coded into the app.js file. Normally we'd like to be able to have a different database for production and development, so next we'll modify the LocalLibrary website to get the database URI from the OS environment, and otherwise use our development database that we added manually earlier. Cloud Foundry has a very flexible services model that enables multiple services of the same type to exist in the environment. It stores all services related configurations in a single parseable JSON object called VCAP_SERVICES. A typical VCAP_SERVICES variable looks like this:

+ +
{
+ "VCAP_SERVICES": {
+  "mlab": [
+   {
+    "credentials": {
+     "uri": "mongodb://CloudFoundry_test_dev:somecr8zypassw0rd@dbhost.mlab.com:57971/CloudFoundry_dbname"
+    },
+    "label": "mlab",
+    "name": "node-express-tutorial-mongodb",
+    "plan": "sandbox",
+    "provider": null,
+    "syslog_drain_url": null,
+    "tags": [
+     "Cloud Databases",
+     "Developer Tools",
+     "Web-based",
+     "Data Store",
+    ],
+    "volume_mounts": []
+   }
+  ]
+ }
+}
+
+
+ +

Writing the code to extract and parse this environment variable is not hard, but it doesn't add a lot of value when others have written libraries to do this. In this case, there is a node.js package we can use called cfenv.

+ +

This will download the cfenv module and its dependencies, and modify the package.json file as required. Open app.js and find the block with all the 'requires' that load the modules into your application. In this example look for the line that looks something like this:

+ +
var expressValidator = require('express-validator');
+ +

If you cannot find that exact line, look for the blocks of 'requires' and look for the last one. Add the following text after it:

+ +
var cfenv = require('cfenv');
+ +
    +
  1. +

    To install the package, go to your terminal and make sure you are in the directory where the package.json file for LocalLibrary is. From the command line, type:

    + + 
    npm install cfenv
    +
    2. +
  2. +

    Now that you have loaded the module, this next line will instantiate an object that will contain the app and services information required for deployment. Add the following after the line that contains app.use(helmet());

    + + 
    // Set up CF environment variables
+var appEnv = cfenv.getAppEnv();
+
    + +

    When this line executes, all the Cloud Foundry application environment information will become available to the application in the appEnv object.

    +
    3. +
  3. +

    Now it is time to update the application to use the database configured by the platform. Find the line that sets the mongoDB connection variable. It will look something like this:

    + + 
    var mongoDB = process.env.MONGODB_URI || dev_db_url;
    +
    4. +
  4. +

    You will now modify the line with the following code  appEnv.getServiceURL('node-express-tutorial-mongodb') to get the connection string from an environment variable that is being managed by the cfenv  module. If no service has been created and bound it will use your own database URL you created as part of the tutorial instead of the one from the environment. So replace the line above with the following:

    + + 
    var mongoDB = appEnv.getServiceURL('node-express-tutorial-mongodb') || dev_db_url;
+
    +
    5. +
  5. +

    Now run the site locally (see Testing the routes for the relevant commands) and check that the site still behaves as you expect. At this point your app is ready to use with Cloud Foundry and Pivotal Web Services.

    +
    6. +
+ +

Get a Pivotal Web Services account

+ +

To start using Pivotal Web Services you will first need to create an account (skip ahead to Create and upload the website if you've already got an account and have already installed the PWS cf CLI client).

+ + + +

Install the cf CLI client

+ +

The cf CLI client is a software tool for managing and deploying your application. Download and install the PWS cf CLI client by following the instructions on Pivotal Web Services or downloading directly from GIthub. Be sure to download the correct version for your computer. After the client is installed you will be able run commands, for example to get help on the client:

+ +
cf help
+
+ +

We'll now go through the steps to login to PWS using the CLI and deploy — or in Cloud Foundry parlance "push" your app.

+ +

Create and upload the website

+ +

To create the app we navigate to the directory where our modified files are. This is the same directory where the LocalLibrary package.json file is located. First, let's tell the cf CLI which Cloud Foundry instance you want to use. We need to do this, since the cf CLI tool can be used with any standard Cloud Foundry system, so this command indicates which specific Cloud Foundry you are using. Enter the following terminal command now:

+ +
cf api api.run.pivotal.io
+ +

Next login using the following command (enter your email and password when prompted):

+ +
cf login
+Email: enter your email
+Password: enter your password
+ +

We can now push our app to PWS. In the below example. replace 'some-unique-name' with something you can remember that is likely to be unique. If it isn't unique, the system will let you know. The reason this name has to be unique to the PWS system is it is the address we will use to to access your LocalLibrary application. I used mozilla-express-tutorial-xyzzy. You should use something else.

+ +
cf push some-unique-name -m 256MB
+ +

Note the -m flag we added is not required. We just included it so that we only use 256MB of memory to run the app. Node apps typically can run in 128 MB, but we are being safe. If we didn't specify the memory, the CLI would use the default 1 GB of memory, but we want to make sure your trial lasts longer. You should now see a bunch of text on the screen. It will indicate that the CLI is uploading all your files, that it's using the node buildpack, and it will start the app. If we're lucky, the app is now "running" on the site at the URL https://some-unique-name.cfapps.io. Open your browser and run the new website by going to that URL.

+ +
Note: The site will be running using our hardcoded development database at this time. Create some books and other objects, and check out whether the site is behaving as you expect. In the next section we'll set it to use our new database.
+ +

Setting configuration variables

+ +

You will recall from a preceding section that we need to set NODE_ENV to 'production' in order to improve our performance and generate less-verbose error messages.

+ +
    +
  1. +

    Do this by entering the following command:

    + + 
    cf set-env some-unique-name NODE_ENV production
+
    +
    2. +
  2. +

    We should also use a separate database for production. Cloud Foundry can take advantage of a marketplace to create a new service and automatically bind it to your app. Bind means place the service database credentials in the environment variable space of the container running your application for you to access. Enter the following commands:

    + + 
    cf create-service mlab sandbox node-express-tutorial-mongodb
+cf bind-service some-unique-name node-express-tutorial-mongodb
+
    +
    3. +
  3. +

    You can inspect your configuration variables at any time using the cf env some-unique-name command — try this now:

    + + 
    cf env some-unique-name
+
    +
    4. +
  4. +

    In order for your applications to use the new credentials you will have to restage your application, meaning that it will restart and apply the new environment variables. This can be done using the following — enter this command now:

    + + 
    cf restage some-unique-name
+
    +
    5. +
  5. +

    If you check the home page now it should show zero values for your object counts, as the changes above mean that we're now using a new (empty) database.

    +
    6. +
+ +

Debugging

+ +

The PWS cf client provides a few tools for debugging:

+ +
>cf logs some-unique-name --recent  # Show current logs
+>cf logs some-unique-name # Show current logs and keep updating with any new results
+ +

Summary

+ +

If you followed the above steps, you should have now deployed the LocalLibrary app to PWS. Well done! If the deployment wasn't successful, double check all the steps.

diff --git a/files/zh-cn/web/api/beacon_api/using_the_beacon_api/index.html b/files/zh-cn/web/api/beacon_api/using_the_beacon_api/index.html deleted file mode 100644 index c65861c7cd..0000000000 --- a/files/zh-cn/web/api/beacon_api/using_the_beacon_api/index.html +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: 使用 Beacon API -slug: Web/API/Beacon_API/Using_the_Beacon_API -tags: - - Web 性能 - - 指南 -translation_of: Web/API/Beacon_API/Using_the_Beacon_API ---- -
{{DefaultAPISidebar("Beacon")}}{{SeeCompatTable}}
- -

Beacon 接口用来调度向 Web 服务器发送的异步非阻塞请求。

- - - -

这篇文档包含了 Beacon 接口的一些例子，可以在 {{domxref("Beacon_API","Beacon API")}} 查阅对应的 API。

- - - -

Beacon API 的 {{domxref("Navigator.sendBeacon()")}} ，会在全局上下文中向服务器发起一个 beacon 请求。这个方法需要两个参数:  URL 以及要发送的数据 data 。其中 data 参数是可选的，它的类型可以为 {{domxref("ArrayBufferView")}}, {{domxref("Blob")}}, {{domxref("DOMString")}}, 或者 {{domxref("FormData")}}.

- -

如果浏览器成功地将 beacon 请求加入到待发送的队列里，这个方法将会返回 true ，否则将会返回 false 。

- -

下面的例子注册了 {{event("load")}} 事件和  {{event("beforeunload")}} 事件的回调函数， 并且在回调函数里面调用了 sendBeacon() 方法。

- -
window.onload = window.onunload = function analytics(event) {
-  if (!navigator.sendBeacon) return;
-
-  var url = "https://example.com/analytics";
-  // 创建待发送数据
-  var data = "state=" + event.type + "&location=" + location.href;
-
-  // 发送beacon请求
-  var status = navigator.sendBeacon(url, data);
-
-  // 打印数据以及结果
-  console.log("sendBeacon: URL = ", url, "; data = ", data, "; status = ", status);
-};
-
- -

接下来的例子创建了一个 {{event("submit")}} 事件的回调函数，并且当submit事件触发时，调用 sendBeacon()方法。

- -
window.onsubmit = function send_analytics() {
-  var data = JSON.stringify({
-    location: location.href,
-    time: Date()
-  });
-
-  navigator.sendBeacon('/analytics', data);
-};
-
- -

WorkerNavigator.sendBeacon()

- -

Beacon API 的 {{domxref("WorkerNavigator.sendBeacon()")}} 的使用方法，跟平常的使用方法完全相同，区别仅在与这个方法存在 {{domxref("WorkerGlobalScope","worker 全局作用域")}} 中

- -

接下来的例子展示了，使用  {{domxref("Worker")}} 发送了一个 beacon 请求，使用了全局上下文的 URL 和数据。

- -

这是全局上下文的代码片段:

- -
function worker_send(url, data) {
-  // 创建 worker 对象
-  var myWorker = new Worker("worker-using.js");
-
-  // 向 worker 发送 URL 以及 data
-  myWorker.postMessage([url, data]);
-
-  // 注册回调函数接收来自 worker 的成功或失败信息
-  myWorker.onmessage = function(event) {
-    var msg = event.data;
-    // 打印 worker 的发送状态
-    console.log("Worker reply: sendBeacon() status = " + msg);
-  };
-}
-
- -

这是 worker 中的代码片段 (worker-using.js):

- -
onmessage = function(event) {
-  var msg = event.data;
-  // 从 msg 中分离 URL 和 data
-  var url = msg[0];
-  var data = msg[1];
-
-  // 如果浏览器支持在 worker 里面调用 sendBeacon()， 那就发送beacon请求
-  // 否则返回失败信息给全局上下文
-  if (self.navigator.sendBeacon) {
-    var status = self.navigator.sendBeacon(url, data);
-    postMessage(status ? "success" : "fail");
-  } else {
-    postMessage("Worker: self.navigator.sendBeacon is unsupported");
-  }
-}
-
- -

查看更多

- - -- cgit v1.2.3-54-g00ecf