Replace 'The XDN'

Author: tristanlee85

guides/caching.md

@@ -59,7 +59,7 @@ The `cache` function can be used in the same route as other functions such as `s
 - Value of `accept-encoding` request header
 - Name of the destination when [split testing](./split_testing) is in effect
 
-When [POST and other non-GET/HEAD](#section_caching_responses_for_post_and_other_non_get_head_requests) methods caching is enabled XDN automatically adds the following to the cache key:
+When [POST and other non-GET/HEAD](#section_caching_responses_for_post_and_other_non_get_head_requests) methods caching is enabled, {{ PRODUCT_NAME }} automatically adds the following to the cache key:
 
 - Request HTTP method
 - Request body
@@ -145,7 +145,7 @@ This will automatically add request method and body to the caching key.
 There are a number of limitations in caching of `POST` and similar requests:
 
 1. If the request body is longer than 8,000 bytes, the caching will automatically be turned off.
-2. Since both mutating and non-mutating requests are executed on the same route, there is no way for XDN to distinguish between such operations and the responsibility for never caching the mutating requests lies with you as the developer. The way to avoid caching responses to mutating requests is to inject `private` into `cache-control` of your response (e.g. `res.setHeader('cache-control', 'private')`)
+2. Since both mutating and non-mutating requests are executed on the same route, there is no way for {{ PRODUCT_NAME }} to distinguish between such operations and the responsibility for never caching the mutating requests lies with you as the developer. The way to avoid caching responses to mutating requests is to inject `private` into `cache-control` of your response (e.g. `res.setHeader('cache-control', 'private')`)
 3. Multiple requests are often need to "warm" the cache for non-`GET` requests.
 
 ### Caching Private Responses
@@ -299,7 +299,7 @@ If you have [static prerendering] enabled, the cache will automatically be repop
 
 ## Preserving the cache when deploying a new version of your site
 
-By default, XDN clears your environment edge cache on every time you deploy a new version of your site.
+By default, {{ PRODUCT_NAME }} clears your environment edge cache on every time you deploy a new version of your site.
 
 This behavior can be turned off by editing your [Environment](environment) config and enabling the following option:
 
@@ -312,7 +312,7 @@ After activating that new environment version, future deploys will re-use the ex
 In order to ensure that users who are actively browsing your site do not experience issues during a deployment, developers can
 configure certain client-side assets to be permanently available, even after a new version of the site has been deployed. For example,
 browsers using on an old version of the site may continue to request JavaScript chunks for the old version of the site for some time after a new
-version is deployed. The XDN automatically makes client-side scripts permanently available if you use Next.js, Nuxt.js, Angular, or Sapper.
+version is deployed. {{ PRODUCT_NAME }} automatically makes client-side scripts permanently available if you use Next.js, Nuxt.js, Angular, or Sapper.
 
 If you are using another framework or would like to make sure a particular asset is permanently available, you can do so by setting the `permanent` option in `serveStatic`. For example:
 
@@ -343,11 +343,11 @@ These scripts assume that you have created environments called "production", "st
 ```js
   "scripts": {
     ...
-    "clearcache:dev": "xdn cache-clear --team=myTeam --site=myXDNApp --environment=development --token=$xdn_deploy_token",
-    "clearcache:stage": "xdn cache-clear --team=myTeam --site=myXDNApp --environment=staging --token=$xdn_deploy_token",
-    "clearcache:prod": "xdn cache-clear --team=myTeam --site=myXDNApp --environment=production --token=$xdn_deploy_token",
-    "clearcache:prod:pdps": "xdn cache-clear --team=myTeam --site=myXDNApp --environment=production --surrogate-key=pdp --token=$xdn_deploy_token",
-    "clearcache:prod:plps": "xdn cache-clear --team=myTeam --site=myXDNApp --environment=production --surrogate-key=plp --token=$xdn_deploy_token",
+    "clearcache:dev": "xdn cache-clear --team=myTeam --site=my{{ PRODUCT_NAME }}App --environment=development --token=$xdn_deploy_token",
+    "clearcache:stage": "xdn cache-clear --team=myTeam --site=my{{ PRODUCT_NAME }}App --environment=staging --token=$xdn_deploy_token",
+    "clearcache:prod": "xdn cache-clear --team=myTeam --site=my{{ PRODUCT_NAME }}App --environment=production --token=$xdn_deploy_token",
+    "clearcache:prod:pdps": "xdn cache-clear --team=myTeam --site=my{{ PRODUCT_NAME }}App --environment=production --surrogate-key=pdp --token=$xdn_deploy_token",
+    "clearcache:prod:plps": "xdn cache-clear --team=myTeam --site=my{{ PRODUCT_NAME }}App --environment=production --surrogate-key=plp --token=$xdn_deploy_token",
     ...
   },
 ```

guides/connectors.md

@@ -4,7 +4,7 @@ Connector packages help build and run your app within {{ PRODUCT_NAME }}. When y
 
 ## Writing a connector
 
-An XDN connector consists of four entry points:
+A {{ PRODUCT_NAME }} connector consists of four entry points:
 
 - `init.js` - Called when the user runs `xdn init`, adding resources to the project necessary for deploying on {{ PRODUCT_NAME }}. May also modify existing files with the project.
 - `dev.js` - Called when the user runs `xdn dev` to run their app in development mode.
@@ -106,7 +106,7 @@ export default async function build({ skipFramework }) {
     try {
       await builder.exec('npx sapper build')
     } catch (e) {
-      // this lets the user know that the build error was within their application code, not their XDN router or configuration.
+      // this lets the user know that the build error was within their application code, not their {{ PRODUCT_NAME }} router or configuration.
       throw new FrameworkBuildError('Sapper')
     }
   }
@@ -122,7 +122,7 @@ export default async function build({ skipFramework }) {
 
 ## prod.js
 
-The XDN runs your application in its serverless cloud by proxying requests to your framework's application server, which it expects to be running on a specific port. The prod.js entry point exports a function that is called when a new serverless function is provisioned. It is responsible for starting your app on the provided port so that it can receive requests from {{ PRODUCT_NAME }}.
+{{ PRODUCT_NAME }} runs your application in its serverless cloud by proxying requests to your framework's application server, which it expects to be running on a specific port. The prod.js entry point exports a function that is called when a new serverless function is provisioned. It is responsible for starting your app on the provided port so that it can receive requests from {{ PRODUCT_NAME }}.
 
 _Optional. This entry point is only needed if your app uses server-side rendering or calls the_ [renderWithApp](/docs/api/core/classes/_router_responsewriter_.responsewriter.html#renderwithapp) _method on ResponseWriter._
 

guides/contributing.md

@@ -1,6 +1,6 @@
 # Contributing to developer.moovweb.com
 
-The XDN is all about putting power in the hands of developers and our documentation is no different. The source code for the {{ PRODUCT_NAME }} developer docs (i.e. this site your reading now) is in an open [repository on Github](https://github.com/moovweb-docs/xdn-docs) and we welcome feedback and pull requests. If you've found a typo or a better way to explain something, please submit a pull request or a file issue! Others will likely stumble over the same problem and benefit from your insight.
+{{ PRODUCT_NAME }} is all about putting power in the hands of developers and our documentation is no different. The source code for the {{ PRODUCT_NAME }} developer docs (i.e. this site your reading now) is in an open [repository on Github](https://github.com/moovweb-docs/xdn-docs) and we welcome feedback and pull requests. If you've found a typo or a better way to explain something, please submit a pull request or a file issue! Others will likely stumble over the same problem and benefit from your insight.
 
 ## Running locally
 
@@ -27,7 +27,7 @@ Finally, visit the site in your browser at http://127.0.0.1:3000.
 
 ## Architecture
 
-The XDN docs are a simple Next.js application running on {{ PRODUCT_NAME }} (yes we [dogfood](https://en.wikipedia.org/wiki/Eating_your_own_dog_food)). The content is stored as pages called "guides". Each guide is a Markdown file located in the [guides folder](https://github.com/moovweb-docs/xdn-docs/tree/master/guides) and the [guides.json](https://github.com/moovweb-docs/xdn-docs/blob/master/guides/guides.json) controls the navigation menu for reaching the guides.
+{{ PRODUCT_NAME }} docs are a simple Next.js application running on {{ PRODUCT_NAME }} (yes we [dogfood](https://en.wikipedia.org/wiki/Eating_your_own_dog_food)). The content is stored as pages called "guides". Each guide is a Markdown file located in the [guides folder](https://github.com/moovweb-docs/xdn-docs/tree/master/guides) and the [guides.json](https://github.com/moovweb-docs/xdn-docs/blob/master/guides/guides.json) controls the navigation menu for reaching the guides.
 
 ## How to contribute
 

guides/devtools.md

@@ -1,6 +1,6 @@
 # Devtools
 
-The XDN Devtools is a widget that helps developers understand how their site interacts with {{ PRODUCT_NAME }}, including:
+{{ PRODUCT_NAME }} Devtools is a widget that helps developers understand how their site interacts with {{ PRODUCT_NAME }}, including:
 
 - Edge and browser caching
 - Prefetching

guides/logs.md

@@ -1,6 +1,6 @@
 # Logs
 
-The XDN platform exposes three types of logs to users:
+The {{ PRODUCT_NAME }} platform exposes three types of logs to users:
 
 - [Build logs](#section_build_logs) capture all the build output from your XDN deploys.
 - [Server logs](#section_server_logs) capture your XDN serverless console output at real time.

guides/migration.md

@@ -6,7 +6,7 @@ To upgrade your project to XDN v2, run `xdn use latest`. XDN v2 introduces the f
 
 ### Path syntax change
 
-The syntax for capturing multiple path tokens has been changed from `*variable` to `:variable*`. The XDN now uses [path-to-regexp](https://github.com/pillarjs/path-to-regexp) for route path matching, which is the same library used by express.
+The syntax for capturing multiple path tokens has been changed from `*variable` to `:variable*`. {{ PRODUCT_NAME }} now uses [path-to-regexp](https://github.com/pillarjs/path-to-regexp) for route path matching, which is the same library used by express.
 
 ### Custom cache keys
 

guides/next.md

@@ -165,7 +165,7 @@ Note that if you don't provide a `url` prop to `Prefetch`, you must specify the
 
 ## Routing
 
-The XDN supports Next.js's built-in routing scheme for both page and api routes, including Next.js 9's clean dynamic routes. The default `routes.js` file created by `xdn init` sends all requests to Next.js via a fallback route:
+{{ PRODUCT_NAME }} supports Next.js's built-in routing scheme for both page and api routes, including Next.js 9's clean dynamic routes. The default `routes.js` file created by `xdn init` sends all requests to Next.js via a fallback route:
 
 ```js
 // This file was automatically added by xdn deploy.
@@ -255,7 +255,7 @@ module.exports = new Router()
 
 ### Dynamic Fallback Route
 
-Usually Next.js requires 404.js to be a static page. The XDN enables you to render a specific page when no other route is matched using `router.fallback`:
+Usually Next.js requires 404.js to be a static page. {{ PRODUCT_NAME }} enables you to render a specific page when no other route is matched using `router.fallback`:
 
 ```js
 const { Router } = require('{{ PACKAGE_NAME }}/core/router')

guides/nuxt.md

@@ -147,7 +147,7 @@ Doing so will exclude these modules from your production deployment and keep the
 ## Routing
 
 The next few sections of this guide explain how {{ PRODUCT_NAME }} interacts with Nuxt's routing, which is important if you are migrating an existing application. If you just created a new nuxt app, you can jump to [Running Locally](#section_running_locally) and come back to these sections later.
-The XDN supports Nuxt.js's built-in routing scheme. The default `routes.js` file created by `xdn init` sends all requests to Nuxt.js via a fallback route:
+{{ PRODUCT_NAME }} supports Nuxt.js's built-in routing scheme. The default `routes.js` file created by `xdn init` sends all requests to Nuxt.js via a fallback route:
 
 ```js
 // This file was automatically added by xdn deploy.
@@ -262,11 +262,11 @@ The `Prefetch` component fetches data for the linked page from {{ PRODUCT_NAME }
 
 ## Static Sites
 
-The XDN supports fully and partially static sites using Nuxt [generate](https://nuxtjs.org/docs/2.x/configuration-glossary/configuration-generate). To deploy a static Nuxt site on {{ PRODUCT_NAME }}, simply set `target: 'static'` in `nuxt.config.js` and run `xdn deploy`. This will run `nuxt build` and `nuxt generate` to generate a static version of your site.
+{{ PRODUCT_NAME }} supports fully and partially static sites using Nuxt [generate](https://nuxtjs.org/docs/2.x/configuration-glossary/configuration-generate). To deploy a static Nuxt site on {{ PRODUCT_NAME }}, simply set `target: 'static'` in `nuxt.config.js` and run `xdn deploy`. This will run `nuxt build` and `nuxt generate` to generate a static version of your site.
 
 ### Incremental Static Rendering (ISG)
 
-By default, requests for any pages that are not statically rendered at build time will fall back to server side rendering. If you use the {{ PRODUCT_NAME }} router to cache pages that are not statically rendered, the first user who attempts to access the page will see the fallback HTML page generated by Nuxt (200.html by default). The XDN will render and cache the HTML in the background so that subsequent visits result in a full HTML response. This behavior is similar to Next.js incremental static rendering (ISG). Here is an example route that adds caching for a partially static page:
+By default, requests for any pages that are not statically rendered at build time will fall back to server side rendering. If you use the {{ PRODUCT_NAME }} router to cache pages that are not statically rendered, the first user who attempts to access the page will see the fallback HTML page generated by Nuxt (200.html by default). {{ PRODUCT_NAME }} will render and cache the HTML in the background so that subsequent visits result in a full HTML response. This behavior is similar to Next.js incremental static rendering (ISG). Here is an example route that adds caching for a partially static page:
 
 ```js
 import { Router } from '{{ PACKAGE_NAME }}/core/router'
@@ -278,7 +278,7 @@ export default new Router()
       edge: {
         // Requests for product pages that are not statically generated will fall back to SSR.
         // The first user will see the 200.html loading page generated by Nuxt.
-        // The XDN will render full HTML response in the background and cache it for one hour at the edge.
+        // {{ PRODUCT_NAME }} will render full HTML response in the background and cache it for one hour at the edge.
         // All future requests to the page will result in the full HTML response.
         maxAgeSeconds: 60 * 60 * 24,
         staleWhileRevalidateSeconds: 60 * 60, // continue to serve stale responses from the edge cache while refreshing via SSR in the background
@@ -290,7 +290,7 @@ export default new Router()
 
 ### Rendering a 404 Page
 
-If you set the `fallback` property in the [generate](https://nuxtjs.org/docs/2.x/configuration-glossary/configuration-generate/#fallback) config to `true`, Nuxt.js will generate a 404.html page that will be served whenever the URL does not match a static page. The XDN will send a 404 http status for these URLs. Note that if you set the fallback property to a string, Nuxt will generate a fallback page with that name, and {{ PRODUCT_NAME }} will serve it with a 200 http status when the URL does not match a statically generated page.
+If you set the `fallback` property in the [generate](https://nuxtjs.org/docs/2.x/configuration-glossary/configuration-generate/#fallback) config to `true`, Nuxt.js will generate a 404.html page that will be served whenever the URL does not match a static page. {{ PRODUCT_NAME }} will send a 404 http status for these URLs. Note that if you set the fallback property to a string, Nuxt will generate a fallback page with that name, and {{ PRODUCT_NAME }} will serve it with a 200 http status when the URL does not match a statically generated page.
 
 ## Running Locally
 

guides/overview.md

@@ -66,4 +66,4 @@ export default nextJSApp => {
 
 ## React, Vue, and Angular
 
-{{ PRODUCT_NAME }} supports the most widely used technologies for building progressive web applications. The XDN CLI automatically detects whether you're using [React (Next.js)](next), [Vue (Nuxt.js)](nuxt), or [Angular](angular) and configures your app accordingly so you can publish your app to the cloud in seconds.
+{{ PRODUCT_NAME }} supports the most widely used technologies for building progressive web applications. The {{ PRODUCT_NAME }} CLI automatically detects whether you're using [React (Next.js)](next), [Vue (Nuxt.js)](nuxt), or [Angular](angular) and configures your app accordingly so you can publish your app to the cloud in seconds.

guides/prefetching.md

@@ -1,6 +1,6 @@
 # Prefetching
 
-The XDN allows you to speed up the user's browsing experience by prefetching pages and API calls that they are likely to need.
+{{ PRODUCT_NAME }} allows you to speed up the user's browsing experience by prefetching pages and API calls that they are likely to need.
 
 ![video](https://www.youtube.com/watch?v=lfhSDCNgzfs)
 
@@ -291,7 +291,7 @@ document.addEventListener('DOMContentLoaded', function() {
 
 ## GraphQL
 
-The XDN also enables caching and prefetching of GraphQL requests via a middleware for [Apollo](https://www.apollographql.com/apollo-client). To enable prefetching of GraphQL queries in both the edge and the service worker:
+{{ PRODUCT_NAME }} also enables caching and prefetching of GraphQL requests via a middleware for [Apollo](https://www.apollographql.com/apollo-client). To enable prefetching of GraphQL queries in both the edge and the service worker:
 
 1. Ensure that your GraphQL API is configured to accept GET requests. The Apollo client uses POST requests by default, but the Apollo server [automatically accepts both GETs and POSTs](https://www.apollographql.com/docs/apollo-server/v1/requests/). We use GETs instead of POSTs for two reasons:
 
@@ -336,7 +336,7 @@ module.exports = new Router().get('/graphql', ({ cache, removeUpstreamResponseHe
     },
   })
 
-  // Some APIs, like Shopify, attempt to establish a session by setting a cookie. The XDN will
+  // Some APIs, like Shopify, attempt to establish a session by setting a cookie. {{ PRODUCT_NAME }} will
   // not cache responses with a set-cookie header, so we remove it before attempting to write
   // the response to the cache
   removeUpstreamResponseHeader('set-cookie')