Data engineering has been on the rise in the last ten years. Nowadays, we create 2.5 quintillion bytes of data every day. From the phone in your hand to the cars on the road, most electronic devices collect and store data, but where does it all go, and what does it mean? Data is stored on the device or remote servers. In other words, local or cloud. Although studying and learning from data is important, you don’t have to be a data scientist to think about data. It’s just as important to understand where your app data is. Apps made in Appli can store data both locally and in the cloud. The capabilities of your app can be affected by this decision. It’s essential to understand the difference.
Local Data vs. Cloud Data: What’s the difference?
Local and cloud data are the same but differ in how they’re managed. This affects things like accessibility, security, and speed. We’ll go more into this, but first, let’s discuss some basics.
- Local: Local data is stored on the physical device in use. The device does not require an internet connection to access the data. This device is the only device that can access the local data.
- Cloud: Cloud data is stored on remote servers managed by someone else. This requires the internet to access the data. These managed servers commonly have backups and replication of data throughout their network. Any device can access this data with the correct configuration, authentication, and permission.
It is essential to understand the differences in how the data is managed. This will affect the capabilities of your app. Local and cloud each come with their pros and cons. There is also a hybrid option. An app does not have to be strictly local only or cloud only. It all depends on your needs and the problems you want to solve.
Local, Cloud, and Hybrid: Different Use Cases
The capabilities of an app can change depending on where the data is stored. In this example, we will explore a recipe app and compare three different use cases — local-only, cloud-only, and hybrid. This recipe app allows users to create, view, update, and delete recipes. Suzie first created the app for her personal use. One day Suzie shows the app to her friend Timmy. Timmy likes the app and wants to start using it. After listening to Timmy’s experience and needs, Suzie makes some changes. Here are some things Suzie had to take into consideration:
- Local Only: All data is stored on Suzie’s device. Any recipes created on this device can only be seen by the person who made the recipe. There is no backup of the data. If the app is deleted, all the recipes are deleted as well. This app can be used without the internet.
- Cloud Only: All data is stored on remote servers. This requires the internet, and users need an account in the app. Users are authenticated when they sign in to their accounts. They can view, modify, and delete recipes based on their permissions. Users can sign in on different devices and access the same data. The data is still in the cloud if the recipe app is deleted from the device. When users modify data, they modify it directly in the cloud, and others can see the changes. The recipes cannot be accessed if the data’s remote servers are down.
- Hybrid: Data is stored on both the device running the recipe app and on remote servers. This can work with or without the internet. When the device has internet, data is downloaded to the device. The user can interact with local data even when the internet goes out. Any modifications to the data are done on the device and then synced up to the cloud. If the app is being used without the internet, other users can only see the changes on the device once it is reconnected and synced to the cloud. As the developer, you can decide when local changes are synced to the cloud. More on that later.
In this example, the recipes are our data. Suzie’s app started off being local only. This allowed her to access the recipes on her phone with or without the internet. Timmy started doing the same thing. In no time, he had the app on his phone and filled it with his recipes. One day Timmy asks Suzie for her famous pulled pork recipe. Suzie goes into her app, takes a screenshot of the recipe, and sends it to Timmy. Timmy thanks Suzie and copies the recipe over to his app. “You know what would be great,” Timmy says to Suzie, “if I could see your recipes on my phone through the app.”
Currently, all the recipes are stored locally on Suzie’s phone. This data must be in the cloud if Timmy wants to see Suzie’s recipes. Suzie starts making these changes by adding a way to create an account and sign in. Users must be connected to the internet and sign in to use the app. Signing in will authenticate the user so they can communicate with the servers. Suzie modifies the database actions that interact with the recipes and specifies the target as cloud instead of local. With the data now in the cloud, Timmy can access all recipes, not just the ones he created. Suzie makes some final changes, so users only have permission to modify and delete recipes they’ve created. Timmy can now see all of Suzie’s recipes directly on his phone while connected to the internet. Things are great, as is the pulled pork Timmy made using Suzie’s recipe.
A few months later, Timmy is camping. It’s lunchtime. He pulls out his phone to look over a chicken tzatziki skewers recipe he had seen. He opens the app and tries to sign in, but his phone doesn’t have service. He already has all the ingredients, so he wings it. During the week, Timmy has lunch with Suzie and tells her about his camping trip. Suzie hears what happened when Timmy tried to use the app and understands what needs to be done. The tinkerer inside of her wants to solve the problem. Later that night, she started working on the app and made it hybrid. The app needs access to the recipes even when it doesn’t have internet. Suzie changed the sign-in process and added a sync routine to it. Any new recipes on the cloud are now downloaded to the phone and stored locally when the user signs in. She also changed the target for the database actions back to local from the cloud. The app can now interact with the local recipes downloaded to it. The next time Timmy signs in to the recipe app, all the recipes will be downloaded and stored on his phone to display with or without the internet.
Pros and Cons
Local
- Pros: No internet required. Local storage is free. Faster than communicating with remote servers through the internet. Easiest to implement.
- Cons: Data is only accessible on the device it was created. There are no backups of the data.
Cloud
- Pros: Data has backups and is accessible on different devices by multiple individuals.
- Cons: Requires internet to authenticate users and access data. Data is not accessible if remote servers are down.
Hybrid
- Pros: Data availability even if offline while still benefiting from a networked database and multiple device.
- Cons: The developer needs to be more involved and decide when to sync the database and where to fetch data from for each database operation.
Low-code Database Actions in Appli
In the recipe app example, we mentioned that database actions have a target. Database actions have “local” and “cloud” as options in the “target” argument. You might think, “Database action? Argument? What are these?” Appli has actions that give your app functionality. Actions are assigned in Appli’s low-code editor. An action falls into a specific category. With database actions, you can create data locally or in the cloud, access the data, modify the data, and so much more. The create the record action is used to create data. It has the following arguments: TableName, Data, Target, DelaySend, and Output. Arguments are input that you provide to the action. This input tells the action how to perform a task. The “target” argument specifies the location of the data. If we use create the record and select “local” as the “target”, the data is created locally on the device.
We can use “local” in all our database actions to make an app local only or “cloud” to make it cloud only. To make an app hybrid, we must sync records locally and to the cloud. This differs from creating a record locally and then recreating the record in the cloud. These will be two different records. We want a single record that we keep in sync using sync records RecordIDs, TableName, Source, AllowDeletes, DetectCollisions, and Output. The “target” argument specifies where the data comes from in this action.
- sync records with “local” will sync the data from local to the cloud.
- sync records with “cloud” will sync the data from the cloud to the local device.
Conclusion
When deciding if an app should be local or cloud, we can look back at the recipe app example and apply what we’ve learned. We learned that this decision could affect accessibility. Who needs access to the data? Do users need to see each other’s data? For most apps, these two questions will answer the local or cloud questions.
Header photo by Christina @ wocintechchat.com on Unsplash.
