edits

i8ramin · i8ramin · commit 1aef51796be8 · 2015-11-30T12:44:45.000-05:00
diff --git a/_drafts/wework-com-is-going-static.markdown b/_drafts/wework-com-is-going-static.markdown
@@ -1,8 +1,8 @@
 ---
 layout:       post
-title:        WeWork.com is Going Static
+title:        Why WeWork.com uses a static generator and why you should too
 author:       ramin_bozorgzadeh
-summary:      Back when the web first started, things were a lot simpler. Most websites were made up of static html pages and there weren't a lot of moving parts. This is the story of how wework.com went from a full-stack "web app" to a statically generated site, and why ...
+summary:      Back when the web first started, things were a lot simpler. Most websites were made up of static html pages and there weren't a lot of moving parts. This is the story of how wework.com went from a monolithic "web app" to a statically generated site, and why ...
 image:        //res.cloudinary.com/wework/image/upload/c_fill,f_auto,g_faces,h_800,w_1000/v1448734984/engineering/wework-com-is-going-static.jpg
 categories:   engineering
 ---
@@ -13,27 +13,26 @@ Static site generators have become a hot topic in the past few years. There are
 for it, check out this graph from [Google Trends for "static site generator"][2]:
 
 [![Google Trends - Static Site Generator][1]][2]
-[1]: //res.cloudinary.com/wework/image/upload/f_auto/v1448735896/engineering/static-site-generator.png
+[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 proceed 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 explantion of how it all works, and this process doesn't work on all web sites, but it does work really well for marketing and informational sites like wework.com. 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. 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 on all web sites, but it does work really well for marketing and informational sites like [wework.com](https://www.wework.com). 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/)!
 
 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.
 
 
-### The static / dynamic hybrid approach
+### Roots: The static / dynamic hybrid approach
 
 One key requirement for us when evaluating different static site generators was the ability to hit an API endpoint and dynamically generate static pages based on the data returned. A real-world example of this is when we add new locations and markets. With a traditional web-app setup (like a Ruby on Rails project), as soon as you add a new location or update one, the new content is up and live on your website. With a statically generated site, this is not the case. You will need to rebuild the entire site and generate new HTML. The good news is, for a site that doesn't have a ton of content, this static site generation is actually really fast. Like in the tens of seconds fast. A couple of minutes if you consider the entire proecss of minifying assets, building and deploying your site.
 
-We played with and evaluated quite a few options, like pure jekyll, yeoman, Middleman, etc. The one we decided to go with is a very well thought out static site generator called [**Roots**](http://roots.cx/), developed by the fine folks at the Brooklyn based agency, [Carrot Creative](https://carrot.is/). Besides the many nice features that Roots gives you right out of the box (folder structure, asset management and minifcation, great extension and plugin system, etc), they also have a really nifty extension called [**roots-records**](https://github.com/carrot/roots-records). Like most well built things, roots-records serves one purpose and does an amazing job at it. It allows you to hit ANY endpoint that returns a JSON collection and use that collection in your templates to iterate over or if you pass in a template, it will also generate individual static HTML pages for each item in the collection. For example, here is all we had to define in our `app.coffee` file to hit our API endpoing for our market/location:
+We played with and evaluated quite a few options, like pure jekyll, yeoman, Middleman, etc. The one we decided to go with is a very well thought out static site generator called [**Roots**](http://roots.cx/), developed by the fine folks at the Brooklyn based agency, [Carrot Creative](https://carrot.is/). Besides the many nice features that Roots gives you right out of the box (folder structure, asset management and minifcation, great extension and plugin system, etc), they also have a really nifty extension called [**roots-records**](https://github.com/carrot/roots-records). Like most well built things, roots-records serves one purpose and does an amazing job at it. It allows you to hit ANY endpoint that returns a JSON collection and use that collection in your templates to iterate over or if you pass in a template, it will also generate individual static HTML pages for each item in the collection. For example, here is all we had to define in our `app.coffee` file to hit our API endpoint for our market/location:
 
 ```coffeescript
 extensions: [
   records(
     marketsByCountry: {
       url:
-        path: "#{process.env.DUBS_API}/api/v1/locations/markets_by_country"
-        headers: { Authorization: "Token token=#{process.env.DUBS_API_TOKEN}" }
+        path: "#{process.env.DUBS_API}/api/to/locations/data"
     }
   )
 ]
@@ -56,8 +55,7 @@ extensions: [
   records(
     marketsByCountry: {
       url:
-        path: "#{process.env.DUBS_API}/api/v1/locations/markets_by_country"
-        headers: { Authorization: "Token token=#{process.env.DUBS_API_TOKEN}" }
+        path: "#{process.env.DUBS_API}/api/to/locations/data"
       template: "views/_location.jade"
       out: (location) -> "/locations/#{location.market.slug}/#{location.slug}"
     }
@@ -66,7 +64,7 @@ extensions: [
 ```
 
 
-### The static host with the most
+### Netlify: The static host with the most
 
 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."
 
@@ -81,7 +79,7 @@ There are many different ways to skin this cat. You can install and configure yo
 - 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 one engineer I recently spoke with who was familiar with their services 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*.
+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. We no longer have the old version up now, so I can't do a side by side comparison, but just 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. Our server response time is **1ms** (this number is around 150-200ms on other, non-static pages) and the page is visually complete in about 2.8 seconds, which is 2-3x faster than it used to be. Of course, we've done other optimizations as well (reducing unused assets, optimizing images, etc) and there are still other things we can do to make it even more performant, but we are very pleased with the results so far.
 
@@ -102,9 +100,9 @@ Which basically says, route all traffic through to `dubsUrl`, which is defined f
 
 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 and people are able to get to the information they are looking for quicker. 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*. Also as a side effect of serving up static pages, your site becomes a lot more secure. 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 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.
 
-In a future post we will discuss how we've begun a journey into [**Isomorphic or Universal Javascript**](http://techblog.netflix.com/2015/08/making-netflixcom-faster.html) by generating our React components as part of this static build process.
+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.
 
 
 
