Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we decided against GraphQL for local state management

tech.okcupid.com

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Why we decided against GraphQL for local state management

#71

Post by sidlls »

openfuture wrote: post #68
pier25 wrote: post #36

State management is one of the reasons I moved away from React and Vue. You need a lot of machinery and plumbing to do something that should be really simple. MobX is probably the best way I've found to manage reactive state with React, Inferno, etc, but still, it's a huge piece of of software for just this purpose. I first moved to Mithril because it doesn't need reactivity. You solve the same problem than React/Vue…

> should be really simple Ummm... no, state management is pretty much the only hard problem in programming.

Can you support that? This doesn't seem like anything approaching the truth in the vast majority of web applications (where things like React are typically used). Mostly, in my experience, front end development is made unnecessarily complex by the developers involved.

Re: Why we decided against GraphQL for local state management

#72

Post by claytongulick »

I dunno. I was pretty frustrated by most of the state management solutions out there, so rolled my own [1]. So far been really happy with it. Super simple graph based notifications, does everything I need.

[1] https://github.com/claytongulick/applicationstate

Re: Why we decided against GraphQL for local state management

#73

Post by cjonas »

pier25 wrote: post #36

State management is one of the reasons I moved away from React and Vue. You need a lot of machinery and plumbing to do something that should be really simple. MobX is probably the best way I've found to manage reactive state with React, Inferno, etc, but still, it's a huge piece of of software for just this purpose. I first moved to Mithril because it doesn't need reactivity. You solve the same problem than React/Vue…

Man... I really disliked my experience with MobX. Idk, just too much proxy "magic" for me and I actually like how "hard" it is to update state in Redux. Changing state isn't something that should be taken lightly! I think a problem people run into (in general) is having too much "non-essential" state I their application; especially in the global state. If state can possibly be derived from other state, then it's not essential

Re: Why we decided against GraphQL for local state management

#75

Post by d0m »

mikewhy wrote: post #34

We're just in the process of switching to GraphQL for data fetching, pretty shocked people would even consider trying to hack client-side state management into it. Redux still fills that role very well.

I don't particularly like Apollo, but the reasoning is that if you fetch data with Apollo on the client-side, then that data is already available in their cache. If you were to use Redux, you'd have to copy that same data in your store.. so might as well use their cache instead. However, this is only for fetched data, not all client-side state management.

Personally, I don't like the "write client-side resolvers mimicking the server resolvers" approach. I'd much rather have a database that is synched with the server and listens for new changes. Once you have your "offline-synched-db", you get offline, optimistic-UI & real-time for free.

Re: Why we decided against GraphQL for local state management

#76

Post by fouc »

pier25 wrote: post #36

State management is one of the reasons I moved away from React and Vue. You need a lot of machinery and plumbing to do something that should be really simple. MobX is probably the best way I've found to manage reactive state with React, Inferno, etc, but still, it's a huge piece of of software for just this purpose. I first moved to Mithril because it doesn't need reactivity. You solve the same problem than React/Vue…

I definitely shot myself in the foot with mithril in terms of performance, and I somewhat assumed that I must've made some sort of architecture mistake somewhere along the way.

By the way did you ever look at http://meiosis.js.org for managing state?

Re: Why we decided against GraphQL for local state management

#77

Post by andrew_ »

Matthias247 wrote: post #7

I wish they would just revert their site to where it was 2 years ago instead of doing anything new. The new version just looks like yet another Tinder clone, and doesn't resemble anymore what Okcupid was good at: Good profiles, which allowed to get an initial impression about people beyond "I like their looks".

I'm honestly surprised that OKCupid is still relevant. After Tinder and Bumble arrived it seemed they were all but knocked out. I've heard from my single friends that Hinge made a resurgence, so maybe these platforms never die as long as there are people willing to give them their personal info/data.

Re: Why we decided against GraphQL for local state management

#78

Post by consolenaut »

city41 wrote: post #70
consolenaut wrote: post #49

I'm doing a big Apollo/GraphQL piece for the BBC for a lot of the same reasons OP lists, and have run into pretty much all the same issues with Apollo that OP has. Its rough because Apollo does so much for you, its wonderful, but there are so many sharp edges and pitfalls - from the buggy devtools to the lack of/incorrect docs, major unanswered github issues & constant API breaking changes even on patch/minor version…

Are you sure you like Apollo? I ask because your comment says it's wonderful, but then gives a lot of reasons as to why it's not. I don't like Apollo on the client (no issue with it server side). I feel the sharp edges and pitfalls are numerous and it's a lot of boilerplate to get anything off the ground. To be totally fair to Apollo, I'm also not sure the projects I worked on really needed or benefited from GraphQL…

I do on the whole yes, its not something I rave about unreservedly the same way I do about styled-components for example, but its still a tool I'd opt for on projects that actually have a need to do GQL stuff.

Its like your favorite screwdriver that you somehow always manage to cut yourself on - you're extremely grateful that you have this tool, it lets you tighten screws even in the narrowest spots, you just wish the handle wasn't so damn sharp

Re: Why we decided against GraphQL for local state management

#79

Post by consolenaut »

andrewingram wrote: post #67
consolenaut wrote: post #49

I'm doing a big Apollo/GraphQL piece for the BBC for a lot of the same reasons OP lists, and have run into pretty much all the same issues with Apollo that OP has. Its rough because Apollo does so much for you, its wonderful, but there are so many sharp edges and pitfalls - from the buggy devtools to the lack of/incorrect docs, major unanswered github issues & constant API breaking changes even on patch/minor version…

That Relay rewrite was over 3 years ago though, and it’s been pretty stable since (the hooks API is coming “soon” but shouldn’t break compatibility). And there was an upgrade path, there was an intermediate compat version which let you incrementally upgrade. The learning curve isn’t that really that steep, it’s just made artificially so by the poor docs. It’s unfortunate that the Relay team doesn’t really prioritise…

True, and admittedly I've only cast a cursory glance over Relay to keep track of where it is every now and again so maybe its unfair of me to write it off quite so quickly. But I think you're also right about the learning curve being made artificially steep by the poor docs, and when you're introducing this stuff to a team who are already new to GraphQL, adding another framework on top with even poorer docs than Apollo is a hard sell

Re: Why we decided against GraphQL for local state management

#80

Post by rubber_duck »

sidlls wrote: post #71
openfuture wrote: post #68

Earlier quoted context omitted.

> should be really simple Ummm... no, state management is pretty much the only hard problem in programming.

Can you support that? This doesn't seem like anything approaching the truth in the vast majority of web applications (where things like React are typically used). Mostly, in my experience, front end development is made unnecessarily complex by the developers involved.

"Just code up 6 these screens, we already have everything working in sketch - how long could it take"

Then you realize the "6 screens" actually turn in to a 50 step state machine that shares state between screens and changes screen logic conditionally on other screens, and the designer created sketches for the happy path.

And your "really simple straightforward state management" now has you going through 10 steps and 3 screens before you can arrive your state 11 which you are working on, you can't unit test the logic because your state is tightly coupled to UI and the HTTP stack, you can't reason about state updates because it's happening all over the place and is written by 3 other people concurrently, and coming to the project 6 months later makes you quit on the spot.

I've written plenty of WinForms to JQuery UI to know that "simple state management" is anything but.

Redux has initial overhead but down the line it pays for it self in these scenarios many times over. Going over requirements/flow with product owner and then writing tests for a reducer specifying the expected states is incredibly powerful in ironing out miscommunication in requirements and much faster than sending iterations of UI app to testing.

Like the parent said - the hairy part of the app ends up being dealing with the state machine - shuffling data over the HTTP is trivial, CSS/layout/animation are not that hard if you know what you're doing and don't need to support ancient browsers.

Post reply on HN