Graphcool can lower the learning curve. Our apps aren’t large, but we have a lot of integrations. Benefits of GraphQL include:
Thanks @maxhodges. Are you using Graphcool with Meteor? it’s looks like BaaS platform, any references I can read?
Playing the devil’s advocate, in your example, can’t I just return a JS object with a similar structure after calling JS method? don’t we need to write resolvers/mutations for those queries which are essentially just JS methods. Now I do understand that we’ve a clear and well defined middle layer data schema that can act is a flexible endpoint, generate docs and debugged with cool tools, which might be essential for facebook like platform or other complex apps with many type of potential clients.
But again for small to medium size apps, do we really need the extra layer when all we require is set of backend methods calls?
Sorry for my little dose of scepticism, it could obviously be misplaced.
no, we are working to redevelop our three Meteor apps with Vue + Apollo + Graphcool (without Meteor).
It’s more like this: say I need to pull data from MongoDB, Stripe, Quickbooks API (order and line item details) and Amazon S3
That’s a big waterfall of db and API requests you’ll need to make via a lot of arbitrary code in Meteor methods. GraphQL provides a more unified way to handle this stuff–a single query language that can integrate data from multiple sources.
Maybe this kind of stuff just doesn’t apply to you, but along with basic (and not so basic) db queries we have integrations with a lot of API–everything from postal rates, currency conversion, and accounting APIS to image storage and transforms, Contentful (CMS API), and payment processing.
Thanks Max, I think we’re getting a bit off topic, but let’s give this one more round 
Again playing the devil advocate here, looking at the all the 12 steps it seems we can get them all done within the context of one API method "payOrder(customerDetails) which will then delegate all the other calls, so how does Graphql endpoint help here, am I missing something?
I think diagram you shared looks like an API gateway pattern, this could be done with plain JS objects and methods and a microservice, perhaps GraphQl/Apollo makes this pattern easier to implement and maintain.
My initial scepticism is specifically toward the folks who’re ditching the simple JS RPC methods to a GraphQl gateway API pattern while also being vocal on why we all should jump on that boat when all they need might be able a simple CRUD akin to that of a todo app which could have been done with few well designed methods.
But that doesn’t seem to be your case, it seems that you guys truly need an API gateway, It looks like you’re working on pretty neat stuff
For one, you get a unified query language. You use the same query language to get data from Mongodb, SQL, or a REST API like Quickbooks or Stripe.
Secondly, you can actually pull data together from multiple sources (a database and a couple REST APIs) in a single GraphQL query. Without GraphQL, in Meteor, you’d have to make three different queries, one for data from MongoDB, one for Quickbooks and one for Stripe. You’d get three sets of data (and probably more data fields than you actually need from the REST APIs) which you’d need to synthesize (map-reduce) together. GraphQL basically does that for you; returning just the fields and structure you asked for.
Maybe just start by watching a few GraphQL tutorials. That’s as much as I’ve done!
To be honest, my 12 step call would probably involve a job queue, since some calls could fail. So maybe it’s overly complex for an example.
But sure, you can build all this stuff in without GraphQL, as we’ve done for the past few years. You could use REST, SOAP, JSONSchema, RDF, Swagger, CORBA, JSONAPI, etc too. For our particular needs GraphQL adds a lot of value. You have to invest some time in setting up your data model and defining relationships, but once you do that, you get a big benefit in being able to use GraphQL. The query tool shows you what entities and fields are available (and their types). I’m using GraphQL to query Contentful (headless CMS) for a static site, and it’s a really query technology. Again just watch some Apollo videos on YouTube. There are a bunch.
Also, you don’t need to rewrite your whole app to get started with GraphQL. You can take an incremental approach and “try before you buy” by just using it for one feature or entity, like an affiliate program, or shipping history, etc.
But depending on your problems and resources your mileage may vary! As with any proposed change, you need to weigh the trade-offs and ask yourself:
Thank you max for sharing your knowledge and perspective, I really like your trade-offs questions!
Guys this has become a Vuejs thread as if thats the only issue meteor has had. As someone that represents a company that has had an eye on Meteor for years but never committed to it I can tell you some of the other reasons if you can take hearing it.
The first time we tried Meteor it was awesome and I do mean AWESOME at productivity. It was Rails level and beyond and we were excited untl we realized
It downright SUCKED at scaling. With all of its productivity it asked the user to take the performance hit even on apps where reactivity wasn’t needed for eveything - no non hack turn off switch we could see.
So we kept watching. I was so certain that the people at MDG were so brilliant (for what they had created) that they would solve such a basic issue as scaling in a reasonable amount of time. We probably would have still took the hit but then - the blaze announcemnt made us realize that meteor was going somewhere it had not yet reached and the destination of what that would look like was uncertain.
No one wanted to jump onboard a framework on its way to something else and therefor in limbo. It even made existing training somewhat deprecated until new training solidified (but when that did - again MDG was in the huge transition to Apollo). React was a lot newer and at the time seemingly more complex - and for the joy of working with a framework that couldn’t scale and which we HAD to use Mongo only? Nah, and we knew those were real issues facing many people because Classcraft year after year was all we could find as anyone doing a wide deployment.
but I still kept an eye on it . I kept hearing about finally being able to use other databases with Meteor through apollo but that sorry…took a long time…and I as stated I don’t even have the sense of where Meteor is going now. From the outside looking in and wishing it had gone along the path of greater productivity it seems meteor itself is heading toward just being a build tool - not anywhere in the vicinity of the fantastic integrated full stack ecosystem that caught our attention.
MDG never checked off those downsides of the platform. These weren’t secret issues that people had. MULTIPLE times - almost year after year - people complained about scaling and using other databases and yeah why not use vue (and anyone claiming now that was not a boat missed with Vue’s ever growing popularity - which would/could of all been married/associated to Meteor - you are just kidding yourself) and all I could do is watch as the sands of times passed wondering when the proposed solutions would get here. So Blaze was a part if it but not the whole ball game.
So from where I sit (and I know less of it than the regulars so its a view of a non adopter - but wisher) again in Apollo and meteor integration something is about to come into fruition and it looks to me like its Apollo and a - build tool?
So I am going to go with meteor for a build tool??? thats not very exciting, and even so, Vulcanjs seems to be giving a better picture of where things are headed than MDG.
So yeah in the interim we committed to laravel for some projects. It had less to do with Vue than this thread lets on. Otwell always with every release knows where he is going and they get there within a year. Its anice well thought out integrated ecosystem. Like rails he seems to have a vision of development and programmer productivity that Meteor started out with.
Again thats the view from outside why at least from our perspective Meteor doesn’t get that love (and someone can trash it because they are on the inside and know more than we do). To me Meteor was poised to take the developer happiness and productivity of Rails to a whole new level in the faster more performant JS world and then said - ummmm…nah.
I blame no one for this really. Its just the way open source works. We often don’t understand the monetary pains of open source when the company backing something has to make money from it rather than having another predominant income stream like FB and Google or even Rails where its used in the real money maker app (basecamp in DHH 's case). Thats a A TOUGH TOUGH road to travel.
I do keep lurking though. Hoping one day MDG will knock my socks off with a little bit more than - meteor is a good build tool.
@manthony, I used to worry about the platform we were using, paranoia that it loses love and we get stuck with code we don’t know what to do with.
We finally embarked on Meteor (see below reasons). You rightly mention two issues: mongo and scalability. We may want to switch out of mongo at some point, and hope Apollo gives us that. Scalability on the other hand is already resolved with Redis-Oplog.
Our reasons:
We haven’t regretted our decision - we just have to accept that there is a lot of noise. In fact, most successes with Meteor aren’t even on this forum, they are too busy being successful
Thought I would share from a commercial standpoint (real company, real product, real customers, really happy)
Hey Ramez,
I think that the activity of this forum proves Meteor works for a great number of people. I was just giving an outside opinion given the nature of the question in this thread. To me its not an issue of paranoia. Its just rationally weighing the options at a great time in programming when you have so many options.
Is Redis-Oplog THE solution though or is it a temporary work around until Meteor and Apollo is fully integrated? If I were MDG (and committed to Meteor) I woud be shouting from rooftops about a now scalable Meteor - given the known rep it has accumulated for not being scalable. I haven’t seen that. Meteor, in my opinion, still has the same feel I have had of it for years - its on its way somewhere else that hasn’t been fully revealed yet. If there were no other stable productive solutions then we would jump in - but there are so I suspect thats why theres a question of love.
Anyway thats just an outside perspective. I know being fully committed adopters you guys could probably and rightfully point out all the solutions . I’ve just given a perspective from the people leaning forward on the fence and why they might not have let go and crossed over. Thats all. Said my piece.
P.S. Redis Oplog is a fantastic example of the power of open source. We came the closest we ever came to using Meteor because of it. Hats off to the developer.
Thanks for the thoughtful reply.
I too am surprised that MDG did not make a big story. As I am somewhat involved I know some bits and pieces. First, MDG mentioned in the past that its core customers on Galaxy were not interested in scalable reactivity. Secondly, they offered the author to write a blog post. He’s been busy and so have i (i was supposed to review it).
To answer the point on Apollo, last I checked, scalable reactivity was not a main objective, but a potential by product. I think in itself redis-oplog is the solution as it uses redis (so that you can use mongo as a dB). As long as you like livequery and mondo, this solution is solid.
@manthony I’m the “creator” of redis-oplog (along with many awesome people from the community), and it’s not a temporary solution, it simply scales. But there are other problems with Meteor that made them search a new Data Layer: locked reactivity to MongoDB, every Meteor project’s API is different, not much support for different databases, no self-documentation tooling, complex to properly use Meteor’s client outside Meteor.
I’ve been studying Apollo & GraphQL in depth for the last month. Long story, if you believe it’s complicated it’s because it wasn’t explained properly, heck, we thought Meteor was explained badly so we created http://www.meteor-tuts.com. I’ve held a presentation this Saturday on Apollo & GraphQL, in 1 hour people were already super familiar with it, and they could start their own project from scratch and use it. I’ve been reluctant in the past to learn it in depth because I thought “it’s complicated” and “Meteor is so simple”, but I realised it’s actually not complicated at all, and no-one would stop me from using Meteor whatsoever.
Keep in mind that Apollo is a facade, it’s not the business logic/implementation layer, it’s an API language. Much like doing RPC, this is why going Apollo doesn’t mean switching away from Meteor, nor avoid using it’s great tools.
I am now playing with ideas to make a package that would make Apollo use Grapher’s sheer power, and make use of RedisOplog to have painless reactivity in Apollo & MongoDB, because currently, to do that, it’s a bit too much boilerplate.
I don’t think Graphql is difficult. We intend on using it going forward but not necessarily with Meteor. I thought I had read it would facilitate a different pub/sub system of its own and hence have its own solution to scalable reactivity. Perhaps I read that wrong.
Is Meteor -tuts up to date including best practices for rightnow? I guess one of my other frustrations is due to bad timing I always came to update my knowledge of where Meteor was at a time when the docs and tutorials were not up to date (as admitted on these forums).
Yes, meteor-tuts is up to date and we’re actually planning on releasing a new update for it soon. GraphQL has a solution to scaleable reactivity because it doesn’t rely on MongoDB oplog (which was the main pain point).
Did you happen to record this? 
The name/concept “Meteor” seems to be overloaded and it’s meaning different thing for different people. I think there’re three concepts here:
Meteor as a Full Stack: if you started before 2015 or follow the Blaze tutorial, then you’re using it and it comes with Blaze, mini-mongo, tracker, DDP, many Atmosphere package etc. This stack is a league on it’s own in terms of speed and simplicity of development, great for starting quickly because you’ve all the layers of a web app integrated, perfect for learning, prototyping and small to medium size production apps.
Meteor as a Backend: if you started after 2015, switched blaze to other view layer and followed the guide with validated methods and minimal pub/sub usage, you’ll end up with this architecture. Here we’re using meteor build system and RPC methods powered with DDP but the client has been replaced with something like react, vue, angular, etc. If you don’t have complex API, integrating with only one client, and have few data sources and using mongo as a DB, yet you might change to something else in the future, then this is a great option to start with.
Meteor as a Build Bool: this is the closet you get to plain node.js project and this is how Vulcan.js and other frameworks are being built on top of meteor, they use meteor to primarily package and compile their files and maybe the accounting system. Most of development effort by MDG over the last years has been (in my opinion rightly) placed here, along with Apollo. The data layer can be rest, but who will go back to rest after DDP, so most likely it’s GraphQL and probably Apollo.
The fact that we’ve these options today, and that you can start with one and evolve to another is why I think “Meteor” as platform/ecosystem is much better now. These are not mutually exclusive options and I think they should all be embraced by the community since they really serve different segment of the market.
With regards to vue, again I think it should get the same level of love as react/angular and we’re not too far off. Better vue support willl surely increase meteor’s adoption as a backend and a build too along with Apollo.
Hey @alawi,
I love your post, just have a beef with this for “Meteor as a Full Stack”:
We have a “large” production app and are still using Blaze. We haven’t faced issues yet, so the imperative to switch to Vue is not urgent (but remains important) as our focus is on adding new features and covering more use cases. But … we are not outsourcing our development (except for one project with @diaconutheodor) so are not suffering from lack of UI expertise (not to mention that it’s easy to pick up).
This is the main thing… At the end of the day, even vanilla node apps get stuck with something… vue vs angular vs react OR feather vs next vs express OR oauth vs passport vs firebase accounts vs whatever… if you use meteor + apollo, then really you can leave it pretty easily if you actually ever need to do that. You grab webpack and switch you accounts to something else… not fun but hardly not the end of the world.
Let’s be real, you are going to “need” to re-write your app in the new latest and greatest thing in a few years… it doesn’t matter what you choose.
Let’s be real, you are going to “need” to re-write your app in the new latest and greatest thing in a few years… it doesn’t matter what you choose.
Maybe the hope is, if your app’s tiers are properly abstracted and concerns isolated, then you can rewrite certain parts of your app without having to rewrite the entire thing. No?
@GeoffreyBooth 2 months later is the savior of CoffeeScript still trying to use Meteor with Vue? Using CoffeeScript perhaps? Last time I asked you how your debugged your meteor coffeescript code you answered using Chrome Dev Tool.
But I just can’t manage to have it let me put breakpoints where I want inside the <script lang=coffee> ... </script> section of my Vue components. Most line numbers in the CoffeeScript code are disabled and among the few that are abled most put the breakpoint at another line that the one I clicked on. sometimes in comments or blank lines, 10-15 lines away. This is profondly frustrating back to debug with console logs
Do you think it is:
Do you have a solution for that?
I must say that the number of transpilers between the source code and the code executed in the browser is becoming overwhelming:
how many source maps are needed for all this stuff and how to properly coordinate their interaction?
I think it’s a akryum:vue-coffee problem. I think the bug is that .vue files usually have a structure like this:
<template>
<!-- . . . say 20 lines of HTML here -->
</template>
<script lang="coffee">
# First line of CoffeeScript code, but line 25 of the .vue file
My hunch is that vue-coffee sends the CoffeeScript code through the transpilation pipeline without adjusting the sourcemaps for the fact that, in this example, the code starts at line 25 instead of line 1. That should be fairly easy to rectify, I just haven’t devoted the time to it. Please feel free to do so (and let me know if you do, so I don’t duplicate your effort).
My workaround has been to just throw debugger statements in my code:
<script lang="coffee">
import { mapState } from 'vuex'
export default
name: 'some-component'
data: ->
debugger # Chrome DevTools WILL stop here
You need to remember to remove them later, but they’re full-fledged breakpoints, not the limited printing you get from console.log. The debugger statement is core JavaScript, and has nothing to do with Vue or transpilation.