6 ms·

Apollo Client 2.0

164 points by raphaelcosta 9y ago

deleted 9y ago
[deleted]
bpicolo 9y ago
Apollo link rest looks handy. Resolving it server-side would be even better. Is it more for client-side resolution?
- biscarch 9y ago
  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 9y ago
    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.
- aarohmankad 9y ago
  I believe there's a relatively simple ssrMode flag in Apollo Client 2.0 that may help your use case here?
  - bpicolo 9y ago
    Might work. Context here is I prototyped a json dsl to do similar graph-like resolving right on top of a python app as a wsgi middleware. Worked pretty well right on the metal. With this sort of graphql extension, having generic query power for restful clients is awesome. TBH I think that's pretty great compared to baking graphql clients.
nevir 9y ago
Congrats to the Apollo team! A ton of work went into this
breatheoften 9y ago
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
- whatever_dude 9y ago
  I haven't used Apollo yet, but: after spending roughly a year with Relay, I can't wait to try Apollo instead. To answer your question: the client basically creates the queries, parses the result, and gives you that. Normally coupled with a React-ready higher order component that handles the query. It's a bunch of automation of tasks that, sure, you could do yourself, but generally you shouldn't as there's some philosophical time sinks (state control etc) that most of these tools have already solved. GraphQL has a learning curve and its own terminology. Apollo also offers some server frameworks (to make things easier), some monitoring tools (Apollo-agnostic) and I guess they bread and butter is their consulting work.
  - Rodeoclash 9y ago
    I'd like to know where you feel Relay hasn't been suitable. We're writing a reasonably large app using Relay Modern combined with graphql-ruby in the backend and it's been wonderful. I did find that Relay does have a steep learning curve but once you've got your head around what is going on it's been able to handle every requirement we've thrown at it.
ewrcoffee 9y ago
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 9y ago
  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.
bgentry 9y ago
> 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 9y ago
  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.html https://www.apollographql.com/docs/react/reference/index.htm... Thank you for building the ember integration, I’ve met a couple people at GraphQL summit that are really excited about it!
  - bgentry 9y ago
    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 9y ago
      For sure - we've been super busy also organizing GraphQL Summit so it's been quite a week!
anonova 9y ago
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 9y ago
  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.
leetbulb 9y ago
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 9y ago
  Have you seen the Apollo Client DevTools? https://github.com/apollographql/apollo-client-devtools https://github.com/apollographql/apollo-client-devtools
  - leetbulb 9y ago
    Wow, cool! Thank you!
dfischer 9y ago
+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!
maktouch 9y ago
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.
petetnt 9y ago
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.
rightnow 9y ago
Apollo is amazing! Have been using it since the start. But too bad there is no working vue version for 2.0 yet. Really hoping for Vue to become officially handled by the ApolloTeam.

Apollo Client 2.0

164 points by raphaelcosta 9y ago

deleted 9y ago

[deleted]

bpicolo 9y ago

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

biscarch 9y ago
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 9y ago
  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.
aarohmankad 9y ago
I believe there's a relatively simple ssrMode flag in Apollo Client 2.0 that may help your use case here?
- bpicolo 9y ago
  Might work. Context here is I prototyped a json dsl to do similar graph-like resolving right on top of a python app as a wsgi middleware. Worked pretty well right on the metal. With this sort of graphql extension, having generic query power for restful clients is awesome. TBH I think that's pretty great compared to baking graphql clients.

nevir 9y ago

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

breatheoften 9y ago

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

whatever_dude 9y ago
I haven't used Apollo yet, but: after spending roughly a year with Relay, I can't wait to try Apollo instead. To answer your question: the client basically creates the queries, parses the result, and gives you that. Normally coupled with a React-ready higher order component that handles the query. It's a bunch of automation of tasks that, sure, you could do yourself, but generally you shouldn't as there's some philosophical time sinks (state control etc) that most of these tools have already solved. GraphQL has a learning curve and its own terminology. Apollo also offers some server frameworks (to make things easier), some monitoring tools (Apollo-agnostic) and I guess they bread and butter is their consulting work.
- Rodeoclash 9y ago
  I'd like to know where you feel Relay hasn't been suitable. We're writing a reasonably large app using Relay Modern combined with graphql-ruby in the backend and it's been wonderful. I did find that Relay does have a steep learning curve but once you've got your head around what is going on it's been able to handle every requirement we've thrown at it.

ewrcoffee 9y ago

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 9y ago
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.

bgentry 9y ago

> 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 9y ago
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.html https://www.apollographql.com/docs/react/reference/index.htm... Thank you for building the ember integration, I’ve met a couple people at GraphQL summit that are really excited about it!
- bgentry 9y ago
  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 9y ago
    For sure - we've been super busy also organizing GraphQL Summit so it's been quite a week!

anonova 9y ago

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 9y ago
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.

leetbulb 9y ago

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 9y ago
Have you seen the Apollo Client DevTools? https://github.com/apollographql/apollo-client-devtools https://github.com/apollographql/apollo-client-devtools
- leetbulb 9y ago
  Wow, cool! Thank you!

dfischer 9y ago

+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!

maktouch 9y ago

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.

petetnt 9y ago

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.

rightnow 9y ago

Apollo is amazing! Have been using it since the start. But too bad there is no working vue version for 2.0 yet. Really hoping for Vue to become officially handled by the ApolloTeam.