In part 1, we looked at the principles of how to model the relationships and data that your mobile app backend will store. Then, in part 2, we looked at how to implement your mobile app backend in Kumulos and access data via API calls from your mobile app. Now, in part 3, we are going to look at app backend best practice, showing how to filter the data returned to your mobile app by exploiting the relationships you have designed and implemented, helping realize the full potential of your Kumulos-powered Mobile App Backend. In other words, make Kumulos do the work so neither you or your app has to!
Filtering by related data
In part 2, we showed how to include related data in the result set returned by your API calls. Then, when enumerating over the result set in your mobile application, it is straightforward to use the related data to determine how to process and display the results. However, in many use cases it does not make sense to waste bandwidth and processing time fetching data from your mobile app backend that is not required. App backend best practice is to filter the data included in the result set by the data to which it relates. We’ll now show how this can be done for each of the relationship types you might use to model your data in your mobile app backend.
App backend best practice for one-to-one relationships
Using the biographies example for a mobile application allows users to enter a biography. App backend best practice would be to store the biography in a separate table (so its not returned by every API method that selects data about your users). Each Biography entry belongs to a User, and each User has a Biography. This is a one-to-one relationship.
Now, lets say the Biographies table stores details of which city a user is from, and you want to select all Users that come from a particular city. To do this, we’ll create an API method working on the Users table.
We now want to add an additional input parameter for “City”
Finally, drag in a Select action with a filter on the City field from the Biographies table.
Kumulos realises that your User has a Biography and therefore allows you to search the fields of Biography from the Users table. And that’s all you need to do to filter your result set by related data – app backend best practice really is that simple.
App backend best practice for one-to-many relationships
Remember our photo sharing app that allowed users to upload and comment on photos? Lets quickly look at the table structure for that again…
Another Users table to store the name and birthday of the photographer as well as a photos table comprising a data field for the photo data, a title and description constitute the main elements of this table. The relationship expressed is that the photo has a photographer who took the photo, and any given user has a collection of photos.
When a user is deleted, any photos that they’ve taken will also be deleted, but not any comments made on those photos, which are stored in the comments table. This table is essentially just two relationships and the actual comment text.
First, we say that the comment has an associated photo, and the photo has a collection of comments. Next, we say that the comment also has a creator (a user who posted it) and therefore each user has a collection of posted comments.
Because a comment belongs to both a user and a photograph, when either the owning user or photo are deleted, the comment will also be deleted.
Okay, so we want to retrieve photos and comments associated with them. There are two ways to do that and which one to choose will very much depend on your mobile app. The first (and most straight forward) is simply to add a new API method on the photos table that also returns related data.
Drag in a select action and in the related data section, tick the ‘With comments‘ box. Now, when you select photos, you will also receive all comments for each photo.
While the above approach is the most straight forward, it may not be appropriate for your mobile application. For example, if the photos are shown in a list or grid view and comments are not shown until you click on the photo, then it doesn’t make sense to waste bandwidth and processing time retrieving comments when they may not be required. App backend best practice would be when a user clicks on a photo, use the ID of that photo as a filter on the comments table. Add a new API method on the comments table.
Select the input parameter ‘photo’.
Add a select action with a filter on the ‘photo’ field.
Kumulos realises that comments belong to a photo and therefore allows you to filter the comments table based on the dynamic property photo – quick as a flash!
App backend best practice for many-to-many relationships
A many-to-many relationship is a composite relationship of two one-to-many relationships. For this, we’ll use our favourite meals example where many people like many meals, we build two one-to-many relationships with the following tables. Firstly, a simple table to store information about people, their name and why they like food.
Then, another short table definition storing a title, description, and the name of a chef who is famous for the meal.
Finally, the favorite meals table stores a link between a person and a meal. It also stores what the person likes most about the meal.
The many-to-many relationship between people and meals has been captured by these two one-to-many relationships:
- One person has many favorite meals (through connoisseur)
- One meal is the favorite dish of many connoisseur
Now, lets say we want to find all people who like a variation of a popular meal. We’ll create a new API method working with the People table.
Next, we’ll add an additional input parameter “meal” that will hold the title of the meal we want to search for.
Finally, we’ll add a Select action with a filter on the “title” field in the “meals” table. We’ll use the containing operator to filter results where the “title” of the meal is like the input parameter “meal” (via the favorite Meals tables).
Because of the M:N relationship between People and Meals (stored in the favorite Meals table), Kumulos will let you search for People and filter on the Meals table. It does this by implicitly linking up through the favorite Meals table. Scrummy!
Mobile app developers and development agencies use Kumulos for their mobile app backend for a variety of reasons. Using Kumulos saves time and money during development, leaving you free to focus on building the rich user-experience that your clients demand (that’s the bit you’re good at). Using Kumulos also gives you access to an affordable, scalable, secure and robust server-side infrastructure that scales automatically with the user base of your app and, in the unlikely event of a problem, we get up in the middle of the night to fix it so you don’t have to (that’s the bit we’re good at).
This series of three articles has illustrated how to design the relationships and data model for your mobile app backend and then how to implement your mobile app backend in Kumulos and access data via API calls from your mobile app. Now, with app backend best practice, you can realize the full potential of your Kumulos-powered app backend so that instead of worrying about load-balancers, database servers and uptime, you can focus on building great apps.
If you have a question or would like to know more, please do get in touch – we’d love to hear from you!