Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
As someone who only recently stopped working with "architects" who says things like "13s additional latency to proxy is fine, things are slower in enterprise," I can fully sympathize with this.
We need to put all the people with standards on a single boat and have another great flood. -
@SortOfTested Thank you.
The best part is that... we're planning to encourage users to use this app on mobiles as well. Now imagine: you are on your mobile w/o wifi connection and you want to open a webpage. And each time it's opened it consumes 30+mb of your monthly GB limit.
UX level: 9000! -
@netikras
I wouldn't expect anything less. They are truly implementing all the best practices to be a failboat center of excellence.
Also, what is this "thymeout" of which you speak 😝 -
@SortOfTested the thyme out is closely related to the basil out and the oregano out. If you combine all three outs then you get an Italian spices out.
-
jdebs3365yMoral of the story: never listen to front-end engineers.
Disclaimer: I'm a front-end engineer.
(but seriously what UI guy worth his salt would think that kind of latency was anything close to ok. I get pissed if my network calls take over 500 ms...) -
@SortOfTested in fairness my experience with "architects" has been the complete opposite end of the spectrum. I recently had one request to change one of our services so that, in his own words, "we shave 2-5 milliseconds off each call". Are you kidding me right now? And for an adminstrative tool? You want me to waist 2 weeks redesigning a service so you can get 2 milliseconds back? I have better things to do. Like watch paint dry or something. If anyone's wondering I don't have any idea where he came up with the supposed speed gain and neither did anyone else. As far as I can tell the change would have had no real impact on performance but required a whole lot of refactoring.
-
@jdebs it's been a good xp for me. It was the first actual project for me where I was an architect. Now I've learned that I should stand by my decisions at all times, because everyone else is trying to make a mess out of the system.
ME: Here's an endpoint to get all the textual info about the entity. And this one fine endpoint is to fetch entity's files
FrontEnd: This is no good. I need all entity info in a single JSON
ME: but files could be quite heavy, are you sure you wan...
FE: Yes, Just give me all the info in a single JSON
ME: okay... I hope you know what you're doing..
ME: <implemented as requested>
ME: <opens a webpage with 2 files attached>
Browser: <takes 30 seconds to open a page and downloads 30MB of data in the JSON>
ME: As mentioned before, your approach is a performance killer
FE: No worries, we'll fix that in the next version. First let's see if anyone will be using this feature at all - maybe it's not even worth working on
ME: <thinking> I know I would NOT be using an app if it takes over half a minute to open up a chat channel. FFS I wouldn't even be using Slack if it took 30 seconds to open some other conversation, because for some reason it wanted to fetch all the uploaded files along with all the messages each time a channel is clicked on.....
ME: <thinking> this project is doomed :(
rant