Meteor-bare vs Graphcool?

apollo
1

Im making a facebook type site to learn GraphQL. Im using React on the front-end and Im looking for the easiest way to get a GraphQL backend up and running but still have a lot of flexibility.

LevelUp Tuts has a series called “full-stack GraphQL with Apollo, Meteor & React”. He users meteor-bare as a build tool and to handle accounts, with React and Apollo on the front-end. I love Scotts content but the series isn’t finished yet. I think this is a similar to VulcanJS’s approach.

The other option is to use Graphcool and go serverless. Can anyone tell me the pros and cons of each approach? I love the serverless idea of not having to manage a server and the easy scaling but I’m a little apprehensive as it’s not something Ive done before.

4 Likes
2

Serverless seems pretty nice indeed, that’s probably the one thing I’d consider leaving meteor for :smile:

If your main goal is to learn GraphQL it seems like a good idea to minimize the amount of other stuff.

3

Look at

However, I love Meteor for just abstracting all the fragmentation away.
Hat’s off to Scott btw…more than awesome he’s putting the course out for free.

Also check out the top notch repo here: Starter kit with local database?

2 Likes
4

I did not explore this in depth yet, but look at this issue: https://github.com/meteor/meteor-feature-requests/issues/224

I strongly believe that serverless applications are the way of the future, but I wouldn’t say to ditch Meteor for it, just make Meteor methods exportable to lambda without having to keep a web node listener running.

I will maybe book myself 8h to 10h this month to do investigate it in depth, as this will mark the next stepping stone in the evolution of Meteor.

2 Likes
5

That seems nice for scaling, but it’s not really “serverless” as you’d still have your main meteor server dispatching jobs and presumably mongoDB.

What makes “serverless” providers like Graphcool or the older Firebase appealing to me is to have the complete backend managed for you, for rapid development and easy maintenance.

6

You don’t need a main meteor server. You export the js inside a lambda function, and the frontend communicates with it… somehow. That was the idea.

Edit: Oh yes, I see that I left a comment stating that we will still have Meteor servers to hold the DDP connection.

I will dedicate some time this month to it. There must be a way to do Meteor Serverless.

7

Ah okay. At that point though, what are you actually using Meteor for? Just as a build tool?

The only valuable clientside feature I see that Meteor provides is MiniMongo, and that’s only when using subscriptions, which requires a Meteor server and MongoDB.

8

Trying graphcool has been on my todo list for awhile. But recently I think I’ve changed to where I would try this over graphcool:

1 Like
9

I’m trying out AWS AppSync, and I don’t like the product unless you’re part of AWS already. It comes with all of the Congito/IAM/etc overhead. Plus, you’re completely locked into AWS.

GraphCool changed a lot recently, and it’s a little confusing. There’s three iterations out there.

  1. GraphCool BaaS
  2. GraphCool Framework (open sourced GraphCool BaaS)
  3. GraphCool 1.0 (GraphCool as a database layer)

I’ve used all three. BaaS is genius, but ultimately not practical. Its simplicity created too many hard, often impenetrable edge cases for production apps. However, if you’re looking to get started with GraphQL and want to experiment, use their BaaS! Migrating isn’t too hard either, so it’s not a bad way to kick start your project.

GraphCool 1.0 is the right abstraction. 1.0 manages the database migrations and codgen types. You still run your own GraphQL server.

2 Likes