Meteor meets GraphQL

announce
62

It’s major selling point to work with non-mongo dbs.
And also from the server performance wise, it’s much better since it won’t deal with oplog stuff and merge box.

But, if you don’t see any issues with Meteor MongoDB, there is no reason.

That being said, GraphQL client side declaritive use is pretty amazing. That might be a reason to use it.

2 Likes
63

Facebook is increasingly a product used by young developers to talk to Grandma. If they want to attract those young developers, they need something to cool to offer. Having the coolest tech stack is certainly a way to do that. Note the problems GE is having attracting developers to work there (they even make fun of themselves in TV commercials - the ones with the “You aren’t developing anymore? You gonna work on trains?” - a total panic).

64

I agree with you. What FB is doing a way to get attention for good young developers. They are not going to make a business on this yet.

But they will be, if FB’s revenue is failing. Check Parse. It’s a pretty awesome platform. I didn’t know that we can host node apps inside it.

Anyway, the tech coming from FB is great. Not everyone, but most of them.

2 Likes
65

I totally agree. Great tech, very well thought out, solidly reasoned stuff from them.

66

@arunoda is there going to be a server only package for Meteor GraphQL? For example I have a few micro services that don’t need the client code (especially Browserify which has slown down my build times in the past).

For now i’m just forking it but it would be great to have a sub package that we could import directly when needed!

At any rate, thanks so much!!

67

Just use Lokka and expose your schema via express-graphql.
Or may be just follow the spec of it.

We didn’t do it with Meteor because we need to work on the User auth first.

1 Like
68

Just use Lokka and expose your schema via express-graphql.
Or may be just follow the spec of it.
We didn’t do it with Meteor because we need to work on the User auth first.

Oh I just meant I only need the server part for a Meteor micro-service, I think you thought I was talking about a regular Node app? I’ve just been using Meteor because it’s nicer with fibers :smiley:


Also using RethinkDB in Meteor is now easy with the promise drivers and Meteor-GraphQL :smile:

BlogPost = new GraphQLObjectType({
  name: 'BlogPost',
  fields: () => ({
    // ....
    author: {
      type: Author,
      resolve(post) {
        return r.table('authors').get(post.author).run();
      }
    },
    comments: {
      type: new GraphQLList(Comment),
      resolve(post) {
        return r.table('comments').filter({ postId: post._id }).run();
      }
    }
  })
});
8 Likes
69

@arunoda have you thought about how GraphQL fits into database schemas?

Postgres will need one but if you’re using a NoSQL database with GraphQL and you have the option to use Mongoose with promises or RethinkDB with Thinky (rethnk ORM) vs the regular Rethink driver.

It seems like with these databases you can skip the schema ORM and use GraphQL as the schema.

However, it gets tricky on the serverside… you still want a schema there.
Server-side fetching/mutation could happen through a separate server-only schema.

Thoughts?

70

Interesting.

Normally GraphQL have projects like this which let you use ORMs like Bookshelf.

But, we can do the other way around as well. We define the schema for some types in GraphQL. Then it’ll create us some good top level filed to query the model and some mutations to update the DB.

There is no project like that, but I think that’s a good option.

It’s pretty easy to implement something like this for NoSQL dbs.

2 Likes
71

@arunoda
What are the benefits of using Lokka over Relay?
What was the purpose of creating it?

Thanks!

1 Like
72

It’s a pure JavaScript client without any dependancies. (even React).
It’s built to use in places where you can’t run Relay and offer a very simple API. (In contrast relay has better features in caching)

4 Likes