4 ms·

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 i

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.
  - e1g 9y ago
    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.
    - Rodeoclash 9y ago
      Great to know, thanks!
  - whatever_dude 9y ago
    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.
ch4s3 9y ago
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.
sumobob 9y ago
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.
- robzhu 9y ago
  This seems like a pretty benign "cash grab" since it depends on helping the client succeed.
- djmashko2 9y ago
  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 9y ago
    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.
- thejosh 9y ago
  As long as apollo the client stays good and opensource, does it really matter if the devs also start doing more commercial projects?

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.
- e1g 9y ago
  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.
  - Rodeoclash 9y ago
    Great to know, thanks!
- whatever_dude 9y ago
  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.

ch4s3 9y ago

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.

sumobob 9y ago

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.

robzhu 9y ago
This seems like a pretty benign "cash grab" since it depends on helping the client succeed.
djmashko2 9y ago
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 9y ago
  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.
thejosh 9y ago
As long as apollo the client stays good and opensource, does it really matter if the devs also start doing more commercial projects?