We’re on to the next chapter of how much does it cost to make an app?, and this addition we’re covering real-time updates. At their most basic level, real-time updates provide data that allows users to make more pertinent and informed decisions, and to then take action (at the right time) based on that data.
There isn’t one single real-time updating method for apps, however – just like anything that is built through software development. So, how much does real-time implementation cost you? Well, to keep the trend going, it all depends on what you want to achieve.
It’s important to note that for all types of real-time updates, there are two significant factors to their cost – time to build/implement, and the cost of data transfer throughout the lifetime of your app. If you’ve read our blog about how much it costs to implement a GPS/mapping API?, you’ll be familiar with the idea that every request made from a client to an API has a monetary cost associated with it.
The same goes for real-time updates (in fact, GPS and mapping APIs use real-time updating to function), and each data transfer will have a cost that comes along with it (for many reasons).
Let’s get into how these functionalities work:
The mechanisms behind real-time
There’s a lot of tasks real-time updating can accomplish – from detecting fraud at the moment of a transaction, to sending out the latest and greatest offer to a customer near your store’s location via proximity marketing.
Updating a device with data from a server can only be accomplished in a few different ways, however:
The simplest form of real-time data transfer is called polling. It’s the equivalent to knocking on your neighbor’s door at regular intervals until they answer. Or, for a more real-world example, it’s when a client continuously requests data from a server, based on set intervals of time.
While it is easy to implement, it’s a very inefficient form of data transfer – even if there is no change of state in the server, data will still be transferred every minute, or five minutes, or whatever pre-determined period of time you set. This forces you to play a balancing game against just how close to real-time you want your app to be, versus the cost to do so. The more requests you have, the more servers you need – which comes with higher infrastructure investment requirements, as well as higher maintenance costs.
The more data requests and transfers a server handles, the higher your costs will be. On the other side of the coin, if you don’t allow for enough server requests, your app won’t actually be updating itself in real-time – it’ll be more like what-happened-five-minutes-ago-time.
Long polling is very similar to polling, but with one key difference; rather than visiting your neighbor’s doorstep every minute, it’s like leaving a note on their door that says “come over when you’re ready.” In more realistic terms, it’s when a server only transfers data to a client if a change has been made to the data on the server.
While this does solve the cost issues associated with polling, it still comes with some pretty significant drawbacks:
- Servers can sometimes be expected to hold on to massive amount of data
- It is difficult to recover a session if a connection was lost with high reliability
Because of this, long polling has the potential to become a burden to large scale apps that require a high frequency of updates, or utilize segmented campaigns to target specific user groups.
Websockets can be thought of as a tool that turns a client into a server – it allows the client to both make and listen for data requests – giving the actual server the ability to very easily update the client.
Websockets function by the client providing what is called a callbackURL. These can be thought of as the phone number the server dials when it wants to transfer data to the client.
What this means is that because a client can actively listen to the server, there is no data transferred until a change has been made to the status of the server, and if connection is lost between the server and the client, it doesn’t matter, because the client will resume its active listening pattern.
It’s the digital version of installing a camera on your neighbor’s front door so you know when they’re home – except less restraining-order-worthy.
Note: “Websockets” and “webhooks” are easily confused terminology. Webhooks are used for server-to-server communication, and tell a server to send data to a specific URL. Websockets are used for server-to-client communication.
These are essentially the previously-mentioned websockets, and function in a very similar manner – the key difference is that they allow the client to determine what changes to data they want to be alerted about. For example, if a package delivery service uses a client-facing app, the client could select different types of data changes to receive alerts for: packed sent, package delayed, package delivered.
Methods of real-time implementation
There’s two pathways you can take towards implementing real-time updates: native development or through a third-party API.
If you’re going down the native development route, the cost of implementation varies depending on a multitude of factors, including: hourly rate, the complexity of the feature, the server infrastructure, and the amount of maintenance that will be required in the future.
Native development of real-time capabilities does come with perks, but its cost will ultimately come down to how much time you spend maintaining your server – while third party APIs come with reoccurring costs in the form of subscription fees – it’s a bit of a toss up as to which costs more. While natively run servers will cost less when everything is running smoothly, if something goes wrong, the maintenance fees fall to you.
Depending on the complexity of the real-time feature you’re implementing, your costs could range anywhere from $10,000 to $25,000.
Let’s go over some of the third-party APIs available:
Kafka can be used for messaging, website activity tracking, log aggregation, stream processing, and event sourcing. Like everything under the Apache license, it’s open source, and therefore free API to implement.
PubNub can provide real-time integration for chat features, IoT device communication and streaming, mapping, GPS, push notifications, and alerts. PubNub’s services start at $49 per month, plus data transaction fees.
Fanout.io serves as a proxy for real-time updates. Fanout also allows you to develop your own APIs alongside their service, so you can provide your own customization based on your app’s specific needs. Fanout costs $25 per month, plus data transaction fees.
Realtime.co is a message broker that operates in real time through the cloud. It can be used for cross platform apps – and has SDKs to go with both Android and iOS. Realtime’s pricing starts at $49 per month plus data transactions, and goes up to $250 per month plus data transactions.
Amazon Web Services offers their own real-time updating API called AppSync. AppSync can be implemented for almost every use case imaginable. AppSync’s services cost $4.00 per million query and data modification operations, $2.00 per million real-time updates, and $0.08 per million minutes of connection to the AWS AppSync service.
Firebase – Google’s comprehensive mobile development platform – has two different real time services: Realtime Database and Cloud Firestore.
Cloud Firestore stores data in documents, which are organized and stored in collections. Documents serve as the unit of storage, and are written in a syntax extremely similar to JSON. Documents can be broken into sub-collections and nested objects, which are referred to as maps.
Both Realtime and Firestore are NoSQL databases, which come with their own pros and cons when compared to more traditional SQL databases. While SQL databases are organized to write data in a very efficient manner; NoSQL databases are organized to read data quickly, but due to their structure, require duplicate data in order to access information.
You can think of a SQL database as a collection of tables that hold very specific, uniform sets of information, that link up in a web. NoSQL databases are structured in branches, which lead to other branches, which lead to other branches.
Basically, when data needs to be shared instantaneously across hundreds, thousands, or even millions of devices, NoSQL databases are very efficient because of their data structure. Both Realtime Database and Cloud Firestore offer real-time and offline support with SDKs specifically built for mobile. Both are capable of being implemented for pretty much every real-time use case you can think of – from chat to re-sizing photos, to analytics and machine learning.
If you know your app will only be used by a relatively small audience in a localized area, and your data sets are straight-forward, go with Realtime Database. Cloud Firestore horizontally scalable – meaning it works better than Realtime Database when used across multiple localized areas, as you don’t need to create shards in order to do so. Because of Firestore’s structure, data is very easily split between different servers.
The Firebase payment model starts at a free version, and has two other plans: $25 a month, and a pay-as-you-go option.
Apps that utilize real-time
Sometimes, it’s a bit difficult to imagine what kinds of apps use real-time features in order to work properly, or improve their UX. So, here are some real-world examples of apps that use real-time tech:
Real-time tech is the backbone of Uber. Without it, users wouldn’t know where their driver was, driver’s wouldn’t know the location of their passengers, and GPS wouldn’t work.
Much in the same way Uber relies on real-time updates to track its drivers, so to does Safelite’s app, which provides users with the location and ETA for a mobile technician.
WhatsApp uses real-time updates for chat, voice, and video features. This is necessary for low-latency communication, and keeps conversations smooth, with even pacing, and no downtime.
Real-time updates are how Dominos keep customers informed about the status of their pizza order – when it’s in the oven, when it’s ready for pick up, or when it’s out for delivery.
Inventory management at scale would be completely impossible without real-time updating capabilities. Keeping accurate track of your company’s stock requires knowing your exact inventory numbers every moment – when you’re working at a national or global scale, conversions can happen at rates that can only be tracked through real-time updates.
Your options for real-time
There’s plenty more services out there – but what’s important to know is that just like most software services, the costs of a real-time APIs increase with the scale of your app. If you’re going the native development route, your costs will largely rely on how much infrastructure investment is required, as well as your servers’ maintenance costs.