There seems to be a fad in the Meteor forums to declare that a Meteor feature or package is “dying” or on the way out simply because:
Someone doesn’t know how to use the feature properly or have the engineering/computer science background to design a system to be able to manage computational complexity or scalability.
The feature or package is stable and mature so it hasn’t been generating much news or required drastic updates.
Someone wants to promote an alternative technology that they have a vested interest in and are trying to manipulate people by creating self-fulfilling prophecies to kill off rivals.
Well guess what - my business has 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.
I and other Meteor developers want this crap to stop.
I want the MDG and other package developers to know - you have done great work!
Your efforts are really appreciated and mean a lot to us. As the saying goes, hindsight is 20/20 but your design philosophy and implementation decisions have largely been correct. Meteor is a good product and is greater than the sum of its parts. Don’t listen to these whingers who are trying to make you second-guess, question all your decisions and abandon your previous work.
Our Meteor app runs 24hrs/day and has hundreds of drivers tracking in at least twice a minute 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 our production server - an off-the-shelf Linux VPS running CentOS 7 - consuming a fraction of a single core’s available CPU power during peak periods and 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.
We look forward to additional performance gains through upcoming Node.js v6 support and other optimisations.
And React? Apollo? GraphQL? Even Flow router? Don’t have any need for them at the moment. Sorry.