Here's a toy example with two inputs. The first has five types of oranges, and the second, ten storage durations for apples. The backend computes a "taste index" or whatever for each input combination used in a fruit salad.
Question: How to decrease response times without tight frontend/backend coupling and excess complexity?
Option 0: We could have requests with 5 types and 10 durations, ie, 15 elements in total. The response would contain a 50 by 3 matrix listing each input/output combination, so 150 elements in total. Here's the start of this matrix:
In my actual app this approach is painfully slow due to bandwidth constraints: ie, large data volumes being sent. The app has 5-8 inputs with 2-1000 elements each. Each input element can be a string, number or a large data structure, whereas results are always double-precision numbers. It's an Angular 9/Electron Desktop app with a Python 3.8 Flask/Celery parallelised backend.
Option 1 Requests in my current solution are as above but a reply only contains a list of 50 results. That is, I only send the Result column from the above table. Indeed, suppose the backend computes the results in nested loops like so:
results = [ ] for orange in oranges: for apple in apples: results.append(compute(apple, orange))
Then the frontend could map the index of each result back to the original input levels, eg, to produce a plot. So there's no need to replicate the inputs in an HTTP response.
This approach has reduced the response times between 5 and 20 folds, depending on the problem size. However, it does bring extra coupling between the frontend and the backend. The frontend now needs to know the exact order in which the backend processed the inputs. This also constrains backend implementations, eg by requiring one big multi-loop method instead of several smaller methods. It's also proven error-prone in use-cases with many inputs.
Could there be another solution, somewhat less performant but with a cleaner design?
I've also tried splitting up input array between requests so as to reduce the load per request/response cycle. However this appeared too complicated: need to re-assemble results, and so on. My internet search has found only remotely related references, such as this SE question, although I might have used the wrong search terms.