added articles related to the meteorhacks show 1

arunoda · arunoda · commit 5dae43dcb385 · 2014-01-28T06:57:56.000+05:30
diff --git a/_data/navbars.yml b/_data/navbars.yml
@@ -12,3 +12,7 @@
       Subscribe for Updates: "http://mad.ly/signups/98366/join"
     Tutorials & Articles: 
       How Loading Time Affects Your Bottom Line: "how-loading-time-affects-your-bottom-line"
+      Fast Render Internals and How It Works: "http://meteorhacks.com/fast-render-internals-and-how-it-works.html"
+      How to Test whether Fast Render is Working or Not: "http://meteorhacks.com/how-to-test-fast-render-working-or-not.html"
+      Integrating Iron Router Based Apps with Fast Render: "http://meteorhacks.com/integrating-iron-router-based-apps-with-fast-render.html"
+
diff --git a/_posts/2014-01-28-fast-render-internals-and-how-it-works.md b/_posts/2014-01-28-fast-render-internals-and-how-it-works.md
@@ -0,0 +1,82 @@
+---
+layout: blog
+title: "Fast Render Internals and How It Works"
+category: blog
+summery: "This annotated presentation shows you how Fast Render works and some of the hacks it does."
+---
+
+This annotated presentation shows you how Fast Render works and some of the hacks it does.
+
+First of all, let’s see how Meteor normally works. 
+
+![How Meteor Normally Works](https://i.cloudup.com/G7FJMkTwwh.jpg)
+
+Normally, Meteor client can’t show anything until it connects to the Meteor server via DDP and receives the data from the server. Depending on the Internet connectivity, this will be an issue, especially in mobile and Wi-Fi.
+
+Fast Render is a solution for this–see how it fixes this issue:
+
+![With Fast Render](https://i.cloudup.com/6azak1msMh.jpg)
+
+Fast Render sends the data required to render the initial page with the HTML, so the browser can render the page without the DDP connection. This provides the same experience as server-side rendering: the user can see the page immediately after HTML has been loaded.
+
+Here is the initial HTML page normally sent by Meteor:
+
+![HTML Comes with Meteor](https://i.cloudup.com/Mluhtxk16m.png)
+
+This is how it looks with Fast Render:
+
+![HTML Comes with Fast Render](https://i.cloudup.com/buJq5psf8o.png)
+
+![Some Hacks I Did](https://i.cloudup.com/fAMz3Md4Y4.jpg)
+
+As you have seen in the screen shots above, Fast Render sends data with the HTML, even though there is no such API available with Meteor to do that. Here is how Fast Render does it:
+
+![Injecting Data into HTML](https://i.cloudup.com/mOlVnB7Lfy.jpg)
+
+Fast Render directly overrides the NodeJS HTTP module, as shown above, to inject the data into the HTML. It is the only possible way to do what Fast Render needs, and works very smoothly.
+
+![DDP Rewrite](https://i.cloudup.com/LQSRhPepzx.jpg)
+
+The next hack I did is the DDP Rewrite, which takes place inside the Meteor client. Let’s see why we need it in the first place. The slide above shows how Meteor subscription works normally.
+
+The **ready** message is useful, since it triggers the Meteor client by saying that the initial data for the subscription has been sent. Now the client can render the page with all the data. 
+
+Iron Router is a special case, because it looks for the **ready** message before it renders the templates for the route. In this case, Fast Render has an issue, as shown below:
+
+![DDP Rewrite](https://i.cloudup.com/hLc33Pkpvx.jpg)
+
+With Fast Render, the browser has the data even before sending the subscription request. But Iron Router will not render the route since it didn’t get the ready message. The solution is to send a **fake ready** message, as shown above. The code below shows how Fast Render implements this hack, again without the support of any Meteor API. 
+
+![DDP Rewrite - Code](https://i.cloudup.com/myawcxa3fo.jpg)
+
+There are some other hacks involved in building Fast Render. You can learn more about them by looking at the source.
+
+![Security Concerns](https://i.cloudup.com/GT9QuTTDGF.jpg)
+
+Fast Render exposes some security issues that are not normally issues with Meteor. The following section describes what they are and how to prevent them. Some of the issues have been already fixed.
+
+> Our thanks goes to Emily Stark from the Meteor core team for raising these issues.
+
+![LoginToken over Cookies](https://i.cloudup.com/ul8K98Qr78.jpg)
+
+LoginToken is a simple token used to identify the user in the browser. It is identical to the Remember Me cookie used traditionally. Meteor uses localStorage for this purpose instead cookies.
+
+Since localStorage data is never sent to the server, Fast Render cannot identify the logged-in user. The only solution is to send the LoginToken over the cookies. This introduces the following issues:
+
+![Avoid Side Effects](https://i.cloudup.com/vmJyEAw6WN.jpg)
+![Avoid Side Effects](https://i.cloudup.com/u98AnBuFRq.jpg)
+
+If your publications trigger side effects  as shown above, they may have been triggered by directly calling to route. This can be done via an AJAX request called by a malicious web site. They can’t get the user’s subscription data, but they can trigger side effects. Directly sending an HTTP request can also trigger this.
+
+So it is recommended to avoid side effects, inside publications, Fast Render routes and IronRouter waitOn functions.
+
+![CORS Issue](https://i.cloudup.com/4RCoQWXz9B.jpg)
+
+CORS is a specification that comes with HTML5; it allows cross-domain communication to work inside the browser. When your app or one of your packages adds CORS support, as shown above,  it is possible for malicious sites to extract the user’s subscription data by sending an XHR request.
+
+This is not something normally happens, but there is a possibility. In those situations, Fast Render detects it, and turns off Fast Render support for particular routes, _**so there is nothing to worry about.**_
+
+![Questions](https://i.cloudup.com/sJGV6VtABg.jpg)
+
+This article has described how Fast Render actually works and some of its internal workings. If you have any questions, please add a comment: I’d happy to answer.
+
diff --git a/_posts/2014-01-28-how-to-test-fast-render-working-or-not.md b/_posts/2014-01-28-how-to-test-fast-render-working-or-not.md
@@ -0,0 +1,24 @@
+---
+layout: blog
+title: "How to Test whether Fast Render is Working or Not"
+category: blog
+summery: "Once you've added Fast Render support, you might not be sure whether Fast Render is correctly applied or not. This article shows you, how to find it out."
+---
+
+Once you've added Fast Render support, you might not be sure whether Fast Render is correctly applied or not. Normally it is very hard to detect it locally, since there is not much latency for connecting to the DDP server.
+
+Here is a simple way to check whether you are using Fast Render or not.
+
+![Non Existing DDP Endpoint](https://i.cloudup.com/DaBMkEnXdy.jpg)
+
+Start your app by exporting `DDP_DEFAULT_CONNECTION_URL` with something that does not exist. When you ask the Meteor client to connect to a DDP endpoint that does not exist, it will keep asking for the connection and never get any data from the DDP. It totally depends on FastRender to render the page.
+
+If you've followed the above instructions for your app (and not added Fast Render yet), it should look like this:
+
+![Without Fast Render](https://i.cloudup.com/N8jVxk09tR.jpg)
+
+Once you've added Fast Render support it should look something like this: 
+
+![With Fast Render](https://i.cloudup.com/1MohsGbKOg.jpg)
+
+You can verify that the Meteor client is still trying to connect to the DDP server we've provided with `DDP_DEFAULT_CONNECTION_URL`.
diff --git a/_posts/2014-01-28-integrating-iron-router-based-apps-with-fast-render.md b/_posts/2014-01-28-integrating-iron-router-based-apps-with-fast-render.md
@@ -0,0 +1,36 @@
+---
+layout: blog
+title: "Integrating Iron Router Based Apps with Fast Render"
+category: blog
+summery: "This annotated presentation shows you how to integrate your existing Iron Router based Meteor app with Fast Render."
+---
+
+This annotated presentation shows you how to integrate your existing Iron Router based Meteor app with Fast Render.
+
+![Routes on the Server](https://i.cloudup.com/8X9NUx0mvT.jpg)
+
+Fast Render runs your routes on the server. Specifically, it depends on the **waitOn** function on the server side to know which subscriptions are used for the particular route.
+
+So you need to bring your route definitions to a location where they can be accessed by both the server and the client. You also need to guard any client-specific code with **Meteor.isClient**, as shown above.
+
+![Extend with FastRender.RouteController](https://i.cloudup.com/iOOcOfPPyC.jpg)
+
+If you are extending **RouteController**, extend it with FastRender. **RouteController** as shown above. If you are not extending **RouteController** and directly passing **waitOn** function as a route option as shown below, use the fastRender:true option.
+
+![Use fastRender:true](https://i.cloudup.com/Q8prGg7A7S.jpg)
+
+If you are using **this.subscribe(‘foo’).wait()** inside a before handler, Fast Render cannot understand them automatically, since before handlers contain a lot of client-side logics. So it is not a good option to run them inside the server. 
+
+Therefore, you need to specify subscriptions manually, as shown below:
+
+![](https://i.cloudup.com/cHRnXaqNZ9.jpg)
+
+**FastRender.onAllRoutes** can be used if **canView** is a global before handler. If it is a before handler for a specific route, use **FastRender.route** as shown below:
+
+![](https://i.cloudup.com/YLG52kb6QY.jpg)
+
+You might have to assign the return value of **Meteor.subscribe** directly into the **waitOn**. But in this case, Fast Render cannot detect the subscriptions, so the correct solution is to wrap the subscription with a function. 
+
+![Use waitOn() with Functions](https://i.cloudup.com/p3Hgtpt9EW.jpg)
+
+Hope this article helps you to integrate your Meteor app with Fast Render correctly with less issues. If you have any questions, please add a comment: I’d happy to answer.
diff --git a/_posts/2014-01-28-meteor-subscription-optimizations.md b/_posts/2014-01-28-meteor-subscription-optimizations.md
@@ -0,0 +1,76 @@
+---
+layout: blog
+title: "Meteor Subscription Optimization"
+category: blog
+summery: "This annotated presentation shows you how to optimize subscriptions while keeping your both users and servers happy at the same time."
+---
+This annotated presentation shows you how to optimize subscriptions while keeping your both users and servers happy at the same time.
+
+Subscriptions management is a common issue with Meteor and sometimes introduces weird issues. That's why we need to take care of optimizing subscriptions. This guide will give you some tips on where you can optimize your subscriptions effectively.
+
+![Subscriptions on the Server](https://i.cloudup.com/EQpEAZ7oaB.jpg)
+
+First we need to understand how subscriptions are handled on the server, which will help us to make good decisions. 
+
+![Grouped by Query](https://i.cloudup.com/agZPzf3NxG.jpg)
+
+In the above publication, a static query has been used. It doesn't change with the arguments from the subscription, so it creates only one **LiveResultSet**. Even if you had 20 subscriptions, there would be only one **LiveResultSet**. This is an advantage because, when a polling takes place, there will be less overhead.
+
+![Grouped by Query](https://i.cloudup.com/yxd8LQDty0.jpg)
+
+In contrast to the previous publication, this one creates a LiveResultSet for every subscription. So when the polling takes place, it will be much costlier, since we will have many LiveResults.
+
+Practically, it is not possible to avoid these kinds of scenarios all the time. That's why oplog integration plays such a huge role: it doesn't do polling and makes subscriptions lightweight in the server
+
+![Data is Cached for Each Session](https://i.cloudup.com/U79xqDmKKw.jpg)
+
+The Meteor server keeps a copy of data (documents) available on each client. It allows Meteor to make better decisions when sending changes to the client. But it also increases the RAM usage, if your data set is large.
+
+![Deps.autorun and Subscriptions](https://i.cloudup.com/xhfoFcwNMT.jpg)
+
+Next, we need to understand how subscriptions behave in the client, especially inside a `Deps.autorun` computation.
+
+![After an Invalidation](https://i.cloudup.com/T0xFW7pQx9.jpg)
+
+In the first invalidation round, slug is **meteorhacks**. It adds two subscriptions to singlePost and postList.
+
+In the next invalidation, slug is **oplog**. The computation removes the old subscription to **singlePost**, with **meteorhacks** as the argument. After that it adds a subscription to singlePost, with oplog as the argument. It does not change the existing subscription to **postList**.
+
+This feature is one of the core concepts underlying Iron Router's subscription model.
+
+![Relation with Iron Router](https://i.cloudup.com/Wm1Lgz7nnc.jpg)
+
+Iron Router runs on a Single Computation. So when it switches between routes, all the subscriptions made from the previous route are removed, **unless they are used in the current route**.
+
+![Three Simple Optimization Rules](https://i.cloudup.com/nHszCg13zG.jpg)
+
+Here are three simple subscription optimization rules that will help you build better applications while keeping both users and servers happy.
+
+![Send data only the page/client requires](https://i.cloudup.com/iJGTtxKRRc.jpg)
+
+We should send only the data that a page or user requires. The page will load faster, and less overhead (in terms of memory usage) will be added to the server.
+
+![Don't unsubscribe busy subscriptions](https://i.cloudup.com/4KUbHwKgUC.jpg)
+
+Some subscriptions are meant to be used in multiple pages/routes of your app, so it is wise to keep them open. Otherwise there will be some bandwidth issues and users will have to wait while data gets loaded from the server again.
+
+![Break the rules as needed](https://i.cloudup.com/FVacZRQdod.jpg)
+
+These are not hard and fast rules: break them whenever necessary.
+
+## Case Studies (Atmosphere & Telescope)
+
+This is a case study where I review Atmosphere and Telescope in terms of subscription usage.
+
+<iframe width="640" height="480" src="//www.youtube.com/embed/nkWtsLjLtmc?rel=0" frameborder="0" allowfullscreen="1">
+</iframe>
+
+## Sneak Peak: Subscription Manager
+
+Subscription Manager is a simple package that allows you to avoid some of the subscription-related issues described in the case study above.
+
+<iframe width="640" height="480" src="//www.youtube.com/embed/xzPg0-_TcXU?rel=0" frameborder="0" allowfullscreen="1">
+</iframe>
+
+I hope these suggestions will be helpful as you build better quality Meteor applications.
+
