There isn’t too much activity on the subject, but I’m thinking of creating a shopping cart experience where the sub apps (essentially a no product shopping cart) can be distributed to users on paid plans.
How do updates on sub-apps look or function?
Do they mimic a main app’s code?
Any input on how this is structured or use cases would be good.
I trial tested the sub-app feature for 30 days last year. At the time, this is how it functioned:
You can ‘push’ a new sub-app from the primary app any time. This new app (which takes up a slot in your limited quantity of private apps if you marked it as private) has a dev URL and you can later assign a custom domain name, SSL, and other site-specific settings. In my case, I was launching each sub-app under a subdomain of the primary app.
Users in each sub-app are completely separated from your main app. This means users would have to sign up separately for each new app. Updates occur in your primary app automatically (unless on a dedicated or custom hosting plan) and you can then ‘push’ those updates AND all your app edits to all sub-apps at once. This can take some time if you have a lot of sub-apps but it is still fairly quick. If you make changes to a sub-app’s core functionality that is paired with the primary app, you will lose that customization upon pushing the primary app code down the branches of sub-apps. So, any changes you wish to make in your app need to be made to the primary app. I rarely found myself editing sub-apps.
One problem I ran across is that the setting up of custom domain/SSL is all manual and you must enter new plugin API keys manually. This really should be something you could setup in a workflow, and I’ve tried reaching out to support before without a response. Automatic creation of sub-app, subdomain DNS, SSL
Primary app allows users to re-sell subscriptions to content that is privately stored. We use the primary app dev environment (…/version-test/) as an ‘alpha’ staging area, and treat the primary app live environment as our ‘beta’ staging area. This allows us to fully test out how each sub-app will ultimately function. Each sub-app is a true replica of the primary app branch (aka multi-tenant). After I push an app from primary.yourapp.com to subapp.yourapp.com, I go to the new subdomain and I see exactly what I would see in the primary domain except I will not have any database information from the primary app available to me (the DB itself is empty upon replication, but the structure is still there). We created a data app (ie data.yourapp.com) that can store temporary+transferrable data between apps or us. Meaning, rows of data that we need in all of our apps are imported manually upon creation of a sub-app. This is pretty easy as you can export + import in a CSV dump.
One big challenge I’d love to figure out a solution for is how we can more easily push updates from a master app to a sub-app while preserving the customizations of the child app that a customer may request/pay for. Could there be a way to somehow compare the underlying code pre and post update and then inject any customizations that may have existed previously that don’t exist anymore on the updated app?
That’s what I use the App Connector plugin for. I have created a sub-app on a subdomain (data.mydomain.com) where I store data I’d like to have available on all of my sub-apps. As for changes to each unique sub-app, you can make many adjustments to the workflows in the primary app editor so that certain functions are available to each user account or users of a sub-app. I’d say build out an “available features” workflow that limits what adjustments people can make to the app based on certain variables set on their user account.