Hello , As we are planning to have a release of reference application 2.11.0, we had planned to include single Page Application module in the coming release. However according to the information got from work being done In Micro FrontEnds squad, there seem to be a change for unbundling/removing the spa module in the next release due to the current integration being worked on to cater between Openmrs and MFE
We would like to here from you
Can either one of you provide some details as to how micro frontends resources are intended to be served within the Ref App?
I know that none are intended to be served for now, but some implementations do that already and the Ref App will gradually welcome micro frontends features.
Sure! What I can tell you right now is that we will just add them (i.e., all necessary assets) as static resources (plain files). The (target) directory is to be determined, but most likely we put them directly into the tomcat webapps directory (maybe subdir “spa”).
We’ll post more infos when we aligned and decided on them.
@florianrappl What is the architectural approach for packaging SPA in a WAR file for distribution? Can it be pulled in via the pom.xml just like OWAs and other OpenMRS modules?
Getting an early version of the Spa module into Addons and released with 2.11 would allow people to simply upgrade the module to latest version and try it out rather than manually installing the module (which would likely reduce the number who would try it out). I don’t think there are any downsides to including the Spa module even in its current form.
Thanks @burke@mksd@ssmusoke@florianrappl, Hope we are to talk about it more in today’s TAC call cc @grace , Personally i also don’t think adding spa module in addons is bad idea and i think there is no duplication with MFEs unless otherwise , otherwise thanks everyone.
cc @florianrappl Feel free to join today TAC call for more ideas thanks When: 7:30pm IST | 5pm Nairobi | 4pm Cape Town | 2pm UTC | 10am EST | 7am PST
@burke since there won’t be any micro frontends being served within Ref App 2.11.0 and that the module will be deprecated, I believe that adding the module is just misleading.
And there is always a downside of adding one more JAR, the Ref App is already bloated with Spring context re-wiring.
This is disappointing from my perspective. I can understand why the Micro Frontend Squad isn’t particularly concerned about the spa module, but I don’t want to underestimate the value of lowering the barrier for the broader community to experience micro frontends within their OpenMRS instance (against their own data). I’m not suggesting a module is the only way to use Micro Frontends; rather, that it provides an incredibly familiar path for existing OpenMRS instances to experiment with a frontend or two against their own data without having to set up or maintain another website (no matter how simple adding a WAR to Tomcat or running a separate Docker container may be, it can’t be simpler than running another OpenMRS module… especially if it’s already bundled in the RefApp).
I’ll concede that we may not be ready now, so perhaps we don’t bundle the spa module with RefApp 2.11 and instead aim for RefApp 2.12 next Spring.
Just to stress what @burke said above… @mseaton@florianrappl@bistenes… on the TAC call today Burke expressed strong reservations about abandoning the SPA module approach. It would be great to have a summary here or in another Talk post as I think the discussion has mainly been limited to Slack which it harder for others to follow.
Hi @burke I am surprised to have this confusion here as you are part of all the demos.
This is disappointing from my perspective. I can understand why the Micro Frontend Squad isn’t particularly concerned about the spa module, but I don’t want to underestimate the value of lowering the barrier for the broader community to experience micro frontends within their OpenMRS instance (against their own data).
I guess you have not tried yet to set up this thing with the current approach. Please refer to @mksrom for a first hands experience. Then I’d say let’s talk which approach is simpler.
Just to be clear: This approach has not been derived out of thin air - we started with the module approach, but it has severe disadvantages and actually is against what the microfrontend squad does. After all, we are developing a frontend here. It should just be static resources that can run essentially anywhere. There is no need for a custom backend module here.
@florianrappl This question needs to be addressed ASAP, and I think it is imperative for the Micro Front end squad to think about packaging within existing OpenMRS implementations that use custom modules. IMO even modern tech needs to be packaged to be used by legacy use
There is a workstream that I am involved in for which packaging is a primary consideration so do advise accordingly to manage the risk early on and maybe consider other approaches
Thanks @ssmusoke for that great question! Yes - it will be able to pulled in via pom.xml (this was actually our starting point).
After all, what we ship are just static resources, and the way of distribution will be flexible (and there will be a few - one will be a Docker image, another will be a Maven package).
Backwards compatibility is important for us. Likewise, we also want to develop something that fits the modern distributions just natively.
I want to be clear: As Florian writes above, It is a top priority for the MF Squad to support backwards compatibility as we move forward. While we are hoping to leverage more contemporary approaches to deployment, we will work to ensure there remains a pathway available for those requiring the more typical route of OpenMRS modules. However, before we worry too much about this, I’d recommend first allowing Florian to develop a POC of the deployment strategy. The current module spa has limitations which I will defer to Florian to enumerate.
Unforunately, the timing of the refapp comes at a point of flux with regards to this question of packaging. The decision to remove module-spa from the release is more related to this reality. Given that there are no production ready MF features ready to be deployed, I think we are getting ahead of ourselves in worrying about how to package it as part of refapp.
I don’t think it’s a big deal to include it in this release if there is a desire to do so. But that decision should be made understanding that this module is likely to be replaced in some significant way by an alternative strategy (though this remains an open question).
The decision to remove this from the refapp release should not be viewed as an intent to disregard the common pathway OpenMRS has historically used for adding on features. Instead, it just warrants further discussion and that probably means we should pause on the module’s inclusion in the release.
We will figure out a solution(s), that brings everyone along for the ride.
Thanks JJ. I hadn’t heard of discarding the spa module until this post and, while I certainly don’t see the spa module as being the longterm solution for deploying micro frontends, it is a very implementation-friendly way of introducing micro frontends to implementations used to running RefApp (i.e., click a button to enable the module and check out the cool new features already working against your data… maybe you want to create your next feature in this space instead of writing more GSPs?). It’s less about backwards compatibility as it is essentially eliminating the barrier to trying out micro frontends. If the timing doesn’t work for 2.11, that’s fine. I’ll still be hoping for a spa module in RefApp 2.12 next Spring.
@florianrappl Thanks, what is the ETA for the maven package to be available, even if its pulling in a single page that can be used. IMO that is the key to ensuring that it is useable end-to-end abilities and helps drive usage and adoption
Thanks everyone for a strong discussion, My conclusion so fur as we wait for more views is that we shall first get rid of spa-module for this release and create a gap for MFE ,then we can include it in the coming release of Ref-app 2.12 as suggested above by @jdick@burke
. @burke i think we do have time to discuss about it ,we can still hold on with it to have fully conclusive decision
Let me know if this is the final conclusion on this. thanks
Reading this thread, it feels like there is a slight disconnect / communication gap around the impact and intent of this. I’m not 100% sure I’m following all of the angles, but it seems that there are a few areas of concern:
The tech that allows for a MFE to run in an OpenMRS distribution
The tech that allows for a MFE to be deployed into an OpenMRS distribution
The change that the Microfrontends squad seems to be making is to ensure that #1 does not require the openmrs-module-spa, but that Microfrontends can run without this module serving up specific front-end assets and that we don’t assume all requests to MFEs will go through the OpenMRS war (eg. via a Controller, Servlet, Filters, etc). This seems to make sense to me.
Where it seems that the openmrs-module-spa would continue to have a role would be in #2, as a mechanism to facilitate deployment of MFE artifacts into an OpenMRS server for those who want to either access these within the OpenMRS application (eg. served up from https://myserver/openmrs/spa"), have a user-oriented front-end to install MFEs (similar to what the owa module provided), or other functions that reduce the barriers to deploying MFEs into a server.
Whether or not #2 should be the responsibility of the MFE squad not develop and prioritize is a reasonable question. But if we accept that the openmrs-module-spa will continue to exist into the future in order to provide these deployment capabilities to implementations that need them, the question about whether to include this in the refapp now should probably hinge on what it’s function is, how stable it is, what features it is enabling, whether it is something we want to promote in the refapp as a best practice, and how much it will need to change to support the new MFE approach to #1.
Thanks @mseaton, for another cool thought. i think we should definitely also think about the stability it is bringing in,enabling features it come with, and future use, i have liked the fact that you extracted the use case of how both spa module and MFEs can be used differently without each depending on the other module
