Building a Web UI for Workflows4s with Scala.js and Tyrian

6 min read4 days ago

Who Am I?

I’m Atharva, a final-year student at IIIT Jabalpur, India. I was selected for Google Summer of Code 2025 with the Scala Center, where I’m working on the Workflows4s Web UI project.

In this blog, I’ll share how I got selected, what my journey has been like so far, and what I’m looking forward to in the coming months.

What is Workflows4s?

Workflows4s is a Scala library for modeling and running workflows in a type-safe, composable, and functional way. It allows developers to represent long-running business processes or system orchestrations as pure code.

What is the Workflows4s Web UI Project?

As part of Google Summer of Code 2025, I’m building a web-based UI for Workflows4s. This UI helps users visualize workflows, inspect their state, and understand their execution paths. The frontend is built in Scala.js using Tyrian, while the backend exposes workflow metadata and execution data through a functional Tapir-based API.

The goal is to create a lightweight, functional, and developer-friendly dashboard for workflow inspection and debugging — written entirely in Scala.

Discovering Scala and Functional Programming

It all started with Scala. A language close to my heart because of how much it has taught me. No other language helped me understand the fundamentals of computer science and software architecture like Scala and functional programming have.

I began contributing to open source through Doodle, a creative graphics library in Scala. That experience was fun and welcoming. I then shifted my attention to Cats Effect, a powerful library for working with effectful and concurrent computations in Scala.

One day, I came across the Scala Center’s GitHub page listing their GSoC proposal projects, and one idea immediately caught my eye: Workflows4s Web UI. It combined everything I had been working on for the past few years — Scala, frontend development, full-stack architecture, and web. It felt like the right opportunity.

Writing the Proposal and Getting Accepted

I reached out to my future mentor Voytek Pituła, who responded quickly and answered all my questions. With that motivation, I dived into the codebase and started exploring how everything was structured.

I drafted a proposal, received useful feedback, and after a few iterations, it was submitted. On May 8, I received the selection email. I was excited! I now had two excellent mentors: Voytek, the founder of Business4s initative, and Dave Smith, the creator of the Tyrian UI library. They both are excellent as mentors, humans and of course, Scala developers. Our working group was supported by Watson, a volunteer developer who became interested in Workflows4s and had prior open-source experience with Tyrian.

To better understand the library, I contributed a custom workflow of my own to the repository. That experience helped me empathize with future users of the UI and gave me confidence that I could meaningfully contribute.

Choosing Tyrian

For the frontend, we chose Tyrian, an Elm-style UI framework written in Scala.js.

We started with the official Tyrian template and eventually migrated from parcel to Vite as our build tool. Vite was fast, modern, and much more pleasant to work with than the previous setup. It also made Scala.js builds easier to integrate with traditional web development workflows.

UI Design Principles and Discussions

During our early discussions, we decided to keep the UI simple and backend-developer-friendly. Some key principles we agreed on were:

Avoid large CSS frameworks like Tailwind or Bootstrap
Try to use high-level, declarative components such as Button(“Save”, Color.Primary) instead of raw HTML
Keep JS dependencies minimal, using as few npm packages as possible
Stick to pure Tyrian and build UI using just Scala

This led to many exciting conversations about how we might influence Tyrian’s ecosystem. While we kept things simple for now, these ideas laid the foundation for future abstraction layers, possibly even something like Elm UI in Scala.

Building the Web API Module

Before diving fully into frontend features, we needed a solid backend API. This meant adding a new module to the Workflows4s codebase, implementing type-safe REST endpoints using Tapir. We chose Tapir because it can be easily used from any stack, and it also allows to generate openapi-spec which is crucial for any official API. The result was a working Web API module that served workflow definitions using real data from the core workflows4s engine.

Voytek encouraged keeping things simple, as the structure could be improved later. With that reassurance, I focused on getting things working rather than perfect. I implemented a basic RealWorkflowService, and created example integrations with CourseRegistration and PullRequest workflows.

Calling our endpoints like /api/v1/definitions returned real workflow metadata. That was a big and satisfying milestone.

Integrating the API with the UI

With a functioning backend, the next step was to consume it from our Tyrian UI. This was tricky. Tyrian did not have official support for STTP, our preferred HTTP client. Fortunately, Watson’s demo on integrating STTP with Tyrian helped me understand how to fetch data. That demowas also immediately integrated into Tyrian documentation to help future users.

The result was our first real UI that displayed live data from workflow definitions. It took effort, especially to debug rendering logic and JSON parsing, but it worked!

Backend Architecture and Cats Effect Transition

While the API initially used Pekko HTTP and Scala Futures, we soon needed to switch to Cats Effect IO to align with functional best practices. This required changing method signatures and dealing with the fact that Pekko HTTP’s Tapir interpreter did not support IO natively.

We explored options like wrapping IO in Futures using Dispatcher, but eventually agreed that the better approach would be to migrate to an HTTP server that supported IO directly, such as Http4s.

Refactoring and Modular Components

Once the basic layout was in place, I replaced our custom styles with Bulma, suggested by Voytek, a lightweight CSS framework. The goal was to make the codebase simpler and even friendlier for backend developers, who usually want to have as little to do with CSS as possible.

I then started modularizing the application using Tyrian’s subsystem pattern. Each feature became a self-contained component with its own model, messages, update logic, and view renderer. This included subsystems like WorkflowsManager and InstancesManager.

Learning Through Mentorship and Code Reviews

Every pull request I submitted came with valuable feedback. Some patterns and lessons that stood out:

Using enums and other Scala 3 features where appropriate
Avoiding default parameters in case classes
Refactoring the view and update logic into instance methods instead of static functions

These lessons taught me how to build software that is clean, modular, and easy to maintain, especially in collaborative environments.

Final Thoughts

This project has been one of the most rewarding experiences of my software journey so far. I got to write production-ready Scala code, contribute to an open-source library, and work with experienced mentors who helped me grow as a developer.

Workflows4s Web UI is just getting started. With signal handling, live instance visualization, and deeper UI patterns coming up, the next few weeks are going to be just as exciting.

Acknowledgements

I am deeply thankful to Voytek Pituła, Dave Smith and Watson for their time, mentorship, and honest feedback. They helped me understand both the architectural decisions and implementation techniques that go into real-world software.

Thanks also to the Scala Center and Google Summer of Code for giving me the opportunity to be part of this project and community.

Let’s Connect

If you are interested in Scala, Tyrian, Workflows4s, or contributing to open source, feel free to reach out. I’d be happy to chat and share what I’ve learned.

Business4s Blog