Works, don't touch it? Or never ending optimization game?
Tags: javascript, performance, optimization
Published: 2024-05-18 15:09:24

---
title: Works, don't touch it? Or never ending optimization game? 
published: true
description: 
tags: JavaScript, Performance, Optimization
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ac6oms24akf8ojerfvm8.png
# Use a ratio of 100:42 for best results.
# published_at: 2024-05-18 14:05 +0000
---

I've built a photo sharing app https://www.wisaw.com. 
I use it on my iPhone all the time, and it works great for me! 

Recently a friend complained that it's really slow on his iPad. So, I started digging...

Turns out, the app retrieves the photos by calling GraphQL backend, 1 day at a time, until it fills the screen. On smaller devices works like a charm, but on tablets -- lots of network calls, and painful user experience. 

My goal was to figure out how to make a backend return 10 days (or more) worth of photos in one call, without making any changes to the frontend -- it's still a pain to re-deploy mobile apps. 

Here is my first bruit force approach:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ac6oms24akf8ojerfvm8.png)

This actually worked. Right away, I saw the number of calls to AWS Lambda, where I host my graphQL backend, to drastically go down. Which means the application does not have to open and maintain as many network connections on slower bandwidth networks. The UX is much smoother. So, should I stop here? Well, there was still something that bothered me about the code. To my taste, the number of repetitive lines of code is insane -- typical Copy/Paste design pattern. Generally speaking I'm OK seeing it in the code when it has 2 occurrences, but 10!!! is just a way too many.

Here is the revised version:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l9dzy2ni9huonwe8kwuc.png)

Much better. JS `Promise.all` is awesome. The final version of the code is much shorter. The number of async calls can be adjusted dynamically by playing with `arraySize` const. Each function call returns arrays of exactly the same objects types, so I can chain `flat(1)` to the end. I can probably even consider passing the `arraySize`, depending on the device screen size, into the lambda call at some point, but that's a different story for some other time (and that would require the mobile app new release). 

So, the complexity didn't really go away, arguably, the code became even more complex. But, I thought it was pretty cool to be able to optimize UX dynamics without touching a frontend. The spikiness of the network calls moved from mobile devices running on slow networks, to calls between the middleware and the database, which are much faster and reliable. 

Should I have touched the code to begin with? It was working OK after all. At the end of the day, the answer is -- yes! Absolutely! I've learned how to `Promise.all` dynamically on a variable size array of functions. It took me like an hour of hacking on a Friday night before heading out to a weekend. 
And, I've had a lot of fun, and, my friend, who started all this, is happy running my app on his tablet -- that's all that matters.