Hi guys, please don’t see this as yet another Meteor flame thread, I am hoping to get good insights from this. I’ve been looking into GraphQL for a few weeks now and want to start building a small side project with it to get familiar. Unfortunately Meteor tutorials are scarce, so I tried out the nodejs youtube tutorial from @helfer and without ever having used node before I was able to follow without any problems and node seemed very similar to Meteor in how you import / export stuff, run things, etc.
I am guessing the major plus points are or used to be the additional syntax, however I believe with 1.5 a lot of this syntax will simply be obsolete. Tracker won’t be used, pub/sub won’t be used, for most other functionality we rely on npm packages anyway, I haven’t used sessions in an eternity thanks to being happy with Polymer & Redux for moving states between components/views, the main things I appreciate are the accounts system, methods & being able to make http calls.
I believe most of those can be replaced with npm packages and other solutions like 0auth though. Given that I’m moving towards GraphQL/Apollo, the question I am asking myself what will be the benefits of Meteor vs. node. I am aware that with Meteor vs node you need to set up less out of the box, however what exactly are those things? Where is node a pain in the ass? Remember, I’ve only tried it briefly. Or in other words: Do we still need Meteor’s magic? Or once you’re an advanced developer, does it make sense to use node instead?
How is my developer experience different from using Meteor vs. node, given that I am a failry experienced developer? I think one of the great things of Meteor are that it exposed me to programming and helped me finally understand it as a non-technical person and that’s great, however now that I have moved past that barrier something like node doesn’t intimidate me that much anymore. Thoughts?
@sashko How do you see it? Where do you see Meteor going in 2017 for someone with my perspective?
Hey that’s a great question. First things first - if you like the original Meteor stack with DDP and Tracker, it’s not going away!
We’re using Meteor + Apollo for all of our apps and we love it. Basically it moves Meteor into more of a “platform” role - managing your tooling and programming language. Here are the things you use Meteor for when data is covered by Apollo:
Build tool + build plugins. I think it’s a really competitive offering and it’s getting better from a performance and feature perspective, especially throughout 1.4.x
Accounts
Testing
Server-side debugging and meteor shell
Deployment with Galaxy, if the product works for you, is super easy
Essentially it’s a stable target to build against which seamlessly transpiles modern JavaScript and runs some useful tools.
Oh sorry! I just forgot about it since I haven’t used it recently. That, plus some of the packages that bundle the app into Electron seamlessly for desktop apps is great as well.
sashko, will Apollo offer a seamless pub/sub experience built on top of GraphQL or will it just expose whatever GraphQL happens to have? e.g. right now there are subscriptions but they are not quite the same thing.
Also to use them you need to write your own endpoints on the GQL server which is not trivial.
If like you say Meteor is now to be seen as a platform, it certainly takes away from the ‘isomorphic js everywhere’ idea which was a Meteor value prop.
You know one thing I noticed was that you don’t have a roadmap for Galaxy, which I find very surprising. I’ve seen it in action recently while helping out a friend and I’m considering using it but given how outdated your docs were it made me wonder if you are giving any priority to Galaxy.
