Welcome back to The Deep Dive. Today we're looking at something a little different.
It's not just a
piece of software, but really an architectural solution that was born out of a
crisis.
We're going to be unpacking an essential open source platform, a kind of digital
front end,
that was specifically designed to handle the immense chaos of scaling a university
classroom
during a global pandemic. Our mission today is to really get a handle on how this
platform makes
life so much better for institutions that are trying to manage huge numbers of
users all at once,
especially if they're relying on Big Blue Button. But first, a quick word on why
all this matters,
why stability and a solid architecture are so key. This Deep Dive is supported by
Safe Server. Safe
Server focuses on hosting complex open source software, exactly the kind of tools
we're discussing
today, and they really support clients on their digital transformation journey. So
if you need
powerful hosting that just works, you can find out more about how they do all the
heavy lifting at
www.safeserver.de. Right. So the core subject today is Pylos. It's an acronym for
platform for
interactive live online seminars. And if you're new to this whole space, the
easiest way to think
about Pylos is this. It's a modern, very easy to use open source front end. It's
designed to sit
right on top of your Big Blue Button or BBB server setup. So it's the nice looking
website, the
dashboard, basically the user friendly part that students and teachers actually log
into. Exactly.
It's built on top of that powerful but sometimes complicated engine underneath. And
what makes it
so special? Well, what makes Pylos instantly relevant for say a big university
deployment
is that it brings a massive piece of enterprise level functionality right out of
the box. Okay.
A built-in load balancer. Ah, the load balancer. That really is the star feature
here. But before
we get into the mechanics of that, let's get the origin story. The source material
is very clear.
This wasn't some commercial product. No, not at all. It was born from pure
necessity. Pylos
started at the TeachMiddleHessin University of Applied Sciences, specifically in
their faculty
of health. So not even the main IT department. Right. And that's important. This
was a faculty
that was deeply affected by the sudden shift to remote learning in 2020. They
needed a custom
solution for their specific problems, digital classrooms, secure group work, and
running these
huge online seminars without everything crashing. I think we all remember those
days in 2020,
just scrambling to find any platform that could handle that sudden surge in users.
Most of the tools out there, even the open source ones, just felt like they were
held together with,
I don't know, duct tape and good intentions. And that experience, that constant
frustration with
crashes, with missing features, with the difficulty of getting things to work, that
was the direct
catalyst for Pylos. They just needed a modern, flexible system that was actually
built for an
academic environment. So let's transition a bit into that core relationship. We've
said Pylos is
the front end, the body of the car, so to speak. What exactly is Big Blue Button,
the engine, doing?
So Big Blue Button is the underlying heavy duty open source web conferencing system.
It's what's
actually handling all the functionality. Like the video streaming, the whiteboards.
Exactly. The video
encoding, shared whiteboards, breakout rooms, all the recording capabilities, all
the real-time stuff.
Pylos just tells it what to do. I see. And a really crucial point here, which they
emphasize
in their documentation, is that while Pylos uses BBB, it's not endorsed or
certified by Big Blue
Button Inc. It's a completely independent specialized wrapper around it. A
customized wrapper
built for a university's unique needs. And this brings us to that big pivot point.
Yeah. Because
there's another well-known front end for BBB, right? Greenlight. Yes, exactly.
Greenlight is
a very functional, widely used project. So the critical question is, why? Why did
the team at
THM spend all the time and resources to build Pylos from the ground up? Why not
just, you know,
fork Greenlight and add the features they wanted? And that's really the core of
this whole deep dive.
If open source is about collaboration, why start over? The sources seem to put the
blame
squarely on one thing. Architecture. They're very direct about it. During that
really intense 2020
online semester, a lot of crucial features they needed were either exceptionally
difficult or
just unsolvable within the Greenlight framework. Unsolvable. That's a strong word.
It is. And the
difficulty wasn't about the skill of the developers. It was about Greenlight's
fundamental
architectural choice. It was built on Ruby on Rails. Okay, so for anyone listening
who's a bit
more on the technical side, can you elaborate on that? Why would a Ruby on Rails
foundation be such
a roadblock for a system like this? Well, Ruby on Rails can be fantastic for
building apps quickly,
especially things that are pretty predictable and synchronous. Think of like a
standard website or
some admin forms, but a massive video conferencing system, especially one that has
to dynamically
manage a whole pool of load balance servers, needs extreme asynchronous handling.
You have
thousands of users, all starting sessions, checking server capacity, updating lists,
all at the same time. So the architecture of Rails, which is more monolithic, more
synchronous,
it just started fighting against the chaotic high concurrency needs of a live
teaching platform.
That's a perfect way to put it. They ran into what we call architectural friction
to build a dynamic API driven load balancing system, which needs constant server
health
checks and routing sessions on the fly. They realized it was just too complex to
force that
into a traditional Rails structure. So it was actually easier to start over. The
cost of
starting fresh with a modern decoupled architecture was actually lower than trying
to force the old
one to work. Which brings us back to that essential feature, the load balancer. And
this is where
Pylus really shines. This isn't just a simple round robin load balancer, you know,
you go to server A,
you go to server B. With streaming video, it's not that simple. Right, because once
you're in a meeting,
you have to stay on that specific server session persistence. Absolutely mandatory.
So the Pylus
load balancer sitting on the front end, it uses the big blue button API to check
the real time
capacity and health of the entire pool of servers before it ever routes a user to a
room. So it
prevents those cascading failures you'd see when an institution just pushed too
many people onto one
single BBB server. That stability is the huge payoff for that big architectural
overhaul. Okay,
that shifts us perfectly from the why to the how. If Ruby on Rails was the problem,
what is this new
flexible architecture they chose? Let's break down the four main components, the
stacks that make up
Pylus. Right, so we'll start with the obvious one. Component one is big blue button.
It's still the
indispensable engine, the core conferencing system. Understood. So what did they
choose to replace
Rails with for the main foundation? That would be Laravel. Laravel is a very
powerful expressive PHP
web framework. They chose it specifically to build the backend JSON API. So when
the source material
talks about its expressive, elegant syntax, what does that mean in practical terms?
It's basically
developer speak for saying it makes building complex scalable APIs a lot simpler
and faster
than what they were dealing with before. It lets you have that clean separation
between the backend
logic and the front end display. So Laravel is... That's component number three.
View. View is the
JavaScript framework they used for building the user interface. So the clean
dashboard, the room
creation pop-ups, the settings pages, that's all view. So by using view, the front
end can be
updated and maintained completely independently from the Laravel backend. A huge
amount of
flexibility compared to a monolithic system where the UI and the backend are all
tangled together.
And this decouple architecture Laravel for the backend, view for the front end,
that is the direct answer to the problems they had with Greenlight. It's the whole
point of the
project. And then there's one final piece, the translation layer. They needed a
reliable way
for this new Laravel API to talk to the big blue button engine. The translator,
what is it? It's
the fourth component, a library called Littler Button, big blue button, A-B-E-P. It's
basically
a specialized, unofficial PHP API wrapper. Okay. It translates the commands from
pilots like create
a meeting or what's the server status into a format that the BBB engine understands.
And then
it translates the responses back. It closes the loop. That makes the whole stack
incredibly clear.
And looking at the technical snapshot, the code is about 80% PHP and 19% view.
That heavy reliance on PHP and Laravel, it suggests something about the original
developers,
doesn't it? But it does. It signals that the internal expertise at the university
was likely
very strong in the PHP ecosystem. You could argue for using other languages like
Node or Go for this
kind of thing, but choosing Laravel was a pragmatic choice. Right. It balanced the
need for a modern
architecture, which it delivers, with the need to use the skills they already had
to get a solution
built quickly. You have to remember, this was an emergency. And for other
institutions looking to
actually use this, the docs mentioned Docker images are available. For a university
IT department,
why is that so critical? Docker just simplifies complexity enormously. University
IT systems can
be a total mess. Different operating systems, weird security rules. Docker packages
the entire
application and all its dependencies into one standard unit. So an admin can deploy
it reliably
no matter what their server environment looks like. Exactly. It radically cuts down
on installation
time and configuration errors. It's really the gold standard for this kind of
institutional deployment.
It definitely speaks to the maturity of the project, which brings us to our final
section,
the open source spirit and the community health of Pylos. It's a healthy project.
It's licensed
under the LGPL 2.1 license, which encourages people to use it. And the metrics show
solid
engagement. You see about 60 stars, 26 forks on GitHub, which shows developers are
actively
interested. They're playing with the code. And for a tool designed for education,
which is
obviously global, localization must be a huge focus. It absolutely is. And they
handle that
through a service called the PO Editor Project. They actively use it to call for
collaboration,
inviting people from all over to help contribute translations. It's a great way to
make sure the
platform works across language barriers. So if you're an Ikey director at an
institution
and you're looking at this platform, what are the practical steps available to
actually
implement it? They've provided really excellent detailed guides. You have the
standard installation
instructions, of course. But crucially, they also have an upgrade guide for moving
from older
versions. And maybe most importantly, they offer a specific migration guide for any
institution
that's currently running Greenlight 2. That migration guide is, that's the ultimate
sign
they know their audience. They're basically confirming, we know you hit the same
architectural
wall we did, and here's the way out. It offers a clear, documented path to
architectural stability.
And all the collaborative spaces are wide open, too. The GitHub repo is really well
organized,
with sections for code, issues, discussions, a security policy. It's all there.
This is a
platform built for long-term community support. So if you step back and look at the
whole journey,
PyLas wasn't some theoretical project. It was a knowledge product born from the
immediate,
urgent need of a university during a crisis. Its main purpose was to solve the
architectural
friction they found in a monolithic system like Greenlight. And the result was this
modern,
flexible platform based on Laravel and Vue. Right. One robust enough to handle the
sheer
complexity of large-scale digital education today. It's a really inspiring example
of
how solving an internal problem with intelligence can lead to a tool that's
valuable for everyone.
It shows the power of making the right foundational choices, even if it means doing
the hard work of a
complete rewrite. And that leads us to our final thought. Since Pylos was founded
purely because
an underlying architecture, the Ruby on Rails and Greenlight, was creating roadblocks
that limited
innovation. I want you to think about how often foundational technology choices
maybe made years
ago in your own organization are dictating the limits of what you can do today. Is
your legacy
system enabling flexibility, or is it silently telling you what you can and cannot
build next?
It's a really compelling thought to explore. It absolutely is a fantastic thought
to end on.
And if you are facing those kinds of architectural roadblocks, or you just need
rock solid hosting
for powerful open source solutions like Pylos, remember that Safe Server cares
about your hosting
and your digital transformation needs. You can find out how they can support you in
building robust
scalable solutions at www.safeserver.de. Thank you for joining us for this deep
dive into
the architecture of modern digital learning. We'll catch you next time.