A recent project I worked on, enhancing Beacon’s regression testing process, called for the development of some new and enhanced features for Beacon’s Test Dashboards. Just four weeks into my time at Beacon, this was my first experience using the platform, developer environment, and Glint, Beacon’s Application Development framework. I was pleasantly surprised at how quick and easy it was to use.

Starting out and switching to Glint

I had begun the dashboard part of this project using Streamlit, because I had used it before and was very comfortable with it—and Beacon makes it easy to extend and incorporate third-party apps. After about 4 days building a backend and integrating it with a simple Streamlit frontend, I had a proof-of-concept in place. But I could not get the customization and performance efficiency that I needed for displaying complex nested components. So I decided to try Glint, Beacon’s application development framework. I was concerned that I would lose time trying to learn a new framework. But I came out pleasantly surprised. It was easy to pick up, effective at letting me focus on essential features, and efficient at updating the views. And of course it played well with other Beacon features.

Learning Glint and rebuilding the UI

With the plug-and-play capabilities of Glint, I swiftly refactored my backend and rebuilt the entire frontend using Glint components within a day. I started by familiarizing myself with Glint through the “Glint Essentials” Beacon University course. Then I identified key components from the Glint Documentation and experimented with their properties using the Sandbox integration directly within the docs. Finally, I chose a demo application from the variety available to Glint developers, selecting one that closely matched my desired layout, and used it as a foundation to build out my application. By the end of the day, I had successfully rebuilt my frontend with Glint.

Understanding Glint, Gromit, and Bindings

Glint’s primary partner in application development is Beacon’s dependency graph data model, Gromit. Gromit manages data relationships and uses live bindings to synchronize data with the Glint application’s views. As a result, forms, fields, and graphics are dynamically populated and updated onscreen as the underlying data evolves and the dependency graph is refreshed. This seamless integration meant that I didn’t have to worry about maintaining session state across a dashboard where complex data-filtering inputs trigger backend processing and then reload the necessary UI components.

Adding new elements to the dashboard

The metadata that I was adding and deriving from my analysis of regression test results provided a richer set of categories and filters, so developers could get a more accurate and more focused view of how and where the tests were failing. But in many web applications, selecting or changing a filter triggers a reload of the page and all of the components, which is slow and inefficient.

Figure 3: New dashboard prototype built with the Glint SDK

One of Glint’s key advantages is its efficiency through the relationship with Gromit, the dependency graph with memoization and lazy evaluation. Unlike other Python application frameworks, Glint only needs to refresh the fields whose values have changed. This leads to significant performance improvements, especially when handling large datasets with multiple filters. Developers can now filter runs by owner, date range, type of test run, and other characteristics, quickly narrowing down to just those results relevant to their feature or function. And they don’t have to wait for the dashboard to reload for each selection. Gromit keeps track of what data has changed, and Glint updates the screen. Gromit also streamlines the coordination of data retrievals with the backend, allowing the frontend and backend to work together seamlessly—all within Python, in an intuitive and cohesive manner.

Building an “intelligent table”

Glint’s integration with the full Beacon Platform made it easy for me to extend the value of the Test Dashboard. I built an “intelligent table” that groups and summarizes root cause analysis across environments. The idea is to group a test module by its root cause over time, as opposed to a single point in time.

Built on the research capabilities of Beacon Notebook, the process uses Beacon’s scalable compute to ingest vast amounts of test data, read and parse potentially thousands of exception messages, analyze them effectively, and contribute additional metadata for the filters. Developers can group and filter test failures to see ones that are newly passing or newly failing, comparators of failures in development and production environments, root cause analysis, and changes to root cause over time.

Leveraging Glint’s Fragments

Developers often want to share test data directly from the dashboard or schedule custom reports to receive automated information about test failures without needing to enter a GUI. To accommodate this, I implemented a report scheduling feature, which on the frontend required building Glint forms. These forms needed additional Gromit backings to maintain state and involved numerous Glint view components, which began to overcomplicate my Model, View, and Controller (MVC) objects.

Fortunately, I leveraged Glint’s Fragments Framework to streamline the process. This allowed me to break down my application into interoperable fragments, each with its own internal model, view, and controller. These fragments could be instantiated as needed with the necessary state, which significantly cleaned up my workflow and enhanced both code reusability and readability.

Working within a comprehensive platform

To complete my report scheduling and data sharing feature set, I needed to develop the backend reporting features. Fortunately, the integrations between Glint and the rest of Beacon’s platform made this process straightforward. After a quick search through the Beacon Docs, I found information on Beacon’s SMTP gateway and used the smtplib context manager, which made sending emails quite simple.

To enable report scheduling, I leveraged Beacon’s guide on reading and writing to object storage, which helped me persistently store report configurations as JSON files in AWS’s blob storage, S3. For batch scheduling, I used Beacon’s Bob product. While exploring the Bob job documentation in Beacon Docs, I discovered the capability to use a single Bob job to spawn multiple unique parameterized Bob jobs on the fly. With just two simple job definitions and two corresponding scripts, I successfully implemented a custom reporting feature that auto-generates well-formatted emails, providing team members with their failure statistics and analytics. This allows developers and managers to schedule and send reports at custom intervals, giving them access to all the relevant information from the system runs page of the test dashboard.

Beacon makes it easy to get started

My internship at Beacon Platform was my first experience working on complex software products in a commercial environment. Fortunately, Beacon makes it incredibly easy to get started, learn the frameworks, and quickly build sophisticated software. The comprehensive documentation and extensive collection of scripts made it easy to learn on the go. Although I initially felt overwhelmed by the platform’s complexity and power, I couldn’t have asked for a better set of tools to flatten the learning curve. These resources enabled me to become a highly productive employee within just a few weeks, and provide real value to the company.