Alternative approach to the Bubble’s recent tutorials for list of things

Another crucial issue - is that they didn’t include tutorials about the privacy stuff.
Many of the apps are without a configured privacy for their databases. That means it’s easy to extract sensitive information, such as contracts, personal documents, etc.

3 Likes

There are a few things we’re tackling and balancing here I’d like to address:

  1. the intent of a tutorial to introduce new people to basic concepts for app building, like: what are data types and fields, how to structure an app, and even how to think logically. The balance here on my end is to give someone new comprehensible information while recognizing there is substantially more nuance to database structure (indeed, a whole career’s worth) than can be covered in a basic tutorial for a non-coder.

  2. getting Bubble’s official documentation up to speed (a constant process for our team). Since, our team has gotten some more documentation around this topic (see @allenyang’s post about our manual: https://manual.bubble.io/working-with-data/connecting-types-with-each-other); and we’re updating relevant tutorials including this one to highlight that this isn’t the Only way to do it.

  3. I’m personally not a fan of insisting there is a “wrong” approach to building most apps (unless there is literally an error that breaks the app). I definitely agree that data optimization is an important goal and there are plenty of times in tech where correctness is critical, because you’re right, redoing things cost time and money. But I think there are times where, in practice, people choose to build their app a certain way that others might see as suboptimal because they have particular goals in mind for their present use case or MVP, and as a platform its nice with Bubble that you can always change/fix things as your app’s needs and user demands change.

4 Likes

Thanks for this, it’s helpful – we’re going to be including links to privacy settings which is covered in our manual into future tutorials where relevant, as a reminder for best practices when building.

2 Likes

Hey, @allenyang,

Do you have the new link for this?

Thanks in advance :slightly_smiling_face: :computer:

Maybe this one? @hacker :slightly_smiling_face:

https://manual.bubble.io/help-guides/structuring-an-application/data-structure#connecting-types

1 Like

Great, thanks, @lantzgould

Thank you for this tip. I was struggling with dealing with test data that we created via the api, because we were previously depending on the “Creator” field and this is now empty. By attaching a User field and using it instead of depending on the Creator field, the app can function properly whether using live data or api created data.

2 Likes

:bulb: finally went off. in our original build, we had 54 fields tied to our User object. Got this down to 6, but 5 of them are still pretty hefty: List of Conversations, List of Events, List of Messages, List of Profiles and Profile. Now I realize that by adding the User object to these data types, I can eliminate these from the User object and “lighten the load” so when the database is creating Users, searching Users, there’s not so much “heavy lifting” going on that might break the server’s back.

This was the second :bulb: that went off, wherever I am using Current User’s *, I will replace this with a “Do search for * where User = Current User” type of search.

While these things can be dealt with “down the road”, I can’t imagine a developer who wouldn’t have rather dealt with “first things first” and getting the data optimally structured is definitely a “first thing.” :beers:

2 Likes

Thanks for sharing your insights!
Glad to hear that you find this topic helpful. :slightly_smiling_face:

2 Likes

It has been extremely helpful. :pray: I was wondering if you could explain how much space the image field takes and is it fine to leave it on the User object or ideally should we strip the User object down to its bare minimum? I have a Profile type and trying to nail down where things like first name last name , user picture should go, on the User or on the Profile ?

I would think it should layer so using the example, the User would have first name , last name, image, and then the Profile would add a little more detail like address, interests, and then an additional ProfileDetail type would store list of image or additional fields like description or keywords.

Since the image is stored as a url (correct?), I was thinking a url must take a lot of space but I guess maybe it’s compressed? Forgive the noobiness of these questions but I’d sure to love to figure it out once and for all.

Yup.


Actually, a URL doesn’t take a lot of space. For instance, the following URL has 74 characters:
//s3.amazonaws.com/appforest_uf/f1596650155253x730935678399024400/team.svg

The number of characters varies depending on a file’s file name or/and your app’s domain name. If you upload a private file, you have kind of:
https://mintflow.io/fileupload/f1601628190750x467484929982482370/Shopify.txt


Please feel free to save it on the User level.
Pretty often cases when you need to show a user’s avatar along with the full name.
If you keep the avatar on the Profile level, then your app will do extra searches.

For instance.

  • User
    • fist_name | text
    • last_name | text
    • Profile | Profile
  • Profile
    • avatar | image
    • address | text (or geo)

So, when you have an image element that gets the User’s Profile’s avatar, the app (on the preview) makes an extra search for getting the Profile’s contents since the Profile is a thing. On the User level, it’s stored as a unique id, not a nested object.


Don’t worry! These are good questions.

Let me know if you have other ones, please.

3 Likes