Question for you @ibacher - which approach are the 3.x RefApp docker set-ups using?
@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.
IMO the default should be option 2, that’s the proper and scalable way to serve a modern frontend like ours.
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.
Personally, I wouldn’t be pushing a full O3 product into a production setting yet. But no, option 2 is still the right choice.
@ibacher So how about how ampath piloted this last year if am not mistaken .
The other question is, could we use the builder to create some sort of a Wizard Form / pagination incase we want to amalgamate many forms into one?
@tendomart this is covered in Ampath forms, called Referencing Component Forms; see the documentation: https://ampath-forms.vercel.app/referencing-forms
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.
Thanks for the link, @grace .Actually implemented this a few days a go .We’re yet to see if the form Engine actually displays them the way we want .
Our interest is basically form engine and rendering of the forms, data obtained from screening patients at a hospital (specialist institute) .
I hope we’re covered for everything to do with forms atleast for now. we’ve been avoiding 2.x and htmlform Entry
Sorry I probably missed this elsewhere - who is the “we” / what organization?
Have you seen this: O3: Support for HTML Form Entry in 3.x
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.
Maybe during development but not during production usage - that is an extra moving piece to be maintained
It’s fewer moving pieces than you are managing now with native Tomcat, Java, and MySQL. 
The pieces are already in place, and automation for setup and maintenance thus we need to maintain that approach as computers are dedicated to the implementation
Docker while useful in many instances is additional overhead for some implementations like ours
