The short version:
I have 100+ apps sharing code via 10+ dependencies.
The long version:
@divyeshlakhotia made a great summary about performance improvement.
I have 100+ small apps, all sharing the same tables, all depending on the same set of small dependency apps.
When I create a new app, I clone it to my computer, replace its
theme folder with the
theme folder of an app called
Standard Theme and push. At this point the new app looks like all the other apps.
Then I add a dependency for each behavior it needs to share with other apps.
For example, most apps need user authentication, so I add the
Users service, share the
Users table from other apps (need to temporarily switch to the old editor for this), add the dependency to the custom component
HeaderWithLogin, drag the custom component on the header of the main form and I can use
self.header_with_login_1.user_permissions() and other methods for the user management.
Another example is the
KeyValueCache, a dependency that I use to store key/value pairs with an expiration date and with other policies. I use it in 20% of my apps, and when I used it, I need to share the
Some dependencies depend on other dependencies themselves, like the
InputBox that depends on the
Validator that depends on
I used to have one large dependency called
CommonComponents, but it was difficult to maintain and it was forcing every little app to have all the services and tables even if it didn’t use them. I also had a few scary moments when I made a little change that broke dozens of apps. So I have split it in 10+ little dependency apps, each doing its job.
I wish each module of Anvil Extras was available as its own smaller dependency: I don’t like to load 20 modules when I need only 3. But the workaround is easy: make your own stripped down version of Anvil Extras by removing the parts you don’t use (I did it for a short period, but depending on the official Anvil Extras is easier and I am lazy).
I have apps that use
pandas and user authentication and tons of other dependencies, and I have apps that work as http endpoints and don’t even have forms, authentication or dependencies.
The bad part of this approach is that I can’t test all in one shot (but, seriously, who tests all ?). One day I might take the amoni road and setup a big test environment for all my apps (but I don’t see that day coming any time soon).
The good part is that I have no performance problems and I can focus on the job of each app without risking to break anything.
Another advantage is that most apps start as a proof of concept prototype, then they quickly become production apps.
Immediately after posting this I noticed the announcement about the self-service package installation… here is another reason to use many small apps: you may need to use different environments on each app