31–40 of 64 posts
I wonder if they feel like GraphQL was worth it, vs. normal API servers. Maybe they saved some dev time on the front end, but did that outweigh the dev time spent on building, optimizing, etc? Somehow I doubt it.
I wonder if they feel like Node was worth it. (seriously)
I wonder if they feel like GraphQL was worth it, vs. normal API servers. Maybe they saved some dev time on the front end, but did that outweigh the dev time spent on building, optimizing, etc? Somehow I doubt it.
I bet REST API + HTTP caching is going to outperform the GraphQL APIs. And maybe most importantly, it’s going to be cheaper.
Do I read this right? 1,000,000 requests/sec across 7,500 instances is only 133 requests/second, and graphql wouldn’t typically represent the business logic or data layer. I love me some graphql, but that seems to be a very low figure. I’m curious how complex the queries are and what else these servers are doing.
Earlier quoted context omitted.
I bet REST API + HTTP caching is going to outperform the GraphQL APIs. And maybe most importantly, it’s going to be cheaper.
I would place a bet along with you on that one. The question the graphql folk need to think about is who's paying for the value add of large one hit requests. cycles add up! There's a price to pay for having your api also have to parse and understand a request beyond just fetching the result.
It was obvious to me from the beginning that GraphQL would add overhead and complexity on the backend; especially related to caching all possible permutations/views of the data. In some cases I imagine it would consume a lot of memory; wouldn't it cause a memory leak vulnerability if you allow infinite permutations to be cached by the server? On the other hand, if you only cache responses to popular requests, doesn't…
> The fact that GraphQL allows all these permutations in the queries is the root of the problem. It's not something which can be solved or optimized within GraphQL. Common ways to solve that are to whitelist the allowed queries or to cache at the resolver level instead of the query level.
Do I read this right? 1,000,000 requests/sec across 7,500 instances is only 133 requests/second, and graphql wouldn’t typically represent the business logic or data layer. I love me some graphql, but that seems to be a very low figure. I’m curious how complex the queries are and what else these servers are doing.
I've seen similar situations where each host was achieving just 16 requests/sec. Engineers are expensive, and growing more so every year. It's hard to justify time spent to optimise rather than throwing more instances at it. The cloud has made this worse in a way, since provisioning more hosts can be done so easily. Not many engineers even have the skill to identify and resolve performance problems, so again, people…
I also agree that most of the devs I have ever worked with, in the UK, have little to no idea about how to actually test performance effectively.
Even though I am personally really interested in performance, even using a cool tool like Resharper profiler takes some time to get your head round.
Either optimising the main app or caching with Redis/Memcached can seriously reduce the number of instances & improve the 133 req/sec per server metric as well.
What might be possible is double-level caching, so you cache underlying data and then query from that, the results of which are also cached.
>"We provision approximately 7,500 instances for 1 million requests per second." Looking at this numbers makes me think that a single instance of properly written server running on a single dedicated piece of hardware can handle this without breaking a sweat. My servers for example handle thousands of requests per second. It looks to me like one giant waste of human and hardware resources. Not very "green" approach I…
The fact that you can get X 100K requests/per second best-case is not really the point. The point is if I don't want to write hand-cranked code for every kind of possible query, I take a performance hit as a result.
Not sure how easy it would be for them to identify poorly performing queries and split them out into their own optimised code.
Earlier quoted context omitted.
I wonder if they feel like Node was worth it. (seriously)
Seems to me Elixir + Absinthe would’ve been a better tech stack.
But with that many servers I can't help but wonder if Rust wouldn't be a better choice. I don't think they'll even need 100 which, as OP pointed out, will drastically reduce their operational complexity.
Furthermore, the strong static typing would have avoided the megamorphic functions right from the start.