Built.io joins Software AG! Read all about the news.

Built.io Blog

Built.io Backend Update: Moving On From Multiple Group Fields For Better Performance


Built.io Backend Update: Moving On From Multiple Group Fields For Better Performance

At Built.io, we strive to provide great products and a continuously improving user experience to our customers. In the process, we occasionally replace obsolete features or older capabilities with newer and better ones. With that said, we have an update to Built.io Backend!

Update To The Group Field In Built.io Backend

Built.io Backend is deprecating the ‘Multiple’ option for the ‘Group’ field.

Beginning Monday, February 6, 2017, Built.io Backend will no longer allow enabling the ‘Multiple’ option for any new ‘Group’ field added to the schema of any class of your application.

Existing ‘Group’ fields of your application with the ‘Multiple’ option enabled will remain unaffected after this implementation, so this change will allow existing applications to function unaltered. However, if you disable ‘Multiple’ for any such existing ‘Group’ field, you will not be allowed to re-enable ‘Multiple’.

Why We’re Making The Change

Put simply, it will improve the performance of your application.

While there is nothing inherently wrong with using ‘Multiple’ for ‘Group’ fields, using this liberally (and improperly) increases the size of the object data (and thereby of the class data). This in turn can make data retrieval and modification difficult. We’ve noticed an upward trend of such problematic implementions, so we’re aiming to provide users with a better, more consistent solution.

Here’s an example of how using the ‘Multiple’ option for the ‘Group’ field may affect your application:

Let’s say you have built a shopping app using Built.io Backend. It has a ‘Users’ class, which, apart from containing the common ‘Name’ and ‘Email’ fields, also contains a ‘Wish list’ field (a ‘Group’ field marked as ‘Multiple’) that stores the details (name, description, category, etc.) of all the products that a user adds to the wish list.

A user may add thousands of products to the wish list, making this single object extremely heavy. Imagine hundreds of users of your application doing this. Subsequently, when you try to fetch all users, the app has to fetch loads of data, thereby increasing the latency dramatically.

Moreover, if anything in the wish list is deleted or modified, the system has to sift through all of the products that were added, and then modify only what was changed. Put simply, this affects the performance of your application.

Is There A Workaround?

Certainly. Instead of dumping additional info in a single class, it is always best to create more classes, and provide inter-referencing.

In using the above example, the e-commerce app’s ‘Users’ class should store the name, email, and other details of the user. Products added to wish list should go under a different class (‘Wish list Products’). The ‘Wish list Products’ class should contain a ‘User ID’ field (reference field referring to the objects of the ‘Users’ class) and a ‘Product ID’ field (reference field that refers to the objects of the ‘Products’ class).

This change will fetch data in the application faster, and it won’t experience any unexpected latency.

What Happens After The ‘Multiple’ Option For The ‘Group’ Field Is Removed?

The ‘Multiple’ option for the ‘Group’ field will be removed on February 6, 2017. Here’s how it will work for various users:

  1. For existing Group fields with Multiple enabled
    1. If you have an application that already has Group fields with ‘Multiple’ option enabled, your application will continue to function that way it used to be. However, if you edit the class schema and disable ‘Multiple’ for any ‘Group’ field, you will not be able to re-enable it.
    2. The addition of new fields will still be permitted, but they will not be marked as unique.
  2. For new Group fields
    If you create a new Group field, you will no longer see the ‘Multiple’ option. In this case, we recommend to use additional classes and references, as explained earlier in the example.

Need Help?

We expect this change to have minimal impact on existing users and result in better, more consistent performance for you next app. However, we’re here in case you have any questions or if you require additional help or assistance. We always love to hear from you and you can reach us at support-backend@built.io.

Popular Posts

Subscribe to our blog