Healthcare is the first module that is entirely contributed by the community(Earthians & other members). Later, Healthcare module is merged into ERPNext. Last year, @rucha_mahabal cleaned up the healthcare codebase and added some new features.
Now as ERPNext grows as a huge monolith, there is a need to separate out modules into separate apps. Today, even though a lot of companies use a small set of features, we are shipping entire ERPNext. In addition to that, separating the modules into apps will provide flexibility on maintanance and release of new features.
Few weeks back, we have started with separating out healthcare module into a separate app. Now healthcare module is completely removed from the develop branch of ERPNext.
How does this change affect you?
If you are not using Healthcare module, this change won’t affect you.
If you are using Healthcare module, it will work as is in version 13. All bug fixes and security fixes will be backported to version 13 as well.
However, when you upgrade to version 14, you have to install Healthcare app.
If you want to raise any new issues or pull requests, please raise them on Healthcare repo instead of raising them on ERPNext.
This feels like this is going in the Odoo direction, unfortunately. This could mean that ERPNext could become Freemium. Which would be unfortunate… But then I am just speculating.
I used healthcare before I think this is a good thing, since a lot of codes in erpnext that we don’t need if we are not using Healthcare. more clear and clean code, less dependency. and pr can go to a separated app not depending on frappe or erpnext .
I think this is a development reason, not a odoo or anything else, it still open source frappe still open a lot of projects they use, i didn’t see any open doing what they are doing and believing in it . i saw these feelings 7 years ago, and here we are frappe is still open source one of the most beautiful frameworks.
Great respect for Frappe , and all the contributes and people in the community
@Not_a_countant We, at Frappe value open source and building great products. Also, open source is not freemium. You can read this blog post by @rmehta to know in detail.
I think there is a fundamental misunderstanding about what “monolith” means here. Absolutely nothing being proposed here violates monolith design.
The point of a monolith application is not “all the code ships together”. To the contrary, apps have been an important part of ERPNext from the very beginning. In that regard, nothing is changing.
Instead, what defines a monolith application is tightly coupled components, capable of assuming the existence of each other. The Sales Order doctype, for example, assumes a great deal about how the Item doctype works. If the Item doctype were to change or disappear, the whole thing would fail inelegantly. In another, non-monolithic system, components would need a way to declare their functions and interfaces. This is what you see with Drupal’s plugin architecture, for example.
From a structural standpoint, that’s the difference between modules and domains: modules assume the existence of other modules. Domains also assume the existence of modules. Nothing, however, assumes the existence of domains. If the Education domain were to suddenly disappear, people using it would lose that functionality, but nothing else would break.
This makes domains (alongside things like integrations and country-specific code) perfect candidates for apps. There are significant advantages to doing it this way. Separating domains into separate apps gives maintainers more flexibility about release cycles, and it simplifies the update process for users who don’t need the code. As ERPNext’s code base gets increasingly complicated, streamlining this way becomes increasingly important.
(Separately, suggesting this is a step towards freemium is in my opinion unjustified and unfair. For years, Frappe Inc has had every opportunity to close off the source code in whole or in part, and for years they have chosen not to. I see no good reason for cynicism.)
Thanks @peterg you have illustrated this very well.
The reason of the change is also that for many years we had like 3-4 engineering doing everything. If we have to make each “product” inside ERPNext excellent, they will need their own identity and ownership. Hence the decision to end the monolith. All of the new “apps” will be designed such that they can all be installed on the same site and there will be no loss of functionality. From the user point of view, it won’t make any difference, just that they have to install the apps separately. Will come out with a detailed post soon on this.
And yes, domains and integrations are the lowest hanging fruits.
It means that Frappe people are committed to improving the Frappe based product based on feedback from the community. Monolith was good a decade ago. Today, it means you are a dinosaur or a woolly mammoth. As I pointed out previously, monolith and Frappe is an epic mismatch. Frappe is good for microservices. Separating domain functionalities into separate software services is the best idea.
ok, makes more sense now. I am agnostic to mono or non mono. I was just concerned about the path it might go on. Seems like it is engineering & management driven rather than a CFO led decision.
You are correct. This decoupling of monolithic domains into microservices apps is more of an shift from the prior mindset of “waterfall” type software architectures to the more recent “agile” way. The technology is already in Frappe, and as RMehta mentions, there is no loss of functionality. I foresee this shift from ERPNext “domains” to Frappe “apps” will greatly impact (improve) the way CI/CD DevOps is done in the Frappe world.
I am very happy that Frappe people have listened to and responded positively to the Monolithic vs Microservices discussion.
For me, the next phase that would massively improve Frappe’s technology stack is to move from SQL (MariaDB & Postgresql) database to NoSQL (MongoDB). The legacy SQL databases are just too slow, too limited, and too fragile compared to NoSQL database where high availability and scalability (both horizonal and vertical) are simple tasks to do using replication and sharding.
Thanks @peterg , so precise! I’m also quite optimistic the separation will also help bring in more contributions from domain experts and collaborators.
And thanks @rmehta , I acknowledge - there has been much assimilation of late and I’m sure there’s going to be more collaboration with Rucha, Anand and other community collaborators on the Healthcare roadmap.
BTW, let’s not forget a big shout out to the devs at frappe, especially @ChillarAnand , whose efforts were instrumental in making this decoupling look, and work so easy for ERPNext users. Thanks!
Will this also mean that the release schedule of Core Frappe / ERPNext vs decoupled apps can be different? So the Core framework and apps could develop at a steady pace without gaining too much weight (and now actually getting way slimmer )?
I think this would be a huge benefit going forward, provided that the API stability rules of the core framework / core apps are clearly defined.
