At one of my employers, we worked on a REST (but it also applies to SOAP) API. The client, which is the application UI, would make calls over the web (LAN in typical production deployments) to the API. The API would make calls to the database.

One theme that recurs in our discussions is performance: some people on the team believe that you should not have multiple database calls (usually reads) from a single API call because of performance; you should optimize them so that each API call has only (exactly) one database call.

But is that really important? Consider that the UI has to make a network call to the API; that's pretty big (order of magnitude of milliseconds). Databases are optimized to keep things in memory and execute reads very, very quickly (eg. SQL Server loads and keeps everything in RAM and consumes almost all your free RAM if it can).

TLDR: Is it really significant to worry about multiple database calls when we are already making a network call over the LAN? If so, why?

To be clear, I'm talking about order of magnitude -- I know that it depends on specifics (machine hardware, choice of API and DB, etc.) If I have a call that takes O(milliseconds), does optimizing for DB calls that take an order of magnitude less, actually matter? Or is there more to the problem than this?

Edit: for posterity, I think it's quite ridiculous to make claims that we need to improve performance by combining database calls under these circumstances -- especially with a lack of profiling. However, it's not my decision whether we do this or not; I want to know what the rationale is behind thinking this is a correct way of optimizing web API calls.


Question: Where did the SHAKEs come from in SHA3?
Answer: 
  Where did SHAKE128 and SHAKE256 originate from?


They follow from the general properties of the sponge construction. A sponge function can generate an arbitrary length of output. The submission of Keccak to the SHA-3 competition proposed a single "XOF" (extendable-output function) with a user defined length, which would have been essentially SHAKE-288. NIST seems to have decided on two instead, with more "normal" security levels.


  Any public cryptanalysis done on them?


Anything on the generic Keccak function may also apply to them. I don't know of any cryptanalysis specifically on the XOFs, beyond what was done by the authors themselves in the submissions and the site I linked above. However, a comment (pdf) to the draft standard complains that the usage of XOFs (i.e. SHAKEs) is not defined well enough and that their security claim is not very rigorously stated.