A simple Google search on ‘serverless’ would lead you to a humongous number of articles trying to convince you how serverless architecture is the next big thing!

An application is said to have a serverless architecture if a major part of it’s computing depends on various third party architecture services such as Amazon AWS, Microsoft Azure or Google cloud. The concept of serverless computing is such a big relief for application developers since the whole complexity as well as cost involved with setting up and maintaining such an architecture that is both reliable and scalable, is almost eliminated.

Leading players in the serverless market

However, ‘serverless’ doesn’t really mean running something without servers, it’s just that you as a developer do not own or maintain a server (essentially the operations it performs), but rather rent it out from a service who’s complete focus is to provide a perfectly working computing environment to you that guarantees availability and automatically scales both up and down according to the changing load.

In such a scenario, it doesn’t come as a surprise that such ‘Function as a Service’ (FaaS) services are becoming extremely popular. They are especially considered when handling unprecedented traffic within a robust architecture is required.

Ably has identified this growing trend of serverless computing and has been working on a service that leverages all the benefits that come with a serverless architecture while being able to add realtime functionality to an application.

Introducing Ably’s Reactor Functions

If you are already a user of Ably, you know that Ably comes with a feature called ‘Reactor’. It is a scalable service that let’s you connect to 3rd party services in order to trigger events or stream data.

Ably’s Reactor service

In a lot of scenarios, developers would like to trigger a function that does some app-specific operations when an event occurs. However, handling the architecture for this function again goes back to handling all the hassles we discussed above. Hence, they prefer using services like AWS Lambda, Microsoft Azure Functions or Google Cloud Functions, to name a few, that can handle the architecture. Ably’s Reactor Functions equip a developer with doing just that!

Ably’s Reactor Functions are a straight-forward way of triggering a serverless function residing on an existing 3rd party architecture service (currently AWS, Azure and Google Cloud are supported) in response to a channel event.

The Ably platform isolates all realtime data via channels (or topics) ensuring that data published on a channel will only be received by subscribers of that same channel.

Unlike some other realtime services, Ably has consciously chosen not to re-build this scalable architecture as a home grown service since it truly believes in interoperability rather than shooting for just another proprietary service. Ably’s decision to support the best-in-breed function-as-a-service providers comes with the reasoning that developers can avoid the tech debt and can choose the best messaging platform as well as the best function platforms independently, making the components of their tech stack less likely to end up with unsupported technology or a technology that requires continuous maintenance. Also, since a serverless architecture is already popularly being used by developers to solve their other needs, using the same service would be a great respite and save the developers huge time and resources that would otherwise have to be spent on learning and understanding how to get around a newly developed service.

A simple illustration of Ably’s Reactor Functions

To understand more about how this works, let’s consider a specific example of using AWS Lambda. A Lambda function is part of the AWS suite that allows code to be triggered remotely. It of course also promises service at scale and high availability. Now consider a simple scenario where a function is to be invoked as soon as someone(usually a device) enters/becomes online on a particular application, so that a little green dot on their social profile becomes green. In theory, this seems super straight forward to implement, but consider a platform with millions of users and a huge percentage of them come online or go offline over a short period of time. A small function that handles this minimal functionality is sure to add significant load on your server and perhaps result in failed requests you do not have sufficient capacity. Even if you are aware of an expected load, it is often prohibitively costly to have sufficient spare capacity available at all times. And of course if you miscalculate the load expectations, you risk overloading your servers

In this case, we can happily host this code as an AWS Lambda function and let it worry about handling all the traffic whatsoever. Ably, being a realtime platform, handles the client’s online and offline events via a feature called presence and provides a simple way to trigger this AWS Lambda function as soon as this presence change happens, via it’s Reactor service.

In Ably, ‘presence’ refers to the online status of a client. Using Ably’s realtime library, other clients can subscribe to presence events, meaning, they will be notified every time another client enters or leaves a channel or even updates his presence data.

Even from a design perspective, these serverless functions operate asynchronously and thus continue executing elsewhere while your application can continue being awesome by carrying out further operations.

Ready to try Ably’s Reactor Functions? Jump into the docs or check out one of our easy to follow tutorials.

Any thoughts?