Grapher - Collection Relationship Manager + GraphQL Like Data Fetcher

announce
143

Just ran across another undocumented gotcha: If you don’t subscribe to a query then this query:

namedQuery.fetch((err,data) => {
   console.log(data)
});

will only show you the documents for the main collection and will never show any linked collections you might mention in the query body. Which means that, for my example of

users: {
        _id: 1,
        username: 1,
        emails: 1,
        groups: {
            name: 1
        }
    }

will effectively become this:

users: {
        _id: 1,
        username: 1,
        emails: 1
     }
144

That is very strange, are you saying namedQueries don’t work as they should ? Do you have a quick reproduction so I can check it out ?

145

So to ask the dumbest of the dumb questions, am I right in understanding that we can’t use Grapher if we don’t use SimpleSchema (SS)?

In our use-case, we’re not using SS atm, since we’re still working heavily with imported data from 3rd party systems, and until we fully migrate over to using our Meteor stack we don’t want to finalize the schema. We are doing some normalization during imports to make it easier to build relationships between collections (manually), but we’re trying to avoid locking down a formal schema at this time. I can see how Grapher would help us, but could we use it when not using SS) or are we stuck with PublishComposite?

Also, anyone got a complete working Blaze example using Grapher that ppl can use as a reference? Translating React to Blaze isn’t the most fun thing to do.

146

@shankscoder Grapher is NOT SS dependent. However if you have it, it extends the schema for you, so you won’t have to. PublishComposite is used for reactive-graph (when you subscribe), I don’t understand being “stuck” with it.

Regarding Blaze, you just need to understand how the Query works, then you’ll be fine.

And don’t worry, no question is dumb ! Feel free to ask more, but give the documentation a careful read, start with the guide.

147

Now that we have redis-oplog, we are testing using a sharded database. Is there a way to tell grapher to use a field other than _id as the shard key?

148

@bamoqi currently no, link definition only works by relating with the _id, however, I understand the need for this. Could you give me an example of what you want to achieve ?

149

To improve performance, we place docs of the same owner on the same shard. So we use owner instead of _id as the shard key. Each doc reference link is { id: xxx, owner: yyy} rather than just id. By providing { _id: xxx, owner: yyy} in a query, we route the query to only one shard rather than querying all shards.

150

@bamoqi I don’t see why it would not work. But you may have to add some additional filters to work to your use-case.

{
  users: {
      $filters: { _id, owner },
      posts: {
           $filters: { owner }
      }
  }
}
151

Yes your solution should work. I am just getting my hands on grapher so I missed the obvious way. Thanks a lot!

1 Like
152

Is grapher production ready? Are there any disadvantages in using this package?

153

Yes. Syntax isn’t as straightforward and easy as Meteor/Mongoshell

154

Using $filter may not work for our use case after all. The problem is that owner is not known beforehand, it is stored in the link as meta data. eg for a schema:

review: {
  reviewTarget: {
    _id: String,
    ownerId: String // The owner of the review target
  }
}

reviewTarget is a meta link. We need to read the link, determine the owner, then add the owner as a filter for finding the review target. Is this problem solvable?

155

@nisthar yes it reached prod-ready in october.

@bamoqi http://grapher.cultofcoders.com/guide/links.html#Meta-filters

users: {
   $filters: {
        $meta: { ownerId: 'xxx' }
   }
}
156

Cool. We considered using meta-filter but there is no example of using it in a query in the doc.

Can we specific a field other than _id as the target-id in the meta-link object? The doc seems to assume it is always _id.

157

@bamoqi that is a frequently requested feature. For now we don’t support it. But is going to be there in the next month or two.

158

Update: 1.2.7

Long time no see!

Changes:

  • Improved security and filtering for body exposures
  • Various consistency fixes like better error messages.
  • Added support for a new concept: $postFilter

What’s next in Grapher?

Grapher is rock-solid. There are still many things to be added but this package, I can agree with that, but it already achieved, with great elegance, its purpose, it has matured. We are using it in every project we have. It proved it’s solidity.

So I am going to put a hold on new features and only focus on bugs, refactoring, documentation, code documentation, code quality and recipes on how to use this framework.

It added the essential layer over meteor’s data system that allows us to bring order and structure into data fetching. Besides that it innovated new ways of fetching relational data optimally in a NoSQL database. Something that did not exist and still does not exist (at least not open-source)

What’s next overall?

The next big problem in Meteor is the fact that if you want to create a CRM with lists, pagination, filters, sorts, forms. You have to write your stuff from scratch. And after that, you would like to re-use it, so you end-up with a mess. And we all re-invent these wheels every day. I come from Symfony2. And I’ve used a package called SonataAdmin. I was building CRUD’s and forms in minutes :slight_smile: This is not the case with Meteor. It’s hard to do it perfectly and time-costly.

Grapher is now offering the essential backbone to do that. And we see this new “CRM builder” as the next stepping stone into the evolution of Meteor framework. I will be finishing the design plan for such a builder within the next 2-3 months. It’s more challenging than Redis-Oplog and Grapher put together. It will be using material design, grapher, react, and still pondering about uniforms.

Cheers!

13 Likes
159

Thank you for your efforts @diaconutheodor. Both Grapher and Redis-oplog are great solutions. I do believe that @radekmie has created an elegant package - uniforms - to manage forms in Meteor. He is very cooperative. Would love to see that these solutions might end up in the CRM solution you are planning to create. I would be happy to share experiences and thoughts on this matter. We are working on a distributed Meteor system (web app and Cordova apps) in which we centrally manage schema definitions and automatically generate forms based on these schemas.

1 Like
160

I’m also working on a visual form builder - stay tuned!

161

No material design pls. Enough of dem thingies T_T
Though, good luck with your project and thank you for Grapher. I really love it.

2 Likes
162

Also just wanted to thank you @diaconutheodor for Grapher and all the hard work!
I really think Grapher helps more complex apps a lot and I will definitely integrate it into my next major overhaul of my production app!

1 Like