@mseaton created TRUNK-6429
We received these two suggestions during the OpenMRS platform 3.x unconference session last week.
- Tasks(schedulers), ensuring the schedules actually run.
- Queue management moving into the core.
cc: @slubwama, @mherman22
3 Likes
@wikumc too summarised for those who did not attend to understand what is really involved. 
1 Like
Both of these ideas came from @slubwama, and I think he’ll be able to elaborate on them further. The entire session was recorded, so a video should be available soon for anyone who missed it. In the meantime, you can go through the meeting notes here:
Another additional thought:
For metadata we always have a “name“ field, but this is only a single value. We have kind of a hack around this via the “display“ property in REST in FHIR, but this a display-only hack, so that these resources cannot be, for example, searched via these keys. It would be great if it Platform 3.0, metadata supported per-locale names.
From @joeldenning In exploring server rendering of esm apps for O3, there is a question of whether to use NodeJS or a Java-based ecmascript engine.
1 Like
Yet another set of things:
-
For fields in the database that store a timestamp, we should convert to using fields that use timestamp with timezone information, so that datetimes are representable unambiguously in the database.
-
For fields that are stored as dates (birthdates without times; observations that take a date value), we should support storing these as simple dates, most likely as strings without being a Date object.
1 Like
Would this mean less burden on computing resources and complete mitigation of managing volatile Node versions and package managers since JS runtime will now be moved into Java-based ecmascript engines like GraalJs or Nashorn ? hence only managing a single run time for both Java and JS ?
Currently in O3, we don’t support SSR; when it comes to the RefApp, our frontend container is basically an nginx server, serving all bundled ESM files to the client for CSR. We’re looking for an ideal SSR option to improve initial load performance (e.g faster first paint, better support for low-powered devices).
The still question stands, should we opt for a JVM JS runtime or separate Node process?
Ooh yeah, thanks for this. And hey @samuel34 what’s the better way to find it than testing out those options, doing SSR for 03 via GraalJS, since .. (Since Nashorn is deprecated)
anyways looks like the past is catching up again, i’d think of having an option for both approaches to run parallel for performance testing purposes then a consensus reached .. Imagine a world where we are back at just installing a single JDK for platform and still leveraging the power of our esms.
What am not yet sure of, what happens when the runtime goes down ? it may mean the entire ship sinks 
The performance complaints that i have always heard about O3, have not been the initial load time. And therefore, i personally feel that adding SSR is not worth the effort. At least not yet. 
I just want to point out that the entire question of SSR is completely orthogonal to Platform 3.0. Even if we need to completely re-write module-spa to support it, that’s something that can be done with or without platform updates.
4 Likes
+1 to that!
Having dealt with the timezone issue in the past, I can say it is essential, especially for centralized (cloud) deployments, which are becoming increasingly common.
1 Like