Satellite Data Types in Bubble

In our last Bubble.io article, we looked at how we can use the Data Weight analogy to visualize how the structure of our Data Types can affect performance. But what do we do with the information?

What is a Satellite Data Type?

Satellite Data Types is another term we introduced in our book The Ultimate Guide to Bubble Performance. In short, they are extra Data Types that you set up to serve a specific purpose, usually unbeknownst to your Users. A typical use case is when you work with a Data Type that has a high Data Weight (containing lots of unstructured data and fields), and your Users also need to frequently and quickly search for that Type.

Returning to our example from earlier, we’re setting up an online magazine with thousands of articles. The articles can be any length from a 5-minute read to 45 minutes, thus containing potentially large volumes of unstructured data. Our magazine also has an advanced search feature, where Users can quickly search for articles that may interest them. In that case, we have what we call a Requirement Conflict. Our Data Type needs to:

• store a lot of unstructured data
• be lightweight enough for quick searching and displaying

As we set up the requirements for this Data Concept, we can easily identify the conflict here: a high data weight slows down searches. In some cases this can be an acceptable compromise – other times you need to rethink your database structure to prepare the Data Concept to fulfill both requirements.

This is where Satellite Data Types come in.

Satellite Data Type for searching and storing

The solution to the predicament above is to separate the two requirements (storing lots of data and searching quickly) into two different Data Types. This is where we’ll return to the Data Concept model – we’re going to set up two separate Data Types, but to our Users, there’s still only one Data Concept: the Article. To keep the two Data Types separated, we’ll divide them into two categories:

The Data Container

The Data Container is the Data Type that contains all the heavy data we need to store, such as the Article HTML/BBCode content. We don’t mind that this one can end up heavier, as we’ll only ever load one at a time.

The Search Data Type

The Search Data Type (the Satellite) contains a more lightweight version of the same Article record. There are two things you’ll need to consider when setting the Type up:

• What fields do you need to search for this type?
  For an Article, typical fields would be the header, the author and perhaps some sort of tags and/or categories
• What fields do you need to display the search results for this type?
  You may need to include fields not needed for searching, such as a thumbnail photo, word count or whatever info you want to show in your results.

Whenever a User searches for Articles, Bubble will be looking for the Search Data Type, and whenever a result is clicked to view or edit the full Article, Bubble switches to the Data Container. As illustrated below, we don’t need to load the Type with the high Data Weight until the last step.

To keep the two Data Types in check, we can set up workflows to update fields on the Search Data Type whenever the Data Container is changer, or better yet – use Back-end Triggers to keep them always up to date.

There are several scenarios where this can be useful – let’s have a look at some of them.

Other scenarios for using Satellite Data Types in Bubble

The important thing about Satellite Data Types it to not think of them as search types or data containers. These are simply two common use cases, but the important lesson is that your Data Concepts don’t need to match your Data Types – you’re free to set up your database in the way that serves your app best, not in the way that your Users imagine it to be.

Site-wide search is another scenario where Satellite Data Types come in handy. In the book, we use TripAdvisor as an example; from the same search bar you can search for countries, cities, attractions, hotels and restaurants. In Bubble, this would mean performing five searches simultaneously – hardly efficient. But you can use a Satellite Search Data Type to combine multiple Data Types into one searchable Data Type, allowing for site-wide search for as many different kinds of records you want.

Satellite Link Data Type is a similar way to combine several data types in cases where you need to link different data types to each other. Let’s say you’re using one of the Rich Text Editor plugins that support tags for example, and you want to be able to tag multiple data types, you can set up a Satellite Link type that “represents” multiple Data Types in a search.

For more scenarios and the full process for structuring your database, you can check out the full chapter in The Ultimate Guide to Bubble Performance.

Satellite data types and workload

When Bubble introduced the workload metric, it added one more dimension to how we need to think about data structure. In particular, the amount of data returned by the database can now affect how much you pay for your app’s hosting.

Satellite data types can be a highly useful and effective way of lowering that cost, by taking data types with a high data weight, and dividing it into one data container (which contains all the unstructured data), and one search container, which containts only the fields that you need to be able to search through and display in a list of results.

Let’s return to the example of a blog or article website: in many scenarios, you’ll want users to be able to search for published posts, and return a list of relevant results. Depending on the number of results, the amount of data downloaded can potentially be big, and satellite data types would make sure that you only download that data when it’s absolutely necessary: that is, when the user actually opens the blog post to read it.

As outlined in the article on data weight, plugins like Zeroqode’s Fuzzy Search function by downloading all the records from the specified data source to the client and performing the actual search on the user’s device. This means that if you’re using the plugin to search through 1,000 articles, the entire list of articles is downloaded every time the page loads. When you factor in the number of users and page reloads, the cumulative amount of data returned by the database can grow significantly, even if each individual record isn’t particularly heavy. At this scale, the plugin’s data source can begin to noticeably impact your app’s total workload.

Before taking action, it’s essential to assess the actual volume of data being downloaded. Scenarios like the example above, involving large lists of results, can indeed drive up workload costs. However, if you’re only handling short lists of records, implementing satellite data types might introduce unnecessary complexity. If your app is live, use the workload metrics panel to determine whether searches are consuming a significant number of workload units. If they are, adopting satellite data types may be a worthwhile optimization strategy.

The way to think about the amount of data, is to go through the following steps:

• Search data volume: reflect on the size of each query: how much data is returned by the database. If you are using lots of constraints and only downloading a small subset of records, the total data weight may not be big enough to warrant satellite data types.
• Frequency: how often does it happen? Do you perform the query every time the page loads? Every time a user searches for something? Performing a query with a high data weight occasionally will not necessarily make any meaningful impact on your total workload consumption: it’s the repetition that really starts popping up in the metrics charts
• Server-side queries: keep in mind that returning data from the database does not only cover data sent to the device. Even if it happens in a server-side-only scenario (such as in an API workflow), the amount of data returned by the database is still calculated and translated into WU.

As you can see from the above list, the workload metric by itself should not automatically mean that you restructure your database and implement satellite data types. However, if you frequently perform searches on data type with a high data weight, satellite data types can drastically reduce the cost associated with the number of characters returned.