Backend Modernization Project

OpenEMR Development
#1

This thread is dedicated to all backend modernization work and communications.

Goals

  • Normalize the code directory structure
  • Separate out the views and the business logic

Note

This project has been on hold for a bit. The approach that was taken before was to use Doctrine2 ORM along with service classes. While elegant, Doctrine2 ORM has a big learning curve and Matthew began to just split out the biz logic from the views into services using the existing SQL setup. Take this for instance: openemr/FacilityService.php at master · openemr/openemr · GitHub

Task Management

Backend Modernization · GitHub (seriously needs some attention, however!)

Team

Chat Room

#backend-modernization

1 Like
#2

I’ve been working on this quite a bit, though in a slightly different area then you originally planned. This includes event dispatching and modulaization. I just finished up finals this week so expect a flurry of movement on this.

#3

I’m thinking that regardless of if we go with modules, we still need to have services for the business logic, separated by domain concepts. This is to say whatever you’re doing is compatible!

#4

I think we’ve moved beyond the “if” modules are happening. I’ve been working on it for several months and am probably well over halfway done with the new infrastructure :slightly_smiling_face:

#5

With that said, there’s no reason the two domains we’ve been working on can’t integrate, in fact they should, and would be easy

#6

@robert.down sounds good to me sir.

My only notes are:

  • Doctrine/ORMs have too high of a learning curve. This is not to say that the community can’t learn, but it is to say that everyone knows straight SQL and, if you think about it, the overall code cleanup/separation is the most important thing at this point so we can think about ORM stuff later really.

  • Similar to the lessons I learned with bringing in an ORM and causing a bit of confusion, do you feel that folks will be able to pick up with the new module pattern without much friction?

#7

Also, I’m very excited to hear that you managed to tackle much of the infrastructure in such a short time. Nice!

#8

I think the ORM solution is the way forward, but agree with the learning curve. I think we should allow developers who are willing to use it the chance to go for it, and those that want to stick with just straight SQL for now can continue that way. Maybe over time we develop some education on ORMs and specifically how they apply to OpenEMR.

I do think the new module system is pretty straight forward. I’m working on a couple of pristine modules that developers can use as an example moving forward. Maybe that’s something we can consider for the ORMs. My goal is a couple of modules that include a broad range of the new infrastructure so there’s an easy way to move forward. However, even so I plan on developing some education for some things - Event Dispatching seems to be an area prone for confusion. Luckily a lot of the new stuff is straight forward and easy to implement.

#9

This is probably where I went wrong. I didn’t supply learning materials with the ORM. Sounds like you have this in mind. Perhaps the Wiki or a markdown file will be helpful here.

#10

My two cents is that you should go with the most durable and/or efficient design, regardless of guessing at skill sets. I’m pretty sure the community and new contributors will be more than happy to sharpen skills or adjust as needed. Not many developers I know who are not willing to add to their skill set.

1 Like
#11

I made a research about the job market in the USA for framework developers and the result is
Laravel 509
Zend 332
Doctrine 168

That tells me something

#12

Doctrine is a the ORM @MatthewVita has been working with, Laravel is built on top of Symfony, which is what we are using a lot of.

#13

Hi @MatthewVita
When we use “useLegacyImplementation” ?

#14

Ha, that was a hack to support older features.

Basically the database table was much simpler for certain older features of OpenEMR and when the database table became more complex, certain code areas didn’t make use of new columns. I have this as a flag to indicate to stick to the more legacy way of the code.

Sorry for the hack!

#15

Apologies, I have been gone for some time. And there seems to be a serious laps in the time frame. I know that Matthew was out for a while and Robert was finishing his degree. @brady.miller @MatthewVita @robert.down

I know that I was not selected to work in this group but I am curious as to the status of this particular part of the project.

#16

Hi @juggernautsei ,

I’m pretty sure we opted not to continue to pursue Doctrine secondary to the steep learning curve, but there’s still a huge amount of things that can be done to modernize the backend.

-brady

#17

Could we include Laravel in the code base and instruct new designs to be implemented there and create a migration path from the old code base into the Laravel framework?

The work can be divided up among volunteers much like the MU stuff was done.

I think it would be a great way to get the code out of the technical debt that it is in and start really building a new better future for OEMR.

I have seen posts from other people that want to contribute don’t know the old code base. I had an experience with a person that spent 2 months trying to make a minor change to the Weno but couldn’t figure out the old coding style. It took me literally 15 minutes. But I have taken the time to learn the old stuff. The world is leaving OEMR behind if we can’t get out of the rut that we are in.

#18

Most of the thoughts in Discussion: Introducing an MVC framework are still valid except more form factors and demands for more inter-connectivity.

That was in 2016 as a followup of a 2013 thread.