Grapher - Collection Relationship Manager + GraphQL Like Data Fetcher

antoninadert · September 8, 2017, 3:10pm

Hi there,

A little question, I see that this package is supposed to work with SimpleSchema, does it also work with Astronomy ?
Is there someone using it or having a very simple integration?

diaconutheodor · September 13, 2017, 3:22am

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

diaconutheodor · November 27, 2017, 1:04pm

Quick Updates

We made Grapher React to work in a recommended HOC manner: https://github.com/cult-of-coders/grapher-react

Grapher 1.3 is on it’s way. It marks a stepping stone in the evolution of data.

The release is almost completed but it needs to be backed by a solid documentation, because this is what discouraged adoption in the past.

We introduce new concepts such as:

Link Caching (Denormalization)
Named Query Caching (In-Memory / Redis)
Reactive Counts
Named Query Subbody Requests
Full compatibility with Redis Oplog

And iterate on previous ones:

Unmatched performance (will be backed by stats)
Reactive Data Graphs

In my opinion, Grapher is outperforming GraphQL in Meteor at almost any level:

Development Speed
Performance
Monitoring (we already have Kadira)
Reactivity (now scalable with RedisOplog)

MDG: While we have no plans to force existing Meteor applications to be rewritten to use Apollo and/or GraphQL, we believe that migrating away from Mongo and Livedata is the right path forward for most applications, and certainly the right place to start for newcomers to the Meteor platform.

I’m sure they will change their mind about that statement.

klabauter · November 28, 2017, 10:31am

Thanks yet again @diaconutheodor for awesome packages like Grapher!!
I am waiting for the 1.3 release and planning to completely switch over to Grapher in January!

If I may, I have a little feature request:

It would be friggin awesome, if Grapher supported some kind of offline functionality. My Meteor app is often used on mobile devices, where Internet connectivity is not very stable and might not be available for some seconds/minutes until reconnect. I would be just awesome if grapher could cache Mongo writes in the meantime somehow and send them after reconnection?!

diaconutheodor · November 28, 2017, 10:44am

@klabauter Grapher is not a complete Data Layer, it’s a Fetching Layer on top of Meteor Data Layer. Meaning you will only use it to consume data, and not mutate it.

Regarding offline capability, Grapher works behind the scenes through methods and publications. So, in theory, you have the same offline capabilities as Meteor does.

klabauter · November 28, 2017, 10:55am

Thanks for clarifying @diaconutheodor!
I just found something which might be pretty easy for you guys to implement into grapher-react: https://hackernoon.com/offline-first-react-native-meteor-apps-2bee8e976ec7
I am aware this is only some sort of cache, but still - might be a nice feature for grapher-react.

diaconutheodor · November 28, 2017, 11:09am

Thank you for the suggestion. The 1.3 release is focused on completing Grapher as a data fetching layer inside Meteor Apps’ Frontend.

1.4 will be focused on a wider approach, moving grapher clients to npm, exposing end-points easily, authorization with Meteor accounts. You can still use this quite easily inside React-Native, all you have to do is expose an HTTP point that accepts JSON Requests and inside it you can createQueries and return the result.

klabauter · November 28, 2017, 11:23am

I should have clarified a bit better:
I am not using react-native … I wanted to show you the “clientside data cache” via redux as proposed in the article. It is just a few lines of code and might be a nice way to have a clientside caching functionality in grapher-react.

Please just take 5mins and read the article briefly … maybe Grapher already has something like this included but it seems to make proper sense to me to cache fetched data on the client and make it available, even if the client is offline.

herteby · November 28, 2017, 4:12pm

Hmm, so he uses redux-persist to save the Redux state to localStorage. You could easily do this yourself with Graphers nonreactive queries, but the reactive ones rely on MiniMongo. Ground:db offers persistence for MiniMongo, but only for client-only collections

klabauter · November 28, 2017, 8:55pm

Yeah I know it’s not really rocket science what this guy is doing in the article!
The thing is: I don’t really have any client-only collections, I need offline support for my normal collections. The optimal way would be to save all minimongo writes somewhere and send them to the server when the client is back online.
Talking about the fetched data (so only reads, no writes): having the data in a persistent Redux state sounds pretty nice no?

relicho · January 17, 2018, 4:11pm

Hi everyone!
I was wondering if this kind of filtering is possible with Grapher.
Let’s say we have two collection with a 1-N relationship called “Companies” and “Employees” where the Employees have a boolean type field called for example “isHardworker”. Can I somehow fetch only the companies (without fetching any of it’s employees!) that have at least one hardworker employee?

diaconutheodor · January 17, 2018, 4:22pm

Left response: Grapher filtering here

mhmdlab · January 27, 2018, 1:53am

@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.

diaconutheodor · January 27, 2018, 6:13am

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 · February 2, 2018, 10:34am

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 · February 2, 2018, 2:35pm

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

diaconutheodor · February 8, 2018, 6:09am

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 · February 18, 2018, 6:44am

@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 · March 5, 2018, 10:13pm

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 · March 23, 2018, 9:41pm

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.