I’m pretty sure Initech as portrayed in the film is far more functional than Twitter is at this point. At least they have “The Bobs” actually evaluating people for their value to the company, and they actually recognize that Peter is “a straight shooter with upper management written all over him,” which is actually a fair evaluation since we can assume that Peter would not be bugging people about their “TPS cover sheets” and would be focused on doing things that actually matter and recognizing employees for actual contributions, probably by letting them smash a defective laser printer in a nearby field. He sure as hell wouldn’t be demanding people come in on Saturday or say “I’m also gonna need you to go ahead and come in on Sunday too…We…aah…lost some people this week and…ah…we sorta need to play catch up.”
As for Twitter employees, if they can figure out a way to extract blood from that particular turnip, more power to them. It’s more than their fearless leader can manage.
So Elon knows about as much technical detail about how Twitter operates as he does about rocket propulsion, autonomous piloting systems, solar power generation, and neuroscience. Surprise, surprise, surprise!
Not exactly. The rules are clear as mud. But I’m pretty careful about what I say and how I say it. Their main goal is to ensure that nothing I do drags their name through the mud or triggers controversy that could come back to them.
I’m not really familiar with GraphQL, but “Twitter uses GraphQL, not RPC” confuses me. Are there not RPCs involved in the execution of GraphQL queries? I mean, not from the client to the backend directly, but between the various nodes of the backend.
I had imagined that Elon’s issue was that he first heard of microservices last week and still holds late 90s ideas about how to structure code to avoid RPCs as much as possible.
From the Wikipedia article, I’d say that it’s basically a particular implementation of an RPC framework. RPC is a capability (the ability to remotely execute a procedure call) not a particular software package. The nitpick only makes sense if you don’t know what GraphQL and RPC are.
Likewise, my read of what Musk what saying about doing payments at Twitter was that he was saying the software stack for pushing small packets of data around is similar to, but better than popular payment software stacks like SWIFT and they could try starting up a second unit that targets the payments space. (I feel like they’ll have a hard time going up against Zelle, Venmo, PayPal, etc. but it’s not completely ludicrous. But there’s no reason that Twitter can’t do payments - just as there was no reason that the Amazon store couldn’t do AWS.)
My general read of this thread is that Musk is definitely moving too fast but that, likewise, everyone in this thread is as well.
Further, he might be moving too fast because he’s $44b in the hole, buying the company, and the company is losing money to the tune of millions a day. To some extent, he’s the wealthiest by turning the whole thing off and calling it a day, because it stops the bleed. Tearing things apart and trying to get it turned around, regardless of all sanity, might be the most rational thing to do short of that.
I think Musk used the term RPC as a generic term for a message exchange or transaction. I think the response to Musk was assuming he meant RPC as in an actual remote procedure call. I’ll use the term transaction to avoid any confusion.
Yes right, there are (at least) two sets of transactions: Transactions from the client to the server and then another set of transactions from the server to the various backends. The set of transactions from the client are travelling over the internet so they typically will have the biggest impact on latency (lag to the user). Presumably the transactions from server to backends are on a very fast network, are (probably?) batched, and have less impact.
From context I think the concern is that there are too many individual transactions from the client. Instead of asking for everything that the client needs in one big transaction, the client uses many small transactions to ask for a bunch of independent pieces. This is a fundamental tradeoff in client API design: clean, orthogonal design vs. minimizing network transactions.
REST is a popular web API. In its ideal form, it makes the tradeoff toward design. As a result, it will make many transactions and parts of the data returned will not even be needed by the client. In reality many (most?) REST APIs make some compromise.
GraphQL is a newer web API, from Facebook, that makes the opposite tradeoff. It allows the client to ask for all of the pieces of information it needs and specify the exact fields so only data that the client wants will be returned.
The point of the response to Musk is that there aren’t actually a bunch of individual transactions, there is just one (or a few) because they are using GraphQL.
I should have included an example:
REST API:
Get my user profile. I need my username and real name. I’m going to ignore the other stuff you give me like date I joined because I am not showing that on the UI.
Give me the list of my last 10 tweets.
For each of my tweets, give me the user profile of the person that posted it.
etc.
GraphQL API:
Give me the username and real name from my profile, give me the list of my last 10 tweets and only include the username of the person that posted it, the time it was posted, and the first 100 characters of the tweet.
Just to be clear, there isn’t a best choice. It depends on the situation. The downside to GraphQL is that none of these pieces of code and can be completely independent since a single request might need pieces of data from all of them.
His tweet was talking about why Twitter was slower in India than California so it was clear that his mental model was that the phone was making over a thousand network calls to the Twitter servers and the calls being “poorly batched” was the reason for the slowdown because India has higher latency than California.
The engineers correcting him were explaining to him that the phone simply makes one network request and all of the GraphQL queries were run purely on the backend. Technically, they’re not RPC calls in the same way we don’t call SQL queries aren’t RPC calls but the GraphQL vs RPC distinction is a nitpick vs the core misunderstanding of how the network traffic flows.
I’m not sure what “UAM” is in the engineer’s post but I think he’s saying that it’s ad weight, bogging things down. He says that there are twenty requests to get the page to display but that’s doesn’t directly address the question of what GraphQL is batching the individual data requests together into a single call into the back end. Even if the technology supports that today, it’s not clear to me if it has always had that feature - they could have started at an older version and never updated - nor how easy it is to make that happen correctly.
In my experience, page weight is the number one killer for India. Giant frameworks like jQuery and (presumably) GraphQL’s front end, added to ads and video ads, developed by people with good Internet connections on PCs makes them design for their own convenience a, experience, and visual expectations rather than for an Indian customer, on the streets, with a cellphone.
I’d look less at the number of calls and more at the size of the resources being returned.
I’m sure that batching any JS calls together would be helpful but just reducing the quantity will help with that and - depending on how much data is being requested - it may well be worth cutting out the extra data load that’s not serving useful features.
Migrating off of jQuery is a bigger and more time consuming effort. Getting rid of the ads and videos would require some A/B testing or data mining to determine the trade-off. I suspect that they still earn more money than they cost in customers over the short term and, to the extent that the long term experience of bad Internet might make a customer want to go somewhere else - that doesn’t mean much if all the other options also have slow loading ads.
The ads are probably there to stay. Probably the best move would be to down rez them.
Longer version, for those who haven’t seen the movie. Although according to the post from @JohnT, the only living creatures who haven’t seen Office Space (besides me prior to yesterday) are probably the few remaining tardigrades on Mars. I recommend watching this from the perspective of Peter Gibbons here being a Twitter employee …
These aren’t actual Twitter employees that Elon fired and rehired, they’re the two guys who trolled the media by showing up outside of Twitter HQ pretending to be fired. This is Elon trying to be funny by calling them back in for a photo and making light of the chaos. Also his juvenile humor (Ligma Johnson)
