{"id":14741,"date":"2023-08-17T11:24:02","date_gmt":"2023-08-17T18:24:02","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=14741"},"modified":"2025-06-13T19:49:22","modified_gmt":"2025-06-14T02:49:22","slug":"dont-use-rest-use-a-mobile-database-couchbase","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/dont-use-rest-use-a-mobile-database-couchbase\/","title":{"rendered":"Don\u2019t REST – Use a Mobile Database for Apps: Couchbase Webcast Recap"},"content":{"rendered":"

I was recently honored to co-present on a webcast with my colleague and good friend, <\/span>Aaron LaBeau<\/span><\/a>, Sr. Developer Advocate at Couchbase. Aaron has nearly 30 years of development experience and specializes in building mobile apps, and so seemed the perfect subject matter expert to join our session titled <\/span>Database Strategies for Mobile and IoT Apps – Why REST won’t cut it anymore<\/span><\/a>.<\/span><\/p>\n

In the program, we set out to uncover the hurdles that developers face when building mobile apps using REST APIs for data, and then explore an alternative approach that not only eliminates the hurdles, it makes apps even better: a mobile database platform.<\/span><\/p>\n

During the discussion, we made the point that while there are more devices and users than ever before, simply producing an app is no guarantee that it will be a success. In fact, the vast majority of apps are uninstalled within the first 30 days of use for reasons such as slow performance, long startups, lost data and crashes. And many of these problems are because of data, or more specifically, how the apps access and handle data.\u00a0<\/span><\/p>\n

Top 5 REST API Pain Points<\/span><\/h2>\n

Mobile developers that use REST APIs for accessing and modifying data are subject to challenges that impact the performance and availability of their applications. In his remarks, Aaron talked about five specific \u201cREST API pain points\u201d that he has encountered over the years on various projects:<\/span><\/p>\n

Reusing \u201cbloated\u201d REST APIs makes apps inefficient<\/b>: here the discussion focused on reasons why REST APIs intended for a web app should not be repurposed for mobile apps.<\/span><\/p>\n

Lack of schema and data type validation<\/b>: a lack of typing and validation in REST can cause mismatches in how data is sent and how it’s expected to be received between the app and the API, which can lead to a crash.<\/span><\/p>\n

Back-and-forth data transformation<\/b>: the need to constantly transform data between the app, the REST API and the backend database – for each request – makes code complex and leaves more room for error.<\/span><\/p>\n

Translating business domain to transport model<\/b>: here Aaron talked about the frustration of creating an elegant and complex domain model that fits your app to a tee, only to have to wrap it to fit the REST API, losing all of its richness and expressiveness.<\/span><\/p>\n

Dealing with an inherently unreliable Internet<\/b>: REST depends on the internet, and as such, so do your apps when they use REST. There are many potential points of failure introduced by network issues, and developers have to implement the communication logic and error handling themselves, which can make even the simplest of tasks extremely complex.<\/span><\/p>\n

Mobile database platform to the rescue<\/span><\/h2>\n

With the pain points covered, we turned the discussion to an alternative approach to data access: a database platform built for mobile apps<\/strong>.<\/span><\/p>\n

\"\"<\/p>\n

A mobile database platform is intended to simplify data handling for apps, as well as work around the inherent unreliability of the internet. <\/span><\/p>\n

In our discussion we described how a mobile database extends data storage and processing from the cloud to the edge, including onto the device. <\/span><\/p>\n

We explored how it can eliminate the REST pain points, reduce internet dependencies and speed up apps with local data processing \u2013 all without sacrificing consistency – by providing:<\/span><\/p>\n