Kyle J. Davis is the Technical Marketing Manager at Redis Labs. Aside from crafting code in Rust or Javascript, he presents and writes about Redis. Kyle lives in Edmonton, Alberta, Canada.
Kyle J. Davis is the Technical Marketing Manager at Redis Labs. Aside from crafting code in Rust or Javascript, he presents and writes about Redis. Kyle lives in Edmonton, Alberta, Canada.A few weeks before our annual conference, RedisConf, our CTO tapped me to create a demo for the keynote. No pressure! He said he wanted me to cover a few new features and make it visually interesting. For those of you who don’t know,Redis is an in-memory database often used for high-performance and real-time applications. Countless times a day you probably do something that touches a Redis server but it’s deep down in the stack. That’s often one of our challenges—it’s not a very visual piece of software! It resides on a server, humming along in the background making things go very fast.
That being said, making a visual presentation was a challenge. At this point, I needed to demonstrate a few different aspects of the database:
- Streams as data pathways between applications
- RediSearch, a real-time search engine
- Redis Graph, a graph-query engine
Intrinsic to all of these demos was that I needed to have a fully functional UI that continued to illustrate that Redis is a high-performance solution.
Streams are a new data type in Redis that allow for time-based recording of semi-structured data. Streams have a push-like property which allows you to easily create an event architecture spanning multiple processes or machines. Effectively, when an event happens in one part of your architecture, many separate processes can act on it and either do something directly or push another event into a stream.
I knew Streams would play a large part in the demo, so I built a Stream-based processor for data flowing out of the Twitter API and into a RediSearch, word frequency counter, and Graph. But not only did the Streams power the data flowing between the Twitter API and the indexers but also the data going out to the UI and the user input back into the servers. Streams have some similar characteristics to WebSockets, so I built a small library that, in effect, proxies Streams into WebSocket messages in and out of the browser demo. This made every interaction real-time.
As far as a UI library, I had previously tried out a few toy projects with Vaadin Web Components and I was impressed. The learning curve was minimal and there was little fuss to get something up and running. For this demo, I needed to develop something quickly without having to worry about the minutiae of UI. It also needed to keep up with the data flowing in and out of the system; a bad UI response would make the database appear slow (fair or not). While much of the visualizations in the demo were powered by custom D3 scripts, all of the UI components were stock Vaadin components.
With the word-frequency use case, I employed a D3-based word cloud and a Vaadin grid to display the word frequency table. For RediSearch, I used Vaadin buttons, text fields, and grids to create the UI. In Redis Graph, I used a D3 force-directed graph to generate a visualization of the graph data but used Vaadin text fields, buttons, and tabs (the tabs were used to create a zoom controller for the force-directed graph).
The Vaadin UI components provided a ton of UI polish and allowed me to focus on crafting critical parts of the demo that showed both high performance and interesting characteristics of these new Redis features. Simply put, without the speed and convenience afforded me by Vaadin Web Components, I would not have had the time to develop such a demo—the same holds true for production applications: Vaadin Web Components allow you to focus on getting the job done without having to worry about the tedium of UI.
You can see a video of the demo in the video below: