Mastering Database Building in Bubble.io: Insider Tips from JJ Englert and Petter Amlie

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hey everyone JJ here with uh Peter from Emil Solutions uh tuning in for our broadcast today I'm talking about Bubble databases everything you need to know about building databases in bubble um Peter did I say your name right let's just started or Peter I'll respond whatever you say I'm sorry about that um so header was you know one of the ogs in this space uh I originally read his book I learned satellites from him as well and I use that into all the way I build databases today you'll hear a lot about satellites today um so thankful to have you on and for your guidance especially in those early stages um it's going to be fun to see how we think through this database that we're going to be creating together the decisions that we're making why we're making it and how we're kind of approaching it so that's really the gist of this call today is just let's get into a UI let's get into lucidcharts let's start putting together these schemas talk through the decisions we're making and we'll take it from there I look forward to it so thanks for the invitation I think this is going to be very much yeah of course before we get started where can people find out more about you and then we'll do that again at the end well I'm pretty available and at the same time I'm not I'm pretty I'm poor at answering stuff which you'll find sometimes I'm I just terrible at it but I am on Twitter you can find me there um on the Amazon Solutions handle I have the amazonsolutions.com which is my website where you can email me uh if you just write something in the Forum I won't see it but if you tag me I will because I'm there occasionally and I'm happy to answer your most most things you know as soon as I at least if I have something to offer I'll be happy to answer it so yeah awesome yeah I I try to put your links to the books that you did as well you did a book on database and database and security um I'm rereading the security one now as we speak I'm getting ready for another course on that so um it's thick but it's good turned out longer than I planned for sure yeah but I think at least it's pretty complete yeah yeah I would definitely say that um all right so Rico welcome always good to have you here my friend uh Michael welcome all my other friends here thank you for joining us much appreciated they will be a replay of this event um I will send in a recording you guys signed up an email so I'll send it to the email also be on the YouTube channel um so don't worry about that so let's get into it without any further Ado I'm gonna add our screen here we go um so I included the figma links so you guys can follow along with this design uh we'll be doing a figma link and then we'll get into our erds as well and start building out these types um the goal really isn't to build out this entire thing it's more so talking through these main relationships um and just figuring out you know what makes sense okay so let's get started right away and we'll get into our user type here so as I go through these flows I'm seeing we need some kind of full name email we have some social connections I'm going to just continue going through these flows um and yeah phone number email full name anything else that I might be missing here so far better uh the first thing I'm thinking here is kind of just to emphasize which I often do in my articles and books and stuff is just to say the importance of planning here because they have a design and this looks great from an end user perspective right uh but this is a food delivery app there is someone who is going to deliver this food as well they'll want to log in so I'm thinking the first thing we may want to think about is kind of how do we separate these users from each other and how many different kinds of users do we have we have at least clients and we have maybe an admin who adds this stuff the food maybe the restaurants have an admin I'm not sure and there may be need for some kind of super admin user which is whoever created the app or the team that runs the app yeah so for that we would use a user role right uh I think what would make sense here is probably an option set or yeah yeah so that's too much or use a role so I label all my option sets with OS in front of it just so I know that it's an option set in the drop downs um and then for this we'll do an admin we'll do a delivery delivery driver and then we'll also do I don't know how to format this right but for an option set but and then order or customer whatever that might be um does that feel about right there yeah that's uh let's not complicate things so let's see if these are our three roles okay awesome so and then over here we'll connect that to the user um user user all roll and then this would be OS roll awesome yep that's a great place to start there so we have our full name our phone our email our user role um you know what I also really like to do here even though this design it doesn't seem like there's really much on the user I I like to set up my satellite for my user now which I normally call my user expanded because I feel like if you start this foundation in the beginning it puts a really good place for you to grow in the future meaning we all know that the user data type is carried with us on every single page load right and so that's just weight that you're carrying with you now you want to make sure that that is as light as possible because that's every page load you're bringing that and so by having a customer expanded type you can throw in all the data for the user that you don't need on every single page load maybe like a date of birth maybe like um you know things like that you know maybe address depending on how you need to get there but things like that that will help you and so right now it doesn't look like you would need an expanded because there's just maybe five to ten fields and you don't really need a satellite for that but I like putting this Foundation now so that way as your user grows over time you already have this foundation in place to just throw it to the expanded or to the user depending on what's best at that time rather than say I'm going to load up my user it gets 15 20 Fields now it's time to make the expanded and then I gotta change everything at that point you know I think that makes sense yeah especially in in application where you save a lot of data on the user um I think if you're losing or sorry if you're using the expanded section to to store yes no values and numerical values small stuff like that then I'd rather keep it on the user sure but in this case I think it also makes sense to do it the way you suggest because of the security issues because we have some different user roles here and they are very different right so the admin user is you know a completely different user type from the client user or the customer user in this case uh in which case setting up privacy rules would be pretty simple because we can just keep this data type completely separate from everything else making sure that you never get access to something on the user field which you're not supposed to or you don't need really I think that's a great Point that's another really good way to look at why these expanded and satellite types provide help in that manner it makes security easier right because you can really get into those privacy rules and restrict those even further exactly yeah yeah um you know a lot of folks when workflow units were launched where they're like oh man does this mean satellites don't do anything anymore like because it's going to take more work units to create the satellites and to manage the satellites right now I have my response to that but what is your response uh well I'd said generally for the workload unit I would say the the initial kind of anxiety that everyone got as they launched this with these missed calculations that weren't really where they should be yeah I think for most applications the the workable units aren't that big of a problem anymore so I think I want to kind of tone down the anxiety that people are feeling that I'm spending too much of this on this on this on this of course you should think about it but um I'd rather have an app that performs well and then look at things as the the app gains users and look what exactly spending workload units and then kind of try to to optimize that instead so um I'm thinking this through mostly from my security and performance perspective really yeah so satellite data types for example they still make good sense because you can avoid downloading a lot of data that you don't need so every page load potentially everywhere rather than you know the one or two times you need to create and manage that satellite yeah and just to illustrate what a satellite data type does in terms of performance it's usually not the singular records we're worried about right if you download let's say you're an admin you download a list of users and let's just uh for the sake of it say that each user has a 10 000 character blog post saved on them right that list would be pretty slow to low because you'll be downloading all of this data which just makes no sense in that case I would definitely move that to a satellite data type so for searching stuff like that but to download single records especially if it's mobile app you want to keep the data load as small as possible and if you have one blog post saved on one user with 10 000 characters it's it's not much data at all right so uh when thinking about satellite data types I mostly focus on lists and large volumes of data and not single records yeah yeah that's a great way to say it and we're going to come back to those lists um in our restaurant uh listing here we'll get back there in actually a couple of minutes but yeah I think that's a great way to say it um you know the big thing that I say is uh it's your searches you know you're searching on your list for all your RGS and everything like that it's if you're doing it with a satellite it's just returning less data which is saving you workflow units right and uh yeah for sure for sure and uh not only that but it's also making it quicker because it's just loading less data to the page uh and it's more secure because it's loading less added to the page exactly yeah and also from a workload unit perspective a search because what great thing about Bubble is that searches are Dynamic right so if I download a list of users and then I add 10 new users you will instantly see them on screen most people you know you've seen this in your apps yeah and of course that consumes workload as well right so if you can keep the data that's repeatedly changing in a satellite data type you don't need to do these follow-up queries every time you look at the list because if we take an extreme example there if you download a list of users let's say you download all ten thousand of them yeah and then these users all of them start typing away and adding stuff to their and then the guy looking at the list goes to lunch for an hour you're continually spending workload units just downloading new data to the page which is uh it's not huge it's not a completely new query but it's it's complete waste right you're you're not it doesn't give you anything so you could think about it that way too you know yeah think about if if a search can remain kind of static in the way that you don't constantly ping the server for new information I love it you know another thing that I see with people using satellites and a mistake that they might make is they have maybe just for an example here I'll show so they have like the user right and then they have the user expanded and say that you know they're doing a repeating group using the user expanded and you know they have their parent user saved here right so parent user and as user and so they need maybe like the full name from the user so then what they'll do is they'll reference the parent to get that full name in that repeating group which essentially means they're loading the satellite but then they're also loading the main type as well to get all that and then it defeats the purpose of the satellite not only defeated but you've actually made things worse we make things work so yeah it's the worst setup you could have it yeah yeah so think about what you place in you know if you save your first name on the user expanded you're not doing this the right way yeah yeah exactly so that's a thing to avoid you know satellites are here to and and they really become handy when you have your UI and you can say okay what is exactly the things that I need to show here and and only put that and then nothing more you know because you're just trying to really populate these RGS um or these listings of just the main types that are showing you know the main fields that are showing a lot of listings without actually loading everything else right so you want to keep your satellites as light as possible and then your main record can get a little bit more chunky because your satellite is serving the purpose for your listings I think it's useful to see this from a user story perspective you know just classical user starters is that when you think about what's on the main thing or whatever you show in the list whether that's your satellite or your main data type that's up to you but what do you need saved on that record to show in the search results right and the list of users obviously we would need to show their name right so you don't save the name on the extender and satellite data type um and then what would you like to show when you click that user for example you're taking to somewhere else maybe a user profile what do you need there right so the goal of satellite data types is not to set up saddle dead types the goal is to think about how you can kind of spread your data and load over multiple steps you have to think about will anyone click every user and open every single user profile it never happens right but they will download all the users that they see in that list and then click them yeah so think about that you know step one search what do you want to show here what do you need in the search results that's the lightweight data type and the heavy data type is the user editing or the user profile whatever you need to see and when you look at the screen you have in front of you right now where it says what would you like to order in the middle left here we have some search results like featured restaurants right you don't you don't need to load their entire menu you know you need this photo you need maybe the reviews you need the McDonald's the name of the restaurant all this information you would say that on the light data type everything else comes in the next step when you click that restaurant right so I think that's a good way to think about it what do I show in the search yeah and to answer this question real quick um it's attached to the user yes and so when it goes to load the user here so we see the user expanded you're only loading the unique ID of this record but not all the fields of this unless you call for this specifically so the unique ID is what like 24 kilobytes or something really really small so you could save unique IDs all day long in a one-to-one relationship um and it just helps you avoid loading everything else a part of this as well so hopefully that helps to answer your question there um you know I think one last thing is with the satellites I don't know what you prefer but I always like to have a two-way relationship on my satellite so I have you know my satellite here my I'm saving the relationship to my satellite and then I'm saving the relationship to my parent back to it because it just makes things so much easier again it's just 24 KBS you're saving but if you like when you get into managing a production application and you're in your database views and you're trying to fix data you need all the tools you can to find the connections between all these and by Saving This Record there then you can easily constraint that in your database views and then see you know whatever that makes sense and so you can modify and fix your data better in the back end if you ever need to I completely agree with that and it's also it's bytes right it's not kilobytes even so it's just incredibly small and you I'd like to see also use the sentence you're doing your future self a favor because at one point you need to find all everything connected to this use or something like that it's just so much quicker I don't see any single reason why you wouldn't just it has a two-way connection there right it just it makes life easier and like we're not trying to build apps to build apps we're trying to build apps to solve problems for our users and then that also means we need to build apps that are easy to maintain in service so we can continue to solve problems for our users rather than just fix our own problems because we didn't set up right in the beginning yeah that's a great Point you're making there because one of the things that people tend to people are kind of almost feel guilty for setting up their database in a way that seems messy to the user but as you say you're not creating a database for the user you're creating an app it doesn't matter what they see right right your app is just a polished user interface on top of a database and that database should be whatever it needs to be to give a great user experience and of course a great user experience is secure and it's fast right yeah so yeah never mind what how the database is structured yeah I think generally you just want to load the data that you need to load when you need to load it and nothing else right so like if you need 50 cents give me 50 cents I don't want a dollar or whatever just give me the 50 Cent and you're just loading the data you need when you need it nothing more and when they go to do that next thing then you can load that data when you go to the next thing they can build that data and maybe you can start prefetching that data in certain points if the once the page is loaded entire or whatnot but you don't want to load so much that you overwhelm the user before they need any of that because then the user experience is going down and it's not secure exactly and the user doesn't know about the user expanded data type right they just see whatever they need to see on the screen yeah yeah uh to get to this question with Michael Michael good to see you another great uh bubble Dad how many fields do you generally limit your to your data type uh for satellite um light data type yeah so uh it depends right but I I you don't want 20 plus fields on a satellite that's kind of defeating the purpose of the satellite you know so it's you know I ideally like less than 10 fields on the satellite but that would mean that the parent would need you know like to make sense like you know 20 fields or more right so it's weird there's no like yes or no there's no binary thing of zero and ones it's just what makes sense for you your build and what doesn't um you know again I think it goes into forecasting the future if your user type is really small and you just don't ever Envision it getting really big then maybe you're good and maybe you don't need to set up that user expanded to to just do that right it depends on you know your app your scenario what you're solving and and if it's going to be needed or not but usually whenever I can see a data type getting over 15 Fields 20 Fields I'm like okay I'm just going to put my satellite in place there and it's going to protect me from making sure that these repeating groups that are loading these data types and these fields are gonna stay performant and not get less bogged down as the status side grows what about you yeah I'd say kind of the same thing it's make it makes your editing experience a lot easier too in the bubble editor that is you know not just if you're going to use your data type you don't want to see 200 Fields um then again you know servers are pretty fast right so there's no hard limit that says you can have 20 but it can of 21. of course right so I would also consider the total data weight which is you know the the amount of especially unstructured data that's what slows things down and makes the download big so you know you I think you could set up a user field with sorry a user data type with 200 fields and one with 20 and compare the two and I don't think the difference would be huge uh once you gain a thousand users ten thousand users might you might start to see it and you might start to see it on download size if the fields contain a lot of unstructured data yeah so the number of fields I don't really I don't think I I have a set rule for that really I just considered the weight in total and as you said you know what is this field going to be used for how can I how can I break up this in steps like we're doing here with user and user expanded yeah yeah I think a big thing for that is you know probably just talking about list Fields quick you know um if this was a list of things and say this was a list of me on this list we had 5 000 records right so that would mean that whenever we load this user which is every single page load we would also load the unique ID for 5 000 things right exactly yeah which is a lot it's a lot it's a lot but I'm you know I I offer the service where I audit bubble applications and I'm seeing so many user types that are really really heavy and they have a lot of lists on them and I'm just like you got to get those lists off your type because it's not doing you any good and you're loading hundreds of things you know and yeah it's just a unique ID for those hundreds of things but you don't need that on every single page load with you yeah it's a good point then from a security perspective to you know you if you can avoid showing the unique ID of something you may want to avoid it so you're not revealing the unique idea of 30 000 users that that gives a hacker some information about your app right they may not be able to use that information for anything but potentially they could if you have some vulnerability in your app right so you know if you can hide that I would try to do that yeah um another question then we'll continue building this from Anthony Anthony I hope this is the case right uh that we're able to dictate the fields that come back in our searches with bubble one day right like that would be fantastic uh that would probably end satellites in some way maybe uh because then we could be very specific about you know what we're returning and not returning um and that helps with performance it helps with security that helps with optimization all that kind of stuff so I hope we get there but disclaimer I've been talking with them about that for two years now so I don't know if we're gonna get there um do you have any insights on that better um no no insights really adjusted it's not that long ago that I heard that they are still working on it so whatever that tells you I've been hearing that for years as well I think when it comes from what I've seen it's probably going to be automated so it's going to be yeah obviously it's not going to download whatever's hidden by privacy rules but it's just going to download whatever's needed and if you open up a new field on the screen it's going to download just just that one field yeah so they're going to automate that for us and I think that follows what bubble does for us right like they automate those kind of decisions to make things a little bit easier um which is you know beneficial but for some power users like us we probably want to know what that is and control that a little bit more but still that would be a welcome Improvement to just download the fields that are being asked for in that call rather than all Fields And as you say this could remove the need for uh for satellite data types maybe which is let's not forget it's a workaround right yeah yeah not optimal we said work around that we set up to overcome come some short comments at the current iteration of bubble yeah yeah and and unfortunately this is just one of those there's quite a bit of it we have a few of those yeah yeah all right let's keep going here I want to get to this restaurant type uh specifically so um we'll come back to this a little bit so we have this this page here and on this page we have categories so Burger Donuts pizzas Etc and then we have our restaurant listing all right so for this I want to start with building out our restaurant listing and then let's talk about how we would do this category okay so um I'm gonna come over here I'm just going to copy and paste that now if you don't mind helping me figure out what Fields I need to add here um can you see the screen on your side or no yeah okay so for a restaurant what do we have we have our name of restaurant right we have reviews um we have a review score we have also a review count if we want to show that yeah so let's do let's um let's come back to reviews after we finish filling out this um this type here because I think that's a bigger conversation of how we can approach that and then we have so we have reviews we have the the total the count we have the name and then we have you know delivery time which is interesting this delivery time there's an option set for you how would you do this I guess it depends a little bit uh if they are if they are just really three available times like 10 to 15 minutes 20 30 to 16. yeah then yeah I think options said probably be the quickest way to do that yeah free delivery is probably just a yes no maybe an option set if there are yeah yeah I would I would say that now for my yes or no field I always do a y n in front of it just to alert me that that is a yes or no type as well and so I find that that just kind of saves me a little bit in the background when I'm searching for the results there so I'll do YN free delivery yes or no and then I'll come back to this delivery time and I think for that we need to create another user role uh sorry an option set and that would be option set delivery time and then this could be you know 10 to 15 mins 15 to 30 mins my format is not perfect uh it's not important for me uh what's important is that we can help you guys learn um more about this so um don't just insert one thought for those who are building uh International applications on this that you may want you know you are in the US and the the apps I guess are probably mostly focused on the US yeah if you're planning for an international launch or something like that you may want to avoid putting your language into an option set like this for example so you may want to save just 10 to 15 and then it's well some other word in another language where you would use the ACT text feature instead just wanted to throw that in there that's that's good Insight I'm uh yes I've only worked within the US for this stuff so um so you're saying a void essentially using uh your language in your option sets in your database in that way yeah if you're going to translate the app if not you're over engineering things but the options that in this case would say 10 to 15 and the expression I guess would say option set 10 to 15. space app text minutes yeah boom yeah I love that that's a that's a great foresight insight there um all right and then we have some categories that this applies to now with these categories this is a good thing of like are we going to do this as a data type itself we're gonna do it as an option set and I think it could be both ways but what would you start with I think in this case we have a few things to think about one is that if you look at that list Burger chicken fast food that's a list of categories that you'll have to store somewhere so I would I would ask myself will that list change over time so let's say you add something rare you know uh Cuban food or something like that that you don't you know you may not have that at launch but maybe you have it two years down the road in that case we may want to have this dynamically so you may want to save those in the database then again it would slow down this load so I think my initial hunch here is to use the database to save these categories and then the list of tags that we're looking at here which is probably a repeating group I think it would actually save this as a list of texts and just say Burger chicken fast food that's list of text oh interesting so you have it on the data type you'll have a data type with it but then you'll just save it as a list of texts yeah so you don't have to load that data type with this is that why exactly yeah because here we have to look up three different the records of the category data type yeah to see what their name is Right which kind of defeats the purpose of making this lightweight satellite the search type so but setting as text is basically just loading a text but saving us a list of text allows us to uh to show this in repeating group yeah which is essentially like an option set anyways loading that list of texts it's kind of as light as that but it's a little bit more flexible over the long term yeah so one of the risks of course is if you keep changing the underlying records you change Burger into hamburger and you'd have to update all of these records but for the sake of a speedy load on this which you really want on a mobile app I would consider doing it that way yeah yeah you know another thing I like to bring up is if you do this as its own data type that means within your admin dashboard the people operate in your business can go in and manage that and add new categories and you don't need a developer to do that right and so it makes it more maintainable and serviceable in the long run to be able to set it up this way but like Peter was saying you get the benefits of is if saving the list of tax you still get the speed benefits that way so it seems like a win-win except for the fact if you ever need to update that that would be a pain but that can still be manageable as well the camera down yeah for sure yeah and it they probably won't right this will probably remain fairly static yeah and you know you can you could also go with an option set here but the opt-in set means that you know maybe you have I don't know like 50 to 75 of these different types and so that will be loaded on every single page load right 50 to 70 things because of that's an option set that's loaded every single page load uh and then whenever you need to add or modify it then the admin that the engineer has to go in and do that right and so that in itself creates friction for you know the operator of the application exactly yeah you wouldn't need a developer to do that and if especially if you're delivering this to a client it's one less question you have to talk about later like after launching one one less maintenance task so um yeah and the option sets are part of the files that are cached so here we can think about the customer Journey again uh customers would be caching the option sets so they just loaded on the first page load but then again this is an app that probably gets a lot of new users hopefully because yeah they want to acquire new users all the time so the first page all day we do would have to download all of these tags which takes a little bit of extra time so yeah uh list of texts there we go so what we do from that is we you know when they're creating these categories they can click whatever categories they want to create and then we'll add it to this category as a list of texts from that yeah exactly we'll generate the list of texts from the name of the category awesome um so we got our there we got there we're there okay so last thing we're missing is just a cover image for this uh cover image and then let's talk about this review so this is this is fun you can do this a lot of ways I have my preferred way um so we have the overall average and then the count of this what is your preferred way to do this uh I'm not sure if I'm getting the question how to display it you mean right so what we we could also create another data type for reviews which we'll need to do anyways but then are we going to save you know on this type a list of reviews and then on the page load are we gonna do a count of that list and then also average out all of those reviews are we going to do that every page load or are we just going to save this statically on the type itself and then manage that relationship in the back end no I would definitely do that statically yeah so especially after the workload unit launched this would take up a lot of workload if we have to calculate this on every cell in this repeating group of restaurants okay yeah yeah yeah I I would do the same thing so [Music] um um Okay cool so it's going to take up more like um processing speed and you're gonna have to build out this operation so anytime you create a new review then that review would be created and then you would modify these records to update the count and to update the average but that's only happening when a new review is created and then it's saving you all of those operations on page loads of not doing the accounts and not doing the averages and every single page load for your application so yes you have to do more work on the back end once that review is created but you're just doing that once rather than all those operations and every single page load exactly yeah yeah so 100 there um so I would do you know a review score and that could just be what that's a number and then a review account and that's a number and again this is the relationship that we're managing on the back end here and on updating whenever a new review is created I'll just go off and create this review type quick just they have it there as a placeholder we don't need to fill it in fully but um so all right so we had that restaurant and we have our delivery times we have our categories we have our reviews now let's talk about [Music] um satellite for this because this this itself looks like a satellite and then we get into the actual details of it all so we still have a cover image we still have a name we still have our reviews we have pricing we have quantity we have description and then add-ons for all this so would you create a satellite for this restaurant or would you just leave it as is as your parent uh I would create a satellite in this case and there's a few reasons for that that again we're thinking into the future here and looking what what kind of problems could we run into here so first thing is just the search speed right we have a longer description here we have a choice of add-ons which I guess maybe a list to search something like that which we want to avoid downloading in on the left hand side here um and also for for places like this there may be you know maybe you're an admin you keep adding these restaurants and you're writing about a restaurant and it's not published yet so you don't want to publish the information yet which is worth thinking about right is this a public restaurant are people supposed to see it or is it not public you know plan for this ahead also makes you or does you're doing yourself a lot of favors so I would definitely think about splitting these two up into our satellite data types the third point there is that this is a very typical use case for something like algolia search where you you know thinking about workload units you could even just offload this whole thing onto algolia but as we know the algoli at least the built-in plugin into bubble is it doesn't offer much in terms of privacy rules um yeah and if you're filtering this on the client side you know it doesn't make any sense to do that anymore yeah so um you may you may even delete the data type that is the satellite data type which comes into the search results if the restaurant is unpublished but you're still keeping the main record which is on the right side does that make sense because yeah I mean you just keep your algolia database clean but you're still saving the restaurant and whenever you publish it it regenerates the satellite data type which is there for the searching yeah I think um you know algolia let's talk about that quick I think it's a fantastic resource and you see tremendous speeds when using it but you can't apply any privacy rules to it though the way it works is by public data right and and it needs that public data in order to do it so the second thing you need that data to have some kind of security on it it falls apart which is a real shame right because it's such a great integration and I've talked to Bubbles team about this and they've looked into making this better with engineering and they just weren't able to do it and it was it was a very sad day but if you're using any kind of like um you know like my buddy day built an application for the uh the bubble plugins and all that stuff was public data and they use that Golia to power it and it was really fast really powerful and it was good because it was all public data it was all good right but yeah if you need to add privacy rules to this then it kind of falls apart there um just generally speaking yeah and you know everything is pushed to alcohol continuously so if you're ever in this situation where you're you're still working on something let's say you're at a restaurant and you have written the name of the restaurant you haven't written the description yet it'll show up and they'll go there search which you definitely don't want right and again talking about workarounds currently the only way to hide something from or go there in a secure way is really to delete the type altogether or the record altogether yeah so but again we're talking pretty technical stuff here and a lot in your first iteration of app you may not even consider or go there so it's uh it's just something again I wanted to throw out there yeah yeah you know you're talking about deleting stuff and I get a little worried because I never delete anything so what I do with deleting is I just archive it essentially I do a yes or no on my archive and I filter that repeating group so you know only bring in archives that is you know no and then that way if the admin on the background never needs to like take it away from the listing they'll just you know have a button archive and it'll just archive both and it's away from everything but it's still there and you can re you know bring it back really easily yeah yeah I think that makes sense uh in most places and I tend to do the same I don't really like to delete stuff uh but uh in this case we would have another data type which is the main restaurant data type where you may be adding a lot of different information yeah and deleting the satellite data type is pretty it's not a big deal right because it's not really doesn't contain anything of value every everything is there on the main data type so yeah whenever you click publish on the main data type we would just recreate the satellite and just get it out there because that way you know regardless of a goalie or not they're still keeping that search pretty lightweight because you're keeping the volume of uh Records in the database as low as you can all right let's keep going on this uh restaurant here so um we talked about if you talk about our categories no we didn't talk about our categories yet uh we were talking about you know satellite and so we're going to create a satellite so this would be a satellite here and it would just contain these fields which we already have here now I have added a parent here that we can use to now beef up for you know the other stuff let me just structure this a little bit better so we can see side by side here um and so what I think we're going to need to do is a couple of things so first we need to add the relationships between you know the satellite and then so it's going to be you know restaurant just to abbreviate here and then we'll you know do that two-way relationship so parent restaurant and then restaurant all right so after that two-way relationship and we come back here and now we also have [Music] um see should we talk should we finish off this parent before we get to the categories or do the categories now and finish off well the parents you mean the restaurants yeah are we missing anything there yet we have a favorite feature here in the heart there I guess which could potentially be slowing things down oh that's right that's yeah that's right thank you let's talk about this favorite feature um and one of our friends brought it up earlier uh vinay where are you all right so this favorite feature how would we approach this now when I think about list fields I think is this ever going to get more than a hundred things right so am I ever going to have more than 100 favorited restaurants and if so then maybe I'll look at its own kind of data type but if it's less than 100 I think that it's best to have it's on its own list field because I see the performance gains and in just less than 100 it's normally faster than doing a search for for a separate type so what I'm thinking here is I would personally have a list of favorited satellite restaurants on my user type all right and then I would display this heart if you know this restaurant is a part of that list on my user type because I'm already loading that user type and I need to show this and I only want to show the you know for the restaurant Satellite I don't want to show for the whole parent I think that's how I would do it how about you yeah uh same way I'm not sure if there's any other sensible way to do it really uh yeah you have to store the list somewhere and probably people if people are favoriting hundreds of restaurants it the feature really loses all this meaning I think yeah so uh yeah I think that's the way to go now you know I I was saying that I would do it on Save the satellite but you know it doesn't really matter in that sense because you're just loading the unique ID here right so you can do it on the actual restaurant itself or it does matter because this is a restaurant a satellite here and you need to see it contains within the satellite right that's what that's why it matters yes you could save actually the yeah you would just say the the satellite you probably have a yeah the satellite I think because yeah that's where you would show the the icon exactly um satellites so then this would be you know on the user we have a list of favorite restaurants and so if you do go to you know on the user over here maybe they have you know favorites that would just load that list really quickly you know you're probably gonna have 20 or less and you just can't get faster than loading a list of 20 or less than having a list compared to its own data type and whatnot so we have this search uh finished off let's just talk about this this category before we get off to this page so we have categories here um and I think this kind of falls in the line of kind of what we did down here it would be nearly the same thing uh it's its own data type right and we can create manage and edit that data type you know however we want in the back end um and and then when we save it so if we here's the question now so now we are um Nasir why not store it on the user expanded because that means we would need to load the user expanded to then do that and the user is already loaded so then it saves you from having to the additional load because we don't need the user expand it elsewhere on this page so far so we don't need to load another type to get there [Music] um a quick question logic behind creating an OS for delivery time that one was on the line for us we just thought you know if there was like four or five different options of like you know within 30 minutes 60 Minutes et cetera we could do it that way but you can do this multiple ways depending on what's best for your application um so this loading this getting back to this category we talked about creating you know its own data type for this it'd be like you know name icon kind of thing and then that would be saved to this restaurant as a list of texts now that still applies here right because when we click here then we would you know filter this RG by you know this text and it'd be you know I have to search for contains or is within this list of texts right yeah exactly um yeah yeah so that's that that's that structure for this page here now I think the big thing is is like this address right we have it on the user type and I think we always want to have that on the user type because you're you're bringing in this address kind of every everywhere with you of like your delivery times restaurants nearby and everything and so you just want to have that address handy uh and just ready load it with you just to always pull with you right absolutely and it's a small text value you can just include it there yeah now do you save the full address or do you break it up into like numbers street addresses States cities how do you go about formatting this address uh and just from what we're looking at now I would just go for formatting the address in the standard Google address format yeah uh I would say if you need to split it up into anything more than that usually means because you're searching in specific ways so you know if I need to search for producers in your state or your city or whatever it would make sense to do so like but um from just what we're looking at here I would just use the regular address yeah and you can use the extract you know to get the user City out of this address you can extract to get the city and the the state but if you are doing that search a lot then yeah it just makes sense to probably just split it up you know when you first get it and just avoid doing those extracts every time yeah yeah yeah cool all right so that's our listing page so we've talked a lot about satellites We Like Satellites it's just an efficient way to you build your databases and just loading the data that you need only when you need it so that finishes that up now we're just talking about our um our parent record here so we need to add some things to it we need to add price um and then um what we got like maybe 15 more minutes so let's finish off this parent record and then just maybe get into um the carts of how we would go about structuring our carts all right um so let's finish this off real quick so we got price description price number description text and then what else we got we got list of add-ons so this is a good one so list of add-ons how would you structure that one better so could you just zoom in on the add-ons here so these are basically yes I want some extra mass room uh in this case um yeah this it probably makes sense to set this up as database records again yeah so that they're flexible uh I think that's probably the only way to do it because there could be a million of these yeah again I think when you clicks what are these now like in multiple restaurants use the same mushroom and pull from that or is this a unique thing for each restaurant that's hard to say I would just intuitively you know you could research this but I would probably set something up for each restaurant because you know extra cheese could be could mean something for one restaurant and something else for another one and just allow restaurants to add all their own add-ons so Paris restaurant has green peppers baby spinach and mushrooms and extra cheese and another one has extra cheese and something completely different but those extra cheese are different records in the database I think that makes more sense this makes it makes it more flexible because maybe one restaurant wants to change the extra much cheese or something like that yeah there's a pricing attached to it potentially you know so then they need to control their own pricing obviously you know yeah yeah so this would be we'd have an add-on data type and then add-on data type would be an image a text and a price essentially right yeah add on image and then image name text price number and then add-ons list of add-ons all right so for my I my professional database course building out this ERD is the final exam so I might have to modify this final exam now for those that are following along how to build this out um but yeah may also be in the final product that you want to connect the add-on to the actual product not the restaurant because I you probably don't want extra cheese in all your products right so that's just how this this example is set up it depends on how your app is going to function really yeah you could connect it to the restaurant or you could connect it to to the product itself so that a a cheeseburger has an option of extra cheese but the spaghetti has another option of a spice or something right right right so we actually missed that so I missed it this is a restaurant but then we dived into this is not the restaurant listing this is the actual like menu item this is the product listing that we're looking at right now I got confused on that um yeah so like we clicked on this is a restaurant yes but this is a menu item within that restaurant so this is its own actual data type in itself yeah so the yeah it's just the the sequence in the figma file here is a little bit strange so yeah we are looking at a list of restaurants in the left hand side but then we go directly into the product in the next slide so yeah I was confused by it as well yeah me too all right we'll just grab this real quick so menu items and um we'll just bring some stuff over real quick um description some busy work here price remember all right so then we can delete some of this stuff and then what we can also do is just do um right we'll do a menu items and this will be a list of their menu items for this restaurant and this will no right there there we go so that will be that and then we can take the add-ons off of this right we'd want the add-ons on the menu item itself uh yeah so we have a add-on data type we add that to each product or menu item as you call it so yeah uh exactly yeah so and then we just this burger has extra cheese and spaghetti doesn't yeah all right so um we have a restaurant a restaurant uh satellite and parent we have menu items on that and now I'm sure each of these menu items itself have a review so we'd have you know we can have we can reach we could structure our reviews to be good for you know menu items and restaurants right like we don't need to create a review for menu items and a review for restaurant or is that how you would approach it uh yeah I'll probably make it one and maybe you even want to aggregate the product reviews into the total restaurant review Maybe um so yeah we could consider splitting the review into types maybe you have one for the restaurant overall maybe you have one for the food or each food item and maybe you have one for let's say speed of the liver something like that if you if you want to make this complex so type of review right now we would need just restaurant and food item but I think that makes change sorry yeah I think we just for that we can create an option set it'll be a type of review on this restaurant and this review so it'll be a review for the menu item a review for the restaurant review for the delivery driver and that would just be an option set dictating that yeah yeah um so I'm not sure I would add that as a list on the menu item I'd rather search for the review and have that review connected to one menu item now that's interesting so why why would you rather do that so how many reviews do you think that is going to be on the menu item uh well we don't know how many there will be but the list the entire list will be loaded anyways so from a performance perspective is there 10 000 reviews you will load 10 000 unique IDs right which could end up being a lot uh but the second thing is that I just feel that I have more control over uh privacy rules when I perform a search you know yeah you can protect the list with a search as well but you can't really you don't get the fine grain control over each item and list so let's again say that a review is under review for example let's say that a restaurant can complain about a review this isn't fair something happened blah blah blah it's just you know the the admin here would place that review under review and in that case we we may not want to show it in list while it's being reviewed I mean just drawing up an example now but I I think it makes sense to to search for the reviews instead because it's it'll be just as fast and it will leave out all records that for some reason shouldn't be on the list yeah I think this applies by the same rules that we talked about earlier with the restaurants is there should be static numbers here and then whenever and we're not showing these reviews here so whenever we need to actually show the reviews then we'll click on it and do that search for then but we don't need to carry it with us here yeah exactly and when you click that see a review if there are 10 000 which is honestly not that unlikely on a restaurant app uh you would only load or if you have a scrolling list for example bubble would only load these as they're needed right right well right now say that your menu item is hella popular and you get Beyond ten thousand your list would break yeah exactly yeah so uh and you know just in general I think this is not just about reviews but in general unless I have a very specific reason to use lists I I rarely do right yeah and there are good reasons to just I don't think this is one of those scenarios yeah agree totally yeah I I try to cap off my my list if it's oops if it's 100 or less I'll I'll look to use a list but if it's anything over 100 I'll just create its own data type for it um so review score number review account number and then this will be you know we'll need to get back to the the parents of this right so we'll need you know a menu item so that way we can strain in the search that we get back there my new item and then we'll also need I guess if we're doing it this way then my friend we don't even need the OS type overview because if you know like if the menu item is populated then that means it's a menu review yeah absolutely yeah we could actually get rid of that field and then you know like this could be you know delivery delivery driver you know if we got there you know whatever that may be something like that so then we could delete this because oops because again what we're saying is if this is populated then it's a restaurant review if this is populated it's a delivery driver review Etc so we got those reviews that's awesome now to your point which I think is a fantastic Point let's plan for this like um you know Arno approved you know so essentially you're only showing in the approved ones uh sorry yes or no instead of like all so this gives you the ability for an admin to say no or the restaurant to say that's not a fair review it marks it as not approved it disappears well admin is reviewing it and then Evan says oh no it is approved and then it say yeah bring it back to yes and then it comes back so it gives you that flexibility to remove it and take it as you go exactly yeah yeah also I'd like to bring at a point on workload units here that is very tempting that each time a review comes in you want to recalculate the score yeah you don't really need to do that you know people don't care if they re this review score is one day old right you can just do this once per day or once per hour whatever makes sense in the beginning if you have a few reviews maybe you want to do it all the time but you know by being a little bit strategic about how often you review the review score and the review count because that's basically just do a search for and a sum or an account right yeah uh you don't need to do that for every single review that comes in if you have 10 000 reviews The Score doesn't even change right that's a really good point but then you get into like how are you managing that reoccurring daily you're like want a new do you just run that new calculation every single time even if nothing's changed or do you filter that search of like if the map modification date for all this wasn't within the last 24 hours don't do it like it it opens up another round of questions like I totally agree we shouldn't be up to dating this every time especially for quantity's sake because that would be excessive so if you can find one way where every single day you modify the quantity for anything that was new within the last 24 days 24 hours then that would make sense but how do you get into managing that Yeah so basically what what this would look like in the back end let's just focus on restaurants for example and and just to forget that there are different kinds of reviews um if we would do this daily you would have to do this daily on each restaurant so you would have a recursive workflow or something that works through all of them which I agree to do daily would be excessive unless all every restaurants receive reviews every single day right so probably I would just make this you know very easy hack on this something like whenever a review is published to a restaurant yeah you've set a yes no field recount reviews on that yeah right and you can use that field for whatever you need so if you are running through restaurants let's say 12 o'clock that recounts or recalculates these review scores it just does that on a list do I search for restaurants that has the update reviews to yes right that's one simple way to go I think that's a great point I I think that also brings up the point of like um that is a field that we're creating to make our lives easier and that is okay right the things that like if this is more efficient and we're able to build a better app for them that's what matters so yes it doesn't look pretty yes you don't need it in that way but if we need to do this to do our own maintenance and to make that maintenance a lot easier then that's a big win exactly yeah as long as it works as long as it works Tony has a question for you Petter um when do you use a list uh well there are some cases where you kind of have to use them so let's say you have a project management system for example and you have a list of tasks and those tasks have tags for example you would have to save those tags as a list on that task so um because let's say these tags are due now or do tomorrow right just a very basic you want to filter this you have to check that list if it's there and it doesn't make sense to set up search the complex stuff to do that so in that case you basically have to use a list for performance reasons I I don't really see much reason to use the list specifically um I'm not sure if anyone's done any calculations on this within the last year but kind of the official statement from Bubble is that its searches are most of the time even faster than lists so um yeah I think it's pretty narrow narrow list of scenarios where lists are necessary but tasks with tags is one of them that could also be blog posts with specific tags attached to them something like that awesome all right so we're running out of time here um so I just want to get to this cart thing before we get there and what we'll do a couple questions at the end but I want to get to sorry sorry could I add could I add one more point to what we're just talking about just to to illustrate could you go back to the screen we're just looking at uh this one yeah so uh this is another case where you look at the add-ons we're losing we're using list of add-ons on the menu items yeah uh you we we discussed that we wanted to create one add-on per restaurant right or one list of atoms per restaurant but that add-on might be added to multiple products so this is this is kind of the same as my tag example that you want to filter products by add-ons let's say an admin wants to do that you would have to save it as lists right the other way around would be to add every menu item on the add-on itself to see where it belonged so that's another example where a list is just the only way to go really yeah all right let's talk about this cart functionality um so we find you know we've we search for a restaurant we find a menu item that we like we add it to our cart okay uh and this is what the cart looks like now so we have essentially menu items on here so and then a quantity of that and then subtotal and whatnot and so the first question is where do we save the cart is the cart going to go to our user type is a car going to go to our expanded user or are we just going to do a reverse search to get to that user what do you think uh well I like to think of carts in kind of two categories you have the the cart you're looking at right now and then you have your history uh so I think the current cart that you're looking at right now we should save on the user type because you want to just bring it up immediately and then we probably don't need a field on the extended user type we just have a user type on the card itself meaning that if you ever have to look through your order history for example we'll know which user it belongs to yeah yeah I think that's I like that a lot I mean the current car so this is really easy you can you know if they're loading the page um you can make it really easy to say Hey you know finish whatever's in your cart you know so you got something right there and that makes sense and then because we are saving the user on the card itself whenever they go to like previous cards you can just load do a search for the previous cards honestly I I would probably just put the previous cards on their user expanded myself uh and I just load that list there um because but it's not I think it's you know it's a wash I don't think you're going to see any big thing either way so that's how I would approach it now I think the car we have a really good um opportunity here to leverage this functionality even further and what do I mean by that well we know we need the basic things of we have a cart and we have menu items within those menu items we need quantities and what is the total price so like we know that we can get there right so total but what I what I'm really interested in is if if they purchased it or not right so for that what I would do is say you know Ryan purchase question mark yes no because if they haven't purchased it that's a clear indicator that they're going to go on my sales funnel and I'm going to sell the like emails of text of hey you have this cart you know that is open still send it to them and here's the menu item surprise that you want to continue like so you know it's easy to forget about you know what you need for sales but I think this is just a reminder that we need these kind of functionalities and attributes in here that will help our sales funnels to convert this item because our our goal here is to get people to buy as much as possible right and so if you're not tracking any kind of you know is this purchase when was it purchased um then you're failing that and matter of fact instead of doing this that's why I know what I would do is I do um I just do purchase dates right and then what I'd say is if purchase date is empty that's my yes or no field otherwise I'm saving the date that it was actually purchased here as well and so you can kind of get two out of one here yeah exactly I agree and uh you'll usually have some kind of transaction connected to this card right which is also contains a lot of information let's say the stripe numbers and all that data yeah which also tells you how far along this card is in the process right yeah yeah yeah that's that's another way to yeah that's that's another good way to do it but I think this purchase light is definitely needed yeah yeah I think the big thing here though is that the point that I wanted to stress is we need this for front-end functionality to get here but we also need it for our sales funnels we also need it to track how many people made it to the cart and actually bought compared to those that didn't and then do we have a conversion problem with this car because of bad rates or good rates like you need to store that data so think ahead when you're building your database don't just think about what is the core functionality needed but what are the things that I could do for core functionality and what else can I do to give my team more information so they can start to track this and maybe that's when you get your team involved you go to your sales team and say hey when looking at this car what are some things that you want to track what does success look like for you then let's set up those metrics ahead of time to make sure that we're storing and accounting for that when we build this feature from the beginning foreign it's a very good point I totally agree awesome so let's end it here on our build uh we got through a good bit we talked about satellites a lot but I I hope that's pretty clear now um I hope you guys enjoyed this build um there was a lot of stuff here that we talked about um I'm gonna just remove my screen any last questions before we get out of here um I'll go through it so um I'm not sure if you can do this can we say this in a cache rather than the database like um you know you can cache it in like a ghost user but uh I I don't know if they're yeah so I would not save it in a temporary way I I'd like to keep the card for as long as you say as you say you may want to send a drip email something like that do you want to finish your card uh so you could you could do that I don't see in some products maybe it's it's worth doing in the case of this restaurant app that we're looking at I would absolutely save it for permanent record and keep it up to date yeah agree how about Greg here so would it be better to have an extended data type for user or search info data type made specifically for search results profile picture I would do an extended data type um I tried to avoid doing searches as much as possible I think for this extended data type it's just an easy you know you load that you need unique ID and whenever you need it you can just segue over to that type and pull in that information without doing a search um it's it's easy enough it's not a big thing for me you're just loading one record what do you think better yeah again the the list of users will probably never be loaded on the front end so this is kind of an admin thing right if you're loading a list of users you're probably either a restaurant owner or a super admin or something like that so um oh I didn't read it like okay I see yeah I'm not sure I think maybe we interpreted the question in different way I'm not sure I don't understand the question to be honest okay it would be better to have an extended data type for user or search info data type made specifically for search results oh yeah okay no I think I get the question so should the satellite be an extended version of the current user or should you set up a satellite data type that is purely for searching I think that is the question uh I don't think there's a straightforward answer to that it would depend on what you need to search for I think the setup we have now with a pretty lightweight user and uh again going back to security maybe on the back end you would need to save additional information on each user where it makes sense to kind of hide it away in a satellite search data type yeah I don't think it's entirely straightforward I would say both cases are are just just as valid really yeah yeah awesome um so that will do it for this um Pato thank you for joining us I really appreciate it um I will try and put your links uh where people can find you uh you know whenever I post this video and whatnot um I already posted your Twitter link above so check them out there I'll just do it again real quick just anyone that wants to follow you he's a great follow um you got a great blog um you recently helped the bubble update the documentation so thank you for that God knows they need more help there so thank you for that doing God's work uh so thank you you also helped recently with the bubble certification help build help them build their certification do you want to say there are a couple quick words about that process as it's getting ready to be open to the public soon uh you mean the the certification specifically yeah uh yeah no I I helped you know kind of set up the certification in terms of what kind of questions do we want to ask and we want to get relevant scenarios all of that I guess the main thing I want to say about it is the feedback we've received so far is pretty good uh but I hope everyone can just agree that we see this as a version one right so if you take the certification and you just enraged that this is not what you wanted you know you didn't understand the questions they were totally relevant something like that we're totally open to feedback right so say this as the first version send us feedback and we'll continue to update this as new features come in and as we get user feedback so uh yeah great yeah okay also please check out the updated manual because there's a lot of hours that have gone into updating that and we're not finished yet just yeah I I recently um built this tool I'm gonna post another thing at the bubble certification that I took from the updated manual I created 90 questions from the updated manual and then created this uh quiz and then I show if you get something wrong I show you the right one and it's totally free in preparation for your quiz that you built for bubble certification so this is like if you want to take that quiz I just post in the chat it's a good way to test yourself before spending the fifty dollars to take the bubble certification one to um you know fine tune your skills there but otherwise you've been amazing for the Noco Community bubble specifically Thank You For All You've Done For What since like 2016 2017 now 16 yeah you're an OG thank you for you know guiding the way for the rest of us and thank you for joining us today um everyone else for joining us thanks for following along uh our YouTube channel no code Alliance um follow me on Twitter at JJ Englert and uh everything else so thank you for tuning in today guys and we'll catch you in the next one see ya
Info
Channel: JJ Englert | NoCode Tutorials
Views: 5,037
Rating: undefined out of 5
Keywords: bubble bubble.io tutorials nocode, bubble.io, bubble, no code, nocode, bubble.io tutorial for beginners, bubble.io for beginners, bubble.io tutorial, no code apps, bubble.io tutorial 2020, no code for beginners, how to build apps with bubble.io, how to build an app with bubble.io, no-code, saas, no code tutorial 2021, what is no code, bubble.io custom states, bubble tutorial, startup, webapp, apps without code, bubbletutorial, entrepreneur, app development, bubble app builder
Id: 3YrLuCDYa0k
Channel Id: undefined
Length: 71min 35sec (4295 seconds)
Published: Thu Aug 03 2023
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.