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:
- Client/server isomorphism when it comes to data handling is an antipattern and MDG rightly moved away from it
- 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