Small API Calls Processed On Server vs One Large Data Pull Stored In Memory

Question

DESIGN QUESTION: I have a SPA Angular 7 app, and have a fair amount of data that needs processing on every input from a user to turn into a graph. for example: if a user turns on the month of January the graph shows the data for just Janruary...then if a user turns on January AND February the graph updates again. There are also other filters a user can turn off and on. What is the best way to implement this feature?

1) Pull down all the necessary data onto the client and store in memory locally with the different months and properties the client turns off and on

2) Many smaller requests to the API and a loading spinner on the graph, processing done in the API to come back to the client relatively formatted

3) Something like Redis or memcache for storing the initial load of data on the component init

I'm slightly leaning towards the smaller calls to the API because I'd rather process with a strongly typed language (C# in this case)

Answer 1

As in all optimization questions, it depends. There is no right and wrong answer here, you will have to analyze your use cases to decide what the tradeoffs are.

Some things to keep in mind: Small calls are more cache-able, and it's well worth relying on HTTP cache-control headers to keep your app clean. This has a downside in classic time/space tradeoffs in that the finer-grained your cache, the more processing power will be needed to reassemble it into the larger output.

If you can avoid graphical rendering on the server, you will generally be happier with the result. The fact of the matter is, the closer to the end-user rendering happens, the better the experience (in general, rule-of-thumb). If nothing else, this is CPU intensive, and there are (generally) a lot more client machines to contribute CPU cycles than server machines.