Hi!
Why exactly is Mongo and NoSQL used for Meteor’s Collections and pub/sub patterns?
Is it bc the JSON documents are easily serializable and makes Tracker’s life easier for Reactivity and optimistic UI?
Why can’t any benefits still be done using traditional RDBMS?
There are folks using it with SQL, you can find some packages here.
Meteor and MongoDB were growing at the time same and both were doubling down on JS ecosystem, so it made a lot of sense to start with it. Personally, coming from Java/SQL, I don’t want to see another ORM layer and data plumbing again, just JS objects all the way, the value is clear and can’t be ignored, many popular RDBMS started supporting JSON type for that reason.
Furthermore, the tight integration has proven to be very useful in many ways. The go-to example is Meteor accounts. Another interesting use case I encountered is job scheduling, you can find several packages (I’m using wilhdart: jobs) where you can add a job scheduler to your app in one command. Again, this is only possible because of the tight integration with MongoDB. Going even further, with Blaze, you have some packages that go all the way from the UI to the DB which is an incredible (and unparalleled) boost of productivity, no other framework comes near that.
Also, another interesting side-effect is that the tight integration enabled the creation of a community with a more or less similar stack that can share knowledge and experiences.
Finally, for pragmatic reasons, I don’t think Meteor team had enough resources to support various databases, the core/original team was pushing on so many fronts, and I think it was hard for them to officially support SQL without being stretched very thin.
Anyway like I said, there are folks using it with SQL successfully for several years in production.
All good points, thanks!
Mongo is life.
The Meteor/Mongo combination is perfect because everything is JS.
Other language/framework/db pairs grew up together, like PHP and MySQL. They were a successful example.
In all my new projects I use Mongo. SQL only to legacy systems integration.
Probably because it’s all JS. So the querying API exposed inside a Meteor app (Collections.find() etc) is extremely similar to how you actually query Mongo natively. So there’s not really much of a translation layer needed in the middle.
But also MongoDB was reaching peak hype at the time Meteor was released and the downsides of using a docstore when a lot of people mentally model their systems relationally probably hadn’t been fully fleshed out.