Serverless Change Capture for Ruby on Rails

A common problem in business applications is change capture, which enables use cases like audit logging, history browsing, and value attribution for content optimization. In finance, audit logs are useful for regulatory compliance. In content and gaming industries, they can be useful to pinpoint which changes increase audience engagement. For enterprise SaaS provider Breezeworks, a service industry team and customer management platform, end users often want to know when an appointment or estimate was changed, and by whom. The combined feed of changes to important business objects like job schedules and equipment availability also offers Breezeworks power users an organization-wide pulse of their company, so they can stay ahead of problems before they impact the job site.

Adding change tracking to an existing application has the potential to be a complex and expensive undertaking, but when I spoke to Adam Block, CTO & Co-founder of Breezeworks, about how they use Fauna, at first he didn’t think his use case was impressive because it was too easy. When I asked him about his use case and pain points, he told me users often want to know when an appointment or estimate was changed, and who made the change. They accomplish this by adding an after_commit hook to their Ruby on Rails ActiveRecord base model, which maintains a copy of the data in Fauna Cloud.

“Teeing” writes to a new database is often part of a database evaluation process, so readers may be familiar with the pattern so far. Essentially, it means that everytime the application server writes to the SQL database, it also writes the same information to Fauna. Using the snapshot retention capabilities that Fauna offers out of the box gives Breezeworks a powerful API which powers user-facing history and activity stream views. Teeing this data to Fauna, and using its built-in history features, is simpler than modifying the SQL database schema to keep multiple versions of records around.

Trying to do this with a single database schema that must represent both the application’s important business objects, as well as their historical changes, can add complexity that impacts every query. Instead, Breezeworks keeps their SQL database focussed on representing the business objects, and uses Fauna for change capture. Breezeworks’ application servers use Ruby on Rails with ActiveRecord, and the models connect to PostgreSQL to store the current state of business objects. Each time a model writes a record to PostgresSQL, it also updates the object in Fauna. This means their SQL queries can remain blissfully unaware of historical versions and all the complexity that comes with it. Fauna has built-in change tracking and event feeds so, when users browse history, not only are the queries efficient, but they are also easy to write.

Breezeworks calls the plugin they developed in-house to write history “Fauna-Tee”, after the unix command. The pattern is so simple that implementing it yourself in another language or framework wouldn’t be much work. The core idea is to add a callback to your existing database driver that duplicates write operations to Fauna. You can query this duplicate data set with Fauna’s built in temporal history and snapshot retention features, including the ability to request an event feed for any query. Fauna Query Language (FQL) makes it easy to offer users historical views and change feeds of important business objects, filtered for specific projects and roles.

Change capture benefits Breezeworks in ways they couldn’t have predicted when implementing it. Customer support depends on it to help users recover from mistakes. Users can see who in their organization made a change, so they know who to talk to about it. Managers can use the combined event feed to see when equipment shortages are holding up work, or which jobs are falling behind. And having historical views of estimates and schedules is important in case of disputes.

By teeing your data to Fauna Cloud, you can get serverless change capture, and enable historical queries as well as event feeds, without impacting your existing database. Change capture doesn’t have to be a complex addition to your application database; it can run smoothly alongside it and deliver tons of business value.