4 ms·

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 cre

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.

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.