Server rendering via Rhino?

[internettrans]

In exploring server rendering of esm apps for O3, there is a question of whether to use NodeJS or a Java-based ecmascript engine.

The Rhino project is one I learned about a long time ago as a possible option. Would a Java module using Rhino be preferred for the Openmrs ecosystem rather than a separate NodeJS process?

https://en.m.wikipedia.org/wiki/Rhino_(JavaScript_engine)

cc @dkayiwa who collaborated on this module at the beginning

[dkayiwa]

@jolyndenning what are the pros and cons for each approach?

[internettrans]

@dkayiwa I suspect the biggest consideration is whether Java should be the primary/only language running on OpenMRS servers. I'm not very familiar with the openmrs backend code, so please forgive if my analysis is missing context:

NodeJS Pros:

• It is the standard, most popular ecmascript engine used on the server
• V8 engine used by NodeJS is usually faster execution times than Rhino
• V8 implements more language features and is more up-to-date with ecmascript spec developments
• Typescript and import maps are easily supported in NodeJS
• NodeJS is a larger and more active open source community
• Developer experience, including installation, debugging, tooling, IDEs, etc is much more well known and fully developed for NodeJS
• Barrier to entry for javascript devs would be lower, due to familiarity with NodeJS
• The concepts of node_modules, package.json, etc are very familiar to the majority of javascript developers and are built into the NodeJS/npm tooling

NodeJS Cons:

• openmrs-module-spa would be deprecated or not used anymore. A new git repository would be needed for o3 server rendered js
• Would be a separate operating system process from the openmrs-core / reference implementation Java processes.
• Without a load balancer / reverse proxy, openmrs-core and/or related Java code may need to make a network request to the NodeJS process to handle incoming HTTP requests for web pages. Tomcat web server would need to run side by side with a NodeJS web server
• Installation of a new production programming language would require writing documentation and perhaps providing openmrs-specific packaging for the reference implementation or other distributions.
• Openmrs-specific conventions for logfiles, monitoring, fault tolerance, etc etc would need to be created for NodeJS processes, if they do not already exist.
• There are additional security considerations when using any new production runtime such as nodejs, including things like postinstall hooks allowing third party code to run arbitrary code. It may be best to consider bundling the NodeJS code to one javascript file rather than using node_modules on the server, for this reason.
• Access to the OpenMRS database instances may need to be configured, including connection secrets, networking in cloud, etc etc. The NodeJS server would possibly want access into json/html configs that are already available within the java processes

RhinoJS Pros:

• RhinoJS can be introduced to openmrs-module-spa in a pull request
• RhinoJS can execute within the same JVM as the rest of the openmrs backend code, so things like memory allocation, auto-restarts, crash reporting, logging, etc etc etc do not need to be rewritten for a new operating system process or production runtime
• RhinoJS can interoperate with Tomcat without a network request to a separate operating system process
• The architectural/devops/sysadmin complexity is a lot lower, since it's just more jars loaded into the existing openmrs ecosystem rather than introduction of new OS process, server dependency for production, etc.
• Access to openmrs databases remains unchanged within the existing JVM process

RhinoJS Cons:

• Debugging, crash logging, etc is less familiar to the average javascript developer, when using Rhino
• Rhino is fully implemented in Java, so contributing back to the underlying open source code would be less accessible to the average javascript developer who isn't as proficient in Java
• Server-side import maps would require investigation into RhinoJS's module loading algorithm
• Learning curve for javascript devs on how to do things they're used to doing with nodejs

[internettrans]

Cc @bmamlin @ibacher

Exploring server rendering was part of my now-expired contract in June

[internettrans]

One other thing I'll add: I would be supportive of introducing infrastructure as code tools, if multiple processes and programming languages are added to openmrs distributions.

Terraform is cloud agnostic and can be used for self hosting, but is controlled by a corporation. I like it overall, but would be willing to explore or create other tooling for it. My guess is that adding Infrastructure as Code tooling may be too big of a change for the openmrs community, since there are so many implementations. The one-process Java backend isn't my favorite approach, partially due to language biases against aging open source tooling such as mvn. Splintering the openmrs backend ecosystem into Java-only and multi-process with other production runtimes such as NodeJS may cause more maintainer burden than it is worth. Global healthcare is an important initiative and I honestly am not sure whether the introduction of single page apps was better for a community that has existed for many years and supports hundreds/thousands of different implementations. The ReactJS server rendering implementation isn't my favorite, usually requiring React Suspense for data fetching when not using one of the corporate-controlled public projects. Refactoring the react hooks to suspense, and the corresponding components that use the hooks, would take a lot of development time. When I tried to introduce React and microfrontends to openmrs, I tried for Suspense but it was during a moment where the ReactJS library was waffling on whether the API was experimental or should be exposed outside of Meta/Facebook's custom versions of React. Single-spa server rendering does support using Angular, Vue, Svelte, Preact, etc at the API design level, but the majority of my experience with it is with ReactJS.

Openmrs is an important enough project where I think any decision about this should be considered carefully. The advantages of server rendering JavaScript frameworks are usually related to performance and SEO, the downsides are additional complexity, particularly with devops. If I were fully committed to openmrs, with funding, I would push for a modernization of the backend architecture and tooling. However, my bias may be against Java monolithic processes, since I started with them in my career before moving to the JavaScript ecosystem. Introducing a NodeJS backend service would be a step towards that modernization, but when I look back at what I pushed for in openmrs I'm not sure my ideas were the right ones to embrace (custom styleguide rather than Carbon, ReactJS rather than Ampath's angular implementation, single-spa rather than just a React app that loads modules, Slack rather than IRC, etc). I trust those who have contributed to openmrs more and for more years to have a better sense of what is the right direction to take things.

[dkayiwa]

@jolyndenning we are at a stage where we are planning to do major backend changes as you can see here: https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965

Let me add a link to these interesting thoughts. 😊

[ibacher]

So, in terms of Javascript execution engines, we already use Nashhorn (an evolution of Rhino) in the backend as an expression language for various forms of evaluation (mostly this is how the O2 application decides which applications should be rendered on a screen).

From my perspective, the role of module-spa is to provide a way of serving the O3 frontend in an entirely "self-contained" OpenMRS install. So, if we evolve that to support SSR (and I'm not sure whether or not that's what we want to do), we should re-work it to use GraalJS (GraalJS is a Java-based implementation of Javascript that supports modern ES versions; both Rhino and Nashhorn only ever partially supported ES6).

That said, we currently serve the O3 frontend independently of the backend using either the docker-compose stack or the Helm charts. While the frontend is currently simply an NGINX server, this could be swapped for Node or Deno or Bun or w/e makes sense and would probably be our preferential way to handling SSR.

I'm somewhat agnostic on publishing Terraform configurations; we haven't really had a lot of ask for IaC setup. Internally, in OpenMRS, we use Terraform primarily for server management and Ansible for server configuration. That said, we've been working primarily with compose stacks or Helm as our means of deploying Dockerized setups, because those allow us to make fewer assumptions about the underlying OS, etc.

[internettrans]

Is openmrs-module-spa commonly used, or is docker-compose with reference implementation more popular? Do Bahmni, Ampath, and other major implementations of openmrs use the esm-apps and docker-compose, or do they still use custom UIs?

Should openmrs server rendering be supported via one-process Java openmrs-core, docker-compose, cloud hosting, clusters, and/or other forms of hosting?

O2 is still more popular than O3, according to one wiki page I read, with some of the old configuration pages referenced on my trips for openmrs conferences in 2019 as ones where there would be hesitancy or lots of work to replace them. Would adding server rendering improve the performance enough to be worth the additional work? Would it encourage adoption of O3?

[internettrans]

I don't know much about Java-based execution engines for JavaScript, I saw nashorn was removed from the Java standard libraries / core recently. I'm open to any of them, if supporting server rendering within the JVM is needed.

Self-hosted open source server rendering of single-spa was stalked by many cloud hosting companies and large corporations that control open source projects. The major open source frameworks didn't provide much tooling that was free of opinions about cloud hosting or which technologies are involved in the build.

@ibacher what are the pros and cons of server rendering versus not server rendering, for openmrs? Is it primarily for performance reasons?

[internettrans]

"single-spa should just be replaced by React modules" idea was planted in me by jealous Twitter coder influencer stalkers and a bisexual man who likes React.

Framework independent applications have their place, despite Meta's aggressions for brand loyalty to one framework

[ibacher]

Is it primarily for performance reasons?

Sorry I missed this. Yes. More exactly, especially with tablets, we've ended up with a situation where we have relatively powerful server machines and relatively anemic client machines, but a client-rendered SPA means that we're pushing the hard work (of the frontend) exclusively to the client machine).

Framework independent applications have their place

FWIW, there's at least one implementation that has taken parts of the O3 Framework but implemented all their MFs in Vue.

O2 is still more popular than O3, according to one wiki page I read

We've got more uptake of O3 in the last 18 months or so it's fairly widely deployed now. We even have one or two implementations that are working with a hybrid approach where newer parts of the app are done in O3 and older parts of the app are done in O2 (with appropriate styling so it isn't massively jarring).

[internettrans]

FWIW, there's at least one implementation that has taken parts of the O3 Framework but implemented all their MFs in Vue.

That's good to hear. Which group is it? I would like to contact the distributions/implementations within Openmrs that may have interest or funding for me to continue work on global healthcare nonprofit software. I've already reached out to Jembi and Bahmni.

I'd love to continue work with Openmrs, but would need stable funding to be able to continue work. I'm applying for grants, full-time jobs, and contractorships, hoping that single-spa can be the ongoing career path for me, but not sure if the funding will happen this time around.

I've also contacted many corporations and nonprofits that use single-spa, but am not optimistic that things will fall into place this time. In 2019-2020 I landed some very good contracts, but now my finances are examined and nitpicked by hate groups who surveil me.

[ibacher]

Which group is it?

EPGAF; I'm not sure if they're using it in production though.