Serilog & OpenTelemetry in .NET: React Demo UI

This post is a continuation of the Serilog series (previous part: Serilog & OpenTelemetry in .NET: Tracing in Grafana).

In this part, we will:

• Explore the frontend application
• Walk through the complete business workflow in the UI
• Wrap up the Serilog series and look at possible next steps

Let's get started! 🚀

Prerequisites

• This episode starts from branch 007-demo-ui. You will find it here.
• The branch adds a manual browser-driven workflow for the same business scenarios that were previously exercised through k6 scripts.

Frontend application

The frontend application is a lightweight React app created with Vite. It talks to the backend through the Nginx entrypoint and lets us execute the same business flows that generate meaningful logs and traces: browsing the catalog, editing the cart, checking out, and handling warehouse operations. The frontend is located in the UI folder of the repository.

Compared to load tests, this UI is much easier to use in workshops or live demos because you can click through realistic scenarios and immediately connect what happened in the browser with what appears in Grafana.

Run the demo

There are two main ways to run the demo:

This approach starts the backend stack and leaves the frontend for you to run on the host machine separately. You can start the UI with these commands:

This approach is faster to start and lets you change the frontend without rebuilding the Docker image. Open http://localhost:5173 after the dev server starts. Check out the README for more details.

Alternatively, you can start everything with a single command:

This starts the UI in containers as well. In that setup, open http://localhost:8080. If you want to make any frontend changes, you will need to rebuild the UI image each time.

More details on running the demo can be found in the README.

Business workflow in the UI

The UI is intentionally simple, but it covers the full end-to-end workflow and produces the exact kinds of logs and traces you want to inspect during a walkthrough.

Here is a breakdown of the main features of the frontend application.

Product catalog

Features:

• Search products by name
• Filter products by category
• Sort products by name or category (ascending or descending)
• View product details (name, category, description, price, availability)
• Add available products to the cart

The page starts with search, filter, sort, and settings controls. Currently, the settings panel exposes:

• Show sold out section - by default, sold-out products stay in the main list and appear dimmed, with the add-to-cart action disabled. When this option is enabled, sold-out items move to a separate section below while keeping the same sort order.

Below that, you can browse the product list. Each product card shows the name, category badge, short description, price, availability, and an Add to cart button. Products already in the cart show a small counter badge. Adding an item triggers a toast notification. It isn't fancy, but it's more than enough for demo purposes.

Cart

Features:

• Change item quantities
• Remove items from the cart
• Clear the cart
• Review the order summary with item prices
• Continue to checkout

Checkout

Features:

• Review order summary with total price (items + delivery)
• Select a delivery option, payment method, and fake payment scenario outcome (Success, Decline, SlowSuccess, Timeout)
• Place the order

When you click the Place order button, the order is created and the payment flow starts. Depending on the selected payment scenario, you can see different outcomes in the UI and different logs in the backend. For example, if you select Decline, you will see an error message in the UI and corresponding failure logs in the backend. If you select SlowSuccess, the UI shows a slower payment path that eventually completes, and the logs reflect that delayed success as well.

Orders

Features:

• View a list of orders with their status
• View order details (items, delivery, payment status)
• Look up an order by ID

Warehouse backlog

Features:

• View a list of orders waiting to be processed in the warehouse
• Filter orders by status and search by order ID
• Collect, pack, and ship orders, with an optional details note for each action

Warehouse inventory

Features:

• View list of products in the warehouse inventory with their stock levels
• Search products in the warehouse inventory by name and filter by category
• Update stock levels for products (Restock, Recount, Write off)

Make your own demo

This lightweight web application makes the demo much easier to present because you can drive realistic business flows manually and immediately inspect the resulting logs and traces in Grafana. This is valuable in workshops, architecture reviews, or internal demos where you want to connect a button click with the exact backend behavior it triggered.

If you want one compact walkthrough, place a successful order, copy its order ID, inspect the checkout flow in Grafana, and then move the same order through collect, pack, and ship in the warehouse backlog. That single scenario gives you a clean story across synchronous requests, asynchronous follow-up work, and user-facing state changes.

As you might have noticed, the frontend application is intentionally basic and there are many areas for improvement. That is a deliberate tradeoff: the goal here is to create an easy-to-understand observability playground, not to ship a production e-commerce experience. I still plan to improve the frontend over time, but the current version is already enough to support useful logging and tracing demonstrations.

Summary and next steps

This post concludes the Serilog series. We have covered a lot of ground, from setting up Serilog in a .NET application, through structured logging and Grafana, to building a distributed demo with OpenTelemetry and a manual UI for driving end-to-end scenarios.

The main goal of this series was to show how good logging practices and observability tools help you understand system behavior, investigate failures, and improve reliability. I hope it was useful and gives you ideas for applying similar patterns in your own projects.

Even though this series is wrapping up, the SerilogDemo repository will keep evolving. Here are a few topics I may cover next:

• Grafana dashboards tailored for troubleshooting, performance monitoring, and business insights
• Alerting in Grafana for errors and degraded flows
• Adding authentication and authorization to the demo and observing how identity context appears in logs and traces
• Deploying the demo to the cloud (for example Azure or AWS) and comparing the local and hosted observability story
• Building Terraform scripts to provision and manage the supporting infrastructure

If any of these topics sound useful, stay tuned for future posts and repository updates. In the meantime, run the demo, inspect the logs, and adapt the workflow to fit the scenarios you want to explain to your own team.

Happy logging!