Grapher - Collection Relationship Manager + GraphQL Like Data Fetcher

[diaconutheodor]

Very glad you are using Grapher together with Apollo, it makes a lot of sense, and you could easily transform a GraphQL query to Grapher, nice!

[klabauter]

I hope it’s okay to post this in here … if not please tell me so and delete this post!

After defining a link between two collections like so:

OpenOrdersBody.addLinks({
  'item': {
    type: 'one',
    collection: Items,
    field: 'itemId'
  }
})

Items.addLinks({
  'openorderitems': {
    collection: OpenOrdersBody,
    inversedBy: 'item'
  }
})

and then querying the OpenOrderItems like so:

const myQuery = OpenOrdersBody.createQuery({
  $filter({filters, options, params}) {
    filters.list_id = params.listId;
  },
  _id: 1,
  list_id: 1,
  item_amount: 1,
  item: 1 // adding this line produces the error below
});
...
withTracker((props) => {
    return {
      supplier: Meteor.users.findOne({ _id: props.supplierId })
    }
  })

I get the following error:

error: "invalid-body", reason: "Every collection link should have its body defined as an object."

What am I doing wrong? I thought I defined my link properly and now I just want to “query for this link” ("item").

[diaconutheodor]

It’s advisable to do this in GitHub. And have high-level discussions here.
item: { fieldName: 1, fieldName2: 1 }

[diaconutheodor]

@mhmdlab

@diaconutheodor

I’d like to thank you for the great tool Grapher. I think it is the big thing inside Meteor ecosystem.

I can not imagine Meteor without it as it made joining and querying decoupled and easy.

It should part of Meteor because even if you want to use Apollo you’d need a relationship manager.

The stack (React + Meteor + Grapher + Denormalize + Apollo) is unbeatable

Keep up the good work.

Would you be willing to setup a quick repository to show how Grapher is used with Apollo ? I know in theory that they should play well together but maybe help us see it better.

Cheers!

[mhmdlab]

@diaconutheodor
Sorry for the late reply I just saw your message.
Yes sure I’ll try to setup the repository this weekend. I already have a project I’ll extract something from it.

[relicho]

Hi everyone, I hope it’s okay to link another thread in here. It’s about a question/problem that I have about denormalization and querying in grapher.

[chathuraa]

Hi @diaconutheodor,

I have a collection with dynamic fields. Is there a way to bypass having to specify the fields that need to be returned in a query?

Thanks,
Chat.

[diaconutheodor]

Unless you store your dynamic fields in a nested object or something, nope. There is no way.

[chathuraa]

Thanks, I’ll implment it that way.

[ujwal]

Hello folks,

I actually read every message in this thread: over 1.5 years. Very educational!

I am just getting into this graph business. Currently looking at Apollo, and my thought currently is: why the hell am I doing this? So much boiler plate! So much esoteric code!

Sometime last year, I wrote an article on “Why I feel in love with Meteor”…I am a reasonably intelligent fella, but had no JS or web application experience until a couple of years ago. I stood up a production app in 10 days… Learning JS, Meteor, and all…Meteor helped me do that.

I feel that if I had started with Apollo, nothing against it but my stupidity, I would still be lost.

So, here is my question…I am starting a new project… And started wading into Apollo… In fact trying out the meteor-Apollo integration by @diaconutheodor. And my client is react-native. But is this the right way to go?

I want the reactivity of meteor, but want to control it. I want the query capability of graphql. I want the accounts system of meteor and connection reactivity. I want the minimal boilerplate of meteor.

Grapher is starting to sound real good to me right now, but how is does it relate to cultofcoders:apollo?

Why am I even messing with graphql when grapher could potentially do it for me?

What am I missing? Forgive dumb questions from a graph newbie…

[diaconutheodor]

Hello @ujwal

First of all, thanks for your patience of reading this giant-ass thread

What I managed to prove with the latest performance reports (https://github.com/theodorDiaconu/grapher-performance) is that Grapher blends in with Apollo, it makes you write much less code, and you have a lot of performance benefits, this is something you rarely see in programming world.

Now, you have to understand that while Grapher shares some similarities with GraphQL in the sense of requesting data, they are worlds apart in terms of their objective and functionality. One is a relationship manager the other is a data layer.

Now the question is not whether to use Grapher or not (the answer is clearly yes), it’s whether you want to use Apollo/GraphQL. My answer is you should look into it. I also thought Apollo is complicated, hard to understand, to learn, but it’s false. Look again at grapher-performance repo I pasted above, look how elegantly the collections and relationships are done:

theodorDiaconu/grapher-performance/blob/master/server/entities/Comment.gql

This is done by using GraphQL directives, and believe me when I say they are very powerful.

The main issue I had is that, to implement something reactive in GraphQL it was so damn hard, I missed the elegance of Meteor. But with a little bit of work, faith and powering through we brought it here:

cult-of-coders/apollo/blob/master/docs/live_queries.md

I think this is far more elegant in the sense that you get the benefits of GraphQL for subscriptions. The only things missing are the “Reactive Data Graphs”. While they may get on the roadmap, the biggest problem with those are the fact they are performance hogs, I highly recommend against (because I know what’s happening behind the scenes), however, with a little bit more code, you can benefit from this in apollo-live-server npm package and configure things how you want.

[ujwal]

Thanks @diaconutheodor! I will continue pushing ahead with your Meteor/Apollo package. At least now I have my react-native client talking to the server

[Jacques]

There is no integration with it, but ofcourse it works. You just have to add the schemas yourself.

If there is no integration, then how can one apply the Grapher methods (e.g., createQuery, addLinks, etc. ) to Astronomy Classes instead of Mongo Collections?

Thanks in advance for clarifying this point .

[diaconutheodor]

@Jacques there must be a way to get the Mongo.Collection instance from the Astronomy Class, and you can play with that one directly.

[Jacques]

Perhaps but then you loose the class-based object-oriented abstraction to manipulate the database which is the main purpose of Astronomy if I understood well.

[diaconutheodor]

Well, I think this is a question for Astronomy maintainers, rather than Grapher. I’m not familiar with the internals, however from my experience I try to move away from OO abstractions of DB, they do more harm than good in the long-run. Cheers

[emhmark7]

Can we have an update about Grapher? Is it current? Actively maintained? VS Apollo? etc. Thanks

[diaconutheodor]

Ofcourse it is maintained. And works together with Apollo beautifully!

[adamginsburg]

@diaconutheodor just checking in if you’re still recommending Grapher… it looks really interesting.

One of the reasons I ask, is I tried running redis but ran into issue with PublishComposite, which we use pretty heavily. And was of the recommendations was to avoid publish composite https://github.com/cult-of-coders/redis-oplog/issues/352#issuecomment-601830807

in your video you mentioned the package is based on PublishComposite, so wondering if I should look at this or if you have any newer approaches.

The other reason, was just looking at last updates was several months back, so thought I’d check before I went down this path.

thanks

[diaconutheodor]

PublishComposite can become very heavy. Use it with precaution. Grapher is still solid if you want to take part of the full Meteor ecosystem with DDP and stuff.