Option 2: Web Server: Serve the frontend using nginx, Apache server etc.
@samuel34 and I are wondering b/c it has some impact on how we advise folks to set up their distros.
I’m assuming it’s a Web Server approach b/c I don’t see the spa module in the 3.x distro.properties file.
I’d want to be very clear that the build and deployment things are completely separate issues. For the 3.x RefApp, we use the SDK to create the distribution, but serve the actual frontend via a separate nginx container.
I agree with @mksd that serving the frontend separately should likely be the default, especially for production deployments, but there are pros and cons to it. The major con right now is that the frontend doesn’t do a good job of handling things if the backend is unavailable.
Would you then push for option 1 in a real production setting ? am asking this because because am also trying to setup O3 on cloud to actually run forms developed from ampath builder now 03 Form Builder.
Fair question. I think what Ian means is the 3.x RefApp itself, as-is right now. Ampath had a focused scope so not all parts of the 3.x RefApp are included in production, e.g. Immunizations widget, or Drug Orders function. Each pilot site determines their own focus areas - eg the Patient Summary is very important to Ampath users, which is driving improved Extensible Summary Widget designs (I’ll try to share that on Talk soon but in meantime see the 3.x squad notes here; screenshot below). So more effort goes into something that the org wants.
Because we don’t have a fully-staffed fully-funded full-time core dev team building 3.x, but instead use a community collaboration model, we depend on organizations and their priorities to get features done (this is why the Product Dashboard/Roadmap is so important). Other features like Immunizations widget or Drug Orders will mature and become prod-ready as organizations decide they want to improve them / get them real-world-ready.
For UgandaEMR we are running the instances off Tomcat, thus #1 which is the default setting
There are optimizations for having Nginx/Apache infront of Tomcat to improve performance for static assets, why not use this age old architecture approach
Obviously SAAS applications & hosted instances have more resources thus can go custom
While the architecture decisions are driving for the “modern” way of running things, it is important to remember and cater for the resource limited settings in which majority of the OpenMRS instances are run and operated
Agreed. I’m assuming Docker can be installed and run disconnected from the internet, so you’d only need to bring updated images the same way you are delivering your updates today. For example, docker save to save an image to tar file and docker load to load it onto a machine.