Meteor Collections+PubSub vs Apollo GraphQL

apollo
1

(This thread was originally a question, but after some research, the title reflects the outcome)

TLDR (more details below): Use Meteor collections and pubsub for Meteor apps for the superior developer experience and data consistency, and learn how to control their power with throttling and/or methods. Use Apollo GraphQL only for fetching from external sources, and do not rely on it for realtime data.

Is there a real advantage to using GraphQL in a Meteor app?

Development wise, and code wise, complexity seems to be about the same between stock Meteor, and the --apollo template (if anything, we’re merely swapping mongo-style query language for GraphQL query language, and one might be slightly harder than the other).

The meteor create --apollo example feels like an extra layer over Mongo. To me, it seems like it’s just easier to use the standard Mongo setup and move along.

Is there a real benefit of using GraphQL, especially the setup found in the meteor create --apollo template?

I don’t see it as going to greatly improve my code base, so the only think I can imagine is there’s a performance reason for going to GraphQL. Is this the case?

1 Like
2

I’m using GraphQL/Apollo for my react native mobile app. It works very well.

3

Is it better? Why? I can easily write a Mongo query.

4

I don’t know what you use to query databases but I need more than just querying the mongodb database. Apollo/Graphql are mature and stable. I feel safe when using them in my project.

5

Makes sense in that case. I was planning to use just Mongo for an app, keep it stock. What I like is reactivity across the wire, Tracker.autorun, etc. I hear this is a pain point with GraphQL: polling is inefficient, and/or missed query subscription events lead to inconsistent data. Have these issues been addressed already?

6

I’ve just used query and mutation. I’m going to use subscription for some features. Hopefully those issues has been addressed.
On the web browser, I think using built-in Meteor Pub/Sub, Method and WebApp is enough to solve most of requirements.

2 Likes
7

If your Meteor needs to “talk” to legacy systems or DBs, or to other systems (e.g. your users are in some SQL with another system) you might want to use GraphQL.
Within Meteor you don’t need it because you don’t have those problems that GraphQL solves.

5 Likes
8

I’m using both. Pub/Sub for data that I need to have as real time as possible and GraphQL for data where I don’t care if they are a bit stale, but don’t want to setup pub/sub to limit the impact on server, these are often public facing presentation pages with a lot of traffic.

1 Like
9

Why not just use {reactive: false} for publications that you want to manually fetch?

1 Like
10

@minhna @paulishca Yeah, I’m just planning to make a pure-Meteor app. It seems easy to fall into hype of using GraphQL when not needed. To me, it seems like extra complexity in dev experience; I’d rather optimize pub/sub when I need to.

Unless I missed something, this is pretty easy to do by throttling a publication. There’s also the {reactive: false} option, which could be used in the backend, and a Meteor.method could be exposed for manual fetching. It doesn’t seem I’m missing something critical that GraphQL provides (assuming I’m making a pure-Meteor app)?

Now, if GraphQL queries were reactive and consistent like Meteor pub/sub, then I could see that being a developer experience win, but at the moment GraphQL subscriptions can cause inconsistency.

Also, live queries seem overly complicated to set up, so that’s a developer experience loss overall.

It seems to me that we just need a Meteor docs page that provides a clear and simple guide to performance and scaling; showing how to limit pub/sub data, and how to make it entirely poll-only as needed.

4 Likes
11

Apollo subscriptions are either too easy to get wrong, or the system itself has bugs. Take a look at this issue and what people are having to deal with.

At this point I believe it is more pleasant to deal with Meteor pub/subs that have “too much data”. Having consistent state is (so far) drastically easier for developers using Meteor collections and pub/sub. I’d love to be wrong though!

Where is the “reactive GraphQL” mode (for meteor create) that we’ve been waiting for since way back in 2016?

Before the more recent --apollo template, it’s been too much work to get started with GraphQL, but even now the --apollo template is not “reactive GraphQL”, it is poll-based (requires manual refetch calls, which can be done wrong, not at all, or too often with redundant data being sent over the wire).

Yes, the refetch results are reactive themselves, but the system in the --apollo template is not full stack reactive like the magic of Meteor collections and pub/sub with its client-side cache.

That full stack reactivity is what Meteor is all about. :leftwards_hand: :heart_eyes:

1 Like
12

By “live queries”, I mean like the ones described here: Subscriptions and Live Queries - Real Time with GraphQL - The Guild Blog

It’s getting there; that article shows two approaches that work well, but require some work to set up.

Meteor would need this – and it would need to be as easy or easier to use than Meteor collections/pub/sub out of the box with a meteor create template – for GraphQL-in-Meteor to reach parity with (and to be a delightful alternative to) the full stack reactivity that Meteor is known for and got famous for.

It will be nice to see this happen, and I wonder if it can be made even simpler than Meteor collections/pub/sub. It’s not here yet, so for now I’m sticking to Meteor collections/pub/sub/methods.

13

This is an interesting comparison between Apollo, URQL, and Relay. Comparison | urql Documentation

URQL and Apollo don’t have the concept of “live queries” out of the box, but Relay does (although if it is poll based, that defeats the purpose). Maybe Meteor needs a meteor create --relay template to show this working. Either that or Apollo should add live queries.

CONCLUSION

Anyway, I hope this makes things more clear. Apollo GraphQL is really not a replacement for Meteor Collections and PubSub, and definitely not a magic bullet that will prevent scaling issues but is useful for cases when only fetching is needed, and especially in cases when data from other backends outside of Meteor needs to be fetched.

Making Meteor Collections and PubSub scale is easier than having to deal with GraphQL data inconsistencies with subscriptions, especially for live content, based on the research I’ve done.

For a pure Meteor app, I’d say stick with Meteor’s full-stack-reactive collections, publications, subscriptions, and methods; and learn how to throttle subscriptions, and/or how to fetch using Meteor.methods as needed.

Trying to fall back to polling with GraphQL (to keep clients in sync), in an app that has “too much realtime data”, is going to be worse than the problem people have complained about with Meteor collections/pubsub. We’re off to a better start with collections/pubsub, not just developer experience, but it already syncs only data that is needed since the last sync, without us worrying about it.

Bring in GraphQL into the picture only when we need to fetch data from external sources.

It’s hard to see past all the hype, even after all these years, in the term “graphql” to really know when to use it. People make it seem like a magic bullet that replaces Meteor’s collections and pubsub, but that’s just not the case (not yet, at least).

14

@trusktr thank you for the break down. I have created the Apollo skeleton and used only the out of the box Apollo to get things going as back then the situations around GraphQL subscriptions was even worse then it is now.
Another use case, which I want to explore with GraphQL is to use it as an API for external apps (both official and connection to other services). So far experimentation in this direction in regards in connecting to other services Graph has been disapointing (I just hope that I’m missing some sort of docs, but I would expect that being advertised a lot given that I hear this use case a lot).
Still there are devs and companies that want to see GraphQL or they will not even look at you, so I will be updating and hopefully in the future expanding the Apollo skeleton and maybe one day we can have a nice convergence, but until then I agree with you fully.

1 Like
15

In my medium to large apps, I use Meteor pub-subs for only data I need in real-time, i.e., auto-complete search boxes, chat, etc. For all other, and most, data, I use GraphQL. Urql on the client side and Apollo/Nexus.js on the server. Some advantages to using GraphQL include external integration and mature client-side caching. This hybrid configuration has worked fabulously for me!

3 Likes