How to exchange rectangular arrays via HTTP efficiently and without tightly coupling requesters to responders?

Question

Suppose a user defines input arrays on a JavaScript frontend. These are sent to a Python backend via the REST API. The backend computes a result for every combination of each array's elements. It then replies with a JSON file containing the results.

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.

Answer 1

May be you'd want to singe single indexing instead of two independent indices. I.e. identify each cell with a unique identifier (its values does not matter, it may be based on indices of rows and columns with a simple arithmetic transform or could be a hash, the order of cells in queries/replied then does not matter and they can be updated separately asynchronously).

In summary transform the 2D problem in a 1D problem with a single hash. Then you can decouple the work to the server and even allow multiple servers to do the job needed for each cell. This changes the nature of the problem in separate problems:

• a single set for "types of ranges" (no need to duplicate these values, you'll eventually associate an ordered index or unorderd hash value for each)
• a single set for "prices of apples" (same remark, transmitted separately)
• a single set of cells (each one with its identifying hash) for computing the "taste index" (this can be any kind of computing, as you seem to just give pseudo-examples and not actual use cases)

You can then bind the client and server(s) with more freedom and optimize what needs to be synchronized with network requests (it may be useful as well for the server and client to share a common session identifier for each client that will be part of the hash built for each element of the 3 sets above, so that you can as well distribute the competing clients on the available servers, which may change dynamically or on demand).

Note that the separation between "server(s)" and "client(s)" is artificial. The server may just do nothing else than being a coordinator or communication proxy between the client(s) in a peer-to-peer system. The actual work being done only by the clients accessible via this server, and interacting asynchronously (possibly the work on each "cell" is actually performed by humans, you cannot expect that the whole "grid" of tasks will be performed in any orderly way; as well there may be restrictions/policies about how each client can interact and influence the work or result of each task or "cell" of your grid).

Finally the representation of the division of tasks in a 2D grid is possibly artificial and does not make sense (there may be spans and cells sharing their tasks or results at random places in that "grid", or the grid may just be an aggregate showing a part only of the data which may be structured completely differently (e.g. a hierarchic tree, or many more axis) and some cells may have no meaning (no task to do, no valid input, no valid result to show, no client interested on working to "fix" that).