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] ...?
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 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.
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
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.
Do you get paid for the code you write? If so, would it be fair to characterize your work as a "cashgrab"?
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.
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.
Thank you for building the ember integration, I’ve met a couple people at GraphQL summit that are really excited about it!
Excited to try out 2.0 soon!
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.
The ApolloProvider parameter for client is also broken: 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, though this issue has repeatedly been opened and closed.
Will definitely take another look at the v2!
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.
Congrats of releasing Apollo Client 2.0, can't wait to try it out in production.
