Skip to main content

Why Resonate

What problem does Resonate solve?

Modern pain points​

Let's try to answer the question, "what problem does Resonate solve?", within the context of today's software development landscape.

Take a step back for a moment and consider the time we are living in.

Will AI replace software developers — or will it empower them?

Resonate was made by developers for developers, knowing that Software Developers, Engineers, and Architects will continue to be the sensible decision makers on how to deliver the intended value of software. Sensible AI will help developers' not direct them. With that in mind, it's critical to continue to address developer pain points and improve developer experience.

Because, developers do still experience a lot of pain with distributed applications. There is too much complexity that's crammed in at the application level. Practically, failure retry, crash recovery, idempotency, service discovery, load balancing, suspension, etc, are things that developers have to repeatedly think about and solve for.

More or less, the complexity and the pain, stem from a system's desire to be concurrent and distributed. Why? So the system is scalable and reliable! Concurrency and distribution enable scalability and reliability. However, the more concurrency and distribution there is the more complex the code becomes. When the code becomes distributed and complex - the system becomes hard to build, hard to maintain, and hard to reason about.

Resonate addresses this pain holistically. Resonate pushes all that complexity (failure retry, crash recovery, idempotency, service discovery, load balancing, suspension, etc.) into the platform and provides developers with a simple set of APIs to use at the application level.

Using Resonate makes reliable and scalable applications dead simple to develop, dead simple to deploy, and dead simple to operate.

When to use Resonate?

Systems engineering for ...​

Use Resonate as soon as you realize you need or have a software system!

The Distributed Async Await spec, and its underlying Async RPC protocol, was intended to be a general-purpose programming and execution model for building reliable and scalable software systems. As an implementation of that spec, Resonate has successfully inherited that intended trait. For example...

Resonate's programming model serves developers by offering a clean, simple, and reliable pattern for awaiting on things in your event loop, whether that is a function executing, a human verifying some work, or an AI agent taking the step next. This makes it great for basically anything relying on a system.

Quality standards​

There are at least two things that we do that should paint a picture of our committment to quality.

First is formal modeling and formal verification.

Resonate is an implementation of the Distributed Async Await specification, which relies on the Asynchronous RPC protocol. These underlying specs have been and continue to undergo formal modeling exercises, which probe their correctness.

Second is simulation testing.

Each major component in Resonate, the Resonate Server and each of the SDKs, is subjected to Deterministic Simulation Testing (DST). This is of course on top of traditional unit testing and integration testing. DST identifies complex edge cases that may cause unexpected behavior in production, well before the code is ever released.

These two things set a foundation of quality that we build upon with every release.

Open everything​

The underlying Async RPC protocol, the Distributed Async Await specification, and Resonate are all fully open source.

Adopting Resonate does mean that you are adopting Distributed Async Await. But it doesn't mean you are locked into Resonate specifically.

Everything you need to fork or build your own is available to you.

But, the deeper philosophy is in imagining a world where every service, API, and distributed component used Durable Promises and Async RPC. Different implementations of the Distributed Async Await spec could interoperate seamlessly. And developers stay in control with far less complexity.