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.
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.
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 
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?
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
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.
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!
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").
It’s advisable to do this in GitHub. And have high-level discussions here.
item: { fieldName: 1, fieldName2: 1 }
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!
@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.
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.
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.
Unless you store your dynamic fields in a nested object or something, nope. There is no way.
Thanks, I’ll implment it that way.
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…
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:
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:
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.
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
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 .