> 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/
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.
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...
Thank you for building the ember integration, I’ve met a couple people at GraphQL summit that are really excited about it!
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.
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), though I had to install three @types packages: graphql, lodash.flowright, and zen-observable.
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.
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.
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] ...?
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.
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.
We migrated from Relay to Apollo after using Relay since 0.1 and then investing to change it for Relay Modern. Never looked back.
I introduced GraphQL and Relay into our stack so was biased towards Relay "because Facebook". As the app grew, we started having found it more difficult to bend Relay to our needs. For example, its focus on React makes it of little help for client<->server comms in vanilla JS or outside of components (e.g. background tasks, service workers, action functions). It also has limited options for directly accessing/manipulating store data, which further restricts its use-cases within the app.
I initially hesitated to change clients because who could do GraphQL+React better than Facebook? When I first evaluated Apollo a year ago, Relay was still more comprehensive so we stuck with it. But today, everything Relay does Apollo either did first (e.g. subscriptions), does as well (e.g. component wrappers), and often better (e.g. direct cache management). For us, the primary reason to change was that Apollo is "JS-First" rather than "React-First" - this provides more suitable building blocks to design components, interactions, caching layers etc. Our client<->server comms are more flexible, more predictable, and easier to explain/develop.
Apollo 2 introduces apollo engine, network links, and custom client-side memory managers - I was satisfied before, but now I'm excited by the new ways to extend & instrument the data-management layer in our app. I would encourage you to evaluate Apollo as it is a highly competitive alternative from a highly competent team.
It's more a feeling (as strange as it sounds), but off the top of my head,
1. Relay's documentation is not good enough. There were points where major features were never mentioned anywhere except for a random keyword thrown inside an example. You had no idea what it did and how. Other times you have a basic feature that should be working but isn't, and made very hard to try different things because of the vagueness of the docs. This is getting better, but not quick enough. It's not their focus, I believe.
2. It's clear from their migrations from Classic to Modern and their efforts in evolving the library that their focus is on making Relay what Facebook needs, not what might help a larger community. See 1. This is their right and their choice, but it means it makes it less suitable for my company's usage.
3. Relay imposes certain additional constraints both on the client and the server (and their schema) that might not be needed or desired. Relay uses a super-standard of GraphQL of sorts, with its own flavor of requirements. I'd rather have more freedom/adopt a more global standard with just GraphQL itself, and just have basic guidances.
It can work and it does. But there's too many sore spots that I feel are greater and more numerous than what I've come to expect. Hence why I think Apollo has a better direction going forward.
It's pretty good imho, but the docs are a little light, especially for ApolloFetch. If you want to go full Apollo, and use their React integration, it basically just works. It's nothing to rave about, but it seem good enough.
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.
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
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
So open source built and invested in to eventually attain money is a bad thing in your opinion? What would that mean exactly? Only large companies that release a few bits as open source is palatable in your opinion? Smaller companies or individuals with a passion and vision for evolving our tools can't structure a strategy to eventually make money from it so they can keep doing it?
At the end of the day, I think it's the perfect model. Especially, when those building the open source, keep what was free before FREE, and simply go even FARTHER to build auxiliary stuff that costs.
This logic just bugs me every time. It's not akin to "selling out" as if you're making art/music, and then you dumb it down for the masses. It's finding the only way to make it work where you can directly and exclusively focus on much-needed tooling, rather than typical non-developer products like Uber or Facebook. And sometimes you don't care about building non-developer products--you just want to build developer tools (because you've gotten obsessed with it and you see what would benefit your fellow developers), and you need to find a way to make a living off of it, or pay the people you've brought on board to attain this long-term vision.
In short, it's a win win for everyone.
And by the way, the fact that you even had to say "[you] knew it was coming" is ridiculous. They at like month 1 of their work on this open source stuff had a paid analytics service. Their paid out service has been out for a very long time. It was as transparent as can be what their strategy is. The amount of work their large team of developers have done could be accomplished no other way.
Ultimately your perspective here, I'm sorry--and this is my perspective--does a lot of harm to the community. If everyone had this perspective in earnest (and I'm not even sure you do), it simply would mean less tools we desperately need. It would be fantastic if we could find more cashgrabs for developers to focus on tooling--there's just so much to be done.
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.
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.
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.
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.
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.
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.
Unfortunately it seems like the core API docs are still woefully out of date and full of broken links: 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