Thanks @burke
I wouldn’t so much differ from @ibacher 's suggestion only adding a few suggestions.
-
Caching using CDN for OpenMRS 3, we can harness some free plans like cloudflare , aws or some others
-
To optimize performance even further we may need to have a redis cache sitting between our api’s and the databases thanks to @dkayiwa having addressed the issue atopenmrs to fhir translation caused by openmrs-module-fhir2/api/src/main/java/org/openmrs/module/fhir2/api/translators/impl/LocationTranslatorImpl.java at 2.0.0 · openmrs/openmrs-module-fhir2 · GitHub and openmrs-module-fhir2/api/src/main/java/org/openmrs/module/fhir2/api/translators/impl/LocationTranslatorImpl.java at 2.0.0 · openmrs/openmrs-module-fhir2 · GitHub
a Redis cache should come in handy to reduce latency caused by the doubled database calls on top of burden generated by the 03 JS addressed above.
- And finally since fhir calls have proven to have heavy payloads even for simple calls, incorporating data compression with Gzip(not sure wether we have this yet) should help cut down on the burden placed on the network caused by exorbitant loads and consequently cut down on data usage costs on the part of implementations.
For example Gzipping a simple 03 Login page yields a 55.57 % drop in data i.e from 3.08kb to 1.36Kb
, expecting the same for the rest / fhir api calls.