16 |
17 |
--------------------------------------------------------------------------------
/packages/.gitignore:
--------------------------------------------------------------------------------
1 | /iron-router
2 | /bootstrap-3
3 |
--------------------------------------------------------------------------------
/posts/does_meteor_scale.html:
--------------------------------------------------------------------------------
1 |
2 | {{#markdown}}
3 |
4 | # Does Meteor Scale
5 |
6 | Most people considering Meteor for a production deployment are wondering if it can scale. Some say Meteor is a good framework for prototyping, but not for production. After you read this article, you’ll be able to decide for yourself.
7 |
8 | ## Scaling Myth
9 |
10 | With the emergence of cloud computing (and specifically Heroku), many have come under the impression that _scaling_ means adding more instances of an application. That's not completely true.
11 |
12 | Routing, sessions, job processing, static file serving, and database optimization are key concerns when it comes to scaling, among other things. Any Meteor app that intends to deploy into production needs to address--or at least consider--these issues. On top of that, Meteor has its own issues.
13 |
14 | ## Issues Unique to Meteor
15 |
16 | Meteor isn't like Ruby on Rails, Express (the Node.js framework), or PHP. It's a special framework with its own issues, many of which have been solved outside of the Meteor community already. We just need to figure out how to fit them together and apply them correctly to Meteor. So, let’s have a look at these issues first.
17 |
18 | ### Use of SockJS
19 |
20 | Meteor uses [SockJS](https://github.com/sockjs/sockjs-node) as the transport layer for communicating between client and server. SockJS needs _sticky sessions_, which means that all the requests for a particular client must be served from a single server for a specific amount of time.
21 |
22 | ### Hot Code Reloading
23 |
24 | Meteor apps are _single-page apps_, which are long-lived in the browser. Single-page apps can sometimes experience conflicts between the server and client due to a version mismatch--especially when new code is pushed often, which is not so rare these days. Fortunately, Meteor features _hot code reload_, which identifies any code changes on the server and asks the browser to reload. Additionally, Meteor is smart enough to preserve session information through the reload.
25 |
26 | Due to the default _hot code reload_ logic, a Meteor client app needs to connect (via DDP) to the same server it was loaded from.
27 |
28 | ### Polling for Changes in MongoDB
29 |
30 | Meteor is all real-time, which it currently achieves by fetching and comparing documents after every database write operation. Meteor also polls the database for changes every 10 seconds. These are the main bottlenecks when scaling Meteor, and they introduce two main issues:
31 |
32 | 1. The polling and comparing logic takes a lot of CPU power and network I/O.
33 | 2. After a write operation, there is no way to propagate changes to other Meteor instances in real-time. Changes will only be noticed the next time Meteor polls (~10 seconds).
34 |
35 | See how Meteor identifies database changes with polling:
36 | 
37 |
38 | ## How We Can Solve Meteor’s Scaling Issues
39 |
40 | There is nothing which cannot be solved. Continue reading to learn how to solve the above-mentioned issues with Meteor, and some other common scaling issues. The next few articles will discuss the full implementation of these solutions.
41 |
42 | ### Sticky Session Enabled Load Balancing
43 |
44 | When serving requests to Meteor instances, a load balancer needs to be able to handle the issues presented by SockJS and _hot code reload_. These issues are not hard to solve so long as the load balancer can be configured to use sticky sessions--and the sticky sessions need to apply to static content, at least for the first HTML page.
45 |
46 | ### Meteor with MongoDB oplog
47 |
48 | As mentioned above, Meteor's bottleneck to scaling exists in the way it polls the database and runs an algorithm to detect and patch in any changes to the rest of the app. But we can get much more performance out of Meteor using the [MongoDB oplog](http://docs.mongodb.org/manual/core/replica-set-oplog/). An oplog-based solution works with multiple Meteor instances without much effort. You can even write directly to the database outside of Meteor, and Meteor will notice the changes.
49 |
50 | Oplog integration removes the bottleneck of MongoDB polling.
51 |
52 | MongoDB's oplog is a log that records every database write operation. It's so reliable that it's used for MongoDB replication (_Replica Sets_). Also, the oplog is a [capped collection](http://docs.mongodb.org/manual/core/capped-collections/), which can be configured to have a fixed size and can be tailed. Oplog [tailing](http://docs.mongodb.org/manual/tutorial/create-tailable-cursor/) can be used to capture database changes in real-time.
53 |
54 | See following illustration to see how Meteor gets database changes with the oplog.
55 | 
56 |
57 | ### Smart Caching
58 |
59 | It's a good idea to put a caching server in front of Meteor. This will reduce the load on Meteor to serve static content. Node.js (where Meteor runs) [**does not** work well](http://www.quora.com/Node-js/What-are-the-disadvantages-of-using-Node-js-for-handling-static-resources/answer/Vineet-Markan) when it comes to static file serving, so using a caching server improves performance.
60 |
61 | The caching server shouldn't cache the first HTML page loaded from Meteor into the browser. This is the only HTML content Meteor loads, and it contains a JavaScript variable called _serverId_ that is used to compare versions in _hot code reload_ logic.
62 |
63 | ### Improved Application & MongoDB Performance
64 |
65 | Fixing the most common performance issues helps a lot in the scaling process. The first thing to optimize is database indexes. Meteor doesn't auto-magically add indexes--they need to be added explicitly. Indexes can provide a large performance gain.
66 |
67 | Subscriptions and queries can also be optimized, with notable performance gains.
68 |
69 | ### Scaling MongoDB
70 |
71 | MongoDB is a core component of Meteor, so it needs to be prioritized where scaling and performance are concerned. Generally, MongoDB performs quite well. It supports both vertical and horizontal scaling. It can be run on a more powerful server, or use [MongoDB sharding](http://docs.mongodb.org/manual/sharding/) to scale horizontally.
72 |
73 | Although MongoDB comes with good sharding tools, care needs to be taken when using sharding.
74 |
75 | ### Use of a CDN
76 |
77 | If your application is heavy on static content like images and video, you **must not** host these files using Meteor. Nowadays, using a CDN (Content Delivery Network) is standard practice, and it’s not very hard.
78 |
79 | ## Okay, Does Meteor Scale?
80 |
81 | Now you can decide if Meteor scales or not! In the next few articles, you'll learn how to use commonly available tools and services to scale Meteor.
82 |
83 | ---------------
84 |
85 | > Edited by [Jon James](https://twitter.com/jonjamz) (Head of Technology at [Writebot](http://writebot.com/))
86 |
87 | {{/markdown}}
88 |
--------------------------------------------------------------------------------
/posts/introducing_fast_render.html:
--------------------------------------------------------------------------------
1 |
2 | {{#markdown}}
3 |
4 | # Introducing Fast Render
5 |
6 | Meteor is supercool when it comes to productivity and building real-time web apps very quickly. But one of the common issues with Meteor is page load time: you have to wait until a WebSocket connection is made and data comes from the server. This is a crucial issue for many apps, especially forums, blogs and public-facing web apps.
7 |
8 | Server Side Rendering (SSR) is the solution for this issue. It will render the initial page on the server, it works well with Search Engines, and it does not require PhantomJS (which is how Meteor currently supports Search Engines). However, SSR is not expected to be comes with Meteor 1.0. (But you can expect it [sometimes later](https://trello.com/c/Lz07fBAm/7-server-side-rendering)).
9 |
10 | ## Meet Fast Render
11 |
12 | [Fast Render](http://meteorhacks.com/fast-render) is not an SSR, but it is very similar and performs the same functionality very efficiently.
13 |
14 | What Fast Render does is pretty simple. It sends the data required to render your first page with the initial HTML loaded from Meteor, so the page is rendered just after the JavaScript is loaded to the client. No more waiting!
15 |
16 | > However, Fast Render does not help much with SEO and does not change how Meteor deals with SEO.
17 |
18 | ## Demo
19 |
20 | Let's try a demo to see what Fast Render can do. I have added Fast Render support to Telescope so you can see the difference below.
21 |
22 | * [Standard Telescope App](http://oridinary-telescope.meteor.com/)
23 | * [Telescope with Fast Render](http://fast-render-telescope.meteor.com/)
24 |
25 | For more information on the comparison, see the video below.
26 |
27 |
29 |
30 | ## Simple Integration
31 |
32 | [Fast Render](http://meteorhacks.com/fast-render) does all the hard work for you. All you have to do is specify which data and subscriptions need to send to the client with the HTML. You can do that with a simple API. See the example below:
33 |
34 | First add Fast Render to your Meteor app
35 |
36 | mrt add fast-render
37 |
38 | Fast Render has been deeply integrated with Iron Router. With just a few steps, you can power your existing Meteor App with Fast Render. Here's all you have to do:
39 |
40 | 1. If you are extending from `RouteController`, extend it from `FastRender.RouteController`
41 | 2. If you are directly using routes, use `fastRender:true` as shown [here](/fast-render/iron-router-support/#option_1_if_you_are_using_waiton).
42 | 3. Then bring your route definitions to a place that can be seen by both the client and the server.
43 | 4. Make sure, `waitOn()` does not contains any client specific code. If you have such, guard them with `Meteor.isClient`
44 |
45 | Fast Render supports more IronRouter [integration methods](/fast-render/iron-router-support/), as well as the ability to integrate without IronRouter. Please refer to the [documentation](http://meteorhacks.com/fast-render) for more information.
46 |
47 | ## Try it Out
48 |
49 | Don't take my word for it. Try it out with your app: I bet you'll love it. I'd also love to hear your thoughts about Fast Render and this is the first project comes with the new MeteorHacks.
50 |
51 | > Sign Up with [this Newsletter](http://mad.ly/signups/98366/join) to get FastRender specific [updates](http://mad.ly/signups/98366/join) once they've been released
52 |
53 |
54 |
55 | {{/markdown}}
56 |
--------------------------------------------------------------------------------
/posts/metadata.js:
--------------------------------------------------------------------------------
1 | PostList = [
2 | {title: 'Does Meteor Scale?', template: "does_meteor_scale"},
3 | {title: 'Introducing Fast Render', template: "introducing_fast_render"},
4 | ];
--------------------------------------------------------------------------------
/router.js:
--------------------------------------------------------------------------------
1 | Router.route('/', {
2 | template: "blogHome"
3 | });
4 |
5 | Router.route('/blog/:slug', {
6 | template: 'blog'
7 | });
--------------------------------------------------------------------------------