Update April 1, 2024
Hello everyone! Welcome the the second installment of Breadboard Update. Today is April 1, and there must be some sort of a clever joke in here. Who knows? Maybe there is ✨.
⚙️ Under the hood
Let's start this update with the engine updates. There are two new developments worthy of attention:
Run as a concept
One big breakthrough we had in the last two weeks was elevating the concept of a run in the importance of how the users interact with Breadboard. We realized that it was sort of a trace, a historical artifact that captures how many graphs came together to produce any given result.
As one of my colleagues put it, while the graph represents a multiverse of future possibilities, the run is all of these possibilities collapsed into a timeline in the past.
Because of that, a run is a sort of Katamari ball of everything that's happened during the course of the run: all graphs that were loaded, all inputs that were supplied, all data that was generated, and outputs that was produced.
This makes them very valuable, since having a Katamari ball means that I can retrace my steps within it, save it, compare it with previous ones, share it with others, and all kinds of useful things that comes with perfect observability.
Runs are, therefore, an important user-facing concept. At any given time: am I looking at the multiverse, or am I examining the past? We are still trying to figure out what this means in terms of the actual user experience. Our intuition is that we will need to have a clearer separation between the two views.
Within the engine, this means imbuing the Run Inspector API with the abilities to serialize and deserialize, which is now implemented. When we click the "Download" link in "Activity Log", we will get the serialized representation of the run.
Loader convergence
We unified all of our various loading code within Breadboard. There is now a single instance of a nascent GraphLoader API which will see all graph loads. This opens a path toward caching, tracking all loaded and invoked graphs, etc. This is an entirely non-user-facing concept -- in fact, a user noticing this change would likely mean a bug in refactoring. However, it unlocks distributed applications of Breadboard, especially in the future where runs are a fully-fledged concept.
🚀 Shipped
First release of the @breadboard-ai/build package
This is the next rev on the more strongly typed syntax for TypeScript-based board development. It currently supports defining new Breadboard nodes with strong types,giving us lots of red squigglies in VSCode if we make a mistake. For more information, check out https://github.com/breadboard-ai/breadboard/tree/main/packages/build.
File system improvements
Building on the progress from previous two weeks, the file system support is now a bit more 🍞 baked. We can create new boards from within the editor:
We can also delete a board:
And of course, we can save a board back to the file system:
All these improvements amount to a fairly nice developer experience. We can now mount a directory in the editor, and build boards within it. It works very well in combination with a Git: use Git for version control (as one should), and use the Web UI for imagining new possibilities with generative AI.
Local board store support
In addition to file system, Breadboard editor now offers the ability to create and manage boards locally within the browser. This feature is powered by the Indexed DB API, and is broadly available across all browsers: Firefox and Safari users no longer need to feel like they're missing out when prototyping new boards. The "Board Store" is local to the browser and enables us to start building even faster:
File change notifications support
All of the features are enabled by the still-emerging GraphProvider API, which enables Breadboard to view graphs as abstract entities whose actual location and state is handled by a pluggable module. This GraphProvider API also has the ability to track file change notifications, which is super-cool. We can't wait for the FileSystemObserver to land in the browsers.
In the meantime, we implemented this feature for Breadboard debugger. When using breadboard debug, we will now rely on GraphProvider to notify us when the source file changes due to user's edits.
Which allowed us to implement the ...
Debugger soft-reload
This is a pretty significant efficiency-booster. Previously, Breadboard debugger would simply reload the whole page on file change during the "hot-reload" cycle. Thanks to the GraphProvider, the debugger only reloads the graph itself, making the hot reload even faster and enabling us to stay focused on rapid prototyping.
Lots of quality-of-life improvements
We've invested a bunch of time into making the editor just a little bit friendlier to use. Lots of bug fixes, and polish.
As one would expect, we can now reset layout of the graph in the editor:
There is now a nice overlay to tell us all about the activity within any node. Just click on it in the activity log and dig in:
Not to be outdone, the Preview toggle also turned into an overlay, so that we can quickly see the mini-app powered by our board -- right inside of the editor:
Last but not least, we now correctly render Markdown in output:
Among other changes:
-
Activity Log cleaned up to show what's important and elide what isn't.
-
Breadboard now lets the user know when loading of the board fails.
-
Graph nodes are positioned a bit more elegantly.
-
When users point the editor to a deleted board, we redirect them to a non-deleted board.
-
More bug fixes.
iOS support
Just to make sure that Breadboard users who love their iPads don't feel neglected, we've made sure that Breadboard editor works well on iOS.
OpenAPI Import v2
The next iteration of the OpenAPI importer is ready to take flight. This capability allows importing most OpenAPI endpoints to a functional board.
To give it a whirl, run:
breadboard import <url>Where the <url> is the URL pointing to the OpenAPI spec. Here's one example of a board that calls Mistral AI that was created with this command:
🧑🍳 On the stove
-
Next up for the
@breadboard-ai/buildpackage: board serialization and being able to write boards in this new iteration of strongly typed syntax. -
We are on our way to make node editing feature-complete. So far, we support schema editor for inputs and outputs, arrays, enums, and defaults/examples. There's more to come.
-
We are teaching Breadboard not just to save runs, but also to load them. This would enable board makers to share runs just like we can share graphs. If we want to highlight a particular interesting run or get our friend's help in debugging a board, loading runs would enable us to send the run over to have another pair of eyes on it.