Your arguments make sense, but Grapher simplifies querying and allows you to build secured database code even for a simple application, and especially when you have linked data which 99% of apps do. That’s the thing, I’m sorry that only a small subset of people understand why it’s so worth it, maybe lack of patience to read through the docs and not being recommended by MDG ?
And regarding your comment:
Very good idea with that landing page! Also we are not targeting advanced use-cases, Grapher is so simple, but it can also be very complex and contain strong caching abilities.
And now, we can use it’s performance inside GraphQL (as I promised from the beginning of the previous massive thread).
I’m personally sold on need for Grapher and we’re planning to use soon to manage some associations that we’ve.
But by advanced use cases, I don’t necessarily mean complex because I know you’ve put a lot of thought on the developer experience, I mean something that is not absolutely needed at the start. As experienced developers, we tend to have the curse of knowledge bias. If we try to see things from a new comer perspective some of which are just learning basics of mongo queries, and their minds are overloaded with absorbing to many new concepts, I’m not surprised that a lot would chose the absolute minimum learning/reading to implement their initial project. But then as they start scratching their heads on how to do reactive joins or reduce the association boilerplate code they’ll start searching for solutions, and that’s when I think, they should navigate to the Cult of Coders landing page
Just to give some feedback: These things need time to get wide adoption. Me personally, I kinda like grapher, but I’m a bit tired of being early adopter of things like this. You seem like a fast-moving person, which implies the risk of you fast-moving away from grapher / meteor one day. Could be wrong, but I don’t want to build my app on another piece of software I eventually will have to maintain myself (not saying you will, there’s just a risk when being an early adapter). This of course makes it a bit of a chicken/egg thing, so these things just need to grow and prove themselves over longer periods of time. Just like react was already out for years before it really got picked up everywhere.
The current GraphQL hype also doesn’t help Grapher. I understand there’s a lot of differences, but there’s also enough similarities that it doesn’t make sense to adopt both IMO.
I think Meteor community has learned hard lessons from some of the early adopters, Kadira was a good example of fast-moving company. So I agree it takes time and patience to build long-term trust and standout from the hype.
You cannot be an early adopter, first commit: Sep 14, 2016. I’m fast moving but loyal, redis-oplog, grapher and now cultofcoders:apollo
I’ve created the proper bridge for GraphQL in Grapher (they are not mutually exclusive at all, they are good friends and I’ve stated this since the beginning, there may come a point where Grapher’s technologies get blended in GraphQL/Apollo).
I just finished creating my repo I have proving tests that demonstrate speeds up to 25x for simple nested queries (3 level only) faster than using standard GraphQL resolvers! But in real life scenarios with remote databases(lots of time spent on the wire), I expect much more serious numbers, we’re talking 100x, 200x, 500x for very large queries, the nature of Grapher as it is with redis-oplog, it has exponential performance growth, the deeper the query the more performant it gets. (Provided the queries are in MongoDB)
As I know that big claims need to be backed up by big evidence, a simple repo would not suffice, and I’m working on that full report, should have the tests and proofs (which everyone can run on their machine) by next Friday, and show everyone that all the work in the past years was for the greater good of Meteor
We are here for the long-run. What we built, we didn’t build for money (Kadira), we built them to stay in Meteor. There was no way to work with relational collections in MongoDB, we made a way, there was no way to scale the reactivity, we made a way, now, there was no way to use Meteor’s reactivity with Apollo/GraphQL, we made a way. If you study our pattern, everything we do is to harness and contribute to the community, give something back, and also find reasons to stay.
I can’t say how amazed I am by your work. Thank you (even if I never tried yet, I am still impressed and will probably start using it in my next project)
Thank you! Btw, the current tests are absolutely flabber gasting, I’m in awe, I just run them, they surpass my expectations:
For a simple query we get 5X
For a bit more complex query we get 35X
For a huge nested monster (5 level deep) we get minimum 200X, because it took 120s and it timed out with failed to fetch, while Grapher does it in 580ms
I’m going to open-source my project, make some nice charts, and going to create a clickbait title on Meteor forums (that doesn’t lie ofcourse) and create easy instructions for people to test this on their own.
Hey, I think what could help with adoption is a list of real world examples. Something that can be found in every other meteor application. That way devs relate to it more easily and might give grapher a go.
@diaconutheodor do you have a blog? I think it’s very good to do blog posts about your progress. We can help spread the word out, it’s not everybody that’s reading forums every day like we do.
Just a suggestion! and keep up with this great job.
The Meteor roadmap alludes to the Apollo stack one day replacing the DDP stack. This feels like the perfect “tight” integration with GraphQL/Apollo that Meteor devs have been wanting.
I feel like that if there is an expectation on the community to implement these kind of “feature requests” to push Meteor forward, that there should be some effort put into getting these projects attention. It’s unfortunate that this great project can kind of just be brushed aside because no one working on the Meteor project has used it. That kind of approach was never taken taken years ago with community work.
For new projects I recommend going with Meteor + Grapher + Apollo. But please wait 1 more week, so we can stabilise and mark as production ready the set of tools we’ve built. In the meantime, start learning GraphQL syntax and look how simple you can add it to your Meteor: https://github.com/cult-of-coders/apollo
Reactivity with Apollo has been solved since 2 weeks. Now I’ve actually found ways to have scalable reactive data graphs which leverage the power of Grapher and Meteor with Apollo. I am currently working on this solution as we speak, here’s how a simple “ReactiveQuery” looks:
// NOTE THIS IS UNREALEASED YET. STILL WIP
import React, { Component } from 'react';
import QUERY_LAST_COMMENTS from './gql/lastComments';
import SUBSCRIPTION_LAST_COMMENTS from './gql/lastCommentsSubscription';
import { ReactiveQuery } from 'apollo-live-client';
const Comments = ({loading, data, error}) => (...);
const CommentsWithData = () => (
<ReactiveQuery
query={QUERY_LAST_COMMENTS}
subscription={SUBSCRIPTION_LAST_COMMENTS}
variables={{ options }}
>
{props => <Comments {...props} />}
</ReactiveQuery>
);
export default CommentsWithData;
So, API is finalised, the next step would be to write a bunch of tests and proper docs.
Congratz to you and your team @diaconutheodor ! You definitely deserve it! Really haven’t seen a more awesome piece of code for meteor than Grapher! Loving it so far and makes my life a whole bunch easier. I know MongoDB is supposed to be NoSQL - but one can’t just ditch all the relational stuff.
I thought about this and I believe the important part is the api code, not the client one
In the end what will make me choose between grapher and graphql bridge is the way to define schemas and resolvers.
The less boilerplate will win.
For now I feel like Grapher is better written than Graphql regarding this aspect.
Tooling is better on graphql now, but it is still not perfect (I love voyager. Imagine the future: create a usable graphql API from a UI like microsoft access but open source)
But I prefer a nice API and doc over a nice tooling !
Tooling can always be done later
Api is super important
@klabauter not only it helps you with relational stuff, in quite a few cases it’s superior to SQL in terms of bandwidth and speed of delivery, which is absolutely crazy, I don’t have time right now to actually create proof for this because I’m working on something that will shake Meteor.
@antoninadert
Grapher & GraphQL are two different beasts, the only thing they share is the similarities in the request body. Regarding docs I totally agree, I got intimidated by GraphQL in the beginning, I was thinking it’s for very large apps that it’s too much, only to realise that it’s a very simple, very elegant AND productive way to design your API.
Where MDG fails in their guidance is in the learning curve. They have solid, well-written documentation, but they don’t have the learning curve or they have it to steep. That’s why we had to make www.meteor-tuts.com to help our new developers learn Meteor faster, and because we love the community we open-sourced it. Something similar will happen to Apollo/GraphQL.
While I totally agree with less boilerplate, sometimes a bit more code can bring huge advantages to working in teams
Dear Meteor community.
Please show @diaconutheodor and his team some love and donate a little bit to projects like Grapher: opencollective
Our community and the Meteor ecosystem is in desperate need of guys like them and push us forward.
