There are some very interesting possibilities to consider for micro frontends, where a web application is comprised of relatively independent sub-applications.
An example of a micro frontend framework: single-spa
The biggest wins for OpenMRS would be:
The ability to weave together web application functionality into a shared front end framework
A potential solution for modular functionality (ability to mount & unmount parts of the application)
The biggest challenges for OpenMRS with a micro frontend solution would be:
Creating an application with a consistent look & feel and user experience
Avoiding a niche solution (i.e., an approach only OpenMRS and a handful of others are still using a year or two from now, where we suddenly “own” the framework including maintaining cross-browser support and the learning curve for new devs steepens)
Handling context (e.g., which patient is selected) and communication between sub-applications without creating significant requirements on sub-application development or dependencies between sub-applications
Performance
Exciting to see how micro frontends are coming. It would be great to ride this wave… but choosing the right wave and not having it come crashing down on us.
Are there other examples of micro frontend frameworks like single-spa? Is there one that is leading the pack? What do folks think about the pros & cons of adopting a micro frontend for OpenMRS?
I haven’t read any of this yet, and am interested in doing so… but, I’d be reluctant to adopt any micro front-end framework, no matter how great it seems, unless it’s been widely adopted and/or seems clear to be widely adopted. (ie the “niche solution” risk @burke mentions)
micro front-end framework seem a right approach to me, although there aren’t many options to choose from, i wonder what effort would be required if we attempted to write our own simpler one for easy future maintenance!
Frameworks and languages are born when people want something more than what’s out there
Also, we’re using a new github repo https://github.com/openmrs/openmrs-rfc-frontend to discuss decisions about the future of OpenMRS frontend. Feel free to jump in and participate in the pull requests, there.
The microfrontends squad had our first meeting yesterday. Present were myself, @jdick, @fali (ampath), @bistenes (PIH), and @angshuonline (Bahmni). If you are part of a group that was not represented in the meeting and would like to be, feel free to post here or DM me. Here are some meeting notes:
We are going to start merging pull requests in https://github.com/openmrs/openmrs-rfc-frontend. Merging will happen when 3 members of the microfrontends squad approve the PR. When an RFC is merged, that means “we intend to build this.” PR #1 is the first one we’re going to discuss and then merge.
We are using the #microfrontends channel in the OpenMRS Slack workspace as a communication point for the microfrontends squad.
The microfrontends squad is going to meet weekly. We will record meetings and upload them to be viewed by anyone in the community.
Our next meeting will be demoing our distributions to each other, to gain familiarity with what is out there and what commonalities there are.
We plan on deploying our code early and often to a test environment, so that everyone can see what we’re doing and the progress we make.
Questions that we discussed that are still open: “To what level will distributions share code? Entire features? Widgets within a feature?” “Does a shared navigation make sense?” “Do we first get all of the existing distributions using the SPA, and then slowly cannibalize them? Or do we start totally from scratch?”
Meetings with lots of people silently listening as I talk are pretty uncomfortable for me and hard for me to act naturally in. With the microfrontends squad we’re trying to build some momentum and teamwork which can be tougher if there is a new group each week with lots of people jumping into the conversation. I’m working on getting used to a dozen or so lurkers in phone calls . We are trying to be as transparent as possible in our efforts, and will be using this Talk thread to provide updates. I’m open to reconsidering opening up each of the meetings to the whole community – but the last few like that have just been pretty stressful for me. I’m leaning towards just uploading the recordings here after each meeting.
Yeah I would like to share slack communication with everyone – is there a way that people have done that in the past without just copy/pasting large swaths of instant messages into a thread on Talk? Slack conversations have threads within the conversation and are hard to just copy/paste.
I don’t think a JIRA project would be helpful for us at this stage of the project. We’re still mostly just in discussions. JIRA might become helpful at a later stage of it, though.
Hi @joeldenning and others, I just peeked at Talk looking to see if there were updates, or if there was a way I could follow along from a distance. It seems like this thread is the place to look, but there aren’t really regular updates.
Depending on the cadence of the actual work, I would love to see some kind of sharing every couple weeks (e.g. the frequency of a typical sprint showcase). And I’m personally not going to listen to call recordings, just for lack of time.
For now that could just be posting a few bullet points summarizing what happened, what the focus is for the next couple weeks, and highlighting any open questions where opinions from outside the core group might be helpful. Eventually it could be actual demos.
(Again, no need to cater to me specifically, I’m just interested to follow along, and don’t feel like there’s any way I can do so.)
@darius thanks for the reminder - I was on vacation for a week or so, but putting updates here is important and something that slipped the last few weeks. We’ve got some good updates from the microfrontends squad for everyone:
We created a PR to openmrs-core that adds SPA routing to Tomcat. https://github.com/openmrs/openmrs-core/pull/2898. After discussions with Burke and Daniel, we’re going to modify it so that routes under /spa will go to the SPA by default. And that other routes will not go to the SPA unless a configuration property tells them to use the SPA as the default for all routes.
We’ve created a deployed environment for the new SPA. See https://openmrs-spa.org/openmrs. Right now it has the legacyui in place, but we’ll be removing that once we have a new login page in place. If you go to https://openmrs-spa.org/openmrs/spa you will see a blank screen that is the new SPA. Check your devtools to see what’s going on there.
We’ve created https://github.com/openmrs/openmrs-esm-devtools which is a single-spa application that will only be used by devs. This application allows developers to override a deployed environment so that one of the javascript modules is loaded from their localhost. This is the intended development workflow for frontend code – you don’t even have to clone or boot up openmrs-core if you are not modifying the backend.
We plan on starting work on a login page soon. I talked with @gschmidt today to start the conversation on how we want to go about designing UIs, a styleguide, and having devs and designers collaborate.
The two recorded meetings are available at that link only for 30 days. We’re looking for a place to host them permanently so they aren’t lost. If anybody wants to take that and make it happen, it would be appreciated.
Next steps:
We plan on building a new login page within the SPA.
After that, we tentatively are planning on trying to tackle Patient Search. If hearing that freaks you out, now is your time to comment . We don’t have designs yet or anything and are in the early stages. So don’t worry, it’s not too late to change or decide on a direction to go with it.
@burke We haven’t been broadcasting the conference call link for everyone to join, but have been uploading them afterwards and posting a link with our weekly update. I believe that it’s hard to get momentum as a group if meetings are large, or if there are new people every week who ask about topics discussed in previous meetings that they missed. My hope is for the meetings to be effective in coordinating efforts and making decisions - my fear of making it a large meeting is that it would reduce the effectiveness. Additionally, like I posted a few weeks ago, large meetings with a lot of silent observers creates a fair amount of anxiety for me (as the one leading the meeting it freaks me out when I ask a question to a group of 20 and get zero responses, or when I talk for a couple minutes with no comments from others and feel like I’m just talking to myself) and makes it hard for me to act naturally in them.
I’m open to being overruled on this one, but that ^ is my preference. Our weekly meetings are becoming more and more effective as we gel as a squad, and I would prefer not to have lots of new participants each week that might jeopardize that. If we’re missing representation from a group that would like to be involved, let’s have them join the microfrontends squad on an ongoing and regular basis
@bistenes gave us an update on our plan for those who want to serve through tomcat the javascript assets used in the import map. After consultation with others at PIH, myself, and @aojwang, Brandon will be authoring a java module that will allow for hosting javascript assets by adding them to application_data
@fali gave us an update on the new login page that we’ve been working on. She and I pair programmed part of it and ran into some hiccups with the latest master branch of openmrs-core and the REST module
I gave an update about a conversation I had with @gschmidt regarding how the microfrontends squad should collaborate with Greg and other designers. We decided that we’re going to create a JIRA project or board and use that to communicate the status of design and development efforts. I need to follow up with Greg on this and make sure we get the collaboration going with this new login page.
@jdick gave an update on the Hackathon that is planned for a couple weeks from now in Kenya.
We are starting on documentation for microfrontends. The documentation will be in OpenMRS wiki and will have its own project page. The wiki will be used for documentation, and the RFC (https://github.com/openmrs/openmrs-rfc-frontend) will be used for our decision making process. Right now our documentation isn’t yet on OpenMRS wiki but we’ll be moving it there in the next couple days. You can find it here: https://github.com/openmrs/openmrs-esm-devtools/pull/3 (the documentation is incomplete and doesn’t cover a lot of stuff, but it’s a start)
Our live demo of our code is at https://openmrs-spa.org. Right now there’s not much to see but in the next week or two there will be specific and demo-able things that we will link to and show.
Perhaps one way forward to both support the needs of efficiency and productivity for the squad while also ensuring the opportunity for additional involvement from the community would be to have a regularly scheduled public meeting as well.
I’d like to propose that the last Thursday meeting of each month be dedicated to as a public forum meeting. Alternatively, we could use a design forum to accomplish the same.
@dkayiwa you’re talking about my post from a week ago? Not the one from today? Regarding the two links in last week’s post - yes they look like the same link, although that’s the link that @jdick posted two weeks in a row. Perhaps the old one was replaced? @jdick can you comment?
. We are trying to be as transparent as possible in our efforts, and will be using this Talk thread to provide updates. I’m open to reconsidering opening up each of the meetings to the whole community – but the last few like that have just been pretty stressful for me. I’m leaning towards just uploading the recordings here after each meeting.