Looked great! Yet since then, talk of Blaze 2, React, GraphQL, WebPack, Routers, etc. have overshadowed the SQL discussion. I know it’s not a sexy addition; yet so vital.
Even MongoDB has added join support in 3.2, apparently for “enterprise”. It is still a far far galaxy away from Postgres. While storing massive amounts of data over long periods of time can mean adapting to ever changing data structures; I feel the main meat of an application has to be reasoned about not slapped together on the fly. The core is almost always relational. Relational is rational.
Anyway, I just wanted to keep the SQL discussion alive. I really enjoy working with Meteor. Alas, besides for prototypes, too often we go with a different solution because the SQL story isn’t complete.
Many Meteor devs are focused on the front end story. There are a lot of people at bay who don’t come on these forums to voice this who would otherwise be here if SQL was officially supported.
Before Slava left, I recall there being dialog between him and the RethinkDB team. There were a few logging features Slava had requested.
It seems that RethinkDB will have these features soon, as of 2.3. RethinkDB is another great database with goals in-line with relational and live data for modern apps.
And if anyone wants a concrete example of how GraphQL and SQL can work together (MySQL, Postgres, SQLite), take a look at https://github.com/vaffel/sql-to-graphql.
Again, GraphQL is a protocol specification on how to communicate with a data store from your app not the underlying technology or method by which your data is stored.
I don’t think SQL will be overlooked - its very attractive for marketing purposes, and still the #1 requested feature. It should come soon as we get NPM support for Meteor. The question of whether or not we’ll get LiveQuery for MySQL remains in the air.
Thanks for the share. GraphQL is interesting for sure. It is however independent of both RDBMS databases and live applications. For our organization, GraphQL doesn’t offer much benefits; REST does a fine job. Even React isn’t so necessary for us; Backbone and JQuery can still solve problems. I do see benefits in both GraphQL and React; it just not as fundamentally important as having a relational back-end.
It is a well though-out real-time data over the wire combined with a good overall framework + platform that gives Meteor so much appeal.
It seems far fetched that an independent NPM package would integrate any better than the existing Postgres solutions for Meteor. Perhaps you can shine light on this? After all, we can just utilize REST endpoints and talk to a relational backend without any specialized packages.
I just want to raise awareness for how important it is for many developers. Relational database support directly from MDG and inherently integrated into Galaxy is a highly desired feature.
You should be able to use other databases with the promise pollyfill and a driver that uses promises. Returning data in a meteor method is easy. Using that in publications is not, but something like any:DB makes publishing easier.
Since its not realtime anyway you can use meteor methods to fetch data and then store them in a local minimongo to consume data the normal way.
SQL is coming in Nodechef’s Meteor hosting solution. We provide extensive SQL select coverage, joins, transactions and much more. You cannot create tables per say but you can use documents to model
tables and use the mongoDB collmod (v3.2) command to enforce a schema on the document. http://nodechef.com/features
I mentioned this in a different thread, and we’re working on some prototypes/plans to make this more concrete, but here’s the general idea:
It should be trivial to add support for any data source to Meteor. The current architecture basically has Mongo baked in to multiple layers of the stack, and couples a lot of things that should be opt-in. For example, in the current architecture it’s not possible to have optimistic UI without livequery.
We need to refactor the Meteor data system to let you fetch data from any source (database or API) with minimal engineering effort. This should support optimistic UI, manual invalidations, and polling out of the box. Then, if someone wants to go through the extreme amount of engineering to support live queries for a specific database, there can be a hook for that.
If we can accomplish the above, then using almost any database in a basic way (no optimized real-time data streaming, but it works for most normal applications) should just be a matter of wiring up the appropriate NPM package.
Right now things are a bit slowed down for the holiday break, but expect more in the new year.
I would be happy to have any database available that has referential intergrity for parent-child relationships. we have a number of mysql db’s where a child can have multiple parents. its really holding us back from making the switch to meteor.
Sounds like good news! Would MDG consider directly supporting Postgres or RethinkDB as a relation solution for live data? This along with the core packages, like Accounts. Slava’s RethinkDB efforts seemed to hint at this. It would be super awesome to have a real-time solution for relational data.
There is effort external effort for connecting to RethinkDB from the client using React. Sort of reminds me of the original Meteor demo with MiniMongo in the browser. They compare this product directly with Meteor.
The one thing that a direct-to-client RethinkDB, Parse, or Firebase solution won’t give you is a way to merge data coming from different sources or services. It is totally reasonable to keep some of your data in Mongo, some in an API server, and some in some external service. We need to support that use case as a first-class citizen, especially in a world where many apps are built as a REST API server on top of many microservices. Loading data directly from the DB isn’t going to cut it.
I feel like GraphQL is misnamed. People hear the name and they’re like “oh crap graphs? is that like a graph database??”
In reality, it’s the exact same thing people are doing with packages like publish-composite in Meteor already, just in a more compact and standardized form.
Perhaps once people become more familiar with it the name will be less concerning.
