I thought the same, I even change all my “Do a search for” expression to “Current user” or “Parent group”. That’s why I am asking. Because I read somewhere on this conversation that “Do a search for” is better as it performs the process on the server-side. Which I assume is faster? Not sure tho. It would be great to clarify this. Maybe @josh or other users with more knowledge regarding this can help us out
Yeah, logically thinking, I think searching for something in the current user would be faster than Doing a search in a whole database.
it looks prommissing. LOL at least the first paragraph is right on point. I think it could help. I will look deeper into it and get back here. Hopefully it helps, as bubble is awesome just to throw it away for this
1 Like
Exactly. It makes sense, however, I think it would depend where the search is performed, and “what” performs it. I think maybe opening a new topic about this would clear the issue.
1 Like
Personally, since I’ve been developing for about a year or two on bubble, I had a huge production app where it was SUPER slow, and I thought it was me using the “Do a search for…” function a lot, logically thinking I was like: "If many user’s a ‘Doing a search for…’ something at the same time it would be the cause of the slowing of my application, so what I did according to my instincts was to make fields inside the current user tab, so for example, I had a notifications type and inside the Users field, I created a new field where it’s type was Notification and made that a list.
Not sure if that made any sense lol
It is the opossite. Current user is faster.
4 Likes
Thanks for the clarification.
How does “Do a search for” compares to “Parent group…” If the parent group source data comes from “Do a search for”?
I ask because, some people said that “Do a search for” is faster than current user because “Do a search for” is performed on the server side, while “Current user” is client side.
1 Like
Other question that comes to mind is the Data base structure in relation with the speed and performance of the app.
For example, my app has a Type call “Publication” that is a form of post by the user. This type has many fields, more than 100 now, as it grew because there are different kinds or types of publications a user can make. Such as interview, article, artwork, and others. So this “Publication” type, has all the fields for the different types of publications, and a field call “Type of Publication” which Im referring to sort and filter values and actions on the app.
The question is: Should I keep the type “Publication” with all this +100 fields, or should I take the time and work to re-organize the data structure and associated workflows into types for “Interviews”, “Articles” and so on, to sort the fields for each kind of publication. And then turn this new types fields under the “Publication” type? (I need to use Publication type in order to refer to all the types of posts at the same time) Would it create a considerable improvement that makes worth the effort?
I hope it makes sense. Just trying to figure out what is best to optimize performance. I think is better to re-organize the data structure t however I wanted to ask before to get some advise
1 Like
Personally I use options to set up the ‘categories’ for the “publications” data type. So you have a data type publications, an option set labeled ‘options-publication-categories’ and on the publications data type you have a data field that is set to be the ‘options-plublication-category’.
For me this has made it easier to set up sorts, filters and parameters for the URL.
I feel like the ease of setting up my database and my pages themselves is the biggest benefit, and I really doubt there is going to be such a huge difference in terms of speed for retrieving the results.
Throughout my app, my pages are set up with a main group covering the entire page dimensions. This group has a data type set but no data source. The page load will take a URL path or parameter to set the data source of this main group on page load. Then all the elements within that main group are set to the paren’t groups thing as the data source.
This makes it very easy for me when I have my database set up in such a way that I have related data types as data fields for the main group. For example, my events page has a data type of event listing. Each event listing has a data field set to ‘event host’ which is a data type of its own.
On my events page when I want to call the information concerning the ‘event host’ I just say ‘parent groups event listing event host -’ then I can get all the information for that event host without needing to do a search for event hosts.
In your specific example:
You need to think first about how the app and the users interact. Are you allowing users to create their own publication type willy nilly and the app has no boundaries on the types of publications they create? Or are the users bound to creating publications that the app has already pre-determined as the type of publications they allow to be uploaded.
If you are setting boundaries, your users should be selecting from a menu the type of publication they are creating. For this, options are the way to go as they are super fast to load, much more so than a data type, for the purposes of selecting the type of publication the user is loading.
In that case, you could do as I mentioned earlier.
If you are allowing your users to create publication types willy nilly and they are not bound to any restrictions on the types they can create, you will have to think about how to limit the chances users are creating duplicate publication types. With that being said, I find it highly unlikely that you would be setting yourself up for disaster when you grow and the publication type list is 10,000 records with 25% of them as duplicates with spelling errors, capitalization differences etc.
So, most likely you’d be restricting the type of publications to a set list of types you allow. So, option sets would be the way to go.
If you already have all the data it is easy to switch over.
- Create the option set of publication types.
- Add to your data type ‘publication’ the data field for ‘option-publication-category’
- Set up a backend workflow to add the option publication category to the publication data type by matching the option ‘display’ value to the existing “type of publication” ( which I assume is a text value )
- Then in all of your searches and filters you can refer to the option type. One benefit here is when choosing the option to filter by you can see the options rather than needing to type in the display name.
One thing to keep in mind is that sometimes you need to call all options of that particular option set and then filter and grab the first item to get the specific one you may want when matching against things that are not the option set itself.
For example, I have option set of States. The display is the state name, and I have a lot of other stuff on each state name such as State Code, Flag etc. When I am matching the state name from a geographic address, I need to filter the state options to match the state name from the geographic address to call all the data from the option set.
Hope this helps. I know I went into more than what you asked for, so, bottom line is, it is faster to set one source and reference that source throughout the page and sorts/filter operations as you are not needing to query the DB again.
Imagine you don’t set a source. You have to ‘do a search for a thing’ every time you need to get data. So the DB is searching through all those things each time.
Imagine you set a source and use it to reference every time you need to get data. You search the DB once through all the things to find the one. Then next time you need data you say to the DB…‘Go to this thing and find this related data’
It is like a filing cabinet…wouldn’t it be easier to tell a receptionist to go to this folder in the filing cabinet to find the data rather than tell the receptionist go to the archives room and search through all the filing cabinets until you find the one with this folder and then open that folder and find the information?
1 Like
hey bro! Thank you so much for taking the time to reply my question.
So, from what you say, yes, the types of publications are limited to 6 types, from which the users can choose when posting. And I understand from your explanation that its better to keep the database as it is, even tho the publication type has +100 fields, some that remain empty after publishing content, instead of using list fields within the publication type. Is that right? So when the data is refer to in the app, the search is performed only on one type. I just want to make sure if I got it right from what you say.
1 Like
What would the list fields be composed of?
Why would some of those fields be empty after publishing?
This might be a personal choice in terms of how to keep things orderly and easy to manage, both from a perspective of building out the app and searching etc.
From what it sounds like, having empty fields is not the best choice, so it might be better to find a way to limit that by grouping the type of publication in a data type so that only fields pertinent to that publication type are available.
If your main goal is to be fast in retrieving data, which this thread is about, I don’t think that the differences would be noticeable unless you are doing a search for a publication type. If they are all on the same data type and the ‘publication type’ is a data field, then filtering will take some time to retrieve compared to having a separate data type for each ‘publication type’ because then you are just doing a search for that data type.
If you search for ‘publications’ and filter with a constraint of type ‘movie’ that will be slower than if you search for ‘movie publications’ because you have to filter.
1 Like
Ok, so: Publication type would contain for example Interview field that is a list of Interviews
And some fields would be empty, as I have it organized now, because some fields related to say “Interview” type of publication when a user publishes a “Artwork” type of publication. I hope it’s clear.
If your main goal is to be fast in retrieving data, which this thread is about, I don’t think that the differences would be noticeable unless you are doing a search for a publication type. If they are all on the same data type and the ‘publication type’ is a data field, then filtering will take some time to retrieve compared to having a separate data type for each ‘publication type’ because then you are just doing a search for that data type.
If you search for ‘publications’ and filter with a constraint of type ‘movie’ that will be slower than if you search for ‘movie publications’ because you have to filter.
Yes, that was what I was reasoning, that it would be easier and faster to keep data organized according to types of publications (interviews, articles, artworks and so on) under a publication type as fields that are lists of those things. So I think I will go ahead to restructure the database structure to save some time in the future.
Thanks again man
1 Like
So I found this after experience 5-10 second loads for a very simple page and seeing the same thing…
@Bubble is this getting resolved? I love the platform, but deploying a Bubble app that takes 5-10s per page load will kill my usage. I’m seriously concerned about going live.
4 Likes
If you are only seeing a longer load right after editing, that does not reflect the actual load time (because Bubble rebuilds resources on editing). For example, my site loads in 1-2 seconds. But when I make edits, and then load the version-test the first time after that, it takes longer. Based on my tests run on various computers, tablets, and phones (after edits and reloads) this is not indicative of what a regular user sees (they just see the regular shorter time).
On subsequent reloads, it should be much quicker. Try reloading the /version-test from your phone or another computer (after doing one load after an edit) on which you did not do the Bubble edit and see if you still get long loading times.
1 Like
Thanks. I tried that. Nothing changes. It seems to get hung up every time waiting for cloudfront per my screenshot. Makes me nervous about deploying.
Got it. If helpful, you can PM me the link and I will see if it loads faster on my computer, just as an A/B test. It is possible that there are certain resources/image files/plug-ins that may also cause a delay. I can try to see if something jumps out as possibly causing a delay.
Also I have seen that sometimes I can see with my eyes that the meaningful “paint” from a user’s perspective takes 1-2 seconds, but Lighthouse or similar tools say it takes 8-10 seconds. Of course, if it visually takes 5-6 seconds to load, something needs to change.
Sent! And really appreciate the second pair of eyes.
@GB44 @deadpoetnsp Did you guys get to the bottom of the issue? Curious to know.