For an Internet of Things (IoT) device, we were working on a data-intensive React Native mobile application, which used location data to plot on an interactive map. The data was serialized and encoded as binary data. For the product to work as intended, the data had to be deserialized and converted to the right format to store it and display it to end users.
The data structure, as the development progressed, understandably grew in complexity and size.
Unlike when developing applications for distributed systems and back-end servers, there are fewer resources to work with for a mobile-first application. On phones and tablets, memory and storage space is very limited.
Hence, processing (data retrieval, data structure for the database, data manipulation etc.) has to be optimized and trade-offs have to be made on what data we absolutely need to save and what we can let go.
1. SQLite
2. Realm
3. Other object-relational mapping (ORMs) built over a Structured Query Language (SQL) engine
We started our journey with SQLite. Given how well SQLite worked with small application data, this seemed like the right choice at the time. However, shortly after, we ran into several challenges.
Migration: Data migration was a pain; it was code and time intensive. Even a simple task in subsequent versions involved a protracted process.
Database (DB) file: Sometimes the journal files maintained by the DB are not deleted after a transaction is complete. We would not want to stop the journaling process run by the database to help debug failed transactions in posterity. Since the database file can be read easily, many extensions have to be downloaded to protect it.
To counter these challenges, I decided to give Realm by MongoDB a try. It is a non-relational database. It lets you declare relationships between different schema objects. It is a mobile-first database and takes memory limitations on a mobile device into consideration.
Realm, unlike other ORMs, has a new engine driving it (which is a custom-made engine, not SQL). This engine at its core is created using C/C++ and is blazing fast (exciting stats later in this post). The ideology behind how the Realm team visualizes data is what makes it so lightweight and developer-friendly.
.svg)
Realm is easy to use; it uses familiar objects to store and retrieve data. All data models and schemas are defined as simple classes which extend the RealmObject class. Required fields and primary keys are easy to use with annotations.
The results returned by a Realm query can be directly used as a list interface and are iterable, unlike SQLite query results, which are returned as cursor objects.
Some statistics for performance of Realm are as follows:
Realm is innovating a lot, and we’ll end Part 1 on that note.
Stay tuned for Part 2 where we’ll explore Realm code examples and take a closer look at some of its core ideas.
.png)
.png)
.svg)
.svg)
.svg)
.png)
.png)
.png)
%20(2).svg)
.svg)
.jpg)
.svg)
For an Internet of Things (IoT) device, we were working on a data-intensive React Native mobile application, which used location data to plot on an interactive map. The data was serialized and encoded as binary data. For the product to work as intended, the data had to be deserialized and converted to the right format to store it and display it to end users.
The data structure, as the development progressed, understandably grew in complexity and size.
Unlike when developing applications for distributed systems and back-end servers, there are fewer resources to work with for a mobile-first application. On phones and tablets, memory and storage space is very limited.
Hence, processing (data retrieval, data structure for the database, data manipulation etc.) has to be optimized and trade-offs have to be made on what data we absolutely need to save and what we can let go.
1. SQLite
2. Realm
3. Other object-relational mapping (ORMs) built over a Structured Query Language (SQL) engine
We started our journey with SQLite. Given how well SQLite worked with small application data, this seemed like the right choice at the time. However, shortly after, we ran into several challenges.
Migration: Data migration was a pain; it was code and time intensive. Even a simple task in subsequent versions involved a protracted process.
Database (DB) file: Sometimes the journal files maintained by the DB are not deleted after a transaction is complete. We would not want to stop the journaling process run by the database to help debug failed transactions in posterity. Since the database file can be read easily, many extensions have to be downloaded to protect it.
To counter these challenges, I decided to give Realm by MongoDB a try. It is a non-relational database. It lets you declare relationships between different schema objects. It is a mobile-first database and takes memory limitations on a mobile device into consideration.
Realm, unlike other ORMs, has a new engine driving it (which is a custom-made engine, not SQL). This engine at its core is created using C/C++ and is blazing fast (exciting stats later in this post). The ideology behind how the Realm team visualizes data is what makes it so lightweight and developer-friendly.
Realm is easy to use; it uses familiar objects to store and retrieve data. All data models and schemas are defined as simple classes which extend the RealmObject class. Required fields and primary keys are easy to use with annotations.
The results returned by a Realm query can be directly used as a list interface and are iterable, unlike SQLite query results, which are returned as cursor objects.
Some statistics for performance of Realm are as follows:
Realm is innovating a lot, and we’ll end Part 1 on that note.
Stay tuned for Part 2 where we’ll explore Realm code examples and take a closer look at some of its core ideas.
For an Internet of Things (IoT) device, we were working on a data-intensive React Native mobile application, which used location data to plot on an interactive map. The data was serialized and encoded as binary data. For the product to work as intended, the data had to be deserialized and converted to the right format to store it and display it to end users.
The data structure, as the development progressed, understandably grew in complexity and size.
Unlike when developing applications for distributed systems and back-end servers, there are fewer resources to work with for a mobile-first application. On phones and tablets, memory and storage space is very limited.
Hence, processing (data retrieval, data structure for the database, data manipulation etc.) has to be optimized and trade-offs have to be made on what data we absolutely need to save and what we can let go.
1. SQLite
2. Realm
3. Other object-relational mapping (ORMs) built over a Structured Query Language (SQL) engine
We started our journey with SQLite. Given how well SQLite worked with small application data, this seemed like the right choice at the time. However, shortly after, we ran into several challenges.
Migration: Data migration was a pain; it was code and time intensive. Even a simple task in subsequent versions involved a protracted process.
Database (DB) file: Sometimes the journal files maintained by the DB are not deleted after a transaction is complete. We would not want to stop the journaling process run by the database to help debug failed transactions in posterity. Since the database file can be read easily, many extensions have to be downloaded to protect it.
To counter these challenges, I decided to give Realm by MongoDB a try. It is a non-relational database. It lets you declare relationships between different schema objects. It is a mobile-first database and takes memory limitations on a mobile device into consideration.
Realm, unlike other ORMs, has a new engine driving it (which is a custom-made engine, not SQL). This engine at its core is created using C/C++ and is blazing fast (exciting stats later in this post). The ideology behind how the Realm team visualizes data is what makes it so lightweight and developer-friendly.
Realm is easy to use; it uses familiar objects to store and retrieve data. All data models and schemas are defined as simple classes which extend the RealmObject class. Required fields and primary keys are easy to use with annotations.
The results returned by a Realm query can be directly used as a list interface and are iterable, unlike SQLite query results, which are returned as cursor objects.
Some statistics for performance of Realm are as follows:
Realm is innovating a lot, and we’ll end Part 1 on that note.
Stay tuned for Part 2 where we’ll explore Realm code examples and take a closer look at some of its core ideas.
.svg)
.svg){kind=small}
.png){kind=small}
