I’ve been using Bubble over the last week trying to build a prototype project management SaaS.
I’ve been thinking about how to limit end-user access to data.
As this is multi-tenant product(that is there will be multiple organizations or teams creating accounts), I don’t want organization A having access to organization B’s data and vice-versa.
I’ve been creating fields in my data tab for each type of thing that can be created, example projects, threads and comments, so that each comment has one thread, and each thread has one project. But I’ve been wondering how best to limit who sees what.
Is it best to just create a field in my data types that is a list of users; where the project admins can assign members to the projects. Or should I do so differently?
Without going into details about your setup, limitation of user accesses is normally (and generally) set in data>privacy. There you can define what users have access to.
If you need a more complex setup, it might be added through custom states etc., but as said, without going into details about your setup. Check the privacy tab out.
To supplement @jonaspalmqvist’s take, there are things you can do to limit access to data, but I don’t know that what can be done in Buble is considered multi-tentant.
Typically, multi-tenent requires a separate virtual database (I believe) so that access to other organizations data is maintained not just by code, but also by physical access to the database. This way, if you make a mistake with the code and forget to put a constraint on an output that only allows members of Organization A to view data from Organization A that the database still only displays day for Organization A since that’s all it has access to.
Anyhow, this is my understanding. Perhaps others can chime in about whether they’ve been able to build multi-tenant applications and, if not, what they’ve been able to do to limit access to data to other organizations and market / explain their solution to potential customers.
I too am faced with a similar problem and I’ve given this a lot of thought.
Wrong:
Keeping each Tenants data is the same database would require adding a “Company” field to all Things (Files). AND any time data is referenced, every Search (data access), would need to have the additional condition on that “Company” Field. This would make coding extremely complicated AND considering that Bubble does not currently allow the definition of multi-segment keys, may even be impossible.
Right
So… I’ve decided to develop my app as a single Tenant SAAS, (much easier), using it as a proving ground. Then once I know everything is right, I’ll upgrade my Bubble account to the Team plan, which includes the use of Sub Apps.
@sridharan.s, you don’t necessarily need to always keep it in separate DBs. That is certainly one way, and even a great way to keep data secure. Probably one of the best ways. But if you follow this link from IBM you can see there are multiple ways to organize multi-tenant SaaS applications. Certainly what I’m thinking of doing is the cheapest way but also the riskiest and most complex in the data application layer. While your way would be easier in a security sense.
Hey @Townsend, thanks for chiming in. I don’t think you would need to add company field to everything. After reading that IBM article, I realized you could potentially create a table/data type in Bubble called Tenant_ID. The fields could be 1) Tenant_Name, 2) List of Users; of course the limit is 1000 users (more fields can be added, but I think these are enough for the explanation).
Now you only need to add the Tenant_ID to the Projects_Data table. You can set a constraint when accessing the data that the current user is part of the list for that company/team.
The downside is that you can’t limit members to only certain projects within an organization with this setup.
Also, Bubble does allow you to set multiple constraints when accessing data. Isn’t this similar to multi-segment keys?
Here is my problem @Townsend, I think your totally right about using the Team plan’s sub-apps being a much better route to limit access to data. It’s just that when you’re in my position and wanting to validate a prototype, I’m not sure if I can afford the price tag right now. It is a huge cost.
In case it helps. I think the core of my SaaS will be similar to the product Basecamp.
Now I’m not building a replica of Basecamp, because my target is more niche and has more specific requirements. But like them the market is comprised of thousands, and potentially millions of small organizations/businesses that won’t necessarily be generating huge amounts of data to be stored.
So the core of my app would be a project tracking system, and any larger files that need to be stored, and shared with team members I want to save to an AWS S3 bucket.
I hope that helps to give a better Idea of what I’m doing.
In this scenario, from what I gather based on the advice from others who have experience, doing multi-db is overkill for this kind of SaaS. As the number of tenants is in the thousands (if the product takes off), but the generated data amount is small per tenant. Ex. 50-100MB with 10,000+ tenants. This data amount is excluding the user uploaded files of course. But these aren’t being saved to the database anyways.
Excellent point there @ilham.hafizovic!! Since each user would only be active in one Company, most Things (files) could be referenced by the User’s data.
ALSO: If it is true, that using multiple constraints, forces Bubble to create a multi-segment key… that’s MAJOR!! As this makes using complex data structures possible. (Though, I’d like a confirmation on that from one of the more experienced users.)
But what’s this 1000 User limit you speak of? I’m not aware of this.
Oh! Yes, I see you 2nd note. You say you want to be able to scale to, “10,000+ tenants”. I myself like to look at these projects in stages.
You have a idea: a new concept that you feel could go over big… Using Bubble allows you to quickly develop and prove your concept. If you don’t plan on charging each tenant, then once you get a good working model going, start a Kickstarter campaign.
Also, if your idea is based on a new business model, spend a $100 and apply for a Provisional Patent. (There’s a good course on this over at Udemy.) It will make your project much more attractive to potential investors, (even if you never follow through and apply for the full patent.) Which makes first round funding much easier, (getting to your 10,000+ tenant goal.)
Investors which you’ll need in a best case situation. As in… when your app with it’s 10,000+ Tenants and 100,000+ of users outgrows Bubble. It happens all the time. Twitter started out with the RAD platform, Ruby on Rails. They quickly outgrew that.
Thanks for the advice. I’ll certainly look into the Udemy course, wasn’t aware it was available.
As for the 1,000 limit. I found this explanation in the full reference here.
List of things
In many cases, you’ll deal with list of texts, numbers, things, users, etc. This lets you manipulate these lists. Currently, lists are limited to 1000 items; trying to add additional items will result in an error message.
As I understand this, if you make a field on a thing/data type as a list, you can only add up to 1,000 unique items into the list. So in my example, that would be 1,000 users per company. For my use case this is more than enough. I don’t believe most of the tenants I have will ever exceed something like 20-30. There are cases of 50+ employees but rare.
Just to re-iterate from @jonaspalmqvist, the Privacy tab is supposed to provide authorization rules on data level, so that you cannot by mistake allow users access to data that is not their own. Creating sub apps is not the way to go.
I have found it very straight-forward to use this for single-user systems, but I ran into problems with organizations if you have more than one data type you want to protect.
Hey @soeren, Thanks for sharing your experience. This is actually what I’ve been worried about. I did try to implement some restrictions in the Privacy tab but I was having difficulty; I’m not sure if they were similar to yours. This is why I was asking this question and thinking of alternative methods such as the one I have written about and researched.
I’ll try again, see what I can come up with. Perhaps the issue is in my way of designing the data tables. I’m not sure. I’ll see.
The tricky part about patents is the Claims. Be careful. If you go to a patent lawyer, they will tell you the more claims the better. Better for their fees. More correspondence with the patent examiner. Again, more attorney fees.
You want to boil down you claims to the fewest possible. The more claims you have the easier it is for someone else to file an improved version. When only the essential claims are listed, it should impossible to change any one without destroying the concept. Good luck.
True. But compared to the alternative of actually coding this even with the help of a framework, I think what Bubble has achieved in allowing us to do in the same amount of time is awesome. So I guess it’s a good problem to have. We can spend more time focusing on the more important parts of our apps/services.
Sounds like we are faced with a similar problem. I agree here: [quote] Just to re-iterate from @jonaspalmqvist, the Privacy tab is supposed to provide authorization rules on data level, so that you cannot by mistake allow users access to data that is not their own. Creating sub apps is not the way to go.
I have found it very straight-forward to use this for single-user systems, but I ran into problems with organizations if you have more than one data type you want to protect.
[/quote]
As for whether or not Bubble can handle a true multi-Tenant data model, without having to move to a Team Plan, the only way to know for sure would be to get a clarification on my earlier point.
In theory, this makes sense, but I don’t think this has ever been done before. That is… creating a multi-Tenant application without using sub-accounts. Some day… maybe. But from my experience, when learning a new platform, starting small and subsequently creating bigger and bigger projects is the surest way to success. There’s nothing worse than attempting a massive project and suddenly finding yourself at a road bock staring at a sea of spaghetti, desperately seeking some odd work around.
And If by chance you realize your model needs to be altered, as is often the case during development, it is MUCH easier to do on a single Tenant application. My advise: start small, test the model, build a user base. Cost restrictions that now seem insurmountable, just melt away once you get some real momentum under your belt.
Also, even with a modest degree of success, you may be forced into a more expensive Bubble plan anyway. And… I’m sure the more people that start using sub-systems, the more flexible they’ll become. There’s already a plugin that allows one Bubble app to talk to another.
It always helps.