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.
@msavin I’m not sure how NPM support will offer
- Real time “live query” for Postgres
- Optimistic UI / latency compensation.
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.
1 Like
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.
It’s not easy but I’ve done this with rethinkdb.
Can’t wait for the real implementation though !!
2 Likes
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.
9 Likes
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.
2 Likes
lol no. I can’t name a single company that uses graphql, except Facebook of course.
Kadira uses it. So that’s at least two, now.
5 Likes
First time hearing the name “GraphQL”. I’m tired of googling spooky names each day. GraphQL? Wooow! Its hard to keep up these days for me…
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.
3 Likes
True.
RethinkDB could “rethink” filling that void somehow. Perhaps by implementing methods similar to Meteor’s methods from within the database that automatically scale with the database. Sort of like the concept of stored procedures only over Sockets.
Meteor being tied so strongly to Mongo is practically acting like a dedicated product for it–what RethinkDB could implement for itself one day. Meteor adds value to Mongo, possibly more value than itself as an entity (I’ve read MongoDB is valued at over $1.6 Billion, Meteor as a real-time platform dedicated to Mongo could feasibly be worth more to MongoDB than Meteor’s current valuation).
What would be powerful is if Meteor, as a Javascript platform, would provide an API to package authors. The Accounts package written with the API could automatically “Just Work” with whatever the database is in the supported stack or at least degrade nicely.
It sounds cool. If I’m correct, on the front-end, we’d put up the query for the data we need, and on the back-end, we would define where that query needs to go to get the data. I imagine it would be like a standardized way of writing a method and calling it.
Meteor MySQL support is rapidly improving!
Since April this year, my business has been using Ben Green’s numtel:mysql package in several production systems handling real-time data, performing reactive updates. My business has contributed fixes and enhancements to this package and we are about to announce a few more.
For example, it will now be possible to subscribe to a published MySQL query using Meteor.subscribe(), just like you would with a published Mongo Collection. The user can choose to use one or more fields in the SQL result set to be used as the substitute for the Mongo unique document id. Alternatively, the numerical index of the row can also be used as the unique document id.
MySQL 5.7 was recently released and one of its most exciting additions is support for a JSON datatype. This will make it much easier to give Meteor MySQL support for popular packages like Accounts (accounts-base).
We see a bright future for enterprise apps that leverage the strengths of Meteor and MySQL.
5 Likes
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.
This post is going to look like a shameless plug- but I made it nonetheless in the hope that it can spark a bit of cross-pollination. What you describe is exactly something we’ve been working on for 4 years, and it would be criminal to not at least share our ideas.
Our project is called Corto, and is an MIT licensed, backend data management API designed for building microservices. Corto combines data from multiple sources while providing a uniform (typed) API, whether data is realtime or “at rest”. Adding new connectors is very easy, by implementing a so called “replicator”.
The Corto API supports:
- Data replication using CRUD
- Poll & merge data across different data sources
- RMI that “hops” automatically to the process where the object “lives”
- Object hierarchies
- Object graphs (references)
- Object invalidation
- Realtime notifications
- Automatic plugin-based translation between representations (JSON <-> XML <-> binary <-> ???)
- Caching remote data (for example, store result of remote REST queries)
- Persisting local data
- A shell for exploring the Corto datastore (& stores connected to it)
Noteworthy roadmap items:
- Request object history across different data sources
- Perform queries at the source across different data sources
- Data units (miles, km, Celsius etc)
- The ‘directed state’ pattern ( a “richer” latency compensation w/request vs. actual values)
We’ve recently developed a DDP connector that makes it very easy to communicate with Meteor front ends, demonstrating that the two frameworks can be quite complimentary.
The API is written in C and low-footprint (~300kb). We’re finalizing v1, after which the focus will be on growing a connector ecosystem. High on the wishlist is integration with time-series databases & mongodb, as well as popular REST interfaces like fitbit & the likes.
Since it’s in the interest of both Corto / Meteor’s users to have a rich (data-centric) connector ecosystem ASAP, it would be great to have our communities join forces.
Finally, to give you an idea, this repository shows a simple Corto replicator. This repository shows a replicator that seamlessly ‘mounts’ a filesystem into the Corto store. This repository shows how Corto handles realtime updates. For a deep dive, see the Corto core specification.
2 Likes
Thanks for sharing!
I see you guys have a Let’s Encrypt certificate for corto.io–I believe you guys need a certificate for WWW.corto.io as well. 
to be sure what’s wrong with mongoDB because i don’t care to learn, and i’ve read that NPM is supported before the topic was created.
Whoops. Good catch! We’ll get that fixed ASAP