
Apollo Client 2.0 - raphaelcosta
https://dev-blog.apollodata.com/apollo-client-2-0-5c8d0affcec7
======
bgentry
> We have also rewritten a large portion of the documentation for using Apollo

Unfortunately it seems like the core API docs are still woefully out of date
and full of broken links:
[http://dev.apollodata.com/core/](http://dev.apollodata.com/core/)

Despite that, my experience with Apollo in general has been good. I maintain
the Ember addon for it, and I find I'm much happier and more productive with
Apollo Client + GraphQL than I ever was using ember-data + JSON API.

[https://github.com/bgentry/ember-apollo-
client](https://github.com/bgentry/ember-apollo-client)

~~~
djmashko2
Hi Blake! Unfortunately we did not have time to finish all of the redirects
for the old site, so we have both versions up at the moment. I expect to have
the redirects working properly by the end of the week, here is the new
location for that page:
[https://www.apollographql.com/docs/react/reference/index.htm...](https://www.apollographql.com/docs/react/reference/index.html)

Thank you for building the ember integration, I’ve met a couple people at
GraphQL summit that are really excited about it!

~~~
bgentry
oh wow, a whole new site :) I missed that in the announcement, and the only
link I can find there is kinda buried in the conclusion. Might be worth making
that more prominent or at least updating the links in the apollo-client repo's
readme.

Excited to try out 2.0 soon!

~~~
djmashko2
For sure - we've been super busy also organizing GraphQL Summit so it's been
quite a week!

------
anonova
Nice to see a lot of improvements! I spent some time today to upgrade an app
from Apollo 1.9. I ran into some issues if you use TypeScript.

The typings used in the library are not listed as dependencies, so I had to
manually install them. This may get fixed soon
([https://github.com/apollographql/apollo-
link/pull/171](https://github.com/apollographql/apollo-link/pull/171)), though
I had to install three @types packages: graphql, lodash.flowright, and zen-
observable.

The ApolloProvider parameter for client is also broken:
[https://github.com/apollographql/apollo-
client/issues/2212](https://github.com/apollographql/apollo-
client/issues/2212)

Also, `data.loading` still gets stuck to true. See
[https://github.com/apollographql/apollo-
client/issues/1186](https://github.com/apollographql/apollo-
client/issues/1186), though this issue has repeatedly been opened and closed.

~~~
shitlord
I was affected by the `data.loading` bug. I really like the Apollo ecosystem,
but bugs like this are highly visible to customers (and often embarrassing to
explain). But I'm glad that these problems are slowly being addressed.

------
ewrcoffee
We tried Apollo in its very early stage, the code complexity and the hard to
debug object cache management drove us away. We are quite happy with some
simple combination of raw fetch and mobx.

Will definitely take another look at the v2!

~~~
aarohmankad
To hit on one of your issues, Apollo Client 2.0 now has decoupled cache
management, meaning you can tune the cache to your specific use case.

------
breatheoften
Is Apollo good? I feel like I’ve been aware of their existence for a long time
— they have a large marketing presence but I don’t actually have any idea what
it is ... there’s a server for making graphql servers and a client for doing
...??? I know they have tools for compiling graphql queries into various typed
language interfaces which I have lusted for.

I feel like every blog post of theirs I’ve ever clicked is high percentage
marketing and not a lot of focused explanation ...

They have a tough communication nut to crack — they have to sell to people
who’ve never heard of graphql, to people who’ve lusted after the vision
communicated very clearly by Facebook for graphql and relay, to people using
redux and the disarray of different mechanisms for straddling the various in
practice divides between local and server state.

Being able to map rest apis into graphql apis on the browser side seems like a
nice migration strategy but there still seems like something missing to me to
feel like I know what the value proposition of the Apollo Client is ...

Are there any good live demo style introductions to Apollo — something
gripping like the original redux conference demo[1] ...?

[1] [https://youtu.be/xsSnOQynTHs](https://youtu.be/xsSnOQynTHs)

~~~
sumobob
I am a huge apollo fan, but their endgame just became clear, get people using
apollo, have those products scale and need monitoring and analytics, charge
for said monitoring and analytics. I knew it was coming, just sad that it was
all a cashgrab in the end.

~~~
djmashko2
Hi sumobob! Sashko here - open source lead at Apollo

I'm glad you've been having a great time using Apollo. I hope we've been up
front with the idea that we have commercial products since the start, and I
think monitoring and analytics are reasonable places to do that since pretty
much all of these services are paid. We also provide paid support to large
companies trying to move to GraphQL and Apollo.

On the other hand, I'm excited that having a business model will continue
enabling us to build great tools, and open source as much as possible. We've
been very careful to make sure that all of our tools are decoupled and
flexible, and don't lock you into using any other part of the stack. For
example, the monitoring in Engine is based on an open source specification
called Apollo Tracing: [https://github.com/apollographql/apollo-
tracing](https://github.com/apollographql/apollo-tracing)

In fact you could turn on tracing in your GraphQL server and pipe that data
into any service you want, so it's pretty straightforward to avoid using
Engine if you don't feel it's a good value for you!

Happy to answer any other questions, we're going to keep working on our stuff!
Sashko

~~~
sumobob
I love your stuff, I've just seen this play in action through the meteor
community and how kadira grew and everything thats happened since then.

You know what they say, once burned, twice shy.

------
maktouch
We're using Apollo v1 and tried the upgrade to v2 a few weeks ago. It was hard
and buggy to replicate what we had (subscriptions, batched requests, polling
requests). We reverted to v1 in the end because if the bugs and the
complexity.

What really hurts us in v1 is the error handling. When querying a collection
of items, if 1 item has an error, only the error is returned with no payload.

Hopefully all of these will get resolved the coming months.

------
nevir
Congrats to the Apollo team! A ton of work went into this

------
bpicolo
Apollo link rest looks handy. Resolving it server-side would be even better.
Is it more for client-side resolution?

~~~
biscarch
link-rest fits the use case where you might not be able to transition the REST
endpoint to be behind a GraphQL API (and thus be server-side resolvable which
is definitely preferable) due to organizational or other concerns.

~~~
bpicolo
Right, but it would be great to take full advantage of the existing rest
endpoint server-side. With that you don't even necessarily need to build
GraphQL apis at all, and sort of get the best of both worlds.

------
dfischer
+1 to Apollo. It’s been amazing so far. No real hurdles. There’s maybe a few
tricks to figure out how to manage auth but it’s not too bad. Good stuff!

------
petetnt
Apollo's set of tools are some of my favorite programming libraries/tools
ever. They _just work_ and more often than not I have thought of an feature
that turned out that they already had.

Congrats of releasing Apollo Client 2.0, can't wait to try it out in
production.

------
leetbulb
Sweet! I've been waiting for this! I've yet to tinker much with 2.0 though...
Is there a nice way to debug state similar to Redux DevTools (now that Apollo
no longer uses Redux)? Being able to use Redux DevTools is one of my favorite
features about Apollo.

~~~
jahewson
Have you seen the Apollo Client DevTools?

[https://github.com/apollographql/apollo-client-
devtools](https://github.com/apollographql/apollo-client-devtools)

~~~
leetbulb
Wow, cool! Thank you!

