Standardizing OpenEMR Frontend Development - Decision Time

OpenEMR Development
#1

Many may not realize how much effort was put into the v5.0.2 release that significantly addressed core code cleanup and security. Also notable is the implementation of REST api and controller/services patterns along with the much appreciated efforts to get our application look and feel consistent.

Wow, think about just how far OpenEMR has come in the past three releases making this an appropriate time to thank our community of contributors. I do so enjoy working with you folks.

To business.
Now, more so than ever, we have the opportunity to firm up our MVC framework. So let’s do that starting with what everyone purposes this should look like. Based on these proposals we can narrow to a winner and move on to implementation.

So my thoughts:
I think it is of the most importance to stay away from relying on third party frameworks and libraries where we can. Often times I find them overkill, heavy or forcing authors into compromises between what the developer wants to achieve and what the framework allows. Symfony may be an exception due to its component nature and could assist in some areas. For those that immediately think, “Why reinvent” I say, Remember OpenEMR’s life cycle and business model. The simpler we keep an OpenEMR specific framework the easier it is to maintain. Remember I am speaking to our core development/conversions here where we need to still be cognitive of value added add ons that may already exist or for future developments. Those would need to be modular for new while maintaining some compatibility for those already more tightly integrated today.
The most difficult hurdle is agreeing on our model/view transitions. We have to be very mindful of converting existing views without having to rewrite most everything which would likely be the case if we used third party.

So bottom lining it, I believe that front end frameworks are unnecessary(and soon obsolete, imo) as web components are now natively support by most all browsers(thanks es6).
In converting existing php generated html to templates using custom tags and custom elements or more generally, web components, we can almost be assured this support is not going away anytime soon.
I plan to example this process soon converting one of our simler scripts. Perhap @robert.down may be interested with helping in this endeavor.

Anyway, you get where i’m thinking plus, i’m tired of typing. Your turn!

2 Likes
#2

Hi,
I like what you are saying, especially the part “we can almost be assured this support is not going away anytime soon”. I’m still a bit of a js idiot, and seeing the simple example will be very helpful for this.
-brady

1 Like
#3

Thanks for getting this convo started, it does seem about time to really lay out a plan.

I think a bit of historical context is key. The last 10 years has seen been the boom of the javascript/client side world - the front end frameworks have been in an arms race and is moving so fast that I find it very difficult to safely and confidently land on any particular framework. React, Angular, Vue, Whatever-Is-Next they come and go or they come and stay but iterate so quickly we would need a small army to keep up. I think this is likely because of the tremendous transformations we’ve seen in browsers as a whole.

While this conversation is about frontend work, I want to say that PHP does not suffer from the same issues. Why? Servers have been relatively stable for many years now and the frameworks that exist tend to be very stable and can live on for many years with minimal breaking changes. Additionally, over the last 10 years PHP frameworks have begun moving to completely modular-based frameworks. Gone are the days of the monolithic Zend solutions. I really like Symfony, I love the way it was built. But we don’t need every. single. module. they make. Instead, I cherry-picked the EventDispatcher - a core component that I hope as we build out the inpatient system becomes the standard way of handling our server side events. Modular = good. It’s a smaller footprint, easier to implement, and the PHP community has worked hard to create abstracted interfaces that makes it easy to swap out upstream components in the future without breaking (much) functionality.

So where does this leave OpenEMR?

I tend to agree with @sjpadgett that relying on any particular front end framework (React, Vue, etc) is an approach we should avoid. Web components are quickly becoming native and offer a solution (in my opinion) that will far exceed any particular framework. Additionally, projects like Polymer offer bride solutions - help us get to web components while still abstracting some stuff that would be needlessly recreated. I like Polymer because they have come out and basically said: we just want to get people to web components - even if it means our project becomes deprecated.

I think more than anything we need to plan out the structure of the front end work. Instead of just diving in, we should stop and really lay out how we are going to build out features. What does our new file structure look like? Where are we putting javascript files? Do we toss all the files into a templates/ folder like we do not (oh please no) or do we follow a modular approach (i.e. all patient scripts go inside the patient module [please yes]).

Lastly, we need to figure out how we are going to handle all the translations. My thinking is that the front end (whatever it may look like) will be fetching JSON from the server via REST. All our translation needs need to happen on the server, when the client-side receives the variables all it has to do is render, no translation needed.

@sjpadgett I’d love to work with you on converting a simpler script.

1 Like
#4

I think each area of the system should be broken down into core modules and loaded, similar to the way Zend or Symfony handle their core modules. These modules should be based on feature sets. I actually prefer leveraging Symfony, Zend, or other server based modules on the backend, but I don’t care if we write our own as long as we have consistent interfaces for the modules. I would not leverage the full fledged framework. OpenEMR adapters and facades would be built around all the modules/libraries so we can swap them out if that ever becomes necessary. This to me seems like the biggest bang for buck for a long lived system such as this.

That’s the backend, the frontend is a completely different animal. I feel there is a huge danger in trying to rely on the latest javascript fad of the day. I write a lot of Javascript code and I’m intimitely familiar with how fast things change. OpenEMR lacks the manpower to keep up with this kind of change and so it needs to forgo feature velocity for maintainibility, learnability, and extendability. Web components is the long term trend for this. We could still write adapter code like we do on the backend so that a framework / library can be leveraged but I think we will not get a lot of bang for our effort here.

I haven’t done much work in writing raw web components as 2 years ago the Polymer technology was still too rudimentary and things such as Shadow DOM were (and still appears to be) a moving target. Component based architecture is my preference as well. My preference would be that anything in core is independent of frameworks but provide appropriate extension points (whether through our event dispatcher, module loader, or some form of component loader) that developers can extend in whatever way they want.

Technically the way Polymer behaved (when I used it 2 years ago) component developers could use any technology they wanted (react, angular, whatever) to build their component if it conformed to the Polymer interface. I’d rather avoid that for the core system as it creates a maintenance nightmare but allow extension/module writers to have that flexibility.

Translations should be handled at the server layer and should leverage existing translation technologies such as PO and POT files (https://www.icanlocalize.com/site/tutorials/how-to-translate-with-gettext-po-and-pot-files/). If needed additional cached versions of the POT file can be sent down via javascript but it should all originate at the server level.

I personally would like long term to move OpenEMR to be more of a rest API and use web components as the presentation layer interface. Installable modules would add additional endpoints as well as house the presentation components that would be visually displayed.

I’m sure I’ll have more thoughts, but I wanted to keep the discussion alive by throwing out my initial thoughts.

2 Likes
#5

Hello team,

does anyone mind sharing an updated overview on the state of frontend development for the OpenEMR project?

This thread is kind of old and there’s a long project history, so I’d like to understand better what’s the context and current situation to find good ways to contribute.

Thanks in advance!