Isomorphic data handling with Apollo?

[nmaro]

I’ve been following the apollo development from a distance, waiting for the time it would be reintegrated with the meteor ecosystem. With the recent blog post we hit a first milestone (I guess the next will be when it gets integrated into the guide).

MDG’s vision is clear: “The aim of Apollo is to serve as the only data stack you’ll need, going forward.”.

I get why graphql is better than REST. But what about what we already have?

Posts = Mongo.Collection("posts")
Posts.find(...)

Remember the first time you saw this client code snipped and thought Where the hell is the code that deals with the communication between client and server? This was the feature that made me fall in love with meteor in the first place. Reactive, isomorphic data handling. Write code in the client that feels like you are fetching data directly from the db. Okay, add a publication to deal with security, a subscription to get reactive code, but that’s it.

So here I am trying to understand the recent developments, and I see the following options:

1. Client/server isomorphism when it comes to data handling is an antipattern and MDG rightly moved away from it
2. MDG will take us by the hand again and create a new full-stack abstraction built with or on top of apollo that feels like the solution above

Or maybe I got the picture completely wrong. In any case, I’d be grateful to hear the thoughts behind these design decisions. Thanks

Edit: less verbose

[awatson1978]

I was wondering about this myself. From what I’ve gathered, the client-side GraphQL queries can be run on the server via a loopback call. Basically, the server will treat itself as a client, and we get server/client isomorphism. The difficulty is with the Mongo shell and other databases.

The good news is that Mongo uses V8 as its shell interpreter, which can be hacked and extended upon with .js files. So people who want to retain an isomorphic data layer will need to extend the Mongo shell so it supports GraphQL syntax.

[nmaro]

Has been a month, but still wanted to thank for the answer.

I also wanted to quote @gdc3 from this thread.

Future of Pub/Sub and DDP

Meteor has its warts and its weaknesses, but pub/sub and DDP certainly
aren’t among them. I get that MDG is integrating Apollo in order to
expand the architectures it can support, but I like how light DDP is and
how I can write many of the business rules once, attach them to a
transform (model) on the collection and use them on both server and
client. I look forward to a long and healthy life for pub/sub and DDP

Exactly my sentiment. My hope is that there is a way to recreate the same experience on top of graphql, so that we can move on.

[nmaro]

Also, the option that a transparent data layer is an antipattern, and that it’s better to separate client-server concerns with respect to data fetching, is still open in my mind. I’d love to hear an opinion from MDG.