Grapher - Collection Relationship Manager + GraphQL Like Data Fetcher

announce
102

Regarding the $all, I would prefer the solution you already described in your github repo:

To give you an idea how this works, you can fetch the data like this:

{
    users: {
        profile: 1,
        githubTickets: {},
        posts: {
            title: 1,
            comments: {
                text: 1,
                date: 1,
                author: {
                    profile: 1
                }
            }
        }
    }
}

To be consistent if you type just

name:1

to show the data. If “name” is a field you get the data of the field, if its an object or an array you get all data with all fields.

103

That’s how it already works. If it’s an object you get the full object.

104

$filter is now working in Grapher Live. I also added $paginate: true (for the first node), so params “skip” & “limit” will be stored in options automatically without having you to write that $filter().

Regarding the $all… I am still a bit unsure the reason I removed it was because it may have lead to security leaks, but I think I have an idea how to make it secure also.

105

Hi,

This package looks great.
I have two questions:
How is caching on the client (webbrowser) side handled?
Can I somehow subscribe to a named query from a raw DDP client (for example .net)? Or can I publish a NamedQuery on the server with Meteor.publish()?

//Jonas

106

@alvestjo

Hello

  1. Reactivity is handled like Meteor currently handles it. Via local collections. Basically it will act like a publishComposite (https://github.com/englue/meteor-publish-composite)
  2. You can subscribe to a named query as you would to a normal query.
  3. Yes you can use it with a raw ddp client.
  4. If you don’t need reactivity you can simply expose a server-side route so you’ll have an HTTP API that accepts a JSON objects and you parse it. And in that route you will use createQuery , you can also secure it via createyQuery(body).fetch({userId: xxx}) if you used expose() on collections and you want to do it securely. If you specify {userId} on fetch, firewalls will be applied even if you are server side!
  5. If you need reactivity and you are outside Meteor’s client-side, you may need to dig a bit deep, bc you need to parse the messages correctly, check here: https://www.npmjs.com/package/ddp-client 
Or can I publish a NamedQuery on the server with Meteor.publish()?

We changed the terminology a bit here, instead of publish, we name it “exposure”. If you expose, depending on how you expose it (you can have it by method,publication or both)

It will create publication: named_query_nameOfYourQueryHere , and 2 methods: named_query_nameOfYourQueryHere and named_query_nameOfYourQueryHere.count (which only counts data, useful for pagination)

Code is found here and here

Cheers, really like the fact that someone outside Meteor’s ecosystem wants to use Meteor with Grapher :smiley:

107

Preparing for the next-level in Grapher: Reducers Concept Check it out, specs are not yet locked down.

1 Like
108

Reducers are LIVE! … along with other requested features! Like link validation, some more verbosity for errors, etc.

They now work with your Grapher-Live package to see what reducers you have for each collection. Reducers work with top-level fields, nested fields, links and other reducers! They work with reactive queries too! :slight_smile:

They integrate with your security from “Exposure Body” and restriction of fields and links.

Feedback is welcome. Cheers!

109

Hi,

Thanks for a very detailed answer!
I am bulding a meteor website that works as a userfriendly frontend for a old door-security-system. I have built a “connector” to the door-security-system in c#.net (running as a Windows service) and this connector use DDP to get notified of changes made in the webinterface (that should be transfered to the door-system). I have found some .net-ddp client code (not very maintaned) and it seems to be working quite good.

It would be cleaner with a REST API but the reactivity of DDP make the triggering of changes very fast. I have been looking a GraphQL with “subscription feature” but it seems to very new and not really a fixed-standard.

BTW: the reducers functionallity seems very good!
//Jonas

110

@alvestjo it’s the same standard that Meteor users. There’s no change done on that part. :slight_smile: If you don’t have nested relational data that you want to pass. You’re better off using standard Meteor.publish

111

Amazing tech. Thanks for sharing it :thumbsup:

1 Like
112

@pierreeric my pleasure :smiley:

If you have any ideas on how to make this even better, even if it’s a wild idea make sure to create an issue for it. Grapher is already production-ready and more and more people start to use it.

1 Like
113

Thank you, @diaconutheodor! With Grapher and Redis Oplog there’s new life in Meteor’s veins

2 Likes
114

Thanks @illustreets. And there’s more to come. I have some serious ideas for Meteor in the next 6 months that will rise to the level of Grapher and RedisOplog

3 Likes
115

Looking forward to that! Btw, do you ever sleep? :slight_smile:

116

When do you think real programmers write their code?
You can’t do that while sane and up, have to fall asleep first.

117

@diaconutheodor can you elaborate a little more about the future plans. Awesome stuffs happening here. :smiley:

118

Hi @diaconutheodor

I have been following your Redis and Grapher projects for awhile now, and look forward to implementing them in a “real” application at some point… hopefully soon. So first and foremost, a sincere thank you for all of your effort.

I was wondering if your Redis and Grapher projects are compatible with each other, and whether or not there are any complications in utilizing both. I apologize if this has been addressed already. I just am getting lost in the threads and am having difficulty piecing everything together.

Thanks again.

119

@moberegger yes they are compatible with each other, grapher reactivity is based on publishComposite, and we solved the publishComposite in redis oplog since 1.0.7 I believe.

@aislan I don’t like to tell and not deliver, :smiley: but the idea is have a documentation generator for your code, and improve on the API that meteor exposes which basically means “methods and publications”, next phase is an Admin Generator, to be able to create CRUDs in few lines of code (this is not an easy task, it’s very easy to do a shitty job), these will be the next steps. And we already began work on them.

@illustreets yes ofcourse I sleep, 8 hrs / night. Otherwise I become a zombie!

3 Likes
120

Hi @diaconutheodor,

Is grapher a front end agnostic? What is the compatible meteor version?

How will you integrate it in an existing meteor 1.2 app, blaze front pub/sub.

Do you have existing tutorials or guide on how to integrate it properly.

Thanks,
Marvin

121

@ajaxsoap so, yes it is frontend agnostic, because it uses Meteor’s pub/sub, rpc system (methods) as a backbone. Now regarding 1.2, we have for grapher the limitation of having 1.3+ because of npm dependencies. What stops you from upgrading ? :slight_smile: I’ve upgraded 3 apps from 1.2 o 1.4 directly without any change.

1 Like