Meteor Reactivity Alongside GraphQL Apollo — Implemented

apollo
1

I love Meteor but I also understand that GraphQL is the future because:

  1. You get API documentation out of the box
  2. It’s getting standardised and lots of developers start to learn it
  3. Miles ahead in terms of scalability, ability to stitch and connect with others APIs beautifully

Many more…

So this is just a small video of something I hacked quickly. For people that are unfamiliar with GraphQL Apollo it’ll look weird and ugly, but I’ll take care of those parts. Long story short, we can do it, we can have the beauty of Meteor inside Apollo. And this would be a production ready npm and meteor package within the next months.

Cheers

23 Likes
2

Can’t wait to take a look at this later! I have been playing around with this type of thing at home and have hit some struggles, so you have impeccable timing!

3

Cool!

Now, wouldn’t it be great if MDG worked on some of this integration work between Apollo and Meteor?

4

This is cool! and I think it’d be a great add to have pub/sub api similar to that of Meteor’s RPC to the GraphQL ecosystem, but please allow me to scrutinize this a bit :slight_smile:

This seems like reinventing Meteor’s pub/sub API using GraphQL, but if someone is building a typical 3 tier app, without the need for a self documented API that can stitch with other APIs since they’re a small team with little integrations, wouldn’t that be a downgrade relative to Meteor’s Methods RPC given the amount of boilerplate and complexity added?

5

@hluz it would be great for MDG to work on so many things, but they have limited resources. It’s up to us the community to support them, heck they gave us Meteor for free, and MIT licensed…

@moberegger I’ve hit struggles as well, outdated documentation on their website, but after doing some digging, looked at other’s boilerplates, I managed to hook it up. My vision is to have a meteor/apollo-super package, that gives you:

  1. Painless reactivity (that works with redis-oplog)
  2. Websocket stiching and Meteor user accounts integration, out of the box.
  3. Is properly merging with Grapher (Grapher is still the bomb.)
  4. Ability to have… reactive data graphs! But it won’t be the main focus I just explored the fact and it’s possible.

@alawi yes. it’s almost reinventing, it’s more like adapting the beautiful concept that MDG came up with, and putting it inside GraphQL. My vision is to hack something to make GraphQL as simple as possible. The reason I started adopting GraphQL is that I was pondering about evolving Meteor’s API in something self-documentable, something better decoupled (https://github.com/cult-of-coders/mutations) and what I realised is that I was slowly reinventing GraphQL… so I said to myself STOP! and got on the bandwagon.

GraphQL beauty lies in it’s ability to self-document itself, it will become a standard and will be widely known by many developers. I can simply write backend code, expose my schema, my mutations, put in a graphql mocker, and the frontend engineer can already start coding without needing my implementation… it’s very lovely, and there are many advantages to it…

Anyway, that “Simple” part is what I’m working on (in my spare time)

7 Likes
6

I’m not sure if this might help but Apollo introduced the ability to create custom directives, perhaps the reactivity can be simplified by creating libraries that introduce custom pub/sub directives to reduce the boilerplate code?

Just thinking loud here.

2 Likes
7

Looks great!
Is there any chance you could publish your code somewhere?
I would love to take a look, without retyping the chunks I can steal from the video :wink:

8

I no longer have it in that form, sorry. I will publish the packages next week. I’ve finished the API, and I worked a lot on how to architect large scale graphql code, I am very pleased with this approach. Will share all my findings and knowledge with the community, as I always do.

5 Likes
9

I have a novice question …

May anyone please, please tell me how was the Apollo/GraphQL/Meteor combo until now? What was missing from what we have now with this revelation.

Didn’t we have Pub/Sub with GraphQL & Meteor before?

Please tell me how does the above post help us so much with scalability? Ability to stitch & connect with other Apis is obvious. Or may I say, how does Apollo etc. help so much with scalability? It’s really important for me to know this.

Is the scalability only bcoz of a separate client: Apollo wires up all apis and leaves the Meteor Server out of it?? Or are there other aspects to scalability with this setup (above)?

I am starting hunting for resources on internet wrt this.

Many thanks.

10

I think Api scalability is quite obvious. Are there any other aspects to Scalability?

Tooling is much improved owing to Static Types.

1 Like
11

Hello guys, following-up on my progress as promised I’ve released some packages

The flock of packages

Return live queries from subscription resolvers:

Subscribe to live queries with few lines of code:

Easy load and merge your schemas, done simple:

And the top cherry:

meteor add cultofcoders:apollo

You can now have Apollo installed just by adding one package and that's it, no other configuration. You get out of the box:

  • Zero configuration Apollo
  • GraphiQL
  • Ready for Meteor’s live data
  • JSON and Date scalars out of the box
  • Built-in support for authentication for HTTP Requests but also for Websockets, however for adding Accounts you have to copy paste some stuff from the package since we wanted it to be opt-in.

I feel the need to repeat myself, Meteor’s Live Queries have been successfully migrated to Apollo & GraphQL, and they work with redis-oplog just as you expect them to, so we’re talking super-scale. Just take a look at apollo-live-client on how to use them on the client and apollo-live-server to see how to create resolvers for your Subscription.

Quick Roadmap:

The Meteor Apollo package will evolve up to a point where it’s super easy to start, but when you grow your app, you’ll most likely just deprecate the package, and copy/paste the stuff from there to make your own custom high-level configs. So it’ll just focus on the out of the box basics, to satisfy the 95% of apps.

My plans for the next period of time:

  • Create a learning curve for Apollo & GraphQL
  • Create a boilerplate with authentication, apollo SSR, lots of goodies (Planning for PWA)
  • Create a video tutorial that walks everyone through Apollo
  • Create a quick boilerplate to show actual proof how to integrate Grapher into Apollo and show the crazy improvements.
  • Think about a merge between Mongo and GraphQL Types

Feedback and critiques are not just welcome, they are expected. Thank you!

Note: all packages are currently not-stable, I expect production readiness in 2-3 weeks after we do some heavy testing, please submit any errors you find the the right GitHub repository, thanks.

23 Likes
12

How many hours do you have in a day? I’ve only got 24 :confused:

3 Likes
13

@diaconutheodor is the new @arunoda

3 Likes
14

@arggh It just looks like I’m doing many things, I’m not. :smiley:

@evolross thanks I guess

I’m honestly very pleased with Meteor, I can now have highly scalable APIs, benefit of painless reactivity with Apollo, scale my reactivity to infinity with redis-oplog, deploy in an auto-scale env with ease (https://github.com/zodern/mup-aws-beanstalk), enjoy SSR, TypeScript. The future looks alright for this nice framework.

8 Likes
15

Updated: https://github.com/cult-of-coders/apollo

Added lots of samples so you can start with Meteor & Apollo & Accounts & Live GraphQL Queries in 1 minute.

3 Likes
16

Hopefully not! That one left in a hurry :slight_smile:

3 Likes
17

I’ve been trying https://github.com/Swydo/ddp-apollo as a Meteor-Apollo integration, but I’m very interested to look into your new integration. Are the two methods compatible or overlapping at all, or would I have to abandon ddp-apollo?

One great thing about ddp-apollo is that there is no need for express.

18

They are overlapping in the sense that this actually uses express(), and basically deprecates DDP fully.

19

Been thinking about that… It would be kinder on people having large apps which are not practical to migrate away from ddp to be able to gradually adopt apollo-live. Would also enable an easier adoption with Vue front-ends via the Akryum integration packages…

20

I had this in mind since I started, apollo-live is so abstracted that it doesn’t even depend on Meteor to use it, it just “happens” to be so well thought for Meteor. :smiley:

However, the cultofcoders:apollo has a different goal in mind, it’s for the newbies (like me) who want to quickly get started with Apollo and experience GraphQL, I had to spend at least 2 days, to get the basics up and running properly. This was my vision:

  1. Install Meteor & Create Project
  2. Install some npms and add a package
  3. Add your first Query (copy/paste from repo)
  4. Enjoy GraphiQL!

With large apps, I’m sure there are good engineers that can look in the source code and make their custom apollo server and subscription server, and harnerss apollo-live, as it works with standard subscription servers. Heck, you could even create a separate microservice just for reactivity (where you can add cultofcoders:apollo), and connect to it, while still beeing connected to DDP.