Persisting user data via external DB - ill-advised?

’d like to treat Bubble as a pure front-end that accesses (virtually) all data via API Connector to an external API service. The sole exception would be using Bubble’s native user authentication/state management (not my own requirement, but sounds highly suggested in the research I’ve done). Even so, I’d like to persist user data to my external DB for such use cases as switching out the web frontend in the future or running data analytics.

Is this approach outside the bounds of typical Bubble.io applications? I hadn’t realized how coupled Bubble is to its own user management until really looking under the hood…

1 Like

The whole reason Bubble is nice is cause of the tight integration between frontend and backend. Stuff like the realtime database allows for changes to display live on the users browser without refreshing the page would be lost once you use the API connector. Lots of other benefits probably that I am forgetting about.

It can be done of course, a lot of people use external databases, and those would come with their benefits as well like better bulk data management. But lose things like easy to manage privacy rules.

You might want to take a look at weweb.io , they are a front end no-code builder that builds on Vue.js, so you can export the usable code if you ever have to. Their approach is more “bring your own backend”. I have no used it personally but did mess with it for a bit.

3 Likes

Moving the database away from bubble but keeping the signup/login on bubble is not very conventional.
Authentication should generally be on the same place as the rest of the database due to privacy rules.
How does the database server know whether a user is authorised to view/modify the data if the user entry is not in the database.
If all the data in your database is fully public then this does not apply, but this is rarely the case.
There are ways to account for this and to let the database know about privacu permissions, but it would probably be more work than just moving auth to the external database alongside the rest of the databse tables.

1 Like

Thanks for this context – it basically confirms that user management is best performed within Bubble itself.

There’s a wide number of reasons why we’d highly prefer to persist data externally, and we’d be willing to forgo niceties like auto-updating UI to achieve this. One possible alternative towards this end might be to use Bubble as a pure front-end pass-through – we wouldn’t use any of Bubble’s native user management/functionality and instead implement authentication and data persistence on the backend. In such a design, would Bubble be able to properly handle/persist application state via workflows?

What do you mean by this :sweat_smile:

I don’t think there is a problem using Bubble only as front end + user table. The user table is needed for Current User. Don’t worry about not able to use privacy rules on Bubble. In a proper external backend, you can limit the returned data field to those that the frontend needs and restrict the returned data allowed for the current user. That is what traditional coding has been doing. Bubble privacy policy is just a way to restrict the returned fields. It is a hack; it has a lot of limitations. You get better privacy using a proper external backend.

handle/persist application state via workflows

I’m referring to the functionality within workflows where downstream steps in the workflow can refer back to the values in upstream API Connector requests.

Oh yes all your actions would be API calls to your external database, and if your API responds with values in subsequent actions you can refer to the result of that API call

Yes thats true, but proper backends you will likely need authentication and role-based access to data; your endpoints need to be secured. You cannot just return the ‘appropriate’ data to requests arbitrarily. You need to make sure that the user requesting the data is actually authorised to view/modify the data, and a user table on the actual DB helps a lot here. When @tylerboodman and I mentioned privacy rules, we didn’t specifically refer to Bubble’s privacy rules, but general authentication and privacy.

Keeping everything on Bubble is by far the simplest solution and you get a lot of benefits + speed of development. Externalising something like image storage or some specific tables to benefit from functionality from another DB service can be useful. But if you decided that for whatever reason you need to externalise all data, Bubble can be used for this too, but you should probably externalise the user table as well.

My biggest recommendation would be to make sure that as many API calls as possible are executed client-side, and avoid forcing Bubble to route it through the servers. Not only will this be faster, but it will also not cost you any WUs. API calls through the server cost WUs. Adding calls - Bubble Docs
You won’t be able to do this for all API calls due to security reasons and having to put some APIs in workflow steps, however for data return APIs you mostly will.

As a side note, whether Bubble is actually the best front-end only builder is up for debate and dependent on your project/team.

as many API calls as possible are executed client-side

Interesting… in my reading of documentation, I haven’t come across any citations of an ability to make pure client-side calls using Bubble. This functionality is separate from the API Connector, right?

Nope its a functionality of the API connector. Check out the above docs.

There are some real heavy limitations, mainly that there can be no headers, calls cannot be used as actions, and data calls cannot be included in workflows ran on the server (this includes some frontend workflows too). You’ll have to handle authentication in a parameter of the body or the URL, which isn’t ideal. But if most API calls that populate data on the page are set up to bypass the server there will be significant speed increases and cost reductions.

The plugins (xano, supabase, etc.) call the DB API directly. They don’t go through API Connector.

If you build the backend API yourself then the answer is to have a token that persists and is refreshed frequently in the users browser. User logs in with username and password. API gives back a token. When you fetch or update data through the API Connector, pass the token and have the API check the token each time. No Bubble Users required.