Stackable

The new Stackable Release 24.3. is out - learn more about its great new security features!

Building a Kubernetes-Hosted Web UI for Our Data Platform

Stackable blog thumbnail, showing an illustration of a man setting and a big laptop beside him.
Posted by on | Featured

Approachability is not one of the biggest strengths of Kubernetes. Anybody who can’t express their questions in form of kubectl commands will have a hard time finding out what’s going on inside a cluster.

Not that it were an easy task. The learning curve is steep.

At the same time, our non-or-less-technical users want and deserve to be able to find out essential information about the Stackable Data Platform (SDP): what data products currently run and how to reach them.

Preferably without needing to get CKA/CKAD certified and having to update their current job description with “k8s & CLI wizard”.

To make it easier to interact with our platform, we are in the process of adding a web interface to the Stackable Data Platform!

The User Story

Getting an overview of what is going on with an existing SDP installation should not be a hard task.

A person who is not necessarily fluent with all Kubernetes primitives should be able to open a browser, navigate to a URL and find out all they need to know with a few clicks. This way they can get back to working with the data tools they need, instead of getting blocked by technical issues.

To make this possible, we want to make it super easy to run a custom web UI as part of your SDP setup, where users of the data platform can access it.

The Architecture

Dev tools for Kubernetes often run on a local machine, instead of on the actual cluster.

Running the web UI strictly locally is an option we want to keep open, so any developer with a .kube/config present can spin it up and give it a try.

However, one of our main goals is to provide value to non-technical stakeholders. This means that the web UI will need to be run as a service, probably in the Kubernetes cluster where the SDP installation resides.

The Backend

Gotta get it out of my system: we are rewriting it in Rust.

Rust is the main language of choice at Stackable. Starting at our operators, utility libraries to internal tooling. We had great experience with Rust so far. So why not use it for a web service.

In addition, we already have some code for SDP management – it will be extracted into a utility library from our current stackablectl tool. The server will expose some of that functionality via a HTTP REST API.

On the Rust side, we are going to build on top of the following dependencies:

  • tokio, the async runtime, which is used to handle incoming network requests over HTTP/TCP.
  • axum, a HTTP framework for building REST APIs. It is based on the tokio runtime.
  • utoipa, a proc-macro/derive based OpenAPI spec generator which integrates nicely with axum.
  • clap, a powerful command line argument parser which powers the CLI interface.
  • tracing is used for context-rich application logging. Our complete stack emits tracing events which can be consumed via multiple different subscribers.
  • snafu for easy custom error handling.

Note: we were considering thiserror and anyhow, but decided to go with snafu instead, just because we use it in our other projects.

The Frontend

The web server won’t just provide REST endpoints, it will also serve static files so we get what we aimed for – a nice web UI.

The user-facing part of the Stackable UI (name placeholder) will be a modern web app written in TypeScript. Core community-provided dependencies are:

  • SolidJS is a reactivity-based framework for building modular web apps.
  • UnoCSS is an on-demand CSS framework that generates CSS based on HTML classes.
  • Vite is a modern and fast TS/JS toolchain for all kinds of frameworks. Based on Rollup.

We chose SolidJS to get the best of both worlds from Vue and React. We have similar reactivity patterns to Vue and JSX from React. Plus, all the code gets compiled to native JS without a VDOM.

We want to try it and will evaluate if it is the right fit for us. If not, we will look into different frameworks.

The list for the front end is currently not complete, and will probably be expanded in the future.

Time to Get Back to Building

We hope that a first version of the web UI will make it into the next release of the Stackable Data Platform, and will help our non-technical users see what’s going on and navigate to where they need to go at a glance in the future.

This will be the first user-facing web app UI crafted at Stackable, and we are looking forward to share our experience, gotchas and lessons learned in a future post!

Comments are closed.