If you’re a veteran in the Node.js/SaaS community, you probably have not seen the name Meteor.js in a while.
Meteor.js is a Node.js framework that first appeared back in December of 2011 with the project name Skybreak.
Meteor.js pioneered many concepts junior full stack developers may take for granted today, such as:
When designing the architecture for a new piece of software I always think of it from a perspective that I am creating a business.
After all, when I build applications I am building it to solve a problem. Which at it’s core is what every business is. A solution for a problem.
The success of that business depends on two factors:
A quote that I frequently read from successful SaaS founders is “Build fast, and ship often.”
This advice is valid when you consider the opportunity cost associated with long release times of software.
User feedback can optimize your development scope by focusing on engineering features and functionality that provide more value for the user.
Two things you can take away from this advice:
If you are developing an application, there are some features that are universal. Things such as user accounts, email communications, data fetching, access control, etc..
Meteor.js includes these universal features out of the box utilizing industry best-practices.
As a developer, having access to these features as soon as I start a Meteor.js project I am able to prioritize development of the application’s business logic; or value creation.
What I mean by value creation is the unique features and functionality of the application.
This enables me to launch products at lightning-speed to learn if the product is going to be successful… or not.
One common misconception is that Meteor does not scale. This is both true and false.
Meteor.js is a Node.js framework. Meaning it is just Node.js under the hood.
The community believes that Meteor does not scale because a lot of developers leverage Meteor as a monolithic application.
Meaning that in order to scale their applications, they often have to vertically scale their cloud instances.
One arguement you can make is that you do not always have to vertically scale your application. Another option is to horizontally scale your application by launching multiple instances of your application.
Both options are valid options, however there becomes a point in the scalability of your app where you meet an equillibrium.
What I mean by this is that if you have an application that has a minimum resource constraint, for example 1ECU and 2GB of memory. You can spin up as many instances of that vertically-sized stack… horiztonally.
But from a business perspective this might not make the most sense because the vertical-stack constraints may be caused by a particular function, or feature, within your application.
This is what makes Meteor a great option for start-ups.
Let’s say you build your application extremely fast because Meteor allowed you to not “re-invent the wheel” with fundamental application functions.
You now have your application live and your userbase is growing quickly.
You have a new problem on your hands, trying to scale your application without breaking the bank.
In the previous section I mentioned reaching the vertical and horizontal equillibrium of a monolithic application. At this point it is time to introduce MicroServices to your DevOps.
For my example application I have 3 pages:
The obvious outlier of the 3 pages is Page 2 which is causing the instance size to be twice as large as the other two pages.
The answer is to extract the business logic from your application and create a MicroService to only provide that function within your app.
You can utilize serverless solutions to provide access to this MicroService in an even more cost-effective manner.
This is a very common project structure for Node.js applications. By isolating the server-side business logic of the application from the Meteor Method, you are able to easily extract the service from the monolithic architecture of Meteor into it’s own service; resulting in a plug-and-play implementation of MicroServices to enable horizontal scaling.
I often rewrite services from Node.js to Rust/Golang when required to optimize resource utilization.
I choose Meteor as the starting point for all my applications because of three reasons: