This article comes to you from the DZone Guide to Database and Persistence Management. For more information—including in-depth articles from industry experts, profiles on 35 database solutions, and more—click the link below to download your free copy of the guide.
Everybody is building mobile apps these days, both natively and for the web. Part of the value of almost any non-trivial app relates to its ability to store data for a user. This can range from something as obvious as a to-do list app, whose entire value-proposition is its ability to remember things for a user, to less obvious cases like mobile games, which may want to store game state or high-scores for the user.
Rather than just storing this data on a single device, users also now increasingly expect apps to make their data quickly and easily accessible across all of their devices. Furthermore, when they have multi-device access, they don’t want to have to worry about whether internet connectivity is missing or intermittent. The app should be able to store it locally and then synchronize with the cloud later.
As soon as remote data storage becomes a requirement for an app, a whole bunch of new back-end infrastructure needs to be set up by the developer. Even with the rise of the cloud infrastructure, this is still a lot of work.
- You need to pick app server and data store software, then run a bunch of wiring code to pipe data between the client and database.
- If you want offline data access to work, you need to build local storage into your client and get the local- remote syncing logic right.
- If you want real-time data syncing between clients, you need to introduce real-time web protocols, or simulate them using techniques like long-polling.
- Finally, to secure your user’s data so that only they can see it, you need to either build your own infrastructure to securely store and verify user credentials, or integrate with services like Facebook or Twitter to allow people to use their existing credentials.
In this article, we’ll look at three platforms that aim to give developers a quick and easy way to implement the common mobile app use case of “storing stuff” for users across devices. All of these frameworks can run in offline mode and offer mechanisms for automatic syncing. They all also have the ability to integrate with OAuth-based identity services.
It’s important to understand that these platforms are not relational databases and thus do not offer features like JOIN queries or full ACID transactions. Instead, their goal is to provide just enough data storage capabilities for a mobile app to satisfy the storage needs of its users. However, they each have their own limitations and trade-offs.
Firebase allows data to be shared between users. To restrict how data can be accessed by particular users, it provides a server-side rules language. However, it’s important to understand that Firebase has no application layer by default—you essentially go directly from your client to the database. Because of this, the rules language also includes capabilities for doing data validation.
Firebase has simple querying capabilities. However, it’s important to configure indexing rules on query criteria to keep performance manageable. Queries that you run with Firebase are live—if the data underlying the query changes after the query has been run, then the query results will automatically update.
It is very easy to get up-and-running with Meteor, as it bundles both an application server container and a local Mongo instance out of the box. It also provides command- line tools for automatically packaging your client and server-side code and deploying it to the cloud with a hosted app server and datastore. This saves you from having to setup a complex build and deployment process yourself. The Meteor platform is comprised of a number of libraries and tools. While they can be used in isolation, they work best together. For example, Meteor’s live-updating view library (Blaze) is designed to integrate seamlessly with its remote data syncing capabilities.
Cognito is a new offering from Amazon Web Services (AWS) that provides a quick and easy way to authenticate users and store data for them. It integrates tightly with AWS’s existing identity management infrastructure, but can also be used with other OAuth providers. Like Firebase, clients go directly to the database rather than through an application layer. To make this secure, no data can be shared between users. Any additional data validation you do will have to be duplicated between different client types, as there is no shared server to put it on.
All of these platforms herald a shift away from the traditional three- tier, request-response approach to storing and accessing user data.
Cognito’s data storage capabilities are very basic. An app can have multiple datasets, each of which can be considered roughly equivalent to a table. Keyed records can be inserted into each dataset. However, you can only look up records by their key—any more sophisticated querying would require a full scan of the dataset. That said, if Cognito’s data-storage capabilities are not enough, you can also use it to connect to other AWS services like S3 or DynamoDB. However, you lose its offline and synchronization capabilities when you do this.
Which One You Might Use
Which of these frameworks you use depends very much on your storage needs. If you have really simple requirements and you’re looking specifically for user authentication as a service, Cognito should be enough, especially if you are already familiar with the Amazon ecosystem. However, its inability to query or share data between users will be a deal-breaker for many scenarios.
Regardless of which you pick, all of these platforms herald a shift away from the traditional three-tier, request- response approach to storing and accessing user data. To one degree or another, they take care of the minutiae of data storage, ensuring our user data is instantly available everywhere, all the time.