Mobile Backend as a Service (MBaaS) Blog

Modeling Data Relationships in Your App Backend

Ever worried about capturing real-world relationships in your data? Establishing a useful data model for physical entities in the real world usually comes with the natural need to express relationships between these entities.

As an example, you may be building an app that allows the user to purchase, sell, and review books. Each book has one or more authors and one or more publishers. An author may very well write more than one book in their career and work with many publishers during their career. A publisher by the very nature of their business will contract with many authors and publish multiple books during the course of their regular business. Each of the actors in this example – authors, books, and publishers – have a one to many relationship with each other.

Building and maintaining such data relationships in your app frontend is not only tedious and time consuming but also comes with undesirable implications for user experience in the form of sub-optimal performance, fault tolerance, and latencies. With a solely frontend implementation, a user looking up a book will make your app do multiple requests into your app backend for retrieving data on the book’s authors and publishers. A frequently requested feature, we just made it easier for you to manage such relationships directly in your app backend built on our NoSQL based datastore. Not only can you link entities between different collections, you can request all related data in one single call instead of iterating and making multiple calls into your backend.

This feature is available through our Javascript library, our iOS library, and our REST API. It will soon be available from our Android library.

This is our first feature towards offering relational abstractions as part our service. Our goal is to bring you features that make it natural and easy for you to work with your data. Sign up for Kinvey to start using this exciting feature and send us feedback at support@kinvey.com. We would love to hear from you.

JavaScript library

You can model data relations, save entities in separate collections, and join relations when fetching data. A simple example is saving a book, with a reference to its author:

When you retrieve data, you often want to retrieve related data as well. For the book example, loading the author entity is possible by setting a resolve property:

If you are extending Kinvey.Entity with your own classes, it is possible to map relations to a specific class. More on this feature is available in the JavaScript Developer’s Guide. This feature is fully compatible with caching, offline support and syncing. Even when offline, you can continue saving, fetching or removing any relational data you want!

iOS library

The iOS KinveyKit library 1.8 supports saving/loading related objects through the KCSLinkedAppdataStore class. Entity classes participate by specifying a mapping by implementing a +kinveyPropertyToCollectionMapping. This method should a return a dictionary that maps the backend field names to their referenced collection.

Using the app as described above, the Book class would look like:

Then, by using the KCSLinkedAppdataStore, retrieving the object is simple. Using only one call to the server, the “author” field will be loaded as an Author object:

The library supports 1-1, 1-N, and N-N relationships between the same or different collections. For more information on the specifics of using the API and to see additional options, read our iOS Developer’s Guide.

REST API

You can model logical relationships in your data by embedding references from one entity to another and you can resolve references during a query.

Using references allows you to store only one authoritative copy of an entity and link to this entity from other entities. It also eliminates the need to issue separate retrieval requests for the linked entities.

In the above example, you can query for the book and automatically retrieve data on the author, on the publisher, and their respective locations in one single call. You can name the properties you would like to resolve instead of resolving all references as well as choose to include the original references in the data returned from your backend.