Grapher - Collection Relationship Manager + GraphQL Like Data Fetcher



Guaranteed uniqueness.

Guaranteed type safety:
Collection2 + Simple Schema Package

Relationships guaranteed by database:
Why is this a problem? Makes it harder to make mistakes ? I doubt it :slight_smile:

MongoDB gives a lot of flexibility and makes coding much faster. Ability to store hash objects in which you do not know the form without recuring to additional forms of serialization or deserialization. + ability to search and index those “potentialy existing” fields. This is what I call a true database, a db that allows me to do anything I want with it :slight_smile:

I think a mental shift is required. Just like you go from any other template engine to React.

Maybe you are stuck in the SQL era. Not saying SQL is bad, but in my opinion it has way more drawbacks than MongoDB. I’ve worked with both large scale enterprise. And the majority of big apps in PHP tend to go to NoSQL data storages like MongoDB or Redis or DynamoDB because the SQL simply can’t handle it.

At this stage the only advantage I personally see in SQL is that it is more mature and better battle-tested. This will change in 5 years.

Cheers :slight_smile:


The transactions thing is bolted on and doesn’t actually do what a real SQL transaction manages to do.
I mean, your mongodb example of “two-phase commits” reminds me of a Rube Goldberg machine.

Type safety, again, this is application level.

And as for the relationship guarantee: Well, with a foreign key constraint properly set you literally cannot create a link to a non-existent document or, even more importantly, cannot unilaterally delete a document bound by such a restraint.

And this whaffling about how easier it is to store objects “where you don’t know the form” - seriously, if you don’t know what you’re writing to your database then you’re doing it wrong.

I’m also not surprised by “big app in PHP” switching to NoSQL - that’s kind of like the one-eyed leading the blind.


I think grapher is really great and it would be cool to actually talk about that, can we not drag the whole SQL vs Mongo thing into this thread again? If you want, start a new thread.


Well, I’m actually currently trying to try out the boilerplate example.

But the cloned repo is now stuck at Downloading meteor-tool@1.4.2-beta.7

This is on a Ubuntu VM, by the way.


@rhywden the war is not over yet :smiley: , but @sashko is right let’s not make this about SQL vs NoSQL.

Regarding the download try this:


I reverted the boilerplate to , do a git pull and try to run it again. There is a problem with the CDN for the 1.4.2 beta versions.


The export command solved the problem anyway - maybe by pure chance.

By the way, I’m getting 3 Syntax Errors in the console when I’m viewing the repo with the Edge browser.
Those errors don’t appear in Chrome.


Ty for feedback. It’s not pure chance, they have issues with their CDN temporarily for beta versions. Could you tell me the syntax errors? Cheers.


That’s the thing I should have mentioned: I can’t actually tell you more because

a) the console only tells me that there are Syntax errors and
b) clicking on them merely leads me to the end of the main html page (and not to the offending line of code).

All I can tell you is this:

SCRIPT5022: SyntaxError (1370,159)

SCRIPT5022: SyntaxError (1370,383)

SCRIPT5022: SyntaxError (1370,318)

And that’s about it. I literally cannot tell you more. The site still work, though.


Weird, does it happen on ?


Then again, DiscoHorse does give me errors in the console as well. So there’s precedent.


Cannot replicate in chrome or safari for mac.


Yes, I said that only Edge shows this behaviour.


Create another separate issue about this. This is related to Meteor & Edge. Just trying to keep this topic clean. Very good that you found it! MDG should take care of this.


Okay, then something else about Grapher. While I do appreciate the boilerplate example the folder structure makes it very hard to see what comes from where and goes where.

It’s reminding me of a goose chase sometimes - /server/server.js goes to /imports/startup/server which is actually /imports/startup/server/index.js which then branches off into a honestly bewildering amount of stuff.

Not helping is that stuff like access rights to users is not found in security.js but in expose.js while the definition of the collections goes like ./index -> ./fixtures -> ../../api/users/collections

Plus, there’s confusing stuff in there, too. Take this from /imports/api/users/security.js:

import { Meteor } from 'meteor/meteor';
import { Accounts } from 'meteor/accounts-base'
import UserSchema from './schema';
import Users from './collection';

Users.FIELDS = {
    emails: 1,
    roles: 1,
    profile: 1

Accounts.validateNewUser((user) => {

    // Return true to allow user creation to proceed
    return true;

Why is the attribute FIELDS set here when it’s obviously not used in the rest of the code here?

And so on and so forth - I can see the case for all those directories and naming conventions and such.

But honestly: You’re creating a labyrinthine structure here where even Ariadne’s Thread won’t help you much to understand what’s going on.


One more thing: Your documentation needs a documentation and description of the parameters for your functions.

For example,


obviously takes three arguments which are only kind of explained through an example whereas the preceding firewall() function isn’t even directly mentioned, only once again showing up in the examples.

And just so I don’t sound too negative: I like this stuff. I just have some difficulties getting started with it.


Regarding the folder structure. This is the recommended folder structure by MDG. and it makes a lot of sense to be honest. Regarding Users.FIELDS I believe that is reminscent of the app I copied it from. Regard it as leftover code. It will be cleansed.

But what you mention is a very good point, people can get confused, so we may need to show the structure tree and explain what is what in the :thumbsup:

Regarding the docs I agree, they can be a bit confusing at this stage. But did you read the guide first ? Before diving into the API ?

The development of this package went through the following lifecycle:

  • Figure out the API
  • Build the App
  • Build draft documentation
  • Build self-documented schema (grapher-live)
  • Build integration for query with react (grapher-react)
  • Build the docs in a friendly manner (meteor docs style)
  • (current phase) Increase adoption by making a very good documentation and video tutorials.

Any changes to the documentation are greatly appreciated. You can edit the documentation directly on github, I would gladly accept some PRs.

Thank you for the feedback, and continue pointing out wrong things, this’ll help us understand better what are the difficulties that newcommers face when trying to learn grapher.



Okay, I’m currently banging my head against this:

What do I need to do to in order to:

Publish all the users to a certain logged in user (or group)?

Because I’m missing something you did in your boilerplate and I’m only getting the currently logged in user.


You need to expose your collection.
Exposure creates a method and a publication depending on the options. This needs to be included and run server-side.
Then you need to query the users.

const query = Users.createQuery({profile: 1}) // or Meteor.users depending on how you import/export


Listen, that’s exactly the problem with the files being all over the place - I cannot make heads or tails of what goes where and why.

Isn’t there some kind of step-by-step walkthrough which explains exactly how to

a) create a collection
b) secure it on the server-side
c) subscribe to it on the client-side
d) and finally query it?

Because frankly I’m a bit tired of having to search through all the files to see what gets defined where and why and how it’s imported there and back again and three days from sunday.

For instance, I just tried to create a namedQuery on the server in order to expose it just like in your boilerplate only to have the build system tell me:

Error: We could not find any collection by the name SampleCollection

meteor mongo tells me that this collection does exist and that it also does have sample data.


I concur, for someone so feverishly complaining about MDG’s lack of simplicity and clarity in their documentation, you’re doing a bangup job muddying your own waters.