I’m having trouble understanding why you’re developing multiple separate apps instead of leveraging ERPNext’s ability to connect and exchange data between modules. Can you clarify the purpose of Frappe Books, Desk, CRM, etc., in relation to ERPNext?
1 Like
@edardev they serve different purposes , I could use frappe books or wiki withour the need of erpnext itself . erpnext is just an app built by frappe . there are many and you can build your own . it does not make sense that everything is smooched into one directory .
1 Like
Maybe not Frappe Books (a standalone accounting app) or Wiki necessarily, but it would make sense to have CRM and Helpdesk tightly integrated with the ERP, since much of the data could be/should be shared: contacts, emails, phone numbers, customers, projects, support issues, etc. If I’m chatting with a customer who’s placing an order in the ERP, it would be nice to know if they have related opportunities or open trouble tickets without needing to copy & paste a name into another app.
It’s understandable that different apps serve different purposes. It’s interesting that you can use Frappe Books or Wiki without needing ERPNext itself. Considering ERPNext is just one of many apps by Frappe, why not enhance and integrate them around the core product? You could develop a desktop or online tool but ensure it’s in sync with the ERP system.
Most of the users on this forum are not owners or maintainers of Frappe Framework, ERPNext, or Frappe Books. We can make guesses at their reasons. But they are just guesses.
First, I suggest watching this video. It explains a little why the monolith was abandoned.
https://www.youtube.com/watch?v=207S3celYqA
My own thoughts:
-
Maintaining a single, gigantic repository that does everything (ERPNext) is very challenging. And often painful.
- Developers and Maintainers must be extremely careful about cross-module dependencies and breaking changes.
- Larger repository = more code to review, lint and maintain, more disk space, more difficult to make sweeping changes (e.g. introducing a new query builder)
- Users of ERPNext many get dozens of modules. Many of which they’ll never use and are just “clutter” to them.
- “Make each program do one thing well”
-
Frappe Books, CRM are licensed AGPL. ERPNext is licensed GPL. The AGPL license can be more advantageous for Frappe Technologies., if necessary.
2 Likes
Thanks Brian, just a few thoughts on the flip side:
-
I would think disk space for code these days is a trivial concern, and if you have multiple apps, some with overlapping functionality and database schemas, don’t you really have more total lines of code to maintain overall vs. fewer?
-
Regarding your example of developing something like a query builder: if your modules share the same code base, wouldn’t the advantage be that the query builder is now available across all the modules with a uniform UI, instead of writing a query builder for each app?
-
If a primary concern is that a user screen is cluttered with menus and module access they don’t need, wouldn’t the simplest solution be to hide access to the unneeded menus and modules, so from the user’s perspective they don’t even exist? And down the road, if the user wants to add inventory management, you can just activate that feature instead of having to install a brand new application?
I guess my real question is: is ERPNext, as we know it, going to eventually disappear and instead become all separate apps down the road (CRM, Helpdesk, HRMS, IMS, OMS, PMS, etc)?
There have been a lot of conversations about monoliths and modules over the years. One thing not acknowledged enough, though, I think, is the fact that ERPNext has always been multiple apps. At least as long as I’ve been around, it has never been possible to install just ERPNext. ERPNext is an extension of Frappe.
A lot of things that people call ERPNext are actually features of Frappe. The uniform UI/UX, for example, has never belonged to ERPNext. That has always been Frappe. Shared functions like authentication, query builders, permission systems, workflows, document sharing, printing, etc., are all 100% Frappe. ERPNext is a relatively thin layer on top of that. (An extraordinarily complex layer, to be sure, but thin.)
Put differently, I’m not sure what – if anything – is really changing. A bit of encapsulation is almost always a good design principle, and separating things into apps makes release planning quite a bit easier. These apps will never be truly separate, however, because they all just extend the structures and interfaces defined by Frappe.
2 Likes
I’m not sure what – if anything – is really changing
Not sure I agree with this 100%. ERPNext has traditionally been (mostly) a single app, based on the Frappe framework.
By splitting ERPNext’s functionality into different apps like CRM, Helpdesk, etc, each with their own set of tables (doctypes) and a lot of specialized UI for each app instead of using the traditional Frappe UI, then the primary advantages of having an ERP–that is, one set of shared data that all modules can access directly and a consistent UX that can be easily customized through a centralized process–are nullified.
Am I missing something here?
At my organization, we use a large number of custom doctypes to manage some fairly complicated workflows. It was getting cumbersome, so a few months ago I refactored everything and split our one very large app into two separate apps. I don’t think a single person using the system even noticed.
I don’t know if you’re missing something, but it does seem like we have some pretty different experiences with the architecture. This, for example:
…is exactly what Frappe’s desk is to me. All these new doctypes in these new apps can still be accessed that way, same as it ever was. The new Vue-based interfaces currently being explored are an additional layer on top of that.
Maybe we’re talking apples and oranges here?
With your custom apps, you can make them dependent on ERPNext and access the ERP’s doctypes, so the data can be shared. And if you stick with the standard Frappe UI and its forms, then your apps will be responsive on mobile devices and can be customizable/translatable just like the rest of ERPNext. So for all intents and purposes, you can make your separate apps an integrated part of your ERPNext system.
But by design, these new modules (CRM, etc.) are independent of ERPNext, so most of the data isn’t shared. And with their unique UI, the customization process is different, they’re not really usable on mobile devices (yet) and internationalization is still in progress.
I appreciate that the custom frontends might not be for everyone. I don’t personally have much use for them either. But, they’re just another feature that can be used or not. The more mature and more familiar form-based interface is still very much alive and under active development.
I think where we see things differently is here:
I just don’t think that’s true.
I don’t know much about the new CRM app, but I believe Rushabh has said that it will be integrated with ERPNext’s sales cycle. It’s easy to create those hooks, so they’d be crazy not to! Contacts/phone numbers/emails have always been part of the Frappe core, so nothing changes there. Meanwhile, Frappe’s most mature separate app — HRMS — is fully integrated with ERPNext’s accounting, and so are many other now-separate apps: Lending, Education, Webshop, etc.
If the last few years are any guide, I suspect that’s the pattern we’ll continue to see: Frappe will remain a primary interface and data architecture, while ERPNext will become a new second-level “core”, focused on accounting and inventory. A new doctype in a separate app has no less access to ERPNext data than ERPNext itself does, and the maintainers have shown that they’re very happy to share data across app lines.
@peterg Yes, I think you’re correct, HRMS requires ERPNext to be installed, so it’s pretty tightly integrated and uses much of the same database. I would consider HRMS to be part of the ERP.
But the newer standalone modules, like CRM and Helpdesk, don’t require ERPNext. It would be nice if the UI of standard Frappe–and therefore ERPNext–eventually converges with the UI of the standalone apps, so everything is consistent and customizable in the same way. Likewise with the databases, but my understanding is that except for a few core Frappe doctypes that you mentioned (like contact & email/phone doctypes), the data is not currently shared.
To illustrate my concern, this is a fairly recent post from another user of this forum:
Last time I looked at the Helpdesk product, it had the same issue, unique and no integration with customers in core ERPNext. Made it useless to me
Besides the lack of integration, I also worry that concurrent development of standalone products will pull resources away from enhancing the core Frappe framework and ERPNext products.
Of course Frappe is a private company, and can choose to put their resources wherever they want 
1 Like
For example, there’s a 100% desktop offline-only accounting app being developed independently of Frappe/ERPNext. This app has no connectivity to the database or APIs. Very nice user interface but no integration with other apps…
I would not be surprised if this were the case. It’s certainly crossed my mind these past few years, and the minds of others.
Still, I have zero hard evidence to support this. I have no contacts at all at Frappe Technologies. I expect they’ll do whatever is in their own best, self interests. Just like anyone else.
Luckily, it’s all open source. So even if Frappe Technologies wins the lottery, decides to go colonize Mars, and never touches ERPNext again? 
No worries. Others can carry on where Frappe left off, if they choose to.
4 Likes
An important question about the GPL → AGPL transition is not being addressed by Frappe: What happens if one wants to mix AGPL and internal apps in a single site?
It is unclear whether the viral aspect of AGPL requires the release of the source code of the internal apps in these cases.
Check this topic for more details:
In my opinion, an AGPL application such as CRM would not override the GPL license of ERPNext, or another GPL licensed app on that same server, because the applications operate independently.
If instead you developed a Frappe application to expand the capabilities of the CRM app, that might be a different story.
As explained in the other topic, the usual boundary for an xGPL license is the process boundary. This is why in the Java world there is the “ClassPath Exception” together with the xGPL licenses which was created specifically to get around this problem.
Exactly! Frappe is releasing apps that can operate independently of ERPNext…except when they’re releasing apps that are deeply integrated with ERPNext. That’s how it’s always been.
I get that you don’t like the CRM or Helpdesk apps, but I’m less clear what previously-existing data integrations feel missing for you now. Rushabh has already said that the CRM app will feed into ERPNext’s quote->invoice flow. I may be misunderstanding, but that’s pretty much exactly how the currently monolith CRM module works now.
More explicit encapsulation will help to solve many of the problems that people have been complaining about for years, but because of how Frappe’s architecture works that imposes no constraint whatsoever on cross-talk. frappe.get_list('My Doc') works the same both between and within apps. It’s all the same data pool, all still accessible from the same unified UX.
Frappe Books was started six years ago, if I’m not mistaken. As a side-project, it seems to have gotten relatively little attention in recent years. That’s what I’m trying to say here: this isn’t a big pivot. Frappe has always had multiple products, operating in the same conceptual space, with varying degrees of cross integration.
1 Like