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
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
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.
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.
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).
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) => {
UserSchema.validate(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,
Exposure.restrictFields()
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. https://guide.meteor.com/structure.html 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 README.md
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.
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
query.subscribe()
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.
, but 
