Swim can be a challenge to explain to people, even if the audience is fairly technical. Unless you've had firsthand experience building and running at-scale distributed applications with low latency requirements, it's difficult to realize that the same open source frameworks, platforms, and tools that power sophisticated applications today are severely limiting our ability to use and benefit from streaming data. Further complicating matters, the architecture of Swim is deeply influenced by many of these open source projects (Akka, Cassandra, and Kafka, to name a few). Swim has no external dependencies. Swim server relies on parts of the JVM, but is fundamentally language agnostic. We also have client bindings for Javascript and others will be coming soon.
While Swim is quite unique, I've often found that explaining Swim is easier when I compare it with other, more familiar technologies.
You've never seen a zebra? Well, it's kind of like a horse. But, you know, it's different...
When I explain Swim to others, here are some of the common comparisons I use:
- Swim is different from a distributed file system
Unlike a database or message broker, Swim distributes dynamic processes in addition to data. This means that Swim always processes data in the most efficient location, based on the origin of data and available resources in the network. - Swim is different from a distributed job manager
Job managers execute ephemeral tasks. Swim executes long running, globally addressable processes. Every Swim Web Agent is its own job manager...and database...and message broker.... - Swim is different from a stateful stream processor like Apache Flink
Like Apache Flink, Swim executes long running, stateful operations. But unlike Swim, Flink executes in a non-general purpose, data-parallel environment, without discrete process addressability and general purpose inter-process communication. Swim is a general purpose application platform, which enables developers to run arbitrary application logic on top of streams, not just analytics. - Swim is different from a distributed containerization system like Kubernetes
Kubernetes distributes processes, but doesn’t itself maintain continuous consistency of distributed data, and provides no decoupling of logical application structure from physical compute infrastructure. Swim automatically optimizes use of hardware resources, so developers only have to focus on writing their application logic. - Swim is different from distributed application servers
Distributed application servers execute general purpose compute tasks, but in a stateless, ephemeral environment. This makes them fundamentally dependent on external infrastructure, and incapable of continuously communicating with each other. Swim Web Agents communicate peer-to-peer via Swim links, which are persistent, stateful connections between Web Agents. - Swim is different from serverless computing
Serverless computing executes delocalized functions, but which are short lived, non-addressable, and far from self-contained. Swim Web Agents are self-contained and and exist continuously to observe and react to data as it streams. - Swim is different from full-stack frameworks like Meteor
Full-stack application frameworks like Meteor provide everything an application needs, but are severely compromised, due to the fact that they crudely abstract over traditional middleware components. Swim is vertically integrated, offering developers unlimited flexibility to build whatever real-time applications they can imagine, without ever worrying about performance.
Learn More
Swim is an Open Source platform for building stateful data-driven applications that continually compute and stream their insights in real-time. You can get Swim here.