Pro Meteor

Arunoda Susiripala
Introduction to Pro Meteor
Pro Meteor is a guide that has been created as a reference for building a
production-quality Meteor apps. Main focus of this guide is to show you on how
to scale Meteor apps and maintain them with existing web proven technologies
& services.
The guide assumes that its reader has a basic understanding of Meteor, but
for readers that need a better introduction, Discover Meteor comes highly
recommended.
Good Luck & Happy Reading!
Arunoda Susiripala
Hacker at MeteorHacks
Understanding Meteor Internals
This section is an introduction to Meteors internals, and serves as the foundation
for the Pro Meteor guide.
Meteor Internals: Meteor as a Server and a Client
A Meteor application is seen by browsers, proxy servers, routers and other
network components as a typical web application. Yet Meteor is comprised of
two main components: a part that runs inside the browser and another part
that runs inside the server. These two parts are congured to communicate
with each other in a way thats similar to modern web applications
e.g. Gmail and Trello
Meteor allows developers to build applications without worrying about the
complexities of client-server connectivity.
1
Figure 1: Meteor has 2 parts, which run on the browser and the server
Meteor Handles Three Dierent Types of Requests
Underneath its surface, Meteor handles 3 types of requests. They are:
Static Files
DDP Messages
HTTP Requests
Static Files
Static les are images and other resources inside the /public folder. Meteor
serves these les automatically when the app starts.
Additionally, Meteor minies and concatenates all JavaScript (including tem-
plates, which are pre-compiled as JavaScript) and CSS les, and serves them as
static les.
DDP Messages
DDP is the protocol Meteor uses to communicate between client and server.
All client-side subscription data, method calls and MongoDB operations are
communicated as DDP messages. This is a very lightweight protocol. These
messages can be inspected with a handy tool called ddp-analyzer.
2
HTTP Requests
While there is no ocial documentation, Meteor can handle HTTP Requests
similar to other traditional applications. For example, le uploads to a Meteor
app are sent as HTTP Requests. See this StackOverow question for details on
how to manually handle HTTP requests.
Meteor has Two Types of Servers
Although Meteor runs on a single port, internally it works as two separate
servers:
HTTP Server
DDP Server
Figure 2: Meteor Server is a combination of a HTTP Server and a DDP Server
HTTP Server
The HTTP server is used to serve static les and HTTP requests. Meteor uses
the connect Node.js module for this purpose.
DDP Server
The DDP server handles all publications, MongoDB operations and Meteor
methods. Meteor uses SockJS as the transport protocol. In actuality, the DDP
server is a SockJS server customized for Meteor.
3
Future guides will detail how to scale these two servers separately.
MongoDB and Meteor
Its possible to scale Meteors HTTP and DDP servers by running multiple
instances of Meteor connected to the same database, but the result isnt ideal.
Because of the way Meteor polls MongoDB for changes, if one Meteor instance
updates MongoDB, it may take several seconds for other instances to detect the
change and propagate it to connected users.
To illustrate this further, think of two Meteor instances (A and B, with their
respective HTTP and DDP servers) serving the same chat app. In front of
these, a reverse proxy randomly connects users to one of these instances. When
someone connected to server A posts a chat, users connected to server B wont
see the chat in real-time, as they would have to wait a few seconds before server
B recognizes the change and pushes the chat to its users browsers.
In later sections, Ill show you how to congure both Meteor and MongoDB to
get rid of this issue.
This polling logic is very expensive for production use, and it would
be better to use a solution based around the MongoDB Oplog.
Meteor 1.0 comes with a such driver, but you can use Smart Collec-
tions until 1.0 comes.
Now you have a better understanding of Meteor internals, particularly when it
comes to scaling. Lets start our journey.
Fibers, Event Loop and Meteor
Meteors use of Fibers allows it to do many great things. In fact, Meteors
popularity may be a direct result of its use of Fibers, though you wouldnt know
it without a deep understanding of Meteors internals.
Its a bit hard to understand how Fibers works, and how it relates to Meteor. But
once you do, youll have a better understanding of how Meteor works internally.
Event Loop and Node.js
Meteor is built on top of Node.js, so we cant forget the Event Loop. Node.js runs
on a single thread, and thanks to the Event Loop and event-driven programming,
program execution isnt blocked by I/O activities (network and disk, mainly).
4
Instead, we provide a callback function that is run after the I/O completes, and
the rest of the program continues to run.
Heres a psuedo-code example showing two dierent tasks.
// Call functions.
fetchTwitterFollowers(arunoda);
createThumbnail(/tmp/files/arunoda.png, /opt/data/arunoda.thumb.png);
// Define functions.
function fetchTwitterFollowers(username) {
TwitterAPI.getProfile(username, function(){
Model.setFollowers(profile.username, profile.followers, function() {
console.log(profile saved!);
});
});
}
function createThumbnail(imageLocation, newLocation) {
File.getFile(imageLocation, function(err, fileData) {
var newImage = ImageModule.resize(fileData);
File.saveFile(newLocation, function() {
console.log(image saved);
});
});
}
Now lets see how the above two functions get executed over time.
Tasks in fetchTwitterFollowers are marked in green, and tasks
in createThumbnail are marked in orange. Dark colors show CPU
time, and light colors show I/O time.
The Blue Bar shows waitTime in the queue and the Red Bar shows
idleTime.
Observations
The diagram above shows us a few interesting things. First, there is no particular
program execution order. I/O activities can take any amount of time to complete,
and they wont block the program from executing other tasks. For example,
ImageModule.resize does not need to wait for Twitter.getProfile to be
completed before it can be run.
Second, CPU-bound activities do block program execution. In the middle of the
diagram you can see a blue bar where Model.setFollowers cannot get started
5
Figure 3: Understanding Event Loop
6
even though TwitterAPI.getProfile has completed. ImageModule.resize is
the reason for that. It is a CPU-bound task, so it blocks the Event Loop. As
mentioned earlier, Node.js runs in a single thread. Thats why Node.js is not the
best choice for CPU-bound activities like image processing and video conversion.
You can also see there are three red bars indicating idleTime. If our app had
more functionality, it could use this time to execute it.
Fibers
Now you know how the Event Loop works, and how ecient it is. But there is
a problem: Callbacks. Callbacks make Node.js code dicult to reason about
(some describe it as callback soup). Error handling and nested callbacks are
uncomfortable to write, and their existence makes code dicult to maintain and
scale. Thats why some say Node.js is hard to learn (and use).
Luckily, several techniques exist to overcome this issue. Fibers, Promises, and
Generator-based coroutines are some of them.
Meteor uses Fibers, and implements APIs on top of it. But before going into it
any further, lets see how Fibers works. See the diagram below.
Fibers provides an abstraction layer for the Event Loop that allows us to
execute functions (tasks) in sequence. It allows us to write asynchronous code
without callbacks. We get the best of both worldsasynchronous eciency with
synchronous-style coding. Behind the scenes, Fibers takes care of dealing with
the Event Loop.
Fibers is really good if you use it correctly (Meteor does it well). Also, the
overhead caused by Fibers is negligible.
How Meteor Uses Fibers
Meteor abstracts Fibers with its APIs, allowing you to write your app without
callbacks. The best part is that you can write your code this way and be
completely oblivious to Fibers. It just works.
Meteor creates a new Fiber for each and every request (DDP Request) made
from the client. By default, Meteor executes one request at a time for each client,
meaning one Fiber for each client at a time. But you can change that.
Fibers is the one of the best reasons Meteor is so popular. Since it allows us
to write Node.js apps without callbacks, it has attracted many developers who
hated Node.js for that reason.
7
Figure 4: Understanding Fibers
8
How To Use Async Functions With Meteor
We cant satisfy 100% of our needs with Meteors APIsometimes we need to
use NPM modules to get things done. But how can we do this if we dont know
how to use callbacks with Meteor?
For example, say you need to use the Github NPM module to get your users
public prole. It needs to be done inside a Meteor method, and we need to
return the prole from the method. Okay, lets try to implement this.
var GithubAPI = Meteor.require(github);
var ghapi = new GithubAPI({version: "3.0.0"});
Meteor.methods({
getProfile: function(username) {
ghapi.user.getFrom({user: username}, function(err, profile) {
// How to return?
});
// We need to return the profile from here.
}
});
We cant use callbacks like above. We cant return the prole to the client from
the callback, because the Meteor method wont wait for the callback before
returning. Now we need to learn how to deal with Fibers. Or do we?
Meteor foresaw this problem and provided us with a very simple API to get
around it. Its not documented yet, but heres how you can use it.
meteor-npm also comes with a set of async-utilities to work with
npm modules.
function getUserProfile(req, callback) {
ghapi.user.getFrom(req, callback);
}
var wrappedGetProfile = Meteor._wrapAsync(getUserProfile);
Meteor.methods({
getProfile: function(username) {
return wrappedGetProfile({user: username});
}
});
The code above is simple to understand. We wrapped the ghapi.user.get
method in a function, and called that function with Meteor._wrapAsync to
9
make it Fibers aware. Now we can use it inside Meteor methods and other
Meteor APIs.
If you know how bind works, you can do the wrapping in a single line as shown
below.
var wrappedGetProfile = Meteor._wrapAsync(ghapi.user.getFrom.bind(ghapi.user));
Finally
Now you have a better knowledge of the Event Loop, Fibers, and how Meteor
uses Fibers. And you know how to use asynchronous functions with Meteor using
Meteor._wrapAsync. Its time to supercharge your app with this knowledge.
Additional Notes
If you are looking to learn more about Fibers and related technology, please
refer to the following great screencasts by EventedMind.
Introducing Fibers
Using Futures
Meteor._wrapAsync
Understanding Event Loop Async and Fibers
Does Meteor Scale?
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, youll be able to decide for yourself.
Scaling Myth
With the emergence of cloud computing (and specically Heroku), many have
come under the impression that scaling means adding more instances of an
application. Thats not completely true.
Routing, sessions, job processing, static le 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 addressor at least considerthese
issues. On top of that, Meteor has its own issues.
10
Issues Unique to Meteor
Meteor isnt like Ruby on Rails, Express (the Node.js framework), or PHP. Its
a special framework with its own issues, many of which have been solved outside
of the Meteor community already. We just need to gure out how to t them
together and apply them correctly to Meteor. So, lets have a look at these issues
rst.
Use of SockJS
Meteor uses SockJS 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 specic amount of
time.
Hot Code Reloading
Meteor apps are single-page apps, which are long-lived in the browser. Single-
page apps can sometimes experience conicts between the server and client due
to a version mismatchespecially when new code is pushed often, which is not
so rare these days. Fortunately, Meteor features hot code reload, which identies
any code changes on the server and asks the browser to reload. Additionally,
Meteor is smart enough to preserve session information through the reload.
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.
Polling for Changes in MongoDB
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:
1. The polling and comparing logic takes a lot of CPU power and network
I/O.
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).
See how Meteor identies database changes with polling:
11
Figure 5: Real-time Changes with MongoDB Polling
How We Can Solve Meteors Scaling Issues
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 sections will discuss the full implementation of these solutions.
Sticky Session Enabled Load Balancing
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 congured to use sticky
sessionsand the sticky sessions need to apply to static content, at least for the
rst HTML page.
Meteor with MongoDB oplog
As mentioned above, Meteors 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. An oplog-based solution works with multiple Meteor instances
12
without much eort. You can even write directly to the database outside of
Meteor, and Meteor will notice the changes.
Oplog integration removes the bottleneck of MongoDB polling.
MongoDBs oplog is a log that records every database write operation. Its so
reliable that its used for MongoDB replication (Replica Sets). Also, the oplog
is a capped collection, which can be congured to have a xed size and can be
tailed. Oplog tailing can be used to capture database changes in real-time.
See following illustration to see how Meteor gets database changes with the oplog.
Smart Caching
Its 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 when it comes to static le serving, so using a caching server improves
performance.
The caching server shouldnt cache the rst 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.
Improved Application & MongoDB Performance
Fixing the most common performance issues helps a lot in the scaling process.
The rst thing to optimize is database indexes. Meteor doesnt auto-magically
add indexesthey need to be added explicitly. Indexes can provide a large
performance gain.
13
Subscriptions and queries can also be optimized, with notable performance gains.
Scaling MongoDB
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 to scale horizontally.
Although MongoDB comes with good sharding tools, care needs to be taken
when using sharding.
Use of a CDN
If your application is heavy on static content like images and video, you must
not host these les using Meteor. Nowadays, using a CDN (Content Delivery
Network) is standard practice, and its not very hard.
Okay, Does Meteor Scale?
Now you can decide if Meteor scales or not! In the next section, youll learn how
to use commonly available tools and services to scale Meteor.
How to Scale Meteor?
In the previous section, we looked at the problems and possible solutions for
scaling Meteor applications. But I did not show you how to scale an app in
practice. So, this section covers that.
Scaling Set-up
Our component diagram is:
There are three Meteor servers, one MongoDB server and a HaProxy server as
the load balancer. For SSL support, we will use Stud in front of HaProxy.
Lets discuss these components and congurations.
Conguring MongoDB
Im using a single-server replicaSet for MongoDB, which supports the oplog. It
is better to use a multiserver replica set, but I will be using a single server to
keep things simple.
14
Figure 6: Meteor Scaling Setup - Components
Conguring a Single-Server Replica First, we need to start our MongoDB
server with replicaSet aware. Use the following command to start MongoDB
with replicaSet meteor:
mongod --replSet meteor
Then, open a Mongo shell and add the following to congure the single-server
replicaSet:
var config = {_id: "meteor", members: [{_id: 0, host: "127.0.0.1:27017"}]}
rs.initiate(config)
It is wise to run a 3 node MongoDB ReplicaSet for your app. I highly
recommend using MongoHQ Dedicated Servers, if you dont have
the expertise.
Access Control Since we are using a separate MongoDB server, we need to
prevent unauthorized access of it. We can congure a rewall or use MongoDBs
role-based access control. To make the set-up simple, I assume weve congured
the rewall properly. If it is not possible to congure a rewall, try using
MongoDBs role-based access control.
Well be using app as the database for our Meteor app. For the oplog integration,
we will be using the local database that contains the oplog.
15
Conguring Meteor
We need to keep an eye on a few things when we are planning a scalable Meteor
deployment. Ill show these in this section.
Oplog Support
I already mentioned in the previous section how oplog can help Meteor to scale
horizontally.
All youve to do is, simply expose the MongoDB URL of your local database as
MONGO_OPLOG_URL.
MONGO_OPLOG_URL=mongodb://localhost/local
(Of course, you need to set MONGO_URL as usual)
IE 8 and 9 Sticky Session Support
IE 8 and 9 do not send cookies with Ajax requests; so this breaks our load
balancer, which well be exploring in the next section. Fortunately, SockJS has
a solution for that, but it is turned o by default with Meteor. To turn it on,
you need to export the following environmental variable:
export USE_JSESSIONID=1
Selecting Servers
It is very important that you choose identical servers for Meteor. They should be
in the same data center and the performance, operating systems and architecture
should also all be the same; otherwise well have an unbalanced load across our
Meteor servers.
In this setup, I am using only a single process on the server. So a server with
multiple cores will not be much help. So try to pick single core server instances.
Ill cover this further in the next section.
Deploying
It is very important to deploy your Meteor app correctly and congure the
servers carefully. If possible, try consulting someone who knows how. Otherwise
you can use Meteor Up, which I built to deploy production-quality Meteor apps.
16
Conguring the Load Balancer (HaProxy)
Im using HaProxy as the load balancer for our Meteor app. It is something very
stable and used in production by many companies. Also, HaProxy has built-in
support for sticky sessions and some of the other congurations that we will be
using.
Sticky Session Support
There are a couple of ways we can implement sticky sessions. We can implement
sticky sessions with cookies, hashing source IP information or customized URLs.
There are some other ways, but these are the common ones.
Hashing source IP is the easiest to implement, but it does not balance the load
properly. We cant trust the IP information and transparent proxy servers (very
commonly used by ISPs) hide the original IP information, which means one
server will get many requests and the others wont.
A customized URL path is a very good option and it is very well supported
by SockJS. But for this, well need some custom logic in the load balancer and
further conguration on Meteor.
The cookie-based solution is ideal for us, since it can balance the load properly
and it is easy to set up.
Load-Balancing Algorithm
It is very important to choose a good load-balancing algorithm. HaProxy comes
with a bunch of algorithms. The roundrobin algorithm is recommended in the
docs. roundrobin is very good for stateless webapps built with Ruby on Rails
or PHP.
However, Meteor is stateful and it has long-lasting connections, so it is better to
use the leastconn algorithm. It sends new connections to the server that has
the lowest number of connections. This balances the load equally, even if a server
goes down and comes back. If we use roundrobin, well have an unbalanced
load.
Conguration
See how you can congure HaProxy using the following conguration le:
defaults
mode http
timeout connect 5s
17
timeout client 10s
timeout server 10s
frontend public
#binding port 80
bind *:80
default_backend apps
backend apps
#load balancing algorithm
balance leastconn
#using JSESSIONID as the cookie
cookie JSESSIONID insert nocache
#adding server
server host1 host1.example.com cookie host1
server host2 host2.example.com cookie host2
server host3 host3.example.com cookie host3
Ive removed some parts of the cong le to keep it simple. You can get the full
cong le from here.
SSL with Stud
Running your app with SSL is a must in production. Unfortunately the stable
version of HaProxy does not support SSL. But we can use Stud in front of
HaProxy to terminate SSL. It is better to deploy Stud on the same server as
HaProxy.
Make sure to install Stud from the source. The version you would
get with apt-get is outdated.
You can use the following conguration le:
#bind to defualt SSL port
frontend = "[*]:443"
#haproxy host and port
backend = "[localhost]:80"
#location of the .pem file
pem-file = "/path/to/ssl.pem"
18
Click here to get the complete conguration le.
Stud needs your SSL certicate and the private key in a single .pem le. See
these instructions for how to create a .pem le.
Enjoy
I hope this section will help you to scale your Meteor app horizontally.
Run Meteor on Multiple CPUs
You already know that Node.js has a single-process, single-threaded execution
model. Since Meteor is built on top of Node.js, it shares the same model.
So, even if your hosting environment supports multiple CPUs (or multiple cores),
you cannot take advantage of more than one by default.
Ill be using the term multiple CPUs to address the scenario of
both multiple cores and multiple CPUs.
Why not the Node.js cluster module?
Node.js has provided a solution to this limitation with its Cluster module. Lets
have a look at it.
Cluster spawns multiple processes of your app at your command. Then, when
your app receives a new HTTP request, it passes the raw socket to one of those
processes randomly. Cluster is not a proxyit simply forwards the raw socket to
another process, and that process takes care of the processing. This makes it
very ecient. Unfortunately, Clusters routing algorithm doesnt support sticky
sessions, which we need (as discussed in the previous section), so we cant use
Cluster directly with Meteor.
There has been an attempt to add sticky session support to Cluster, but its based
on source IP information. There are better ways to implement sticky sessions,
such as using cookies or HTTP path (URL), but they are nearly impossible to
implement into Cluster due to the way it works. Cluster doesnt read the content
of the raw socketsuch as cookies and other HTTP informationit just forwards
it before anything is read on the server.
Using a separate load balancer
So, how do we take advantage of multiple CPUs? The only solution is to use a
separate load balancer. We talked about load balancers and how to use HaProxy
with Meteor in our last section. We can use the same technique here.
19
Figure 7: How cluster works
Make sure to add a dierent cookie name for the load balancer used
here and the load balancer used for scaling.
Cloudare Meets Meteor
If you have not yet heard about Cloudare, its a must-have item for your
web toolbox. It oers many services for web appsprimarily for increased
performance and security. Here is a list of services Cloudare oers (in ordered
of my personal preference).
Simple DNS Management
SSL Support
Caching Proxy (with CDN) for your static les
Optimize HTML and static les for faster loading
Web Application Firewall
DDOS Protection
In addition to these features, Cloudares pricing model is extremely attractive.
Cloudare does not charge for the usage: instead, it oers an aordable per-
application at fee. Of course, a free tier is oered as well.
20
Using Meteor with Cloudare is a bit tricky, as Meteors DDP connection uses
WebSockets, which is not supported by Cloudare yet. But with few simple
tweaks, you will be able to use Meteor with Cloudare.
This is not a guide on how to use Cloudares features, but on how
to use Cloudare with Meteor
DDP and Cloudare
Cloudare runs on top of a customized nginx server but it does not yet support
WebSockets. If youve just added Cloudare support to your Meteor app, youll
nd issues connecting to the DDP server. You have two options here.
Option 1: Disable WebSockets
Figure 8: Using Cloudare with Disabling WebSockets
This is the simplest and the best option. All you have to do is export the
following environment variable before starting your Meteor app.
export DISABLE_WEBSOCKETS=1
Option 2: Use a separate subdomain for the DDP connection
With this option, you can continue to use WebSockets with your Meteor app,
but you will not be able to use some of the Cloudares features. All you need
to do is add a separate DDP connection to your Meteor app, which will bypass
Cloudare. Follow the steps below:
Add a CNAME or A record called ddp pointing to the your Meteor App
21
Figure 9: Using Cloudare with WebSockets
Bypass Cloudare by not clicking the cloud icon on the DNS manager. (It
needs to be grey.)
Add the above subdomain as your default DDP connection by exporting
the following environmental variable before starting your Meteor app.
export DDP_DEFAULT_CONNECTION_URL=http://ddp.yourdomain.com
Now your DDP connection is bypassing Cloudare and your Meteor can use
WebSockets.
What are the benets for using Cloudare with Meteor?
Now its time to explore how Cloudare helps Meteor with Cloudares features.
However, not all of the features help Meteor; some of them need to be turned o
or to be used with care.
As a Caching Proxy with CDN
As Ive mentioned before, it is not wise to use Meteor to serve static content.
Cloudare proxies all of the static content, such as CSS, JavaScript. and Images
by default. As such, your Meteor app is not directly serving any static content,
which is exactly what we need. Also, Cloudare acts as a CDN, so you gain that
benet, too.
However, Cloudare does not cache any HTML content. That helps us to load
balance our Meteor app correctly with sticky sessions.
22
As your SSL terminator + SSL provider
As Ive also previously mentioned, NodeJS is not good at serving SSL, and
Meteor has no option to congure SSL. Therefore, we need to use a separate
SSL terminator such as stud or nginx.
Cloudare has a very interesting SSL service that acts as both an SSL certicate
provider and as an SSL terminator. Simply put, you dont need to buy an SSL
certicate and make any congurations; you just need to click a button.
Unfortunately, if youve used Option 2 to allow DDP support, you cant enjoy
this feature, as now your DDP connection is bypassing Cloudare.
To use SSL support, you need to use the Cloudare Pro subscription
plan
Turn o Minication and the Rocket Loader
Meteor does already minify all your JS and CSS les. There is therefore no
reason to do so inside Cloudare. However, minifying multiple times does not
break anything.
Cloudare also has a feature called RocketLoader, which loads JavaScript asyn-
chronously. But Meteors JavaScript (just a single le) needs to be loaded
synchronously, so you will need to turn this o.
Cloudare has some security options, which asks users to enter a CAPTCHA
before entering the site. This is used to block malicious users. Sometimes,
your users may be using a shared Internet connection, or the ISP is using a
transparent proxy or something similar. This might cause Cloudare to trigger
the CAPTCHA, which might confuse the users of your app.
I really cant say whether it is a good option to turn this o or not. But keep in
mind that there is a situation like this also.
DDOS Protection
First of all, if you are considering this, your app is popular :)
Cloudare does a good job at handling DDOS, and it has prevented some major
attacks. This is how you can gain its benet
To obtain the DDOS protection, you need to hide the IP address (or direct
access) to your Meteor app from the public. This relates to both your main
website and the DDP connection.
If you are using Option 1 with disabling WebSockets, you are already behind
Cloudare, and direct access to your Meteor app is hidden from the public. So
whenever you need DDOS protection, you can simply turn it on.
23
But if you are using Option 2 with a separate DDP connection, your DDP
connection is exposing direct access to your site. This allows the attacker to
bypass Cloudare and directly attack your app. If you are keep using this option,
and if you decided to use DDOS protection at a later point, migrate your app
(or load balancer) into a new server. Then apply Option 1 and turn on the
DDOS protection.
Hope this section helps you to use Cloudare with Meteor correctly and handover
some responsibilities to it and keep focus on building your app.
Finally
Now, youve learn about How Meteor actually works and how it can run as a
production deployment.
This is not the end, there are some other topic which will be available later.
Make sure you are subscribing to the Pro Meteor guide on MeteorHacks.
24