The Lego unit
When’s the last time you held a Lego brick? If you had to think at all, go order a set. Write it off as a business expense. It’s research. Take a moment to sit down, unwind, and build… anything There’s a beauty to Lego that is hard to describe yet everyone feels. It revolves around an invisible constant hidden inside every piece. 1.6. 8/5. The “Lego unit.” This number drives the design and the ratios of all Lego pieces and is the key to Lego’s trademark feel. 1.6 is not a number drawn from the laws of physics. It’s an artificial constraint. The Lego company could ignore it at any time, but they don’t. The same pieces you buy today fit with the pieces from decades ago and it’s all because of a number. 1.6.
You won’t see many pieces that measure 1.6mm, but each dimension of every piece is constrained by a multiple. The wall of Lego bricks is 1 Lego unit thick. The circular studs measure 3 Lego units wide and a one stud brick is 5 units square. Bricks are 6 units tall, plates are 2. These multiples lead to relationships that seem natural in use. Three plates is the height of one brick. Every five bricks of height equals 6 studs length (each are 30 Lego Units). The beauty of a system like Lego’s comes from everything working, always. It’s easy to make two things fit together, it’s difficult to make one hundred things fit together. It’s nearly impossible to make one hundred things today fit with one hundred things built 30 years ago. This takes planning and unwavering commitment.
Some look at “constraints” as a negative, but we look at them as liberating. With constraints come the freedom to focus on what matters.
Comparing technology to Lego is an easy metaphor but it usually stops at the building blocks. We’re not making toys at Vino, though. We’re making a systemized platform that prioritizes relationships and forever compatibility.
The Vino unit
Like a Lego brick, a Vino component is several layers away from its foundational unit. The “Vino unit” is a port. Ports are like an asynchronous stream of messages that can contain a successful value, an exception (a logical edge case), or an error (a problem).
A Vino component is a collection of input and output ports and the logic that sits between them. Components are stateless and disposable. Think of components like functions and ports as a consistent way of delivering both input parameters and return values.
Above components are providers. A provider is a collection of components. Providers can maintain state where necessary, e.g. for database connections, file handles, etc. Providers are like source code libraries or modules, except they are self-describing with a consistent interface. A consistent interface means that you can swap providers out with zero re-integration. Use an inmemory collection provider for prototyping, a filesystem collection provider during development & QA, then a redis collection provider for production. As of this post, Vino supports providers written in native Rust, WebAssembly, and as external GRPC microservices.
Schematics define a list of providers, their namespaces, and how their components connect. Schematics also have input and output ports and thus are also components.
A Vino network is a collection of schematics. Since schematics are components and a provider is a collection of components, a network is also a provider. It’s components or collections of components all the way down.
The Vino runtime is the execution layer that manages Vino networks. You can embed the runtime within an application itself or run it directly via a Vino host. A Vino host is an implementation of the runtime and how most will run Vino applications.
The secret to composability is consistency
This component->provider->component cycle is what makes Vino so powerful. Everything is either a component or a collection of components. Beyond the root component though, we stop dealing with source code as the only way we can describe logic. Schematics are where we start defining logic as relationships and we do that via easily changable configuration.
The ports standardize every connection so generic tools built for one component work for every component. Vino uses GRPC as a standard way to connect and control providers so you can treat Vino like a standalone application that automatically turns its whole self or any of its parts into a scalable microservice.
Make sure to sign up at https://vino.dev/ for updates on the release of the Vino runtime.