SaaS Database Structure on Bubble (Will Make or Break Your App)

today we're going to talk through a few things that you'll want to keep in mind as you build out a data structure for a multi-tenant environment in bubble multi-tenant just means that you're going to have organizations come to your app right so these are the primary users and they're going to use the app within their organization only so there's not going to be any data that crosses between organizations because of this it's really important for you to create the right architecture for the data so that things are protected we don't want members of One organization to be able to access data from another organization of course you can create more granular permissions at a user level Beyond this but we're going to take a look at what your options are so you can see what path makes the most sense for your app it's Gabby over at coaching no code apps where we help non-technical entrepreneurs build custom apps to launch their app-based businesses or grow their existing businesses all without coding now when it comes to building out a multi-tenant structure in bubble you actually have two different paths that you can take you can either build everything out within a single application so this is one one database that is shared between all of your organizations or you can use bubble's sub app system which enables you to create independent applications for each of your organizations and because they're independent apps every organization gets their own database so right away we can see a few obvious pros and cons between the two with a single application you're much more responsible for creating the right privacy rules to protect the data from leaking between organizations you have to make sure that every single table every single user is accounted for when it comes to reading data or making changes to data now a single application is much more lower maintenance compared to a sub app because everything is just happening in one application your logic is always going to refer to the one app now let's compare this to sub apps sub apps mean that you have a separate application per organization and because there are separate applications you're going to have separate databases this creates a built-in security right out of the gate you don't have to do anything because when a user logs into their organization's app the only database they have access to is that apps database now of course you can create connections between applications using plugins and API connections but that would be a very intentional connection that you would of course need to be aware of any security around that as well but with that built-in separation between apps a lot of the heavy lifting is done for you in terms of security Now sub apps are higher maintenance compared to a single app system there's more logic that you'll have to consider so that all the functionality Works no matter what application the user is in because sub apps are separate applications they're all going to be on their own domain so that's something that you'll want to keep in mind especially if you have Integrations involved with your functionality there's also a cost factor that you want to consider here every individual sub app has to be on its own individual plan now you do have control over putting sub apps on different plans to depending on the usage of each organization but it is something that you're going to have to maintain long term now I want to break these two pads down a little bit further so we'll start with a single lap structure with a single app you're working on one application which means one database where everything is shared okay so it's up to you to create the right structure and rules around all of that structure to make sure that data is separated properly between your organizations even though everybody is logging into the same app and technically accessing the same database what you want to do here is create an organization data type this is going to store all the top level information about that organization can be their name can be any branding logos colors okay any particular features that that organization should have access to or not if you're going to have like a subscription system for your business model but this data type is really important for creating the right relationships and privacy rules to separate the data as long as all of the other data types in your database relate back to the organization you have everything you need to lock things down you want to pay close attention to your privacy rules and really leverage this in your structure without these rules you are going to risk data leaks between organizations a single app structure makes things really easy to search the entire database there might be cases where you do want users to search across organizations even if it's just you as a complete system admin to gather everything from all of your organizations it's easy to search because it's one single database you don't have to communicate with an external service however speed of those searches can decline if each one of your organizations is adding a high high volume of Records right so you do want to think of it strategically here about the volume of activity and the volume of data that's going to be added to the database not just structurally but performance wise what's going to make sense for you long term now we like to recommend starting out with a single app structure no matter what you can always transition to a sub app structure later on you'll see why in a second so looking at the sub app structure there's a clear difference in the separation between the apps right because we have multiple apps every app has its own database and so naturally things are separated you can't accidentally cross data between your applications now you can share data if you want that has to be done through an API connection there are various plugins that can help you with this but at the end of the day the underlying structure of all of your tables within the app to support your functionality all of the individual tables should still work like a single app right your images need to tie back to an organization your messages need to tie back to an organization your users need to tie back to an organization we actually still recommend having that organization data type so that you can save all of the white labeling details to that organization remember a sub app means that it is derived from primary so you're still going to build out everything all the logic in one application and you're simply going to deploy those changes to all the sub apps independently you're never going to edit your sub apps independently so it's up to you to create the right Dynamic logic to display the right information from a dynamic database to the users in the front end having that organization data type even though we know an independent app only relates to one organization it's still going to be super helpful for creating that white labeling logic privacy rules are of course still recommended for all of the other permissions you need to create in your application especially user level permissions your users may have roles right some users should be able to read data versus edit data versus create data okay so your privacy rules are still going to be very helpful for that because some applications are going to exist on their own domains the domain itself is going to become much more relevant for user access okay so perhaps these are companies where users can only sign up if their email address matches the company domain and that can lead to different functions and flows and data access within the application perhaps the company has guest users that are allowed to sign up but again depending on their domain understanding that they're a guest they're not actually a part of the company they may have restricted access to certain data now with a sub app structure your overall performance can be more efficient for you because each application works independently like I said before you can control the different plans that these apps are on if the usage of an organization is much higher you can put them on a higher plan that has more app capacity and because each application is independent in their database the searches can be more efficient simply because the amount of data is less per app now on the other side of that if you wanted to pull data from all of the applications into one place there's a little bit more work there you do need to create API connections to retrieve that data from those separate applications or if you wanted to go in the other direction if you wanted to make something happen from one central place and push that to all of the sub apps now I'd like to go through a few common use cases for single app structures and the sub app structures keep in mind these are absolutely not the only use cases and you can find these use cases being used in the other system it really just depends on the volume of data that you're working with industry requirements that you're building for some Industries have to have white labeled separate databases and so you're kind of forced to use the sub app system also consider where you're at in your app's development if you're just getting started like I said we usually recommend starting out with a single app just to begin with and you can always transition to the sub app system because the underlying architecture is going to be incredibly similar anyway so when it comes to single applications one of the most common use cases is marketplaces where the end user needs to be able to search across all organization data that has been generated in the application take Etsy as an example shop owners will sign up to Etsy to create a shop and add in their products create listings and sell products on this platform right so the shops are all of the individual organizations but all that data is being housed in one Central database that way the end user right the customer the person who's shopping around can search very easily across all shops for whatever product it is that they're looking for the shops are all hosted on one domain right they do have custom Dynamic pages I should say for each of their listings so things come up in SEO results uh okay and they can share those links easily but at the end of the day they're all on one shared platform they still represent themselves all of the data tied to that shop is unique to the shop their listings their products their transactions their customers notifications all of that information but because the end user needs to be able to do an app-wide search across these organizations it makes much more sense for all that data to be housed in one place now of course you can build a Marketplace system in a sub-app environment especially when it comes to B to B to C uh connections now for sub apps there might be some characteristics of your functionality that could make this decision really obvious for you the first is a fully white labeled experience uh for the domain okay so with a single application everything lives on one domain but with a sub app system because these are independent apps they all have to be on their own domain they don't have to be on a subdomain they can be completely unique domains from one another now a great example for this is if you're building an application for a large organization that has franchise locations and each franchise is going to be on its own domain so you're essentially creating the sub apps for each individual franchise this allows the manager of that franchisor the owner of that franchise to custom their experience for their sub app only it doesn't have to affect how the other franchise owners operate but they're all under the larger umbrella of the organization of the business right the main business this way the franchise data is housed in one independent database that's not going to be crossed with other franchise databases this also works really well for HR Management systems for an Enterprise that is present in multiple countries so for example you could create a sub app for every individual country's subdivision of that larger Enterprise I also like to call out functionality that involves a lot of file heavy features so uploading a lot of files storing them with specific access to files can make a big difference in not just the performance but also the security around this data keep in mind that file storage and bubble apps is something that you'll have a limit on based on your plan you can also increase your your storage size there but again if you have sub applications then every individual organization can have can be on its own plan and therefore you can control the file storage per organization so that it makes sense for their usage now I'm certainly not suggesting that you have to use sub apps whenever you're working with hot file heavy features but there are just some things to consider there you can of course create all of the rules and restrictions you need within a single app environment as well again no matter what path you're going down whether it's a single app system or the sub app system you want to make sure you build out that top level organization data type that's the the key to everything that's going to allow you to connect all the other tables to a single organization record so that you can create all of the rules you need around accessing data properly this type of multi-tenant structure is an application a lot of our own clients build and many of them have started with our free Workshop over at coaching nocodeapps.com Workshop this training will walk you through all the planning no code tools and development strategy you need in order to start building your app so join for free at coaching nocodeapps.com Workshop foreign [Music]

Channel: Coaching No Code Apps

Views: 18,553

Keywords: no code apps, bubble app builder, web app without code, apps without code, bubble no code, no code training, no code tutorials, bubble tutorials, bubble bootcamp, bubble.io app builder, build apps without code, no code movement, bubble.io tutorials, bubble.io lessons, free bubble.io, bubble apps, bubble.io course, no code tools, app business, build apps without coding, saas, saas app on bubble, database structure, bubble database, saas database

Id: o3BDGYHR160

Length: 13min 14sec (794 seconds)

Published: Wed Nov 30 2022