Meteor, Apollo, and the @live directive

apollo
1

I stumbled across this video from GraphQL Summit 2017 which talks about a new @live directive in GraphQL, which allows you to keep certain parts of your query reactive. It is particularly interesting because pretty much everything Rodrigo discusses in this talk will be very familiar to Meteor devs: benefits, tradeoffs, gotchas, etc. He further goes on to talking about the complexities in designing a backend to do this, and the different strategies available (Meteor is specifically mentioned).

Meteor figured this stuff out years ago… just with a different coat of paint. I feel like Meteor was (and perhaps still is) way ahead of its time in this area, because live queries are being presented as a new concept to many developers. This may be new to GraphQL, but Meteor has been doing it for years.

Some devs on here have been bringing up the idea of a tighter integration between Meteor and Apollo. Maybe this is an opportunity for that. Image being able to tag a certain part of your GraphQL query with @live and have it just work, leveraging the Meteor pub/sub system behind the scenes and having data being transported efficiently over DDP.

At the end of the talk, Rodrigo mentioned that someone sent him a github project that enabled a reactive experience with GraphQL and Meteor. I think he may be talking about this one. This looks like an interesting start!

There has also been a lot of interesting work in this area that has been done in the community:

There is the DDP Apollo project from @jamiter that has already figured out the transportation layer!

There is the Grapher project from @diaconutheodor that uses a GraphQL-like syntax for queries. Not sure how adaptable this would be to get working with a GraphQL query, but this project has already figured out how to efficiently setup a data layer with queries coming from the client. Add in a very good scaling solution with Redis Oplog and things become even more appealing.

I don’t know, maybe this is too pie in the sky. I’d be curious to hear what others think about how feasible something like this is.

Thank you for your time! Looking forward to any discussion!

5 Likes
2

@moberegger, thanks for starting this thread. It’s good to have a centralised place to talk about this specific topic. I’m very interested in this myself and done some research on the current state of the @live directive. Although I think Meteor is up for the task, there is a lot of work to be done in other areas.

Keeping close to the mainstream libraries

There is always a way to implement it ourselves, but personally, I would like to see support build in standard libs. The example repository using Meteor with RxJS is a great initiative. But if we want people to actually start using it, we want to keep close to the spec and mainstream libs. I’ll go into more detail about this later.

So what needs to be done to support @live for everyone?

  • Apollo Client doesn’t support @live yet
  • graphqljs doesn’t support multiple results from a query yet (Observables)

See this thread for the current state of support in Apollo Client 2:

This is on the roadmap for the Apollo Server:

  • Talking about the need for Observables in graphqljs.

Currently working example of Meteor and @live

I also think this is the example repo he talks about:

There are some issues though:

  • Doesn’t work with Apollo 2. See for example this issue.
  • Doesn’t seem to be aware of the proposed patch syntax. ({ path: [ 'author', 'posts', 0 ], data: { title: 'Hello', views: 10 } })
  • It uses RxJS (meteor-rxjs), which is very good lib, but we might get away with using plain Observables.
  • Uses own GraphQL-RxJS, which is nice, but not standard.

Other interesting issues/discussions

Lee Byron, one of the authors of GraphQL, is saying you don’t need observables, but doesn’t give a hint about an alternative:

Grapher

Grapher is also a great peace of software. @diaconutheodor did a great job here and explains some of the pain points of GraphQL in this post:

I believe though, also after the video you shared, that these issues will get addressed in the future and with help from the community, we can make GraphQL (almost) as easy to setup as Meteor, including support for @live queries. In the meantime, for people who can’t wait for that, Grapher is a nice alternative. But again, not as widely supported as GraphQL.

Next steps

I believe the focus should be on getting @live support into Apollo and GraphQL itself and work from there. Connecting Meteor afterwards, probably using Observables, should be a walk in the park (which it never turns out to be, but let’s stay positive here :wink: ).

1 Like
3

You can still harness some of Grapher’s powers inside GraphQL: https://cult-of-coders.github.io/grapher/#Linker-Engine You can use the Engine. But you will not have the performance benefits of Hypernova. For that you need a Query.

Grapher’s purpose is to make things easy. We did not care about performance that much, but we cared enough, and it was a matter of luck and a bit of innovation, and we became the fastest relational MongoDB solution out there, but that was not the purpose, the purpose was simplicity and ease of use.

We are using it in all of our projects, we helped lots of customers transition to Grapher. I’ve talked with people that used Grapher temporarily and wanted to shift to GraphQL, they changed their mind after using it for a few months, and stuck to Grapher…

It works on Meteor’s data layer, what kind of support are you expecting? There aren’t any bugs left, at least bugs that we are aware of, it’s been battle-tested for over a year.

We are working on some very high level things in our labs, something that will push Meteor years ahead any other framework. Grapher will be the backbone of it all. We believe that shifting to Grapher or starting your apps on Grapher will help you a lot in the future, when we’re gonna launch our next jaw-breaking open-source product.

Cheers!

1 Like
4

Grapher is a great tool, no doubt. But it’s not GraphQL. GraphQL has it’s own syntax, tooling, community, etc. and it works with any sever language, creating a lot of hosting possibilities. It’s not Meteor or Mongo specific. So in that sense, it’s a totally different ball game. I’m not saying it’s better or worse, just different. When I say GraphQL is more widely supported, I mean that it’s available to more developers and generally accepted sooner, because it’s not tied to a specific setup or language. Even if Grapher is the best thing since sliced bread, there are a lot of people that want to use GraphQL anyway, for whatever reason. I’m trying to support them specifically and move the Meteor + GraphQL implementation forward.

The title of this thread is Meteor, Apollo, and the @live directive, so personally I would like to focus on that. Discussing the benefits of Grapher wouldn’t help us getting @live support in GraphQL for Meteor developers.

2 Likes