Large App or Multiple Apps with Dependencies

I have an app that has now become quite large. The app consists of a ‘core’ which every user will need and various ‘modules’ which some will use and others will not and should not be able to use.

It has about 30 tables and probably about 60 odd forms plus a fair chunk of server modules.
Some tables are simply reference tables with minimal data but used by every ‘module’, others are large data tables with lots of linked rows and used by a few ‘modules’. At the moment everything is in one app.

After reading some great posts about app structuring (such as this - thank you @AWSOM) I am trying to decide what the best approach is with regard to using dependencies or not.

Would splitting the app into a ‘Core’ with navigation and having it load in the required ‘modules’ be beneficial? What are the pros/cons with this approach? What are the impacts on data tables other than needing to be shared?

This post suggest that this is the way forward

Any suggestions/comments would be appreciated.

1 Like

I remember reading that it was possible to build an entire suite of apps, and shuttle the user from one to another, as long as the apps shared a Users table. Depending on how your app’s functionality is grouped together, this might be one way to divide and conquer.

Edit: For example, if one sub-app requires certain privileges, and an insufficiently-privileged user tries to switch to that sub-app (by hook or by crook), then that sub-app’s server-side code could simply log them out, denying them access.

Edit 2: This might also lead to moving some database tables off into corresponding sub-apps. Note: If an app is supposed to enforce foreign key constraints, on any tables, Anvil won’t do it for you. Your code will have to do it. And that code will need access to every affected table.

For example, when an app deletes a purchase order (e.g., because it has been cancelled), it should probably delete any detail records (e.g., in a linked table), too.

1 Like

Hi Rick,

My situation is very similar to yours (at least when it comes to my main Anvil project :blush:). I’m in the process of refactoring a large monolithic Anvil app into a main app with a number of sub apps brought in as dependencies. For me, this approach to separation of concerns by “app decomposition” works well – and greatly increases my ability to reuse code for other projects.

I pursue a structure something like this:

Main client-side app

Server-side app (with client-side Python modules that call server functions, therefore also a dependency. This allows for caching and keeps things clean).

App for custom components (dependency)

App for feature 1 (dependency)

App for feature 2 (dependency)

App for styling (no Python code, but with css-files brought into the other apps via Native Libraries)

App for db (a no-code app, only showing the db – shared with the other apps)

The “app for db” is really just to be able to have data tables open on a separate screen, so that I can see what’s going on in the db during testing (remember to refresh, e.g. by switch to another table and back to see any change between runs). In general, I find it easier to navigate my project when I can have each sub app open in a separate browser tab (or sometimes in VS Code, if only Python code).

On a personal level, I also find it easier to execute plans when it’s about “nailing one app at a time” rather than a seemingly less specific corner of a large app (although it technically should not make a difference).

All the best,

Rufus.

2 Likes

This is an interesting idea, particularly the DB app! It would make coding a whole lot quicker because you get instant feedback while debugging. Very cool.

1 Like

Also very interesting. I will have a think about how this will impact the app because for the most part, we almost never delete rows as they need to be archived or updated instead. Thanks for the feedback

I also use a very similar structure (Cloning apps and data tables for Production and Development Apps - #3 by owen.campbell) which gives me a lot of flexibility for testing.

e.g. If I’m doing some work on a server function, I can clone my UI app, change the dependency of the clone to point at the master branch of the server side app and test my new function in isolation.

1 Like