@searls Hard same.

@searls How I wish I could say the same.

@searls I used to be big on it, but recently I've not at all needed anything it offers really. Then again, I'm mostly doing server rendered pages too, nothing particularly fancy.

@searls I'm with you here. Seems like a prime example of a solution to a purely "downstream" problem. I'd rather focus on first-order problems. 🙂

@searls Good post. In my experience, people start out thinking that GraphQL is going to save them from having to understand how a client will use their API, but soon learn that it actually requires them to understand every possible way any client could ever use it.

Turns out the old way is easier!

@searls Same!

@searls I always try to avoid it since it seems unnecessarily complicated (also as a consumer of the API)

@searls I'm glad we used it because it provided a pathway to our non-technical-by-default clients to start to think about how they could use their own data in fruitful ways, and some of the things they have built are extremely useful and tailored perfectly to them in a way it would be unsustainable for us to provide. It is personally a bit teeth-grinding, though.

@searls From day one it seemed to me to be a technology that offered more in the way of insight into Facebook’s peculiar organizational structure than it did into how most software should ship data from server to client most of the time.