After the relaunch of the Wormatia website and the move to the new server, the third major project of the year for my football club followed. The aging live ticker software was to be moved onto a new, up-to-date software foundation.
To prepare for this a little, I had already started migrating the live ticker admin interface to VueJS components and switched communication over to JSON API requests. This meant the admin interface was already relatively decoupled.
Now came the next step. The API under the application's hood could be replaced, and the existing VueJS components could be integrated into the new application.
The whole thing really did work very well and, in the end, even went faster than I had expected.
A main goal for the new application was for the software to be particularly lightweight, so that even under load it would not put too much strain on the infrastructure. The old live ticker had once crashed during a match against Rot-Weiss Essen. Back then, we simply put a Varnish cache in front of the ticker, which then absorbed the load without any problems. The new application was to be as fast as possible, ideally not relying on a cache at all, or at least allowing us to set a very short cache duration. This has the advantage that ticker users can see the latest content very quickly. That is especially important for a live ticker.
A live ticker like this also has to withstand larger load spikes. There is the phenomenon, for example, of football fans repeatedly pressing F5 in their browsers in the 90th minute to see whether anything else has happened or whether the final whistle has blown. That puts a lot of pressure on the web server.
To give the conclusion away up front... The new application can easily meet those requirements. A ticker page can consistently be generated on the server in 5–10ms, without a cache.
Server log
The Google Lighthouse test agrees. Frontend performance seems to be quite OK :-)
Google Lighthouse test
Go Application
The heart of the live ticker application is now a Go application. I chose golang because, unlike PHP, which was used in the previous application, it is compiled. The Go application is just a single file that can be started. Everything is contained in it. So a separate web server is not strictly necessary. The web server is already included in the application.
To avoid having to develop everything from scratch and to get a little convenience, I decided to use the Fiber web framework.
The framework offers lots of things I could put to very good use. For example, it allows logic to be inserted between a request and the server response through so-called middleware components.
The live ticker uses several of these components to compress data, authenticate users, and restart the application in the event of a serious error, among other things.
Most importantly, though, the framework lets you route URLs to provide different pages and an API. The API is then responsible for communication with the live ticker admin interface.
Architecture of the Wormatia live ticker server application
Docker "From Scratch"
Since we had moved the new Wormatia server infrastructure entirely to containers, the live ticker was also put into a container. Fortunately, Go applications are particularly well suited to running in containers.
However, you need a little infrastructure to build the Docker image, the template for containers. We use a Drone-CI server for this. As soon as there is a change to the live ticker software's source code, it performs an automatic deployment.
In the CI pipeline (see image), you can see whether everything is working. All steps for building the application are automated there. First, the Go application is built. All dependent components are downloaded and the application is compiled. We also run automated tests to check whether the application behaves correctly.
Deployment via Drone-CI
After that, the VueJS admin interface is built. This is also an application, written in Javascript, which is then served by the server application during operation.
Admin interface during a match
All artifacts—the things generated in the CI pipeline—are then packed into the Docker image. The Docker image is then sent to a Docker registry.
After that, a script logs into the Wormatia server and makes sure the new Docker image is transferred to the server and a new container based on it is started.
The great thing about the Go application is that a Docker image can be built from scratch. That means the container contains only the files needed to run the application and nothing else. This provides maximum security, since an attacker can do virtually nothing in a container like that. There is no shell in which commands can be entered.
Our container contains only the JS files for the admin application, root SSL certificates for TLS communication, and time zone information needed for database communication. This also keeps the Docker image very small. In our case, 19.9 megabytes!
The whole thing is assembled in a multi-stage build. For all the technical folks, I have published the Dockerfile here.
FROM golang:alpine as builder RUN apk update && apk upgrade && apk add --no-cache ca-certificates RUN update-ca-certificates FROM scratch COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ COPY --from=builder /usr/local/go/lib/time/zoneinfo.zip / ENV TZ=Europe/Berlin ENV ZONEINFO=/zoneinfo.zip ADD liveticker2 / ADD static/ /static ADD views/ /views WORKDIR / EXPOSE 3000 CMD ["/liveticker2"]
Twitter, Goal
To provide a good service for ticker users, we automatically send Twitter messages for certain events: goals, the start of a match, and the end of a match. To make sure this happens promptly, it has also been automated. When the goal button is pressed in the ticker, a message is sent to a Node-Red system, which then sends a tweet via Twitter.
Node-Red flow
Operations
We also need a database to run the live ticker. Here we use MySQL 8. Operations are monitored with a Prometheus server. An additional container is started for this. It includes a "mysql node exporter" to collect database metrics for the Prometheus system.
Everything uses very little memory and runs very quickly. At the moment, the database uses the most memory. We could probably optimize memory requirements here as well.
Extremely low memory requirements
A look at the monitoring system shows that memory usage by the server application dropped massively when the new application started. We achieved a saving of around 70%.
One goal we had set ourselves was to optimize the application's performance. A look at the monitoring shows here as well that the new application is much better optimized.
The diagram shows response time before and after the deployment of the new application, at around 17:40.
Server response time from the monitoring system's perspective
Conclusion
The new Wormatia live ticker is faster and leaner. On top of that, operating the application is considerably simpler. The new Go application rocks!
Alla Wormatia!