.svg)
00:00 - Start
00:20 - Introduction
01:34 - Agenda
02:24 - Application Planning
08:45 - Application Architecture
10:05 - Frontend
35:30 - Backend
49:50 - Summary
Hi there, I would like to welcome you very warmly to our next episode of our JUST No-Code podcast. Today we're going to cover a topic that's more technical than business, organizational or that sort of thing. Today we're going to talk about exactly how to take care of the proper performance of no-code applications. We will go through all aspects of such applications that you create using no-code platforms. Because how we approach their development is very similar to how we do it in the traditional approach, that is, we have to take care of such aspects as proper database structure, like proper performance, flipping certain things between the frontend backend between the server and the user device. Of course, we have to approach planning accordingly. On the other hand, I also want to tell you today about some important aspects that are specific to the world of no code applications, especially platforms like Bubble and Xano. As I said, the topic today will be a bit more technical. Of course, we will go through topics such as planning.
Obviously, every application we develop has to be planned properly. We'll talk about how to take care of performance on the Frontend, that is, after the part of the user that he de facto touches, that he sees. How to communicate with that user?
How to make sure that these applications on this Frontend don't muddle up, so called, so that they work properly? And we will talk to each other about performance on the Backend, that is, how to make sure that the application already on the server side also does not delay us in any way or eat up server resources in some terrible, ridiculous way. So I invite you very cordially. Today's episode begins. Okay, so let's talk about planning at the beginning. Whenever we start working on a new application, we should think de facto about what this application will be about and why we should do it. As you know, any application, any type of application whether it will be a CRM Client Relationship Management, whether it will be some kind of online store, whether it will be a task management platform, whether it will be some kind of job listing platform, whether it will be a platform for managing employees in a company or resources of a company must be properly planned. It is very crucial that when we start, we approach the development of applications in general.
We should, of course, ask ourselves first what the application is, where the de facto points that will put the most strain on this application will be?
It is known that screens such as the login or registration screen are not likely to be the screens that are the heaviest or perform the heaviest workflow in our application. So we should think about ok, where do we have those points in our application where possibly these performance issues can occur? Where are our users hoping for something to happen quickly? And where are the de facto points where the user will be aware of it or will be forced to, but properly informed that they will have to wait for some action to be performed? You have to keep in mind that no matter what kind of application you would create or how much infrastructure you would have available you can always hit a point that will simply require time to execute and this time will not be counted in seconds, but, for example, in minutes in hours. And it is these points that need to be properly planned. How to approach them? What should be included in them? How to inform the user how to break down this whole workflow between this front end of the application, i.
e. what the user sees, and how between the server, i.e. what the de facto user does not see, but happens somewhere outside his de facto scope or field of vision.
So we always need to plan these aspects carefully for ourselves. Of course, in planning, we have several other aspects that we should take into account and which we will also talk about a little later in our podcast today. Namely, if you plan the application, you will also plan the structure. If you will be planning the structure, you will have to think about whether the application will be a so-called Single Page or Multi Page, whether to make the structure of the database you will be doing now, whether you just want to do it as soon as possible, because you just want to implement the idea in the shortest possible time, which is also ok, but it also has its downsides such that if you do not take care of the right structure of the database at the beginning, because you just want to do it as soon as possible to make it work whatever and not take care of, for example. to make the base more performative, more efficient in the long run, so that you can easily expand it with more things.
Well, then the problem will possibly arise later. Of course, you can approach it like this I only implement the idea now, and if the idea works, then there will be funds and time for redevelopment. Well, but this is not always the case.
And we will also talk to each other about all these aspects today, because they are crucial from the point of view of just planning our application. On the other hand, what I want to emphasize, and this is the first point, which is short, but very factual and very important. You must remember that planning always our application is a key issue. What a lot of people deprecate at this early stage is that if we don't take care of these very applications at the very beginning, we will potentially have a lot more problems later on than if we just spend a day or two to properly plan whether it's the structure of the application, or the database, or the pages, or how this workflow as a whole will be distributed between the parts or between the modules of this application. And you must always keep this in mind and I will emphasize it. I will repeat it for the third time. Planning is the key issue. If you or your customers say that for them it's not crucial, that they want to go as fast as possible, then you should raise a red alert, say hey, okay, I understand that velocity, that this speed of software development is crucial for you, but let's at least plan some basic elements of this.
So that they work in the right way, because it may turn out that if we do it the wrong way, do it quickly, without thinking in any way about these aspects, then later we will simply have to spend twice as much time on rebuilding this application, or even worse, building it from scratch. De facto this will mean that we have to spend twice as much on this application, and de facto we will end up spending probably three times as much. So remember, please, I emphasize planning is always a key issue when it comes to app development, because apps are not something very simple. Unless we are creating a very simple app that we are able to create in a week, which of course is a very strong rivalry of app creation. Planning, on the other hand, is crucial because an app is a living organism. If we don't take care of the heart of the application, that is, for example, some databases, then later we will simply end up with inefficiency, anemia of our application.
So remember I am repeating this for the umpteenth time, but this is really a very important issue. Planning is the key issue.
If we've got that out of the way, what I'm going to talk about today is the division of applications, the division of this performance, this application performance into two areas. We have, of course, the application area, which we talked about in one of our podcasts. This is the Frontend, which is what the user sees, where the user interacts with our application. That is, everything that he sees on the screen of his computer or his phone, and also we have the Backend, which is where things take place without the user's participation, which the user does not de facto see, which happen on our server. Of course, resources in the initial stages of application development, when our idea is not yet realized, are also severely limited, and we should take special care of their performance. But we should also care and have it in our heads that if we don't take care of performance now, then later we will simply have to, for example, pay twice as much for server maintenance.
Why? Because in order to process the same things, if our application does not have a properly prepared performance, properly the specifics of that performance, we will simply need more processing power.
More capacity equals higher monthly costs to simply maintain those servers. So we know we have the Frontend, we know we have the Backend, and that's from the Frontend. Today I'm going to start this conversation around how to take care of just that performance, so that we can make sure that the application is running properly. And the first point I would like to discuss is the pages. As you know, every application consists of different pages. The web application that you create has various sub-pages that users deal with, such as a landing page that presents a price list, some information about your application or your company. Yes, this is a page such a typical business card, to which users do not yet log in in any way. They simply see your application there for the first time, e.g. it is, of course, a login registration page, there is also a page that is available to users already after they have logged in. And now yes. Each application should be broken into several pages, because as I said, they should be separated from each other, e.
g. functionally. That is, we have this landing page on it rather than hiding any stuff behind a Paywall or behind this login wall and so on.
This is simply our business card, which should be light weight, mega light, so that it reads mega fast. The login page should also be a separate page that the user goes to in order to log in. It will be a separate page. This will already come from the very structure of our application, which we should plan for ourselves in advance. Well, and the page that is already available after loading. As you know, every time a user goes to another page, this page has to load. This means that it takes some time. The more the user has to navigate between different pages, the more time he will de facto waste. Well, because he will have to wait for every single page to log in. How? Well, of course, it's natural for every user that between the login page and what's available to him after he logs in, there's some time that the application has to take to reload that content, make that content available to him, and so on. Well, because it is verified whether he is he that has been logged in, he is redirected to some place accessible only to logged-in users?
This is where we are at, where the user is already counting on the application to work great. And this is where we're going to take a little pause, because I'd like to tell you about that right now and make you aware of it. For those who don't know, apps can be structured in different ways and what exactly does that mean? We have an approach that is called Single Page Apps and Multi Page Apps. Single, as the name suggests, means that we have one page, literally one page, where all the functionality is. Now if you ask how it is a single page, If in multiple applications I have a side menu even after logging in I click on it and I see that there is different content on that page. How does this happen? Well, the de facto thing about this approach is that we actually have all the elements on one page. Here we have, let's say, such a simulation of the menu, it's not even a simulation, it's just a menu, but when you click on a menu item, another page should be displayed to you, we don't reload the user to another page, we hide some content.
From the user's point of view and we show him other content. Remember that every content in our application is grouped into some container, into some group, so all those items that, for example, relate to the page my profile, user list, order list are. We just have a container, which is called, for example, order list, user list, my profile, and we just hide this container from the user and show him another one. That way we just don't have to reload that content, because it loads behind that first user login. We load all these elements, and they are just hidden. And when the user clicks on a menu item, that's when we show him that group. And that's the Single Page approach. This gives us the impression to the user who uses our application that he's going to see how fast everything works. As I click immediately I can see everything. Of course, still the same things, and we'll talk about that too. He sees on this Single Page, where he has, for example, a list of users or whatever.
They have to be loaded, they have to be loaded. But that's a little bit different and we'll talk about that later.
How to make here also these things load in a very fast way. On the other hand, the transition between pages itself is very fast, and on the one hand it's a super approach, because of course then users say, see this is how it works, it just works like a storm. I click, I can see everything right away. On the other hand, you have to remember that if you load there views of 20 pages, 30 pages, 15 pages or something like that. It always depends. Of course, also what is in those containers. Well, because a container is unequal, a page is unequal to a page, then you have to remember that this first loading will be much longer, because it means that de facto at this first login, at the first loading of the page we have to download all this information from this server. On the structure of the page and what is on it de facto. Of course, as long as the element is not visible, we do not download the data, so de facto we do not burden the user or his connection with the fact that he also has to download all the data that he would see there.
Well, but the structure of the page itself, that is, all that HTML, CSS, etc.
Then it is already downloaded as much as possible. Of course, this is a benefit, but you also have to remember that if the page is too heavy and, for example, we get to a situation where our page loads more than 5 8 seconds, then the user will say gee, okay, it takes a while, it takes a while. Of course, if this happens once, and users spend all day in our application, well, it's always a matter of balancing Multi Page. Whereas the approach is that each of those views that I said, that is, the user list, the order list, my profile yes, then with each click we would have the user redirect to a different page. That is, the user would just come and wait for that page in between to load. And here we have the fact that, of course, this page will load faster, because it will be lightweight. Each of these individual pages, but more often there will be loading reloading of the user between all these pages.
And here I do not have de facto myself. In my opinion, there is no such thing that one approach is better than the other.
Because you also have to remember that such disjointed pages help us, for example, to maintain that users can certainly access only what they should have access to. It allows us to separate certain data from each other. It allows us to separate functionalities, because, for example, let's recognize that our application has functionalities that are available at different subscription levels. Then it's easier. Maybe sometimes I say, maybe sometimes, because it's also not a rule to keep access to these functionalities away from users who are on lower subscription plans. On the other hand, as I say, there is no rule here and there is no one right answer as to which approach is better. So you already know what the difference between Single Page and Multi is. You know exactly how it works and how it differs. You also have to remember that our overriding goal is to make the pages lightweight, and in the case of singles this is hard to maintain. Well, because we simply load multiple pages into one and use, for example, parameters in the URL to display the appropriate groups, hide containers accordingly, and so on.
So we have to make sure that
If we are downloading this data structure, so that along with the data structure we do not download data or lists of elements that are invisible. Well, because that would mean that then the page with the first login will download very slowly, that is, de facto we load the structure of the whole page, of course. We have it a little more, but it only occurs once. This is some kind of benefit. Something for something is always there. On the other hand, we have to make sure that the data does not download along with those elements that are invisible, so that the data only downloads when the elements are visible. And this is what you have to keep in mind. And this is a very important aspect that you have to pick up on the planning of your application. What the de facto structure of this application and the structure of the pages will look like, so that the user navigates through this application in a fast, efficient way and does not feel that every now and then he has to reload between different pages, because this is de facto annoying.
And on the other hand, so that this first loading is also not too long, because you also have to ask yourself how often users visit our site, or rather, they also use the site by simply entering it, firing it up once and working with it all day, or every now and then they enter, leave, enter, leave.
Well, because it affects what kind of perception they will have of the application and how it loads. So that's it when it comes to the Single Page versus Multi Page approach and planning for it to be lightweight, to load quickly and to just not annoy users in any way most simply put. Right. What to do, on the other hand, to make the pages lightweight, just like HTML itself? CSS are rather lightweight elements. As long as we don't overdo it, because here we can also overdo ourselves, but on our pages we very often add various graphics, images that weigh something there, and they are the ones that very often cause performance problems. You have to remember that if you allow users to add various records to, for example, your application, which are displayed as some kind of listing or whatever, and users can add files there, for example, or they can add images there, then you have to or should take care of those images that users add. Remember, users are not technical.
Users will very often upload images that weigh 10 MB, 20 MB or, horror of horrors, even more.
They're going to throw a lot of different things in there. It's up to you as developers of this application to make sure that these items before they go to the server, who will be downloading from their perspective, that they are appropriately lightweight. On the other hand, as developers, this is one aspect that we will talk about a little later. We, on the other hand, as developers, if you are creating, for example, some landing page or there should be some graphics or some files or whatever on the site, you should also make sure that they are not heavy. You have to keep in mind that if you have a graphic on your site that weighs a few MB and it's one graphic that weighs simply 5 MB, 10 MB or whatever, it's going to slow down the loading of your pages a lot, because simply that page is going to be heavy. And now still multiply that by the number of users and that. If the server is serving this page to users then he suddenly has to send a lot more of this data and your users have to download a lot more of this data.
So you have to remember that, first of all, the images you upload should preferably be in PNG format or since they are images.
These are the graphic formats that are the lightest and most recommended when it comes to the creation of just web applications or websites in general, because they are lightweight, and provide a very high resolution. On the other hand, of course, still such a format is an image of images or icons that we ourselves, which is a pure HTML element and allows us to upload. This is a so-called vector graphic, which allows us to scale it to different sizes, but in the background is recalculated just the scale of what scale the element is displayed at, and it simply always retains its appropriate, its appropriate quality. It is just always very clear and appropriately appearance. So this is another aspect that you have to take care of. First of all, to make sure that the images or files that you build for the pages that users download are lightweight and that they don't burden that very first page load. So this is another aspect of how to make sure that these pages are lighting lite, that they are as light as possible and that they can be loaded or downloaded very quickly simply from the server.
You have to remember that every time you go to a page, you are downloading the content from the server.
You simply do the downloading of it to your own device. And now I'm just going to move on to what I talked a little bit about at the beginning, which is searching and displaying information on the Frontend. And we're going to talk here just about how not to create searches, displaying information and so on. Filtering or pugination. How to just take care of the data that we retrieve. And I don't just mean. How the page looks, but also the data that we display on our page. Is it just lists of elements, or already some detail of some single element or something like that? How do you make sure that this data also loads quickly and on this Frontend? Let's start perhaps with just what I've already said a little bit about, which is what our users upload. Very often in applications or on various sites we have to deal with lists. That is, we have a list of some items, whether they are, for example, a list of jobs, or a list of users, or any other list.
We are the ones who download this list. And here again to the list we have different approaches. On the other hand, even before we get into what approaches we have to the list, let's talk about what users upload to our platform.
You have to remember that in order to allow users to create content on your platform, you also have to have some control over it. Users don't think about what they upload, how they upload it and what effect it will have on the performance of your site. If you let users upload text and don't embrace it in any way, there may be a user who uploads text that is a million characters long. What does it de facto mean that it has a million characters? It means that it will weigh quite a lot, and a user who wants to download, such information may have a little problem, because he will be downloading a text that has a million characters, and on top of that a graphic that weighs 20 MB. And what will happen at that point? What will happen is that he will simply wait a very long time to download such information. So we as developers should make sure that if you allow users to create content freely, and this is a public application that any untrained user can log into, don't make him aware of what he should do.
You are the one who should take care to limit what he can de facto upload.
That is, for example, if you give the opportunity to upload images or some files, for example, limit their maximum size, or if not limit this maximum size, then compress it. That is, after uploading to you on the server as compresses or reduce its quality? Something like Facebook does? Surely you have noticed that if you are using Messenger and you have a super graphic taken with the latest Samsung or the latest iPhone, where the camera quality is super and on your device this photo weighs 50 MB, when you upload it on Messenger it heavily loses quality or Facebook? That's because it's Facebook that compresses that photo heavily along the way so that you don't just take the servers. You also have to remember that you also pay for the space on the servers, that is, for how many of these photos you can upload. So if you're going to let every user upload infinitely much data there, or infinitely large files, you're going to find that all of a sudden you're going to have a much higher cost of maintaining that disk space where that data is going to be added.
So that's it. In a word of how we should take care of what our users create.
On the other hand, let's talk about the listings right now. First of all, they are composed of the fact that we search our database for some information, so that this data loads quickly. Well, then, of course, our databases should be suitable for indexing. This is already a more advanced topic, more Frontend, and here I will not go so much into the details of what is indexing, what is casting and so on. Because this is not the topic for today. It is already a very advanced topic. On the other hand, you must remember that the more complicated rules you have for searching this data, the more rules for searching this data, the longer such a search will simply take. So you should avoid this. You should already at the server stage itself restrict access to certain data or, for example, display pre-filtered data to users, and if they want more filtered data in a more specific or more structured or more comprehensive way, then. And lower. It's not a very nice Polish word, but at the very beginning it loads you data somehow pre-filtered, so that this list behind reads very quickly, so that the user already has preliminary data.
And when the user wants to filter, you give him this opportunity. That is, he selects the filters, clicks, searches and then you show the loader and the user is aware that such a search may take a little longer, but by doing this automatically from the very beginning you don't load this application, that is, you avoid these complex, these very complex searches or heart contractions, heart contractions. That is to say, we have a nested search for items, because that also puts a lot of strain on the search performance of these lists. We also have the ability to filter these lists and filtering. Of course, we can do on the server side, which is much faster, but we can also do it on the user's device. Each of these approaches has its pros and cons. I will not discuss this one in detail. On the other hand, you must always be aware of the fact that you can filter the data just on the device side, and then it is the user's device that will be loaded, or on the server side.
So here, too, you have to approach this in a well-balanced way, to distribute it in the right way. So that on the one hand if you have a lot of users do not push everything to the server, because the servers may be overloaded, but try to leave some things for the devices to do on the user's device.
Sorry, I got a little confused here, so that simply relieves the load on your servers and leaves something for the user or his devices to do. The next element that can very much speed up the loading of data is pagination, that is, de facto it doesn't load you immediately all the items that are found in your database. Let's say there are 1000 of them, you just paginate them, that is, you display some part of this information, e.g. the first 10 records to the server and in the server's memory it has another 10 stored, so the user sees that he has 10 records, he sees that he has another pages he can visit and the moment he clicks on the second page so the next page loads another 10 records. And another 10 are loaded by the server to have in memory, so that de facto the user has the impression Hey, look great how fast this loads. Immediately I see 10, another 10 I click the third page, I see immediately another 10.
De facto it is done so that we display 10 records to the user and keep another 10 records in memory.
As he clicks it displays, but the server works for itself immediately, that is, it downloads another 10 records. This way we don't immediately download the information about the thousand records we have in the database only from twenty, which is much faster and will give us a response from that server much faster. So in this way we can make sure that the data all not only the application structure, but also the data that we will want to display to the user is downloaded in a very fast and efficient way. At the very end what I wanted to talk about when it comes to the topic of Frontend and keeping proper performance on the Frontend is clear communication with the user, and this is a topic I would like to point out that is also very important, and in many applications for some unknown reason it is very much overlooked or treated negligently. I don't know if this happens to you as well, but what I see in very many applications from various manufacturers is that if I click on something. Then I wait.
I wait, I wait. Nothing happens too much, it's not too informed, or the screen just types itself or starts to be behind such a gray, a little bit of such a gray blur.
Is shown ok. seemingly something is happening, but I do not know if the application crashed or something is happening and only after a while something this screen disappears and more data is shown. In my opinion, this is a mediocre UX and our job as developers is to always inform the user that something has happened or when logging in a few Login button. Well, and ok, I can see that the browser there on the wheel, because I pay attention to such things, that something is happening there, something started to load, and there is nothing on the screen. I clicked I can click a second third time well and something takes a long time. I don't know if I didn't click again, or maybe something didn't work. Also, very often the buttons do not have a reaction to the click, they just look the same all the time. So I don't know if I clicked or didn't click. I am not informed about what is de facto happening in our application. And here I would like to point out that in my opinion it is very important to talk to users through this frontend interface, to inform them exactly what is happening.
You have to keep in mind that users' frustration with what they think is not working or slow is mostly due to the fact that they were not informed that something might be slow. Users mostly have no problem with having to wait for something. If we tell them and clearly communicate for them. And what exactly is the issue? Just as I already gave this example of the login screen, I typed in my email, I typed in my password, I clicked login the button didn't react in any way, it didn't give any animation or any blow up of such a lifter that it was touched. That's first of all, and secondly, when you click it on the screen nothing happens, you just have to wait. In my opinion, a much better approach would be that if I clicked it, I got it. You know, such an organoleptic response, that is, under the title of the button lit up. It gave such an indicator image that I clicked I can see that I clicked. And secondly, for example, the loader appeared on the button, meaning I know that something is loading and I have to wait.
Of course, again if it takes an unknown amount of time, the user will start to get frustrated, but at least at this point he was informed that he clicked, that something is loading and only something will happen.
And this is the correct approach. Another thing is, for example, exporting something to PDF, to CSV files, and so on. Very often, if users want to export something, for example, they are not informed that something will take a long time, they click export pdf. 5-10 seconds pass and only the file has been downloaded, but on the screen de facto nothing is seen. And this happens in very many applications I observe or use. In my opinion, a much better approach would be again to turn on some loader or some board on the user's screen saying we are generating a PDF. That might take a while. Wait, don't refresh the screen, something users often do. If something takes too long to generate according to them and they have not been informed about it, that they should not refresh the screen, because it will interrupt the process that they will have to do all over again. We should in a clear way always or some elements or maps or something inform users in a clear way that something is happening and they should wait.
That way we just beat down their frustration, we beat down the number of packages they will send to us or email inquiries that hey, something is not working.
Hey, I'm waiting an awfully long time for someone to load and I don't know why. You have to remember that very often this is due to frustration and a lack of proper communication to users that something is happening, something is loading or that they have to wait. So those are the key elements of how our Frontend should be structured, so that it clearly informs users about what's going on in our platform and that it works in an efficient and super way. And I think we've covered the Frontend pretty comprehensively how we can take care of it and its performance. So now I'd like to talk about how to take care of that Backend performance. And here I'm going to go back to something that I also talked about at the planning stage, which is the database structure. Namely, this is one of the most important topics when it comes to applications, and I have noticed that in very many no code agencies or in no code approaches in general it is very often overlooked. And what is the reason for this?
Databases are very often presented to everyday users or developers or anything anyone else in an Excel-like way. And in an automatic way our brains of course turn on this monkey brain.
Reptilian brain that begins to associate certain information, relate to it, to certain associations, etc. My subjective opinion. Well, and because of the fact that we have this association maybe a little bit with Excel, that there are tables, where we create these databases for ourselves, that it is so easy. The way you can create a relationship between these data, that it's so easy to get to this data. Well, then people start to deprecate it a little bit and push it away. Okay, fine, then I have the structure of the database. I have all the data here, the information that I wanted to include here. So great, we've got it ready, It displays on Frontend, it works, it's great. And of course the moment you are alone and you create this application yourself and test it you + 5 of your colleagues or friends then how? Ej application did not test it will work super. It will work great because these data, first of all, are few.
Your five or ten can't generate the amount of data that half a million users will generate Or 10,000 users, or even a hundred users who have been in the app for half a year, because that's half a year's work of users, so it's hard to make up for that, if this data is going to make any sense or replicate or mimic this real data, then you think this app works great, that it's going to work great.
On the other hand, this is not true. In the long run you will see that you will start to have a very big problem. If you don't take care of the correctness of this database at the very beginning then unfortunately you will have a very big problem. And many complaining users who will simply stop using your application. How to take care of this database structure? Of course, I point out that we may face this pitfall that we are alone at the beginning, that there are few of us and that we start to use, so there nothing bad happens, because simply the infrastructure will cope with it and will not be too much burdened by it. Maybe in the beginning nobody cares too much about it. On the other hand, this is one of the most important things. What impact does it have? First of all, if the data structure is bad, and Bubble, for example, it works in such a way that if we have some record in the database that has 20-30 fields, then, unfortunately, if we display it on the Frontend, we retrieve all these fields.
And what does this de facto mean? If you have a list of users, and the user in the database stores information about name, surname, date of birth, date of registration, email address, password about whether he confirmed Kukiz, when he did it, and his home address, whether he has children, whether he has a wife, whether he has a dog, some description of his profile, profile picture, some other information?
Yes, links to social media is this data is getting a lot. And of course on the Frontend, where you can see. Okay, but I only display the user's first name, last name and his email address on the user list. Then you'll think you're only pulling out those three pieces of data. On the other hand, this is not true. The way it works with Bubble is that if you pull a list of users, you don't pull only the fields you see from the database, you pull all the fields. That is, if a user has 30 fields in him with this information like first name, last name, etc. And you display 20 users then you have to multiply 20 times 30, not 20 times 3. That is, not 20 times 3 fields that I display that is this amount of data, but 20 times 30. This already gives a completely different amount of data that we de facto download on the Frontend, that is downloaded by our user who uses our application. And you have to keep that in mind.
It's different in Xano, when we create some endpoint that we can query a list from the database then we already have control over that and we can say OK, if this is a query that has this parameter then I want you to return only these 3 fields and then we return this small amount of data.
On the other hand, you must have it in the back of your mind that you must always take into account that your database structure in the case of Bubble will have a gigantic impact on how many fields it has and what kind of fields they are, whether there are files there, whether there are images there, whether there is a list of files and so on. Isn't it Xano where I have control over what de facto my user will get in response, that he, for example, only gets these 3 fields and not 30 fields. Well that's one aspect that has a very significant impact on what your database structure will look like, because it also as I said the case of Bubble should look a little different and in the case of Xano it should look a little different. What I don't recommend, of course, is building, for example, lists of files in record-specific fields. Suppose we have a user and that user uploads documents to our platform. It's very many people's approach that they create an additional user data type field, where they give a File List field.
And all the files that the user uploads are uploaded there, and he uploaded 10 files there, 10 megabytes each, so a total of 100 MB.
What does that mean? It means that if I download one record with a user, I am automatically downloading 100 MB of data, because I still have all this information that is there, all the information. And this is a very bad approach, which I highly advise against, which is to keep lists directly in the records. It's much better to build a separate data type, which will have a relation, that is, information to which user the file information belongs to, and it will be a single record, because that way we have control over how many files we download, whether we download them at all, and we only download them, for example, when we go into the details of a particular user and download only those files of a particular user, not. Again if we display a list of 20 users then we download 20 times 30 plus still times the number of files those users have. So in general some sick number of data. So this is a very important aspect of our database structure.
And of course I'm not going to dwell on the database structure, because we could do a separate training at all, a separate webinar. These are also different databases of different notations. It looks even different in different no code platforms, because they use different structures underneath, different databases, different databases and so on.
So here we could do a completely separate training or a separate paper about it. On the other hand, I wanted to come back to such general points, which are of very high importance or very high significance, in terms of how we should take care and that we should always take care of this database structure at the very beginning, because if we don't take care of it, we will have problems sooner or later. Problems that will be very hard to unscrew, because the structure of the database is also taken into account on the frontend, and if we change the structure of the database, we will also have to make changes precisely in the structure of our application, which will be very troublesome at a later stage, where we will already have this application quite developed. Another aspect I would like to talk about is the so-called complex workflow, which is a complicated heavy workload. Very often I come across that these heavy workloads are done on the frontend, and first of all this is bad for the reason that they can take a lot of time, and secondly it is bad because then it is the user's device that has to do all these calculations, and we don't know de facto what kind of device our user has.
Does he have a super extra expensive laptop, does he have some old android or an old iPhone from 2010. Well, maybe 10 of this one I exaggerated, but from 2015, for example, and this device will no longer be as powerful, will not perform as well as our latest iPhone or our latest Samsung, well, because it will not have such computing power. Very often we forget this, we look through our prism. Okay, I tested it on my new iPhone, I tested it on my new Samsung and it worked great. In your case, yes, but your user may have a much worse device. A much older device that is no longer going to handle this so super. So rather these repetitive workflows, these heavy workflows, we should rather put them on the Backend and load the Backend with them. That is, pass this information to the Backend, and simply display the result on the frontend. And that's how we should restructure these workflows. It is very important precisely that we weigh when should the user device be responsible for doing some work, and when should the servers?
Because again, here we have to balance the fact that we don't want to push everything to the server, because it will be pointless to overburden the server and increase its maintenance costs.
Well, but we also don't push everything out to the user's device, so just balancing it between one and the other is very important. Of course, there are some workflows that require a very long execution time. Let's say we have a very large database and our user wants to export data from that database to CSV. Well, and it will take, say, 15 minutes. Should we do it on the frontend? Definitely no. Users won't always understand that it will take 15 minutes. They won't always be able to keep their laptop and the site open for 15 minutes, because the moment they leave the site, they will close it. This will also interrupt the workflow. You have to keep in mind that workflows on the Frontend are done as long as on that Frontend, where the user is logged in and has that tab open. The moment he closes that tab. De facto he also closes the workflow and they will all be terminated. So if, for example, we just have a workflow like this that might take a couple of minutes or a couple of minutes, we should display a message to the user saying Hey Listen, we accepted the execution of this, we know what you want to do, but it's going to take a couple of minutes or a couple of minutes.
We will send you notifications or send you an email. When we're done, we'll send you a link to the file you want to download so you can fix it at your convenience. When we're done processing your request, because it can take a few minutes. The user is informed, understands what's going on, understands why it will take longer, so for them it's ok, But we don't forcefully keep them on that open tab, because surely most of them will close that tab. We shift the responsibility to the server. The server doesn't need to have the user active to do his job. The moment it does its work it will send information to the user. So yes, we should structure that very workflow when it comes to the Backend and taking care of what should be going on there in our Backend simply. So that's the topic that deals with workflow. Finally, now that we've covered the Frontend and the Backend, I'd like to talk a little bit about. OK, and how do you check, how do you approach this for debugging in general?
Or to check where we de facto have a problem? Well, because OK, we also create these applications, We don't always have time to think carefully, and we also don't always what we come up with, or what we plan, will be right in practice, because we can't predict everything, we can't plan everything, and you have to keep that in mind as well.
On this planning also, there is no point you know, every comma, every dot to plan, because you are just not able to do it. So how to approach it, when we did something according to the plan, But it doesn't work. It just doesn't work. What to do, If it's going to be about the frontend, then of course we have Dev Tools in every browser, that's the kind of tool that first of all will show us what's going on when loading our site, the whole workflow, that is, what's loading, how much time it's taking, whether that time was therefore long because, for example, our workflow was waiting for something, or it took so long to get a response from the server? If it was a very long response from the server, well, we will know that we have a problem on the server side and it is somewhere there. We need to look for that cause. So that's how we can debug the frontend. Just look in these Dev Tools what de facto was being downloaded, how long it was taking and where de facto we had these longest, response times or longest response times.
And that's where we're going to see that if the problem is on the Backend, that's where we're going to see it, because, for example, we're going to know that response from Server took 10 seconds about 10 seconds, that's a very long time to load something quite simple, so why did it take so long?
Then we go to our server, so how can we debug it on the server. On the server, of course, we have to do these workflows and look at the server logs and look at how much each workflow or each step took time and de facto what that time was spent on. Yes, of course, I can no longer go into the details of where we will look for such answers, because we would have to discuss this on specific cases or specific queries. On the other hand, I simply wanted to draw your attention to where we can de facto look for answers in case something takes too much time according to our users, or according to us. On the Frontend Dev Tools in the browser, which are able to tell us a lot about how our application is loading, what is loading, what is taking how long and what is the source of this possible problem. If the problem lies on the server side, well then, of course, depending on where we have this server reviewing logs, reviewing cash etc.
To see where the de facto problem lies. So in conclusion today we discussed how to take care of application performance not just de facto no code, but in general how to take care of application performance.
I gave you a little tip on how to take care of the database structure. What is the difference in structure if we talk about Bubble or we talk about Xano. You know, each approach, each platform will be different, because also we can combine no code with traditional approach we can combine traditional approach with no code, so we will look for the answer very often in different places. We will do planning in different ways, because planning for each different database structure or for each different database solution will look different. And so on and so forth. But we discussed how to generally take care of the Frontend and performance on the Frontend, that is, on the user side. We discussed how to balance the workflow or all that data between the user's device and our server. We also discussed de facto how to take care of performance on our server or on the Backend side, which de facto has the biggest impact on performance on that side. So I hope today's episode was helpful for you and gives you an overview of how to take care of this performance.
I would just like to add from myself that as much as possible all these aspects are also taken into account in no code platforms and there with this performance.
If we take care of it, there should be no problem, even with hundreds of thousands of users. That's it from me for today. I hope you found the episode interesting. See you in the next episode. JUST No-Code Hi!
.svg){kind=small}
21 05' 49'' E
21 05' 49'' E
