eddiit

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

@@ -16,9 +16,7 @@ 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. 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.
+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.) If you consider the amount of information that changes on a daily, or even weekly basis on a site like [wework.com](https://www.wework.com), it is actually quite wasteful to have a server process each and every request that comes through. 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).
 
 
 ### Roots: The static / dynamic hybrid approach
@@ -68,27 +66,27 @@ extensions: [
 
 One of the biggest challenges of this whole process has been to figure out a way to slowly migrate our site over from a dynamic app, over to a static one. One way to do this would be to stop all development for a few months and rebuild the entire site using this new infrastructure. But as the saying goes, "ain't nobody got time for that."
 
-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).
+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 URLs to serve up the old content, and some URLs 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, 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:
+There are many different ways to skin this cat, ranging from Apache or Nginx configuration, 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
-- Ability to proxy requests to other URL's (internal and external)
-- Global CDN to improve our international traffic and SEO
+- Ability to proxy requests to other URLs (internal and external)
+- Global CDN to improve performance and SEO for our international traffic
 - Easy to use and configure
 - Great and responsive customer support
 
 We found one host that met all of those requirements and more, and they are called [Netlify](https://www.netlify.com/). Never heard of them? Neither had we, but as a colleague of mine recently put it, "Netlify is like the developer whisperer". This team has put together an amazing service that handles SO much for you from a dev-ops persective of hosting static sites. And if there is a feature that is missing, they will bend over backwards to either implement it for you, or help you figure out a solution. I can sit here and sing their praises all day long, but its probably best if I explained a bit about how they were able to help us with our migration to a static site and make the static verions of our site *2-3x faster*.
 
-To get started, one of the first pages we decided to migrate over to static was our [`/locations`](https://www.wework.com/locations/) page. This page doesn't get a ton of traffic, but has dynamic content coming from our backend, so it seemed like a good place to start. Looking at the graph below you can see the downward trend (in the world of performance, downward trending graphs are usually a good thing) from the day we rolled it out.
+To get started, one of the first pages we decided to migrate over to static was our [`/locations`](https://www.wework.com/locations/) page. This page has dynamic content coming from our backend, so it seemed like a good place to start. Looking at the graph below you can see the downward trend (in the world of performance, downward trending graphs are usually a good thing) from the day we rolled it out, and also the steady performance since we launched it.
 
 ![Performance graph of locations page](http://res.cloudinary.com/wework/image/upload/c_scale,f_auto,w_1000/v1448740493/engineering/locations-graph.png)
 <small>*Via [calibreapp.com](https://calibreapp.com/)*</small>
 
 One can argue that the same level of performance can be achieved using CDN or Edge Caching, and this is definitely true. And in fact, edge caching is one of the many features that Netlify offers. But properly setting up your application to take advantage of edge caching, and then knowing when to invalidate that cache deserves a blog article on its own. As the saying goes, *"There are only two hard things in Computer Science: cache invalidation and naming things."* We've decided to spend more of our time on naming things :-)
 
-So how are we serving up traffic to `wework.com/locations/` from the static host and other pages from our current non-static host? It was as simple has modiftying some DNS settings to route all traffic through Netlify, [creating a `_redirects` file](https://www.netlify.com/docs/redirects) at the root of our very basic static site, with some rules about which URL's to pass through and which ones to handle. Netlify's proxy and rewrite is actually very intelligent in how it handles requests. If it finds the file, folder or resource locally in your folder structure, it will serve that up before it tries to proxy it. On our site, we have a catch-all rule that looks like this:
+So how are we serving up traffic to `wework.com/locations/` from the static host and other pages from our current non-static host? It was as simple has modiftying some DNS settings to route all traffic through Netlify, [creating a `_redirects` file](https://www.netlify.com/docs/redirects) at the root of our very basic static site, with some rules about which URLs to pass through and which ones to handle. Netlify's proxy and rewrite is actually very intelligent in how it handles requests. If it finds the file, folder or resource locally in your folder structure, it will serve that up before it tries to proxy it. On our site, we have a catch-all rule that looks like this:
 
 ```coffeescript
 extensions: [
@@ -103,7 +101,7 @@ Which basically says, route all traffic through to `ORIGIN_URL`. We never have t
 
 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.
 
-By doing this, we hope to see an improvement in direct and SEO traffic and hopefully a small uptick in our KPI numbers, as it has been proven that conversion numbers generally improve when your pages load faster. This also allows us to expand globally without having to worry as much about traffic load and performance. One thing to keep in mind with all of this is that it is not necessarily *easier*, but it is a lot *simpler*. There is a [great article on Smashing Magazine](http://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/) written by the co-founder of Netlify (Mathias Biilmann Christensen) about why static site generators are the next big thing. I highly recommend checking it out.
+By doing this, we hope to see an improvement in SEO traffic and hopefully a small uptick in our KPI numbers, as it has been proven that conversion numbers generally improve when your pages load faster. This also allows us to expand globally without having to worry as much about traffic load and performance. One thing to keep in mind with all of this is that it is not necessarily *easier*, but it is a lot *simpler*. There is a [great article on Smashing Magazine](http://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/) written by the co-founder of Netlify (Mathias Biilmann Christensen) about why static site generators are the next big thing. I highly recommend checking it out.
 
 Stay tuned for **part 2**, where we will discuss our journey into **Isomorphic / Universal Javascript** with React, and Webpack and generating our React components during our static site generation process for fun and for profit.