Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

info sharing: vs relay2 #132

Open
cometta opened this issue Oct 22, 2016 · 1 comment
Open

info sharing: vs relay2 #132

cometta opened this issue Oct 22, 2016 · 1 comment

Comments

@cometta
Copy link

cometta commented Oct 22, 2016

Hi team,
Just to share with you all, relay 2 is on the way. the garbage collection seems cool. but I feel cashay is more suitable to use side by side with redux. https://www.youtube.com/watch?v=TcpS2nvt4-4 . no mention on subscription feature in relay2.

@mattkrick
Copy link
Owner

@cometta relay 2 is doing a lot of things right. For a deeper dive, check out https://zeemee.engineering/relay-2-simpler-faster-more-predictable-128769e72318#.11gyo5rgl

  • static queries. this is gonna increase your payload for mutations since you might be fetching things that your current view doesn't care about, but the difference probably isn't huge & a decreased upstream payload is worth the cost of an increased downstream payload. Overall fantastic. This is the 2nd time they used the 50ms to 5ms benchmark, but with no means of reproducing, I can't say if it's faster than cashay or not. Cashay does a lot of things to make the diff faster than relay 1.
  • arbitrary mutations. it's too early to tell, but any change to their mutation API would be good. Cashay, Apollo, and Relay all have ugly mutation APIs.
  • client state. i think it's very awkward to force your local state into your relay store. i'd much prefer stuffing your domain state into redux 😄
  • GC. This isn't really GC & and I wish they wouldn't call it that. It's a good idea, but I've never come up against memory constraints. Then again, I'm not trying to shove my web apps down the throats of 3 billion people with older mobile devices. When redux calls unsubscribe on a listener, it doesn't offer a hook. If it did, Cashay could do this very easily. Instead, what cashay does is dump the cache for a container when it gets invalidated. If that component got unmounted, then it won't get new data, so it'll just hold onto the parsed AST and an undefined value. We could offer a cashay.gc() command to clean stuff up, but honestly I've never run into memory issues so I've had no need to build that.
  • offline caching. This is scope creep for a client cache & i wish they'd knock it off. Now i have to persist my redux store + my relay store? bleh. I'd rather relay sat inside my redux store & just persist the one.
  • connection streaming/deferred. this is great, but again, your downstream payload is gonna pay for it if you're not using websockets because you're sending all those headers down. if you are using websockets, you probably just wanna use a subscription, anyways. I thought these were more GraphQL features instead of relay features...

You're right, they don't even talk about subscriptions, which bums me out. Hopefully they steal @live from cashay, which was stolen from GraphQL, anyways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants