
Apollo Client 0.5 - clessg
https://dev-blog.apollodata.com/apollo-client-0-5-f1eb3f122ace
======
saikat
Having worked with a lot of Javascript frameworks aimed at creating web
applications/SPAs (used Cappuccino to build a wireframing tool, Backbone.js to
build a dashboard for a payments provider, React/Relay to build a phone
calling tool and events platform, and now React/Apollo to build a peer-to-peer
texting tool), I can say that React/Apollo/GraphQL is my new go-to stack for
new JS projects. It's a pleasure to work with, and a lot of the pain points of
creating large apps with JS in the past are handled very well. Congrats to the
Apollo team!

~~~
johntran
What are the pros and cons between Relay and Apollo?

~~~
helfer5
Before we started building Apollo Client, we actually tried Relay, but found
it difficult to adopt, so we started a community effort to build a more
flexible GraphQL client. Our main goals were to make incrementally adoptable,
compatible with all view layers and easy to understand/debug.

While Apollo is easier to adopt and use, it's still under active development,
so it's not as stable as Relay, and hasn't been optimized for performance the
way that Relay has.

disclaimer: I work on Apollo Client

~~~
scoot
/disclaimer/disclosure/ \- when you disclose something, it's a disclosure.
(Sorry, personal bugbear, along with e.g. / i.e. confusion. Both are rampant
on HN! :) )

------
bgentry
I started a new Ember.js project recently and got frustrated with Ember Data
and JSON API. In my experience, it's the weakest part of Ember by far. Out of
curiosity, I tried wiring up Apollo Client to my backend instead. Turned out
to be very easy to get going.

So far I like apollo-client and GraphQL much more than Ember Data. I get full
control over what data is being loaded on each route and only fetch exactly
what's needed. Mutations with explicit arguments are also much better than the
blob.save() / save-everything style encouraged by ember-data.

With client-side resolves in the next release, this integration should get
even better. Hopefully they'll also switch to using GETs for non-mutation
queries to enable some much better caching options.

------
crucialfelix
I spent a day or so with relay and kept being blocked by mysteries or tired
out from the amount of code you need to set up for a mutation. Branched and
tried it with Apollo and everything has been pretty easy going.

Merging Fragments in the style of relay were my main concern with Apollo but
they do have this now.

All in all much more flexible and readable than relay.

------
djmashko2
One of the developers working on Apollo GraphQL stuff here, happy answer any
questions! So exciting to see this on HN.

~~~
pinouchon
Do you plan to make an integration with Meteor ? My main frustration with
Meteor have been than it is tied to mongo (and not a relational db). I see
Apollo as a way to plug Meteor with any data backend. If I'm not mistaken,
that was the original sales pitch of Apollo.

So my question is: should I have high hopes of being able to work with Meteor
and Postgres with the help of Apollo?

~~~
djmashko2
A lot of people are doing that already! You can use Meteor as the build and
deployment system for your app, and use Apollo for data. The main remaining
blocker is the accounts system, since it is still tied to a particular MongoDB
schema. We're working with people in the community on some ideas about how to
make Meteor Accounts database-agnostic, so once that is possible it will truly
be possible to build a Meteor app on top of any backend.

~~~
pinouchon
Can I find any moderate-size app that uses Meteor with Appolo and Postgres as
an example? The Meteor guide and tutorials, as well as most well-known Meteor
open source apps (wekan, telescope...) use mongo collections.

And since Meteor is a full stack framework, I would love to see a guide about
how to best structure an app with Meteor and Apollo (I'm in the camp where I
don't like to fiddle around with what's the best js stack. I'm happy to have
the framework authors decide that for me, and get down writing my goddamn app)

~~~
djmashko2
It's meant to be part of a decoupled stack where you can pick and choose
different options for UI, backend, etc. We're constantly working towards
having clearer integrations and patterns. If you just want to get a thing
built without making decisions and putting in some work for integration, I'd
just go with the built-in Meteor stuff for now.

------
anonova
I've been wanting to try out vue.js and have a GraphQL endpoint. Apollo seems
like a Relay alternative that's not tied to React. Can anyone compare the two
(Vue.js+Apollo and React+Relay)?

~~~
djmashko2
I haven't used Vue.js yet (but really want to try!) There's a community
integration with Apollo here: [https://github.com/Akryum/vue-
apollo](https://github.com/Akryum/vue-apollo)

------
duaneb
This looks really cool.

The name is completely unrelated to its function; I thought this was NASA's
code. Imagine my disappointment when I saw a javascript library for working
with GraphQL!

~~~
sumobob
and then your excitement after checking it out?

~~~
duaneb
Well it's a nice client! Just had to alter my expectations.

~~~
djmashko2
Thanks - we went through a ton of different names, and almost all of them had
some sort of collision. We try to mention GraphQL up front on all of the
content to avoid extended confusion :]

~~~
clessg
I probably should have included the fact that it's a JS GraphQL client in the
title, but I wasn't sure if that would violate HN's "editorializing" rule.

On the bright side, we apparently got a few people who thought it had
something to do with NASA. Muahaha!

