more and more edits based on feedback

Author: i8ramin

_drafts/wework-com-is-going-static.markdown

@@ -16,9 +16,9 @@ for it, check out this graph from [Google Trends for "static site generator"][2]
 [1]: http://res.cloudinary.com/wework/image/upload/f_auto/v1448735896/engineering/static-site-generator.png
 [2]: https://www.google.com/trends/explore#q=static%20site%20generator
 
-The idea is actually quite simple. Whereas on a traditional *dynamic* site, each page is processed and generated on the server per request (let's ignore caching strategies for the sake of argument), a static site is processed and generated just **once** on each deploy and all the server has to do is serve up the resulting generated HTML. Of course, this is an overly simplified explanation of how it all works, and this process doesn't work as well on all sites, but it does work really well for marketing and informational sites like [wework.com](https://www.wework.com). Not to mention that this very blog you are reading is actually a statically generated site using [Jekyll](http://jekyllrb.com/) and hosted on [Github pages](https://pages.github.com/)!
+The idea is actually quite simple. On a traditional *dynamic* site, each page is processed and generated on the server per request (let's ignore caching strategies for the sake of argument.) A static site, on the other hand, is processed and generated just **once** on each deploy and all the server has to do is serve up the resulting generated HTML. Of course, this is an overly simplified explanation of how it all works, and this process doesn't work as well on all sites, but it does work really well for marketing and informational sites like [wework.com](https://www.wework.com). Not to mention that this very blog you are reading is a statically generated site using [Jekyll](http://jekyllrb.com/) and hosted on [Github pages](https://pages.github.com/)!
 
-If you consider the amount of information that changes on a daily, or even weekly basis on a site like wework.com, it is actually quite wasteful to have a server process each and every request that comes through. One of the main reasons we even have a server-side component for wework.com is to allow us to easily add, update and manage information on the site. We can still achieve this with a statically generated site by utilizing an API to serve up the data and take the load off of our application server for serving up the html pages themselves.
+If you consider the amount of information that changes on a daily, or even weekly basis on a site like wework.com, it is actually quite wasteful to have a server process each and every request that comes through. One of the main reasons we even have a server-side component for wework.com is to allow us to easily add, update and manage information on the site.
 
 
 ### Roots: The static / dynamic hybrid approach
@@ -32,7 +32,7 @@ extensions: [
   records(
     marketsByCountry: {
       url:
-        path: "#{process.env.DUBS_API}/api/to/locations/data"
+        path: "#{process.env.API_ENDPOINT}/api/to/locations/data"
     }
   )
 ]
@@ -55,7 +55,7 @@ extensions: [
   records(
     marketsByCountry: {
       url:
-        path: "#{process.env.DUBS_API}/api/to/locations/data"
+        path: "#{process.env.API_ENDPOINT}/api/to/locations/data"
       template: "views/_location.jade"
       out: (location) -> "/locations/#{location.market.slug}/#{location.slug}"
     }
@@ -70,7 +70,7 @@ One of the biggest challenges of this whole process has been to figure out a way
 
 We needed a way to move things over piecemeal. One page at a time. This meant that we couldn't move wework.com to a new static host all at once, but at the same time, we needed some URL's to serve up the old content, and some URL's to serve up the new static pages. One way to do this is via a [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy).
 
-There are many different ways to skin this cat. You can install and configure your own Apache or Ngnix server. You can use something like [`rack-reverse-proxy`](https://github.com/jaswope/rack-reverse-proxy) or a slew of other similar solutions. There are pros and cons to each approach. For us, being a team of web developers, we wanted to spend our time focusing on our KPI's and optimizing our pages for performance, and not on setting up and managing servers. We had a few requirements. Specifically, we were looking for a host that could:
+There are many different ways to skin this cat, ranging from installing and configuring your own Apache or Ngnix server, using something like rack-reverse-proxy to a slew of other similar solutions, each with their own pros and cons. For us, being a team of web developers, we wanted to spend our time focusing on our KPI's and optimizing our pages for performance, and not on setting up and managing servers. We had a few requirements. Specifically, we were looking for a host that could:
 
 - House our new static site and scale with us
 - Have an API and webhooks so we can trigger builds when content changes
@@ -91,11 +91,11 @@ So how are we serving up traffic to `wework.com/locations/` from the static host
 extensions: [
   netlify
     rewrites:
-      '/':  dubsUrl
-      '/*':  dubsUrl + '/:splat'
+      '/':  originUrl
+      '/*':  originUrl + '/:splat'
 ```
 
-Which basically says, route all traffic through to `dubsUrl`, which is defined further up using `ENV` variables. We never have to touch this rule, and as soon as we added the `/locations/index.html` resource to our static site, Netlify was smart enough to serve that page vs proxying it through.
+Which basically says, route all traffic through to `originUrl`, which is defined further up using `ENV` variables. We never have to touch this rule, and as soon as we added the `/locations/index.html` resource to our static site, Netlify was smart enough to serve that page vs proxying it through.
 
 
 The reality is that we are currently maintaining two versions of our site as we move things over, but this allows us to continue doing business as usual, make updates to existing pages and not have to stop our normal workflow as we migrate things over little by little. What's great about all of this is that we are sharing the same data across both sites.