The App Build feature in Kumulos is a mobile Backend-as-a-Service (BaaS) on which you can very easily and quickly build and host your App Backend. App Build provides secure, scalable SQL based data storage in the cloud that can then be accessed and manipulated via a REST API and/or RPC API methods from one of our many client SDKs including iOS, Android, PHP, Windows, OSX and more. This leaves you free to focus on building the rich UI and UX that your clients crave, without having to worry about the hosting and availability of your app backend.
In part 1, we looked at how to design the relational data model for your app backend with Kumulos. Now, in part 2, we’re going to use these example data models to implement your app backend in Kumulos, showing how this then allows related data to be retrieved from a single API method.
Implementing one-to-many relationships in Kumulos
In part 1, we used the example of a mobile application that allowed users to upload and share photos to illustrate how the one-to-many relationship can be used to model related data. We also showed how this relationship can be implemented using a Belongs To field. We’re now going to look in detail at how to implement this data model for your app backend.
First off, we need to add a table to store a user’s name and the date of their birthday.
Next up, we need to create a photos table, containing a data field for the photo data, a title and a description.
A photo has a photographer who took the photo, and any given user has a collection of photos. The Belongs To field is used to express the one-to-many relationship as follows:
This record belongs to ‘Users’ as (their) ‘photos’. This record has a ‘photographer’.
When a user is deleted, any photos that they’ve taken will also be deleted.
We can extend our data model further and introduce the ability for users to comment on photos. To do this, we need to add a comments table to store comments on photographs.
This table used two Belongs To fields to implement two one-to-many relationships. 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.
“postedComments” is used instead of “commentsPosted” because Kumulos determines the relationship type from whether or not the word in the “as” section is singular or plural. So, you must use phrases ending with either a plural (for one-to-many relationships) or singular (for one-to-one relationships) noun.
Implementing many-to-many relationships in Kumulos
In part 1, we used the example of a mobile application that allowed users to share their favourite meals to illustrate how a many-to-many relationship can be created using two one-to-many relationships. Lets look in more detail at how to implement such a data model for your app backend.
Lets add a table to store information about people. Essentially we want to know their name and why they like food.
We’ll now add another simple table storing a title, description, and the name of a chef who is famous for the meal.
Now, here’s where the magic of this data model happens. We add a favorite meals table to store the 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 connoisseurs
So, to select a person’s favorite meals, you should select from favorite meals (including the meal record) and filter the select by the person’s ID. Similarly if you want to know who likes a particular meal, select from the favorite meals table (including the connoisseur) and filter by the meal ID.
Because a favorite meal belongs to both a person and a meal, if you delete a person then the entries for their favorites will be deleted but the meal itself wont. The same is true if you delete a meal. Any people who like that meal will stay put but any trace of them ever liking it will disappear.
Fetching related data from your app backend
Having added Belongs To fields above to implement the one-to-many and many-to-many relationships in your app backend, you can now exploit these relationships to fetch related data from your app backend with a single API method. When you create a new API method with a select action, the API editor will allow you to include records linked by “Belongs To” in your result from select actions.
Using our mobile application for sharing photos as an example, we can add a new API method on the photos table.
Then, we can check the comments box to say that we want the related row(s) from the comments table returned with each row from the photos table. Neat huh!
In Part 3, we will look at how we can go a step further and filter the data you fetch from or update in your app backend based on the data it is related to. But again, if you cannot wait until then, further information can be found in the docs.