Interesting question!
Here are my findings for store/intersystems/irishealth-community:2020.4.0.524.0 and a simple app in the USER namespace.

Uncompressed (Mb) Compressed (Mb)
IRIS 3 323 897
IRIS Squashed 3 293 893
App 8 436 1 953
App MSB 3 526 937
App Squashed 3 576 931
App MSB + Squashed 3 363 904

Notes:

  • MSB means Multi Stage Build
  • Squashed means that an image was built with a --squash option
  • Uncompressed size is calculated via docker inspect -f "{{ .Size }}" $image
  • Compressed size is calculated via (docker manifest inspect $image | ConvertFrom-Json).layers | Measure-Object -Property size -Sum
  • More info on calculating image sizes is available here

Conclusion: either MSB or Squashed work fine, but just MSB would be better for storage as it can have shared layers (squash always produces one unique layer). Squashed is easier to implement.

It's not a server who checks for expiry, but a client. So your flow works like this:

1. 15:00 calling application runs a GET request for patient?MRN=A
2. 15:00 CSP Web application calls HIHLib.REST.Server class and forwards request on to namespace for handling (via business services,process and operations)
3. 15:00:05 response is returned with EXPIRES 300 and VaryByParam set to *
4. 15:10 a seperate internall process results in patient with MRN A - first name changed from pete to bob
5. 15:12 calling application runs a GET request for patient?MRN=A
6. 15:12 web browser (on a client side) sees that patient?MRN=A request is cached locally and still valid due to EXPIRES 300. Web browser is returning a cached value to a calling application without going to the server.

And server would never get a second request (that's the point of the EXPIRING header after all).

Expires controls how long the response is valid. It's for things like HTML pages which are static.

If you think that a response can change every time a client requests it, you should not add an EXPIRING header.