6 ms·

At one of my previous jobs, we designed a whole API to be slightly more contrived but requiring only one round-trip for all key data, to address the iffy intern

by nine_k 1y ago

At one of my previous jobs, we designed a whole API to be slightly more contrived but requiring only one round-trip for all key data, to address the iffy internet connectivity most of our users had. The frontend also did a lot of background loading to hide the latency when scrolling. It's really eye-opening to set up something like toxiproxy, configure bandwidth limitations, latency variability, and packet loss in it, and run your app, or your site, or your API endpoints over it. You notice all kinds of UI freezing, lack of placeholders, gratuitously large images, lack of / inadequate configuration of retries, etc.

baby_souffle 1y ago
I wish more developers bothered to test on flaky connections. Absolutely infuriating when an app can't keep up with your muscle memory...
Tteriffic 1y ago
Years ago API’s and apps that used them were expected to do some work offline and on slow networks. Then, suddenly, everyone was expected to have stable Internet to do anything. The reason, I think, is the few apps that expected to be always online seemed better to users and easier to architect. So most architectures went that way.
- sfn42 1y ago
  The reason is developers are worse. A decade or two ago, developers were nerds who loved tinkering with computers. Today tech is big money so everyone wants in. Most devs don't care, it's just a paycheck. Until someone starts setting expectations and holding people responsible for their trash code, we'll continue to see code monkeys write broken codebases. Not to mention where is the mentorship? I've worked as a mechanic, I've worked in construction, I've worked in a store. In all the above, I was mentored. Not for very long in the store but still, the other two have 2 year apprenticeship programs. The i got a degree and a dev job, apprenticeship? Nah dude here's a big legacy app for you, have fun. Mentorship? Okay I technically had a mentor. We had a lunch every couple months, talked about stuff a bit but nothing much. And I mean this is going to sound a bit pompous but I'm above average. I had mostly A's in university, I finished every single project alone and then helped others. I was a TA. I corrected the professors when they made mistakes. I wrote a lot of code in my free time. I can't imagine what it must be like for one of my peers who honestly didn't know Jack shit and still graduated somehow. I'm working on an app right now, took over after two other guys worked on it for about a year. This app isn't even in prod yet and it's already legacy code. Complete mess, everything takes like 5 seconds to load, the frontend does a crapload of processing because the data is stored and transferred in entirely the wrong structure so basically they just send all the data and sort it out on the frontend. I honestly think the fastest way to get this app working properly is to scrap the whole thing and start from scratch but we have a deadline in a couple months so I guess I'll see how it goes.
- _carbyau_ 1y ago
  > Then, suddenly, everyone was expected to have stable Internet to do anything. I had reasonable - not mega - internet in Australia at the time. But the first 5 years of Steam sucked hard. Get home from work, go to play [game of choice] only to find it will take hours to update.
devmor 1y ago
This reminded me of a feature request I dealt with at an employer, while working on backoffice software for a support team. The software loaded a list of all current customers on the main index page - this was fine in the early days, but as the company grew, it ended up taking nearly a whole minute before the page was responsive. This sucked. So I was tasked with fixing the issue. Instead of loading the whole list, I established a paginated endpoint and a search endpoint. The page now loaded in less than a second, and searches of customer data loaded in a couple seconds. The users hated it. Their previous way of handling the work was to just keep the index of all customers open in a browser tab all day, Ctrl+F the page for an instant result and open the link to the customer details in a new tab as needed. My upgrades made the index page load faster, but effectively made the users wait seconds every single time for a response that used to be instant at the cost of a one time per day long wait. There's a few different lessons to take from this about intent and design, user feedback, etc. but the one that really applies here is that sometimes it's just more friendly to let the user have all the data they need and allow them to interact with it "offline".
- sfn42 1y ago
  There's no reason you can't have the cake and eat it too. If google can index the entire web and have search results and AI results for you in an instant, then you can give users instant customer search for a mid sized corp. A search bar that actually worked fast would have done the same as their Ctrl f workflow. Of course if the system is a total mess then it might have been a lot of work, but what you describe is really more of a skill issue than a technical limitation.
  - thunderfork 1y ago
    [dead]
  - deleted 1y ago
    [deleted]
  - devmor 1y ago
    I would not consider Google search, nor its AI overview an example of a good system. It is an effective product, in so far as it generates revenue, but it is not an example I would use to describe a system that provides a good and useful experience to its end users - which was and generally is my goal when designing software.
grishka 1y ago
VKontakte has a very clever but at the same time cursed solution to this — the `execute` API method. It takes JS-like code that runs server-side. You can make up to 25 API calls and transform the data any way you please before returning it to yourself, all for the cost of one network request. Working with every other API after that feels like a massive regression.
nikanj 1y ago
You also get a surprisingly large amount of pushback for refactorings like this, because a lot of professional developers have been taught to value code quality and API purity over such frivolities as actual user experience.

by nine_k 1y ago

baby_souffle 1y ago

I wish more developers bothered to test on flaky connections. Absolutely infuriating when an app can't keep up with your muscle memory...

Tteriffic 1y ago

Years ago API’s and apps that used them were expected to do some work offline and on slow networks. Then, suddenly, everyone was expected to have stable Internet to do anything. The reason, I think, is the few apps that expected to be always online seemed better to users and easier to architect. So most architectures went that way.

sfn42 1y ago
The reason is developers are worse. A decade or two ago, developers were nerds who loved tinkering with computers. Today tech is big money so everyone wants in. Most devs don't care, it's just a paycheck. Until someone starts setting expectations and holding people responsible for their trash code, we'll continue to see code monkeys write broken codebases. Not to mention where is the mentorship? I've worked as a mechanic, I've worked in construction, I've worked in a store. In all the above, I was mentored. Not for very long in the store but still, the other two have 2 year apprenticeship programs. The i got a degree and a dev job, apprenticeship? Nah dude here's a big legacy app for you, have fun. Mentorship? Okay I technically had a mentor. We had a lunch every couple months, talked about stuff a bit but nothing much. And I mean this is going to sound a bit pompous but I'm above average. I had mostly A's in university, I finished every single project alone and then helped others. I was a TA. I corrected the professors when they made mistakes. I wrote a lot of code in my free time. I can't imagine what it must be like for one of my peers who honestly didn't know Jack shit and still graduated somehow. I'm working on an app right now, took over after two other guys worked on it for about a year. This app isn't even in prod yet and it's already legacy code. Complete mess, everything takes like 5 seconds to load, the frontend does a crapload of processing because the data is stored and transferred in entirely the wrong structure so basically they just send all the data and sort it out on the frontend. I honestly think the fastest way to get this app working properly is to scrap the whole thing and start from scratch but we have a deadline in a couple months so I guess I'll see how it goes.
_carbyau_ 1y ago
> Then, suddenly, everyone was expected to have stable Internet to do anything. I had reasonable - not mega - internet in Australia at the time. But the first 5 years of Steam sucked hard. Get home from work, go to play [game of choice] only to find it will take hours to update.

devmor 1y ago

This reminded me of a feature request I dealt with at an employer, while working on backoffice software for a support team. The software loaded a list of all current customers on the main index page - this was fine in the early days, but as the company grew, it ended up taking nearly a whole minute before the page was responsive. This sucked. So I was tasked with fixing the issue. Instead of loading the whole list, I established a paginated endpoint and a search endpoint. The page now loaded in less than a second, and searches of customer data loaded in a couple seconds. The users hated it. Their previous way of handling the work was to just keep the index of all customers open in a browser tab all day, Ctrl+F the page for an instant result and open the link to the customer details in a new tab as needed. My upgrades made the index page load faster, but effectively made the users wait seconds every single time for a response that used to be instant at the cost of a one time per day long wait. There's a few different lessons to take from this about intent and design, user feedback, etc. but the one that really applies here is that sometimes it's just more friendly to let the user have all the data they need and allow them to interact with it "offline".

sfn42 1y ago
There's no reason you can't have the cake and eat it too. If google can index the entire web and have search results and AI results for you in an instant, then you can give users instant customer search for a mid sized corp. A search bar that actually worked fast would have done the same as their Ctrl f workflow. Of course if the system is a total mess then it might have been a lot of work, but what you describe is really more of a skill issue than a technical limitation.
- thunderfork 1y ago
  [dead]
- deleted 1y ago
  [deleted]
- devmor 1y ago
  I would not consider Google search, nor its AI overview an example of a good system. It is an effective product, in so far as it generates revenue, but it is not an example I would use to describe a system that provides a good and useful experience to its end users - which was and generally is my goal when designing software.

grishka 1y ago

VKontakte has a very clever but at the same time cursed solution to this — the `execute` API method. It takes JS-like code that runs server-side. You can make up to 25 API calls and transform the data any way you please before returning it to yourself, all for the cost of one network request. Working with every other API after that feels like a massive regression.

nikanj 1y ago

You also get a surprisingly large amount of pushback for refactorings like this, because a lot of professional developers have been taught to value code quality and API purity over such frivolities as actual user experience.