(Is it a best practice to create a shared custom_app (like a base app) and let other custom apps extend from it?)
Hi everyone,
In my use case, I have an app A which is customized differently for each client — resulting in versions like A1, A2, A3, etc. These apps are all based on Frappe v14/ ERPNextv14, but when I want to upgrade to Frappe v15/ ERPNextv15 (to use new functions or APIs), I would have to update all variants (A1, A2, etc.), which is time-consuming and error-prone.
To solve this, I’m thinking of creating a shared app B that contains the core logic and common functions as midldeware. Then, each client-specific app (A1, A2, …) would be a lightweight extension of B.
This way, when there’s an update or an upgrade needed, I only need to update B.
Is this a good approach in terms of architecture and maintainability within the Frappe/ERPNext ecosystem?
Would love to hear if anyone has implemented something similar or if there are any caveats I should be aware of.
Thanks!
If your custom app is generic and can be used as-is this makes sense.
You can create CustomApp-A, then create multiple apps like customer-1, customer-2, etc. You would then set CustomApp-A as a dependency for the Customer apps.
1 Like
Hi there,
I manage a few frappe instances, and I do something like this. I have one app that goes on every site, and then some of my instances have their own app for organization-specific logic.
I don’t fully follow why you’d only need to update app B when there’s a version upgrade. Org-specific logic can break just as easily as general logic can. But, you’ll have less code duplication to manage, which is always a good thing.
1 Like
I fully agree that updating only app B isn’t always sufficient — there are cases where dependent apps also need to be maintained. With that in mind, I’m wondering what should a base app ideally contain?. If it tries to handle too much, there’s a risk it may start duplicating functionality that’s already provided by Frappe itself
I believe you can simplify your architecture by designing App A to contain the core logic and shared functionality of your custom app. Then, create separate apps like A1, A2, and A3 that extend or override specific parts of App A to meet each client’s unique requirements through custom hooks or overrides.
Trying to create a generic base App B might be much more challenging, as it’s difficult to determine what should go into B without making too many assumptions about future use cases.
1 Like
For me, there’s not a lot of planning to these apps, and that’s pretty much the point.
If I need something that isn’t in core, I put it in an app. If it’s something that seems likely to be useful for multiple companies, I put it in the base app. Otherwise, it goes in the app that belongs to the company that needs it.
Once in a while I’ll refactor to clean up code, but the whole idea here is rapid deployment. If my goal were something coherent and polished, I’d be looking at making a pull request, not an app.
1 Like
In your approach, do you often encounter situations where functionality or modules end up being duplicated or overlapping across different apps due to specific use cases or business flows? I’d be really interested to hear about any challenges or edge cases you’ve faced while maintaining this kind of architecture.