Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I knew we were in trouble when we started having to sort the query criteria in order to support caching of requests.

If I use graphQL again it’ll only be for admin features. Anything where very few users will use it and very infrequently. Preferably in spots where caching works against the workflow. OLAP vs OLTP.

GraphQL is really about reducing friction between teams. High functioning distributed systems all have two qualities in common: work stealing and back pressure. Without back pressure there is nothing to stop the project from running off a cliff.



what's work stealing?


It’s when you can reassign a task earmarked for one machine to another after the fact. There’s a latency and throughput problem to keeping all tasks on a central server until a worker finishes an existing task.

But if you locally queue, and one worker gets unlucky and gets the longest tasks, then the whole cluster sits idle while this worker starts and finishes multiple tasks. If you reallocate the ones that haven’t started or have timed out, then the overall time comes down quite a bit (and in the latter case also covers workers that crash).

For development teams it could mean moving the boundary on a service or API so your team does more of the feature work than originally planned, because the other team keeps getting jammed up on bugs or other operational issues.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: