Removing Single Page Application (spa) in REF-APP 2.11.0

@ssmusoke that specific question is not answered yet.

@mksrom to step in but the idea was to Mavenize as much as possible indeed. We will see, the work on packaging has barely started.

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.

1 Like

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


1 Like

@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.

1 Like

Yes, if this is not the way we expect microfrontends to be served going forward, probably doesn’t make sense to bundle it.

1 Like

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.

1 Like

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.

Take care, Mark

1 Like

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.

1 Like

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. :slight_smile:

1 Like

@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:

  1. The tech that allows for a MFE to run in an OpenMRS distribution
  2. 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.

Other thoughts?



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

Mike, I agree with you regarding separating things into (1) and (2). I agree that (2) would allow an implementer to follow the common OpenMRS pathway for making available MF assets. And I think the module as is does this ok though I’d let @bistenes confirm this.

I do think the intention is to find a seamless way of using more contemporary approaches to achieve both (1) and (2). This should be clearer once @florianrappl has the POC to demonstrate.

1 Like

Yeah, I agree with what @mseaton and @jdick are saying, that it could be a good mechanism for making deployment easy. It could certainly do that better than it does at present, even.

However I’m definitely open to alternatives that @florianrappl might propose, provided they’re well fleshed out.

1 Like

FYI @sharif - we clarified this topic at the TAC meeting on Friday last week. Here’s what we agreed:

Decision: Remove the SPA module from the RefApp 2.11.0 release.


  • Whether or not we use a module-approach to enable implementations to experiment with microfrontends is still an in-flux-decision. On Thursday at the MFE Squad weekly demo, Florian demo’d an early prototype that supports an alternative way for frontends to be deployed and related to each other. Summary: This approach ties core parts of the framework together; and implementers can download whole MFE in more logical way. We still need to define best practice for working w/ frontends and being able to start using them, instead of via modules that plug in. Idea is loading in OMRS frontends w/ npx; so you’d have the frontend running and be able to pop in your own modules easily. (Goal is lower-barrier way for people to load and start experimenting with Frontends.)
  • We can always add the module to the Add-Ons directory if we end up using the module-based approach in the near future; however, right now there isn’t a plan to maintain the SPA module, so it doesn’t make sense to add it to the Add-Ons directory at the moment until the plan is more clear (so definitely not to the RefApp bundle).
  • That module is not yet vetted enough to know it won’t cause surprising concerns elsewhere (though this is probably unlikely)
  • We need to reduce the scope of this release to allow quality testing

I hope this helps :slight_smile:


Thanks alot @grace for this important feedback unfortunately i missed that call, so am going to unbundle it today thanks

1 Like