Forum Academy Marketplace Showcase Pricing Features

When To Split App

Just looking for some advice here. When do you decide to split an app into two or more apps that share a single database? The app that I’m building out has internally-facing elements and externally-facing elements, so I was considering splitting my app into internal and external components that would share a database. Is there an organizational efficiency in doing this, or would you recommend keeping them in the same app?

I have done this - split an app into two. It turns out to be a bit of a headache in my case.

  • You can update one app without it impacting the other
  • Using the Bubble App connector is straight forward
  • It does reduce the size of the app
  • It makes you security story easy to explain; the users of this app can only access this subset of data via these API calls


  • You can’t share the DB in the sense of having both app using the same DB, you need to have an API connection from one app to the other to read the database, meaning
  • you lose the “autoupdate” feature of Bubble - if the underlying data changes in the API connected app you need to re-fetch the latest data. (major pain if you need to have data synced)
  • you end up with many API’s, its difficult to keep track of what API is used for what purpose
  • you pass everything now by Unique ID and you can’t do the x.y.z access sub attributes, especially painful with Option sets.
  • I found the Oauth API authentication thing (as opposed to token authentication) just added too much complexity with having the users in another system.

I thought it would speed the app up, ie it is now a smaller app - it hasn’t really made a noticeable difference I believe.

I would only do it again if I designed it from the start so that each app had their own database with just their specific data, so that the API calls were minimal and I would ensure option set usage is minimal - preferably zero between apps. I’d point out that this app has a huge of amount of functionality and is complex just from scale.

If your apps do really share database tables it is probably not a good idea to split it. If you apps shares a database, but not tables I’d consider splitting the app.


Sharing tables vs database - does sharing tables mean like a joining table?

What I mean by sharing tables - is literally two apps/pages/etc that literally access the same table (and fields in those tables) . Nothing technical :slight_smile:

Copy. So if you have 6 things are three groups of 2 are used strictly for 3 diff pages (1, 2 page a), (3, 4 page b), (5,6 page c) then you could split into 3 apps but if any of those cross just do one app

Exactly. Then splitting the app will be easy - as there is very little (if any) database access between the apps. When you have data being access by one app (B) from another app (A), updated in that app (B) and then being persisted back to (A) … you start to spend more time sorting this out, than the benefits of the split app. (is what I found)

In examples where the persist from B back to A isnt necessary and it’s one way or it’s on a one time basis each action - does that change your opinion on usefulness of seperating apps?

Building on Kevin’s question:

In the case of an e-commerce website, where there are shared database tables, but the flow of information primarily goes from App A (customer facing - place order) to App B (employee facing - receive order), would that be limited enough to merit splitting the app?

1 Like

@kevin16 If it was readonly from B to A - and that data didn’t change so frequently that you didn’t need to keep a “fresh” value on B then sure - it would just be like any API. You can imagine the extra work required if …

  • Get Data from A to B
  • Data on A changes
  • How do you know when to update B for a fresh copy of A?

Same sort of answer @ladd0393
It would be a nice story to say AppA is only access by Customers AppB is only access by Employees - nice and clean - and a strong story. But once you are coupled by API’s between the apps you lose a lot of the development efficiency you have with Bubble of being able to willy nilly change field names, table names. Now you have to keep to end points in sync. (which is totally do-able just a bit of friction in the development process)

I would start on paper and figure out exactly is the list of API’s between the apps.

For example I just spent the morning basically replacing what I had implemented with the Bubble App connector with custom endpoints that flattened the objects being returned so as to reduce the number of API calls on App B - as performance was terrible. Once you are coupled with API’s you need to think about how many API requests you are making - when it is local DB these seem to be cached and fast.


Thank you so much Lindsay!