# Integrating microfrontend tooling into OpenMRS SDK? **URL:** \ **Category:** Development\ **Tags:** openmrs-sdk, micro-frontends, sdk\ **Created:** [January 25, 2021, 10:40pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843 "2021-01-25T22:40:29Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![grace](https://talk.openmrs.org/user_avatar/talk.openmrs.org/grace/32/16942_2.png) [@grace](https://talk.openmrs.org/u/grace)\ **Post date:** [January 25, 2021, 10:40pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/1 "2021-01-25T22:40:29Z")
We’re trying to clean up the documentation to make it easier for others to contribute to Microfrontend work. @bistenes brought up the SDK with me today, and since we’ve been talking about the Technical Roadmap for 2021, seems like good timing. Proposal: Imagine if the tooling a dev needs in order to contribute to Micro Frontend work was already part of our SDK. You’d run `openmrs-sdk` (and maybe add a tag for whether you want MFE tooling or not), and it would set up a SPA environment for you so that you simply navigate to SPA on your local server and you could get started. In theory this could also reduce initial support requests as people try to get started using SPA. Questions: - Do people think this is something we should try to get done in Q1 or Q2 this year? - What tools, or how much of the MFE system, would we want added to the OMRS SDK? CC: @mseaton @burke @dkayiwa @jdick @florianrappl ---
**Author:** ![mozzy](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mozzy/32/11815_2.png) [@mozzy](https://talk.openmrs.org/u/mozzy)\ **Post date:** [January 26, 2021, 12:28pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/2 "2021-01-26T12:28:22Z")
Sure looks a wondeful idea ---
**Author:** ![ssmusoke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ssmusoke/32/8020_2.png) [@ssmusoke](https://talk.openmrs.org/u/ssmusoke)\ **Post date:** [January 26, 2021, 2:13pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/3 "2021-01-26T14:13:13Z")
@grace IMO the OpenMRS SDK should have any proposed packaging and deployment feature for modules, distrbutions including micro-front end asset packaging (which will probably be a pain) including the distribution management being proposed by Mekom for the Iniz module ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [January 26, 2021, 2:45pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/4 "2021-01-26T14:45:36Z")
This is a great idea! > [@grace](#): > > Do people think this is something we should try to get done in Q1 or Q2 this year? It would be lovely to have something in place before GSoC gets started [for the purposes of these projects](https://wiki.openmrs.org/display/projects/GSOC+2021%3A+Modernizing+Administration+functions+for+OpenMRS), as that’s when I’d expect we have a spike of users trying to setup an MF for the first time. > [@grace](#): > > What tools, or how much of the MFE system, would we want added to the OMRS SDK? As much as we can make easier by integrating things into the SDK. I think at a minimum: 1. Some capacity to create a “new” microfrontend project with reasonable defaults. 2. Some capacity to easily load this into a running instance of OpenMRS (which is pretty trivial, though it would be nice if there was a command to automatically activate it for given SDK servers). 3. Some capacity for bundling up the resulting JS + other assets into whatever format we expect this to be deployed in (ideally a format that can be versioned in some fashion). ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [January 26, 2021, 3:15pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/5 "2021-01-26T15:15:10Z")
Sounds a great idea , however since MFE projects are taking a totally different path , i may have this suggestion 1. What is more expensive coming up with a new JS based SDK dedicated to **MFE / OCL** Some problems (We can Weigh Benefits vs Cost) 1. If we came up with a **MFE / OCL SDK** , what would be the cost of starting something new / maintenance vs simply adding the feature to the existing SDK which means maintenance as well ? 2. Does a **MFE** and may be OCL Developer want the cost of setting up Java and Maven for the sake of MFE / OCL(may Be) . Why not setup node / npm and concentrate on that 3. If Current SDK becomes a **god-sdk** won’t we have more diverging problems for the maintainers ( **Java VS Node** ) Just asking I may be wrong this way , otherwise a MFE / (and may be OCL ) feature on SDK is a sweet bunch of bananas for this year 😀 😀 ---
**Author:** ![grace](https://talk.openmrs.org/user_avatar/talk.openmrs.org/grace/32/16942_2.png) [@grace](https://talk.openmrs.org/u/grace)\ **Post date:** [January 26, 2021, 3:23pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/6 "2021-01-26T15:23:36Z")
> [@ibacher](#): > > It would be lovely to have something in place before GSoC gets started [for the purposes of these projects](https://wiki.openmrs.org/display/projects/GSOC+2021%3A+Modernizing+Administration+functions+for+OpenMRS), as that’s when I’d expect we have a spike of users trying to setup an MF for the first time. Exactly! @tendomart excellent suggestion re. the OCL for OpenMRS work as well, thank you for thinking of that. You ask a good question about whether there should be 1 or 2 SDKs. What do others think about that? @dkayiwa @burke? ---
**Author:** ![grace](https://talk.openmrs.org/user_avatar/talk.openmrs.org/grace/32/16942_2.png) [@grace](https://talk.openmrs.org/u/grace)\ **Post date:** [January 26, 2021, 3:24pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/7 "2021-01-26T15:24:59Z")
> [@ssmusoke](#): > > the OpenMRS SDK should have any proposed packaging and deployment feature for modules, distrbutions including micro-front end asset packaging (which will probably be a pain) @ssmusoke sorry can you clarify: What exactly about the MFE asset packaging do you anticipate will be a pain? ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [January 26, 2021, 4:19pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/8 "2021-01-26T16:19:03Z")
@tendomart A few things: - I’d separate out the OCL stuff from the MF stuff. Yes, they’re both generally ReactJS-based SPAs, but the OCL for OpenMRS Client is (in my mind) a one-off project rather than something we’d expect to see people adding their own custom versions of. - I agree that there very little value to a pure front-end developer having this integrated into the SDK. I’d expect that what we actually going is adding some thin Maven wrappers around functionality provided by NodeJS-based scripts, so a front-end developer could always just by-pass the Maven stuff. - However, for new devs who might work on both a module and a front-end for that module-provided functionality, having the SDK integration isn’t too much overhead (and if we’re thinking in a microservice way, teams are generally supposed to own “features” rather than dividing the work into “backend stuff” and “frontend stuff”; having a single tool to create whatever kind of OpenMRS-related project you need helps make that easier). - I think the worry about a “god-sdk” is a little misplaced. In terms of Java code, the SDK really only has a small number of responsibilities: 1) setup a new module / project, 2) setup and run a local OpenMRS server, and 3) deploy modules / projects to the local server. Everything else (compiling code, building and packaging OMODs, etc.) is handled elsewhere (and generally by the default Java / Maven stack). Having a version of `openmrs-sdk:create-project` that creates a MFE project by calling whatever appropriate generator using system NodeJS and that can (call out to) the NodeJS tools for automatically creating / deploying an import map doesn’t seem like a huge lift. ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [January 26, 2021, 6:30pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/9 "2021-01-26T18:30:30Z")
Ooh Noted , thanks for the insight @ibacher ---
**Author:** ![grace](https://talk.openmrs.org/user_avatar/talk.openmrs.org/grace/32/16942_2.png) [@grace](https://talk.openmrs.org/u/grace)\ **Post date:** [January 26, 2021, 6:45pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/10 "2021-01-26T18:45:59Z")
> [@ibacher](#): > > Having a version of `openmrs-sdk:create-project` that creates a MFE project by calling whatever appropriate generator using system NodeJS and that can (call out to) the NodeJS tools for automatically creating / deploying an import map doesn’t seem like a huge lift. @bistenes @mseaton does this sound like what you had in mind? @dkayiwa How could we proceed with breaking down this work and getting this done? Is this something that the TAC or PM Team would take on, in a similar way to how we get the releases handled and launched? ---
**Author:** ![ssmusoke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ssmusoke/32/8020_2.png) [@ssmusoke](https://talk.openmrs.org/u/ssmusoke)\ **Post date:** [January 26, 2021, 6:47pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/11 "2021-01-26T18:47:09Z")
> [@grace](#): > > @ssmusoke sorry can you clarify: What exactly about the MFE asset packaging do you anticipate will be a pain? @grace I have no idea since I have not yet dipped my toes, into it it yet, so was just a suggestion. @tendomart 2 SDKs are a no-go area. What is so special about MFE/OCL that requires a new different SDK. Remember the lifetime of these front-end technologies is 2-3 years, so it will be replaced soon with something else FYI - Server side rendering is back in vogue with new paradigms like HotWire and now React has some implementation ---
**Author:** ![mozzy](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mozzy/32/11815_2.png) [@mozzy](https://talk.openmrs.org/u/mozzy)\ **Post date:** [January 26, 2021, 7:07pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/12 "2021-01-26T19:07:38Z")
> [@ssmusoke](#): > > Remember the lifetime of these front-end technologies is 2-3 years, years or just months 😀 ?? ---
**Author:** ![mseaton](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mseaton/32/8088_2.png) [@mseaton](https://talk.openmrs.org/u/mseaton)\ **Post date:** [January 26, 2021, 8:45pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/13 "2021-01-26T20:45:15Z")
I agree with @ibacher’s points, though since you called it out over the others @grace I think SDK goals that facilitate creating a new microfrontend (eg. create-project) are less valuable than those responsible for installing and updating artifacts into a server (eg. the deploy goal), whether this is a new install or an update of an existing install, and whether this is an individual artifact or all of the components that make up a broader distribution. At PIH, we rarely if ever use the openmrs-sdk:create-project goal. We very often use goals like “setup” and “deploy” against a server that is configured with an openmrs-distro.properties file as a part of a distribution. The typical workflow would be to: 1. Install a distribution into a new server with openmrs-sdk:setup, where -Ddistro points to a maven project that has an openmrs-distro.properties file on the classpath. 2. Update this server to the latest version of the distribution over time, using openmrs-sdk:deploy -Ddistro points to an updated openmrs-distro.properties file with new versions 3. Update this server to run a new or update an existing artifact, but running openmrs-sdk:deploy while in the top-level directory (with pom.xml) for a given project. It would be great if we could start: 1. Specifying the microfrontends that are part of our distribution in a structured configuration file (expanding on the current openmrs-distro.properties, or evolving this in some way) 2. Have the SDK goals responsible for installing/updating artifacts into an SDK server able to do so in a manner consistent with how it supports modules, war, and owas. (Note: supporting config packages would be the other component we’d want to support in a similar fashion) Mike ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [January 26, 2021, 11:58pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/14 "2021-01-26T23:58:24Z")
Agree with not creating a second SDK. Devs working primarily in frontend technologies already have tooling like npm, nvm, etc. Enhancing our SDK to facilitate the packaging, deployment, and running of OpenMRS instances with new frontend artifacts makes sense. Put simply, our SDK should make development, packaging, & deployment easier while focusing on simplifying & standardizing the OpenMRS-specific steps that devs otherwise need to do manually and the fewer OpenMRS-specific aspects of development we have, the better. ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [January 27, 2021, 8:35am UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/15 "2021-01-27T08:35:17Z")
> [@ssmusoke](#): > > @tendomart 2 SDKs are a no-go area. What is so special about MFE/OCL that requires a new different SDK. Remember the lifetime of these front-end technologies is 2-3 years, so it will be replaced soon with something else > [@burke](#): > > Agree with not creating a second SDK. Devs working primarily in frontend technologies already have tooling like npm, nvm, etc. Noted all ,thanks ---
**Author:** ![bistenes](https://talk.openmrs.org/user_avatar/talk.openmrs.org/bistenes/32/18573_2.png) [@bistenes](https://talk.openmrs.org/u/bistenes)\ **Post date:** [May 11, 2021, 9:23pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/16 "2021-05-11T21:23:22Z")
I’d like to work on this in the next couple weeks. Not the generator part (sorry @ibacher ) but rather the integration with `setup`, `deploy`, and `run`. What we have presently is IMO a second SDK, `npx openmrs`, which is a very good thing and was definitely the right decision. The task now is to integrate that with the maven SDK. I agree with @mseaton 's proposals. As @ibacher suggests, I think we should implement this by having the maven SDK delegate to the `openmrs` frontend tool as much as possible. So I suggest that `openmrs-distro.properties` should support the following sorts of properties: ```bash # Microfrontends to include, a la microfrontends.json spa.microfrontends.@openmrs/esm-home-app=next spa.microfrontends.@openmrs/esm-login-app=1.3.0 # The base application path and SPA path spa.apiBase=openmrs/ spa.spaBase=openmrs/spa/ # Paths to config files to build in spa.config=config.json,config-site.json # Additional import map lines spa.importmap.config-file=assets/another-config.json # becomes the line "config-file"="assets/another-config.json" # Additional assets to bundle with the application spa.assets=assets ``` Where we have files `config-json`, `config-site.json`, and `assets/another-config.json` all in the distro folder. This will build the specified frontend application to `frontend/` in the application data directory, both in development and when building the distribution. This will work out of the box with `openmrs-module-spa`. I don’t know how the SDK should support builds where the frontend is being served from outside the application data directory. We should figure this out. @mksrom , @mksd ? I realize this seems like a lot of new stuff in `openmrs-distro.properties`. Other ideas are welcome. But these are all application build parameters and that seemed like the natural place for them to go. CC @jdick , @corneliouzbett , @dkayiwa EDIT: Changed `spa.@xyz` to `spa.microfrontends.@xyz` ---
**Author:** ![corneliouzbett](https://talk.openmrs.org/user_avatar/talk.openmrs.org/corneliouzbett/32/15464_2.png) [@corneliouzbett](https://talk.openmrs.org/u/corneliouzbett)\ **Post date:** [May 12, 2021, 6:28am UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/17 "2021-05-12T06:28:18Z")
This is great! I might start working on MFs. > [@bistenes](#): > > I don’t know how the SDK should support builds where the frontend is being served from outside the application data directory. We should figure this out. @mksrom , @mksd ? IMO: with the assumption that the individual who wants to serve frontend assets outside the application directory already has a pipeline of building those assets. So maybe adding a prompt to decide whether to serve from a remote URL, If yes ask for the URL and skip building the frontend assets, then use the information to set the GPs; `spa.remote.enabed=true` and `spa.remote.url=`. Dunno how SDK is architecture but a simple insert for the GPs will do the trick. ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [May 12, 2021, 2:41pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/18 "2021-05-12T14:41:19Z")
> [@bistenes](#): > > I don’t know how the SDK should support builds where the frontend is being served from outside the application data directory. We should figure this out. @mksrom , @mksd ? As far as I know that doesn’t matter too much. And otherwise I am really excited to see this work being moved forward @bistenes! That will be really useful for the ICRC as we start embracing O3 in the next few months (hopefully). Cc @frederic.deniger ---
**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\ **Post date:** [May 13, 2021, 2:27pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/19 "2021-05-13T14:27:04Z")
Thanks for working on this @bistenes ! With a quick review, this makes sense to me! Take care, Mark ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [May 17, 2021, 3:08pm UTC](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/20 "2021-05-17T15:08:40Z")
@bistenes Thanks for this, this looks great! > [@bistenes](#): > > ```auto > # The base application path and SPA path > spa.apiBase=openmrs/ > spa.spaBase=openmrs/spa/ > > ``` Are these actually necessary to create a distro bundle? They look to me like more of runtime considerations than distribution-time, but I suppose these are embedded in the actual SPA page? > [@corneliouzbett](#): > > Dunno how SDK is architecture but a simple insert for the GPs will do the trick. The SDK doesn’t really have a role in the actual instance running nor do we want to make that a requirement. So having the SDK directly create GPs is probably not the best idea (the SDK at best loads a skeleton of the OMRS DB schema that’s then modified by the Liquibase scripts). [Next page](https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843.md?page=2)