Hi!
I just got startet with Meteor, and I have never used Mongo before. So Im wondering, how is MySQL with Meteor? I guess it does not have the reactivy like Mongo?
You can have reactive MySQL with the numtel:mysql package.
Alternatively, you can get non-reactive MySQL with the npm mysql package, but you will have to wrap the calbacks with Meteor.wrapAsync to use with Meteor’s server-side fibers/futures.
Thanks. What about the speed compared to mongo?
One more thing to consider if you’re planning on using mysql (or any SQL based data store with Meteor). MDG themselves are putting a significant amount of their resources behind Apollo, which can leverage any type of backend by wrapping access to it via a GraphQL server. It’s only a matter of time before any of the existing Meteor + mysql packages are no longer applicable / usable with modern Meteor versions. If you’re planning a new Meteor project that uses mysql, you might want to jump on the Apollo bandwagon sooner than later.
I strongly disagree with @hwillson.
My business embraced Meteor in early 2015. Since then, we have been using it with MySQL for our webapps and it works beautifully.
Originally, we chose to use MySQL instead of MongoDB for interoperability with our legacy LAMP-based solutions, but since those were retired, we have continued to use MySQL with Meteor on its own merits. Please search the forums for my previous posts where I have written at length.
We have also been actively developing the wj32:mysql and vlasky:mysql forks of Ben Green’s numtel:mysql package.
These packages differ in the way that they handle the data, but all of us developers collaborate with each other.
numtel:mysql treats MySQL result sets as arrays and uses an array-based diff algorithm for updates.
wj32:mysql was worked on mainly by one our developers named Wen Jia. It treats MySQL result sets as dictionaries and uses a user-defined key selector algorithm. On the client side, data can be stored in the standard MongoCollection.
vlasky:mysql is my experimental fork of Wen Jia’s package, in which I have replaced the older node-mysql library with the newer node-mysql2 library, which supports prepared statements and offers higher performance.
I see the prepared statement functionality offering the following benefits for Meteor/NodeJS:
- Avoiding the overhead of MySQL parsing, resolution and some optimization on the frequently repeated queries used for publications.
- Providing immunity to SQL injection (current approach of argument escaping is resistant, but not immune)
- Prepared statement results are returned in a binary format instead of text-based format, reducing the amount of data being transferred and parsed by NodeJS.
I will share more news/updates about using Meteor with MySQL as soon as I have more time.
5 Likes
Actually @vlasky, we probably agree more than you think 
.
I’ve used mysql with Meteor successfully as well, and have really appreciated the hard work the community has put behind its integration with Meteor. I just wanted to add another view point on this however, since MDG themselves have shown us their plan for moving forward with other databases. Apollo is their plan, and it should be considered when planning new Meteor based apps. I’m saying considered though, not necessarily adopted (yet). If you’re happy using one of the current Meteor + mysql approaches, then great! (I am as well) It’s just that it’s only a matter of time until Apollo replaces a lot of what we’ve come to know as Meteor (watch @debergalis’s recent talk for more info). At that point community supported mysql packages will have a lot of work ahead of them to adapt. Maybe they will - which will be awesome! I just think it’s important to consider where MDG is heading, and what their plan is for handling non-mongo based data sources moving forward.
1 Like
I think the point of my reply was that @dirkdiggler41 seemed to be interested in reactive MySQL. I’m quite certain that Apollo will deliver on that eventually - maybe this year. In the meantime, there’s a decision to be made, and if the requirement (if there is one) for reactivity can be shelved, then Apollo is a good choice today - and @pcorey says here that this also removes a significant attack vector.
2 Likes
You’d need to do your own benchmarks based upon workload and how you’ve configured your databases. You would be better advised to look at your data requirements and relationships to choose the best engine for your use case.