Mark was a wrench and his talk is about a lazy developers approach to building real-time
web applications.
Give him a warm welcome and applause.
Thank you and it's your state.
So good morning.
Today I want to tell you about my two hobbies.
First I'm a musician.
I play the bass guitar and my other hobby is a cloud solution architect.
That's my money making hobby.
And the project I want to talk about today gave me the opportunity to combine these two
hobbies into one little project and I want to share the learnings from it with you.
Okay, so the challenge.
The picture above you see Ralph.
He is a friend of mine and he plays along.
He plays songs, people sing along.
But we had one problem when we play somewhere with WENUs from 100 to 1000 people.
Songbooks don't scale.
We had songbooks but they got damaged.
The WENUs were dark.
People couldn't read.
Songbooks even were stolen.
One fact that was beneficial for the project, we have music stand software on our tablets.
They are networked to each other and this music stand software has an API.
Terrible software, proprietary stuff.
I don't want to talk about this software today.
But what we made from it so that you are able to use it in your own projects.
How to get lyrics to the people with minimum effort.
That was our task.
We had to solve.
And so that it doesn't get boring, I want to start with a demo so that you see the result
and later on I will show you how we accomplished that.
So please use your mobile phones and with it decide or your computers will work both.
If you call this web page, you will see.
Let me show it here.
This side, the other side.
There it is.
You will see exactly that page which I have loaded here.
It's waiting for lyrics.
So the communication is established and when I now start sending the lyrics, imagine somebody
on the stage would change to the next song in the music stand software.
Okay, let's do it.
I had an AI friend of mine write a few songs about open source and the like.
So if my talk is boring, just look at the songs and I'm also open for collaborations
in getting music to them.
Okay, let's go on.
What do we see here?
The songs get updated like I just said before.
And we even have confetti when there's a new song.
So the title of the talk was the lazy developer.
Why does being lazy matter?
If you are too eager, it can happen that you think of a structure, how to implement something
and that you stick to this structure, that you don't have this gut feeling that's too
complicated, has to be easier.
You create code duplicates and the like.
If you're too lazy on the other hand, you get nothing done.
So you have to find the sweet spot.
Being lazy enough and being eager enough to get things done.
And because I did this in my spare time, that was the only approach which could work.
So I had to have something easy which allows me to get this job done but also allows to
scale to a venue of a thousand people, to a thousand people requesting this resource
at the same time.
And here's my technical approach to that.
We have the people who want to sing along.
We have the musician with the music stand with the let me call it rest-ish API, what
I saw wasn't so good.
A small VM at the cloud provider.
Everything should start with something like this.
A host name which I said on it.
After installed, then I used catty as a static web server for static pages.
Great project makes it easy to host things with the same default TLS configuration without
any effort.
So it was just spinning up the container and it's immediately served the web pages like
I wanted to have them.
So now we need a component which does the heavy load which transports the data to the
devices of the people.
There are many solutions around and since I'm working as a cloud solution architect
with Kubernetes, you always look at the CNCF landscape.
And as well in my company, as for this project, I saw NETS as the solution.
We use it for micro service interaction in our projects but NETS also has a web sockets
interface which make it possible that the people which are getting the web page through
the static web page on the browser, the JavaScript part connects through web sockets to the NETS
server.
And then the musician needs to have a computer which pulse the API and as soon as there is
a new song, the lyrics get sent to the message broker and when we talk about message brokers,
there are a few patterns around how messages are being distributed.
We have a classical fan out pattern here.
The message comes in, the message broker distributes it among all of the subscribed devices and
what's really nice about the approach, it's just a few lines of code in the end.
So let me show you.
We have the project here.
You will get access to the GitLab repository at the end of the talk and also linked online.
Okay, so we have the NETS server.
The ports, the 8443 is the web sockets port over TLS.
3 times 2 is the NETS native port mapped to the outside.
Then we tell NETS the host name so that for the TLS mapping and since Katie takes care
of the certificates, we map the certificates from the Katie directory as we only file mount
which we can access in this Docker compose repository I have set up here.
And Katie, the easiest thing, just the regular web server ports mapped to the outside.
Katie took care of getting the Lats and crypt certificates automatically.
I only had to set the HSTS headers and had an A plus on Wallace SSL check.
It's something I always want to try.
Okay, and look at the application itself.
This div does everything so it's more meta text than real payload on the page.
There's the div with the id lyrics and as soon as something new comes in, its content is
replaced and the JavaScript part is also something very simple.
You see that's everything I did, basically developer.
The communications magic is here.
We include the NETS web sockets library and then we connect to the NETS server.
We subscribe to the subject lyrics and as soon as something drops in as we receive new
lyrics, we handle them over to handle lyrics which form its first line in bold and shows
the rest just like we received it from the NETS server.
If you want to have a look at the NETS configuration, it's also not much.
I have defined two permission sets.
One default permission so any user of the system has the set of permissions and it's
just subscribed to lyrics and we have the lyrics publish security profile for the authenticated
publisher.
I defined the user with the hash password, assigned the permission and down below here
you can see the web socket definition where I also use the TLS certificate, caddy gets
me from let's encrypt.
Next line I assign anonymous access to the user that it works with the login.
No, not login.
Okay, that's it in a nutshell.
If you are interested about the topic of message brokers, I can highly recommend the book enterprise
integration patterns.
It's a book from 2003.
I'm showing an IT book from 2003 but the principles are still the same.
Of course, there are a few new.
If you go to the website, they also have listed new principles but I wish I had new in the
book 20 years earlier.
Now I have it on my desk.
My GitHub repo, check out Nats, check out caddy server and it's absolutely possible.
You don't have to use Nats for this.
You can use an MQTT server.
I did the same example with EMQX.
Rapid MQ should work.
Also with Redis, it also has web sockets integration so you could also use that.
My example was in Nats.
If you are interested in Nats, I asked the guys of the project if they could send me some.
On this corner of the desk, if you leave the room here, you can grab a sticker.
After all, we are on conferences for the stickers, isn't it?
That way.
Okay.
That's about it.
What did we learn?
Let others do the heavy lifting though.
Just be lazy enough to find the right ways and get things done and concentrate on the
things that really matters.
Reach out to me if you have questions.
I will be around.
Don't forget the stickers.
Have a great Svastim Sunday and a safe trip home.
I'm Markus Röntschler.
Thank you.
Okay.
Thank you for your talk.