Merge pull request #55 from wpengine/Intro-edits-summit

Intro - Edit grammar

README.md

@@ -6,18 +6,18 @@ If you're new to headless, this is the place to start. If you've created headles
 
 ## What is Headless WordPress?
 
-When we talk about headless with WordPress, we mean using WordPress for content creation but not for front-end rendering. Instead of using traditional WordPress themes, you develop your front-end using a JavaScript framework like React. Also, the front-end is hosted on a separate server from the WordPress instance.
+When we talk about headless with WordPress, we mean using WordPress for content creation but not for front-end rendering. Instead of using traditional WordPress themes, you develop your front-end using a JavaScript framework like React. A separate server hosts the front-end from the WordPress instance.
 
 Since the front-end is responsible for displaying content to the end-user, it needs to access the content. To do that, it utilized the WordPress REST API or GraphQL via [WPGraphQL](https://www.wpgraphql.com/).
 
 ## Why Headless?
 
 Headless is gaining momentum for a few reasons:
 
-- Developer Choice - developers want to use modern frameworks like React to build sites and applications, and headless enables that possibility.
-- Scalability - When you remove the burden of WordPress's rendering, you reduce the load on your WordPress instance, which allows WordPress to scale much more manageable.
-- Security - Removing the responsibility of rendering from WordPress minimizes the surface area for attacks. Now, you can choose only to expose the API to the internet.
-- Integrations - The WordPress community indeed provides many integrations through plugins, but they don't always work well together. When you go headless, you have more control over your integrations, and most services support integrating with JavaScript and Node.js.
+- **Developer Choice** - Developers want to use modern frameworks like React to build sites and applications, and headless enables that possibility.
+- **Scalability** - A headless WordPress site scales more manageably because WordPress does not hold sole responsibility for rendering a site. 
+- **Security** - Removing the responsibility of rendering from WordPress minimizes the surface area for attacks. Now, you can choose only to expose the API to the internet.
+- **Integrations** - The WordPress community provides many integrations through plugins, but those plugins don't always work well together. In a headless instance, you have more control over your integrations because most services support integrating with JavaScript and Node.js.
 
 ## Hosting Your Headless Apps
 
@@ -35,7 +35,7 @@ We call the Node portion of your site an **app**. An app can have _n_ number of
 
 An **app** is a logical container of all of your _environments_ for the Node portion of your site. An app can have multiple _environments_ like production, staging, and development.
 
-Apps are linked to a single GitHub repository (i.e., https://github.com/matt-landers/headless-wpe). Environments link to a branch within the repository of the app. It's up to you to decide which branch relates to which environment. It's common for your _main_ branch to be linked to your production environment.
+Apps link to a single GitHub repository (i.e., https://github.com/matt-landers/headless-wpe). Environments link to a branch within the repository of the app. It's up to you to decide which branch relates to which environment. For example, it's common for your _main_ branch to link to your production environment.
 
 Here's an example configuration for a typical app with a Production and Development environment.
 
@@ -85,8 +85,8 @@ Each **environment** has the following properties:
 - `wp_environment_name` - the name of the WordPress environment (found in the user portal) that you want to link to your Node environment.
 - `env_variables` (optional) - an array of environment variables that you want to be available at build-time and runtime as OS environment variables.
   - In Node, you can access these variables with `process.env`.
-  - Environment variables are useful for storing information needed to build or run your application, like API keys/secrets.
-- `domains` - (optional) If you want to connect a custom domain, you need to configure your domain one of 2 ways.  Custom domains require a `production` environment.
+  - Environment variables help store information needed to build or run your application, like API keys/secrets.
+- `domains` - (optional) If you want to connect a custom domain, you need to configure your domain one of 2 ways. Custom domains require a `production` environment.
   - Root CNAME pointed to `js.wpenginepowered.com`
   - A records with the following IPs:
     - `141.193.213.10`
@@ -96,6 +96,6 @@ Each **environment** has the following properties:
 
 ## Connecting Your WordPress Backend
 
-Each app environment pairs with a WordPress backend. In the [WP Engine User Portal](https://my.wpengine.com), the WordPress equivalent to an _app_ is a _site_. A site has environments just like apps. Each _app environment_ needs to pair with a `_site environment_` via the site's environment id found in the user portal. You make the connection by setting the `wp_environment_name` property for each environment in your app config.
+Each app environment pairs with a WordPress backend. In the [WP Engine User Portal](https://my.wpengine.com), the WordPress equivalent to an _app_ is a _site_. A site has environments just like apps. Therefore, each _app environment_ needs to pair with a `_site environment_` via the site's environment id found in the user portal. You make the connection by setting the `wp_environment_name` property for each environment in your app config.
 
 The `wp_environment_name` property is **required** as it provides the authorization context for the environment, which determines which users have access to modify and deploy the _app environment_.