Migrate accounts which is mongo-reliant to rethinkdb
Use Mongo-style query server-side to make queries to rethinkdb for backwards-compatibility (and because I dislike ReQL, but that’s personal)
Both were very lofty goals and we seemed to going in circles everytime a new unsupported mongo query pops up. Not easy going from string style query to functional queries. I’d be happy to share our code base but it’s far from production-ready and I don’t want people to be mislead. I would rather stake our future on redis-oplog than rethinkdb, as redis-oplog uses existing structure of mongo reliance and adds a layer on top, while using rethinkdb the way we wanted to was a monumental undertaking require forks of core packages.
We based it on https://github.com/Slava/meteor-rethinkdb which works well btw – but depends on customization of a library for client-side queries that will likely not be updated. So you can use that and be on your way (we found no bugs in it, it may just not have all the things you need, try it)
I’ve also noticed a void of documentation in specifically integrating Apollo with Meteor. Part of the confusion is probably attributed to the plethora of solutions/documentation available now?
However, I was pleasently surprised on how seamless it was to integrate Apollo into an Angular2 Meteor app. I’m sure the same thing can be said for React, Blaze or other clients?
Copied the front end code from https://github.com/apollostack/frontpage-angular2-app "Angular2 App"
I couldn’t get this Angular2 app working. There’s some Webpack/Angular2 error breaking many things??
“Module build failed: TypeError: Cannot read property ‘exclude’ of undefined”
Creating an Apollo integration for meteor is a strategic action for meteor survival but they are postponing it and the result is increasing ‘To be or not to be’ posts in forums.
Totally agreed. Integrating Apollo into Meteor today isn’t that bad, it’s just not the 1 line meteor install apollo that meteorites are used to. It’s a hassle keeping all the deps in line after upgrades but doable if GraphQL is a need.
However, the build perf is (was) horrible and is something that I considered switching the Meteor stack for. It was getting to the point of costing $1 or something for every reload lol. Deploys took 10-15 mins depending on the Meteor version.
The increased perf in 1.4.2 is greatly appreciated and additional gains here will drive a much larger impact than an easier GQL integration
I second this. I don’t recall which patch it was, but I suddenly saw a HUGE boost in build performance while working locally. I can’t tell you how much that’s increased my productivity. Not just because of the wait time, but in some cases the long build times resulted in something like this:
Me too. I’m currently in the progress of migrating a meteor+blaze+ddp project to meteor+blaze+apollo, using @jamiter’s blaze-apollo package. Planning to deploy it next week and then write a post about it.
It’s for the Dutch Hour of Code initiative to teach children how to code. The neat thing is that it’ll open up a part of the GraphQL ApI to the public. If you’re interested, let me know!
Just upgraded my app to Meteor 1.4.2.3 and was shocked at how fast the rebuild times are now compared to 1.2/1.3. Good job MDG and thank you! @thea@sashko
@benjamn Well, thanks for the huge rebuild-time speed improvement! I’m curious, is there something the developer (me) can do to take full advantage of whatever was done under the hood? I still have a bunch of files in /client that I could move into /imports and then export/import. Aside from tidying up, would that help rebuild times? @sashko
Hi all, as @sashko mentioned above, the best way to keep tabs on what Meteor project maintainers are working on is to take a look at the roadmap on github (which is now updated monthly or after major changes) , or the most current release branch.