Meteor is alive and well! In 2015, my business implemented a Meteor-based real-time vehicle tracking app utilising Blaze, Iron Router, DDP, Pub/Sub - features and packages that a vocal minority of misguided people seem to want to kill off or at least disseminate Fear, Uncertainty and Doubt (FUD) over.
This anti-Meteor FUD is being spread for the following reasons:
1) Someone doesn’t know how to use the Meteor feature properly or have the engineering/computer science background to design a system to be able to manage computational complexity or scalability.
2) The Meteor feature or package is stable and mature so it hasn’t been generating much news or required drastic updates.
3) A competitor wants to promote a Meteor or Meteor package alternative that they have a vested interest in and are trying to manipulate people by creating self-fulfilling prophecies to kill off rivals.
Our Meteor app runs 24hrs/day and handles hundreds of drivers tracking in every few seconds whilst publishing real-time updates and reports to many connected clients. Yes, this means Pub/Sub and DDP.
This is easily being handled by a single Node.js process on a commodity Linux server consuming a fraction of a single core’s available CPU power during peak periods, using only several hundred megabytes of RAM.
How was this achieved?
We chose to use Meteor with MySQL instead of MongoDB. When using the Meteor MySQL package, reactivity is triggered by the MySQL binary log instead of the MongoDB oplog. The MySQL package provides finer-grained control over reactivity by allowing you to provide your own custom trigger functions.
Accordingly, we put a lot of thought into our MySQL schema design and coded our custom trigger functions to be selective as possible to prevent SQL queries from being needlessly executed and wasting CPU, IO and network bandwidth by publishing redundant updates to the client.
As we know, Meteor is tightly integrated with MongoDB which we did not consider to be well-suited to our needs. Did this result in us ranting publicly about how Meteor and/or MongoDB are “dying” or “having no future”? No!
Instead, we found a way to embrace and extend Meteor - an ongoing task.
In terms of scalability in general, are we limited to a single Node.js process? Absolutely not - we use Nginx to terminate the connection from the client and spread the load across multiple Node.js processes. Similarly, MySQL master-slave replication allows us to spread the load across a cluster of servers.
In my view, the reason why Meteor is not more popular is because too few people are sharing their Meteor success stories and the MDG has not been doing much to promote Meteor publicly.
More people need to showcase their Meteor-based solutions and stories of success at technical conferences and developer meetups and events - especially those that concern NodeJS, MongoDB, MySQL, Databases, IoT and WebApps in general.
And what makes Meteor superior to plain Node.js development? We get much higher productivity from our programmers who can write less code and make fewer mistakes developing in Meteor compared to say using Node.js with express. Here are 3 benefits we enjoy:
1) Meteor's use of fibers allows a synchronous programming style whilst avoiding callback hell. Meteor has an easy to use facility Meteor.wrapAsync() that allows you to use run any callback function, e.g. from a third-party package, within a fiber. There is also Promise.await() that does the same thing for packages that use Promises.
2) The isomorphic design promotes code reuse between the client and server-side and simplifies client-server communications. You simply decide whether you want to implement a Meteor method or a Meteor publication based on your application's needs.
3) Meteor's inbuilt, easy-to-use data validation methods promote secure, robust code.
In summary, Meteor is much greater than the sum of its parts.