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

81–90 of 99 posts

Re: Why we decided against GraphQL for local state management

#81

Post by bdcravens »

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.

I don't mind complexity when it's necessary, but things like persistence and authentication are things that have long been table stakes for server-rendered apps.

Re: Why we decided against GraphQL for local state management

#82

Post by fourstar »

weeksie wrote: post #33
vosper wrote: post #29

Earlier quoted context omitted.

I don't think this comment is fair - acemarke does show up in virtually every Redux discussion on HN, but I've found his comments to be reasonable and helpful. I don't think labeling them as spam is justified. He makes an effort to address specific points, doesn't get defensive or angry, and seems to take criticism and feedback seriously. He has responded to my own critiques of Redux in a reasoned way. I think that i…

I see it as someone clout-chasing for their framework. A framework that promotes questionable practices. Framework developers and working engineers have diverging interests. The problem with his style is that he parades himself as an expert but he's emphatically not an expert. He's a guy with an agenda to push his open source framework. I understand where the bias toward politeness comes from, but that makes groups l…

Bitterness: The Comment.

You can write a short story about this on your blog, now that you’re a “full-time writer”.

Re: Why we decided against GraphQL for local state management

#83

Post by fourstar »

acemarke wrote: post #46
weeksie wrote: post #45

Earlier quoted context omitted.

You've worked on two apps. Besides that you've been a part of the evangelist ecosystem for a tremendously simple framework. You are not what I could call an expert in using Redux. You are almost certainly an expert in Redux's internals but that's not what we're discussing. In fact the root of the problem is exactly that you've conflated one for the other.

I know I'm feeding a troll here, so last response. I've looked at hundreds of other codebases, ranging from beginner apps to complex enterprise-level apps. I've talked to thousands of people who are using Redux in many, _many_ different ways, and catalogued hundreds of libraries people have made to add on to Redux. I _know_ how people are using Redux in practice, and what kinds of problems they're running into. I'm q…

The guy just likes to larp as a writer, so it’s not a surprise that he’s loving the discourse. Just ignore him —- He’s massively coping for his front-end shortcomings.

Re: Why we decided against GraphQL for local state management

#84

Post by jklm »

mschuster91 wrote: post #60
vosper wrote: post #27

Earlier quoted context omitted.

Genuine question: What technologies / techniques are you using while your competitors flounder around with GraphQL?

Tried and true server side rendering. Sure it will not look as snappy as a PWA... but I guarantee you that a seasoned team of Drupal developers can get up and running faster than a team of juniors fresh out of coding bootcamp, or even a team of senior-ish Javascript frontend devs who haven't heard about GraphQL yet, and much less have years of experience.

This feels like a strawman...I’m sure a seasoned team of GraphQL devs could getting something running faster then a team of veteran devs who are trying to use Drupal but have no experience.

Re: Why we decided against GraphQL for local state management

#85

Post by kevsim »

We've been using Apollo's cache as our one and only source of state in the issue tracker we're building [0], however, as of late we've started running into all kinds of problems. Mainly performance related as the Apollo cache flattens the object graph on insertion but then rebuilds the graph on read (whether you need it to fully do so our not).

To remedy this, we're currently moving away from it. Either to Redux or just plain useReducer (TBD).

0: https://kitemaker.co

Re: Why we decided against GraphQL for local state management

#86

Post by 11235813213455 »

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…

With React you can always use a very simple global store, and re-render the whole React tree when changing data in the store, or something more fine-grained like this hook https://gist.github.com/caub/1ab1190ae9e309318905be734364b65....

Completely agreed about Redux and other over-engineered state management

Re: Why we decided against GraphQL for local state management

#87

Post by pault »

weeksie wrote: post #31
acemarke wrote: post #28

Earlier quoted context omitted.

Or, with `createSlice`, you get the action creators for free with your reducers: const todosSlice = createSlice({ name: 'todos', initialState: [], reducers: { addTodo(state, action) { const { id, text } = action.payload state.push({ id, text, completed: false }) }, toggleTodo(state, action) { const todo = state.find(todo => todo.id === action.payload) if (todo) { todo.completed = !todo.completed } } } }) export const…

I see what you’re doing there. I also see why you think it’s a good idea. "How the community" uses redux is badly. I guess congrats for reinforcing that at scale. Gives me some more hours to bill when I run across the next ratsnest.

Can you provide some examples of a better way to use redux? The react and redux toolchain is so flexible I'm always interested to see what ways other people come up with to use it.

Re: Why we decided against GraphQL for local state management

#88

Post by mschuster91 »

jklm wrote: post #84
mschuster91 wrote: post #60

Earlier quoted context omitted.

Tried and true server side rendering. Sure it will not look as snappy as a PWA... but I guarantee you that a seasoned team of Drupal developers can get up and running faster than a team of juniors fresh out of coding bootcamp, or even a team of senior-ish Javascript frontend devs who haven't heard about GraphQL yet, and much less have years of experience.

This feels like a strawman...I’m sure a seasoned team of GraphQL devs could getting something running faster then a team of veteran devs who are trying to use Drupal but have no experience.

No, it's not a strawman argument. Graphql was released in 2015, so even the most senior devs you can find have only five years of experience (ignoring people who have worked at FB before).

Drupal however has a history dating back to 2001!

Re: Why we decided against GraphQL for local state management

#89

Post by aosaigh »

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…

This is called “convention over configuration” and I don’t know where the front end software world went wrong in ignoring it. Ember.js is still a great example of a “batteries included” front end framework that makes all the decisions for you and prevents you from going off the rails. The downside is a high learning curve but once you’re experienced you can make reliable apps quickly

Re: Why we decided against GraphQL for local state management

#90

Post by vosper »

mschuster91 wrote: post #88
jklm wrote: post #84

Earlier quoted context omitted.

This feels like a strawman...I’m sure a seasoned team of GraphQL devs could getting something running faster then a team of veteran devs who are trying to use Drupal but have no experience.

No, it's not a strawman argument. Graphql was released in 2015, so even the most senior devs you can find have only five years of experience (ignoring people who have worked at FB before). Drupal however has a history dating back to 2001!

5 years of experience in any frontend framework, including Drupal, is enough time to learn how to stand something up pretty quickly. I’ve been doing web apps for 15 years: the frameworks are not that complicated.

And if we’re picking Drupal because of its age (and if not then why Drupal, of all things? What’s the overlap with GraphQL?) why not go back further and assert that someone who’s great with C and CGI could do even better?

Post reply on HN