Ive done one project with Metoer (+ React) so Im not the most experienced but I defiantly understand the basics. Even though I’ve loved working with Meteor I’m considering going with Graphcool + Apollo + React for my side project.
This is partly as I think GraphQL is a more marketable skill (I’m a developer). It seems better future proofing for my project. Id like to go serverless. Id like to have less lock-in with 1 system - I was shocked to see Meteor was pulling in jQuery to my project! I know you can stop this but it illustrates the downside to the ‘black box’ approach.
From having a quick look at Graphcool + Apollo + React it seems easy to set up a database with reactive updates. It has a few authentication services (Auth0 seems to be popular). Theres a bit of a learning curve with GraphQL and maybe some more wiring but other than that what do I lose by not going with Meteor? The reactive database and user accounts was the big win for me with Meteor so Graphcool seems like a more flexible and potentially more performant solution.
Well, in all fairness, graphcool is another lock-in. If you want to go truly vendor agnostic, and willing to maintain a large set of dependencies which don’t always play well with each other without some serious tweaks, you can go with a pure node/react/graphql set up.
Furthermore, coming from the developer marketability perspective, using graphcool will not mean that you will have experienced developing a graphql server, you’ll just have used a graphql client and a specific graphql server implementation.
I’d recommend a Meteor set up where graphql is your data api instead of Meteor’s data backend. This way, you’ll deal with actual code rather than dealing with tooling. And you can consider meteor as your build tool which takes away the pain of setting up transpilers and the build pipeline. Furthermore, you can always fall back on meteor’s data backend for things you don’t want to involve graphql, or even start off with a prototype meteor data backend and refactor to a graphql api if you truly mean to improve your skills as a developer.
GraphCool recently changed… you will have experience with a GraphQL server. GraphCool just flipped their business model and product around. GraphCool is now a database layer – abstracting CRUD operations and database migrations. It requires a GraphQL server with resolvers (in JS they have a graphcool-binding package for the resolvers, but once the other server packages fully implement SDL, it’s likely we’ll see GC bindings for other languages).
To the original question, I think Meteor is great for familiarity, build tool, and user accounts. But I’m on the GraphQL / React / Apollo / Gatsby / Netlify train.
I was indeed referring to the new graphcool. I mean it when I say it is another vendor lock-in if you see meteor as a vendor lock-in.
There’s no fundamental paradigm that graphcool offers that meteor does not and there’s no fundamental paradigm that might lead one to think meteor is closed that graphcool does not have.
Please take a moment to really reflect on that last sentence, this is so very utterly true. Not that it is a bad thing, but we should recognize what these products are and are not.
Both are amazing products, but they share the exact same strategy. It is just that graphcool is built around graphql and data while meteor is built around javascript and code. And then you go host either one on your own server or pay them to host for you for some bells and whistles.
Now the fact that meteor is built around javascript and code makes it more open and flexible in my opinion.
Then why say “using graphcool will not mean that you will have experienced developing a graphql server” when that’s wrong? You need to write a GraphQL server. GraphCool is simply a CRUD codegen and database migration.
And it’s not remotely close to the same amount of lock-in. Unless you consider, say, choosing Postgres as an equivalent lock-in to Meteor. GraphCool can be hardly used or used for everything. It’s up to you. And it can be purged completely simply by writing the types and updating/ migrating the database.
This same argument can be applied to its meteor counterparts where for you can easily say “you can move away from meteor simply by writing the foo and updating/ migrating the bar.”
Again, both meteor and graphcool provide/enforce the same amount of fundamental vendor lock in and my opiniated argument is that because meteor’s domain is “code”, its hooks allow for more flexiblity all the while letting you work with standard javascript without any abstractions to the javascript language, whereas with graphcool the graphql tier is hidden behind an abstraction.
To me, graphcool today is to graphqlwhat meteor used to be to javascript until 2 years ago.
Edit: I think I should clarify a few things because most of my points refer to somewhat abstract topics
graphcool is an amazing product which you should definitely evaluate as a serious option to graphql development
graphcool and meteor provide similar levels of vendor lock in im their respective fields which are different fields, though with potential overlaps
if you care about improving your marketable skills as a graphql developer, the abstractions from graphcool will “undermine” that goal just as meteor used to abstract too much until two years ago so much so that it “undermined” your javascript knowledge
meteor has had sufficient time to keep up and sometimes take the lead with javascript which had sufficient time to standardize/mature
graphcool is relatively very new in a field which itself is quite new and has not fully standardized/matured
meteor deployment today is a standard node deployment whereas graphcool deployment requires a special type of deployment target, although freely available amd not too hard to get running, not as widely adopted as node as a deployment target
I posit that going with meteor as a “build tool” to develop the server on standard graphql and the client with react in the same app is a better choice for the op to both learn graphql and have minimum to none vendor lock in from the get go as compared to using graphcool and a webpack+react set up.
Thanks for your answers guys but I’m still pretty confused! Is there a killer feature / fundamental philosophy change in Graphcool + Apollo vs Meteor?
Whats the reason / scenario that i should go with Graphcool + Apollo rather than Meteor, given that im finding the learning curve pretty steep whereas Meteor I didn’t struggle with.
Well then, that changes my suggestion because graphcool is by far one of the easiest options for you to go self hosted graphql server and if you find its learning curve steep a vanilla server on node/meteor (they are the same btw) might be even steeper.
You might want to give graphcms a try because its interface is very intuitive, simplified because it aims to be a cms, and then you can concentrate on learning the client part, once that’s done, you can move on to improving your server side skills.
But I hear you, graphql is not as easy to pick up with any tool. You should give it time. But you’ll realize that there’s an aha! moment to it when everything will suddenly make lots of sense
I think @serkandurusoy is just address your own requirements. If you want less lock-in and want to avoid blackbox solutions then I’d agree that Graphcool doesn’t seem to tick your own boxes. Personally, I don’t share your aversion to vendor lock-in–I was a Microsoft dev for over a decade. So Graphcool sounds fine to me. But it seems more akin to a Firebase or Microsoft Azure direction than going with more fully open options.
@ffxsam please do share your experience, perhaps start a new thread? The “promise” is amazing, but hands on experience on such a young product is invaluable to us all!
EDIT: Actually… now I can’t find the clause saying not to share screenshots or feature descriptions. But I’m pretty sure I read it somewhere. I just asked the product manager for AppSync if it’s OK.
I haven’t had time to write about AppSync yet… but I can say that it will be available to everyone (still in beta) really soon. Keep an eye on your AWS console!
Strange. They must’ve whitelisted it for you for some reason. It’s definitely not widely available yet, as of today.
So Graphcool sounds fine to me. But it seems more akin to a Firebase or Microsoft Azure direction than going with more fully open options.
The beta Terms of Agreement prevent me from sharing any details. But I would urge anyone to sign up for the preview! 
I’ll try to find time to post something soon.