Meteor.js is a very popular framework for creating web applications. It boasts a powerful templating engine, form processing, and basically provides all the facilities required to build a web application. It is a framework that’s constructed using Node.js, which means that it can be used for server side development, along with front end content aimed at users.
Additionally, it can be used to develop projects in real time, which is the key to developing simultaneous content for both mobile and non-mobile devices. Unfortunately, even with its many virtues, Meteor has kind of a reputation for running slowly and generally having bad performance. Some of this reputation is justified and some of it is not.
In this article, we’ll look into some performance topics relating to Meteor. Some of the things presented here are real performance challenges that are inherent to Meteor that you’ll have to work with if you want to use it and some of them are bits of advice that can improve your Meteor experience if you attend to them.
One of the really nice things about Meteor is that, because it’s open source, you often don’t have to wait for the developers to notice a problem and then release a fix for it. That’s the case with the current implementation of MongoDB, which notoriously does not perform well.
Word down the grapevine says that Meteor’s developers are working on a fix, but in the meantime, there’s a service called Smart Collections, which is a completely rebuilt collection implementation for Meteor. Smart Collections boasts five times the speed of the current collection implementation feature built into Meteor, and it doesn’t slow down with a lot of subscriptions, either. Smart Collections can simply be dropped into the current version of Meteor, which makes installation and use very easy.
Given it’s sub-optimal performance, a lot of people dismiss MongoDB. That’s fair, and it’s one of the better things about Meteor – you can ignore what you don’t like and use what you do. However, if you’re developing using Meteor, it’s worth your time to look into whether you’ll need to index the queries used in your project to make sure they don’t need to be entered into the MongoDB. This won’t necessarily be required for every app out there, and in fact, there are a lot that don’t need it. However, if your app is the kind that does require indexing support, not doing it properly can really make your app’s performance plummet. There’s an official guide available on the Meteor homepage that can walk you through what apps do and don’t need this kind of indexing.
In terms of communicating commands and other things throughout Meteor’s structure, these communication models are once again built on top of MongoDB. This means that they persist throughout the database, which is fine in a lot of cases. However, sending all communication through the database is a recipe for very poor performance and overtaxed performance assets. There are a lot of times that persistent communication simply isn’t necessary and you’d prefer to work outside the database. For these situations, you can use a service called Meteor Streams, which directly communicates data between two specified points in the structure or between servers and clients. Meteor Streams is available for free on GitHub.
One of the limitations of Mongo is that it doesn’t support features organized into arrays. This doesn’t prevent you from using them, or prevent them from functioning, but the code on those lines works outside of the normal structure of the project. As a result, it takes a lot more power to go through them. Updating to another service like Smart Collections is probably the best idea if you have a codebase that uses a lot of arrays.
Like arrays, nested objects aren’t supported by MongoDB. This means that using them efficiently means going beyond MongoDB and finding another service that can parse them correctly. Fortunately, there are plenty out there to choose from that can work with nested objects.
Filtering is a process that scrubs out junk data and smooths things for the transition from server to client side. It’s a useful and important process that’s necessary for server-client communication. It speeds up traffic between server and client by eliminating useless data before it’s sent. However, it’s important that you only filter things that are actually traveling between the client and the server. It’s a taxing process, and one that you don’t want to waste time on if you can help it.
In a similar vein to field filtering, managing subscriptions can really help your performance. Meteor automatically keeps a copy of each document that relates to server use or subscription to the server. This is a process that saves bandwidth, especially in cases of heavy communication. However, it’s possible for subscriptions to become bloated and over-full. In the long run, this can increase the server’s RAM usage. Paring down subscriptions is a good way to keep that from happening.
Websocket is the tool that’s used for a client to connect to the server. It offers a direct link between the client and the server, and it’s the main point of connection between the two, and the main way that users experience your content. However, it can also slow down your app if it’s activated in situations when it doesn’t need to be, namely when it’s not in use. You can disable Websocket in this situations, which will preserve processing power for other tasks.
This final point is sort of a situation of built by association. Meteor, as you know, is built on top of Node.js. Node.js is notoriously bad at serving static content, which means that Meteor is also bad at doing that. Fortunately, there are services out there, namely CDNs or proxies that can bypass the parts that Meteor are bad at. However, you don’t want to overuse these because they’ll slow down your app a ton if you rely too heavily on them.
These are just a few tips about how to make the best apps using Meteor. Hopefully, they’ll help you the next time you try using Meteor to create a web development project!