 All right. Good day everybody. My name is Tom, this is Florgement. He will assess me with questions if you might have questions in the end. There should be a few minutes left for questions. Today I'll talk about emitter. We're a scalable, fast and secure PubSub in Go. Now suppose you have two devices that need to talk to each other. Probably the first thing you think of is to use sockets. Now suppose I have a device that needs to talk to Florgement's device, then I need to know his address of course, and he needs to know my address for that to work. So that will probably all, for two people that will work fine, but suppose my friend Judy is sitting there, suppose she also wants to join the conversation, then still I need to know the address of Florgement. Florgement needs to know my address. Florgement needs to know user address. You need to know Florgement's address. I need to know user address. User needs to know my address. So you can probably already imagine this is not very scalable. If all of us would want to talk to each other, then you probably don't have a very nice situation. And apart from scalability, then it will also not be very fast anymore. And the next thing, security, I didn't even mention. If you want to be secure, it's not automatically arranged if you use sockets. So secure, fast and scalable network communication is difficult to achieve for some developers, and in very many fields it's very relevant, so for IoT, gaming, mobile, etc. So one solution for that to mainly the fact that everybody needs to know everybody's address. So one solution to have decoupling in space is to use a public subscribe system. In such a system there is one central point, the broker. So you can see it as a server, and instead of everybody directly talking to each other, everybody sends this message to the broker, to that server, and that server then sends the message to all the relevant devices. So, yes, let's go to the next slide. There are several challenges if you want to have a public subscribe system with a broker. The first one is scaling. So suppose it would not just be this group of people, but suppose there would be one million people, and maybe one server is not enough to handle all that. Or suppose the amount of people or devices or sensors or whatever you think of is small, but there's really a large set of messages, and also one server might not be enough to function as a broker. So you need multiple servers, and if you have multiple servers, of course, how do I know to which server I should talk to, and how should Portland know to which server to talk to? So there is some routing challenge there as well. Probably the servers also need to talk to each other inside the broker. So routing is one challenge. So the scaling and also the routing is then a challenge. And the third one is availability. So suppose I'm offline for a while, and I then want to see what has happened while I was gone, then the broker needs to store messages. And probably you don't want to have just one server storing the messages, because what if the server is down for maintenance or if it crashes? So probably you would like to have at least two servers containing every message. So routing-wise, that's also a bit more of a challenge. And then ideally, suppose you have these two servers and one crashes, then ideally the other server realize, hey, I'm not the only one that contains these messages. So if he realizes that, you would actually like him to copy the message to one or to multiple other servers. So we're out of this tricky situation. So that's also not all that easy to implement the availability. Then security. So suppose maybe here in front people are talking about football, and there are in the back people talking about politics. And here some people are talking about some very super-secret stuff that I'm not allowed to hear about. Then you somehow need to make sure that data is secured. So I can listen to these people, but I'm not allowed to receive messages about this super-secret stuff over there. So probably you want to have some kind of a key to be allowed to hear certain topics or to listen to certain channels. So that's also a challenge to build that in. If you had to do it yourself, no, please go back. And the last one is message filtering. So maybe here was politics, there was football. Suppose I don't really care about politics, then I don't even want to receive that message. And ideally the broker would take care to only send me the message that I'm interested in. So ideally you'd also have message filtering. But those are the five of the main challenges if you want to build your own system that takes care of all this messaging in the back end. All right. So wouldn't it be perfect if there would be a solution to all of these challenges? So if there would be ideally an open source software off the shelf that can take care of all these challenges for you. And the good news is there is. And Emitter is such a system. Emitter is a scalable, published, subscribed broker. It's all written in Go. And to talk to that broker you can use the standard MQTT protocol which is supported for most languages. So here's some more specs about Emitter. Emitter is scalable, so it's built to handle millions of messages per second and to scale horizontally. It's also fast, and I'll show you a bit more about the speed later on. It's designed to ensure reliable, fast message delivering, delivery and high throughput. And it's secure. So we support TLS encryption. And what I mentioned before, you can have channels. So the topic and the channel, you can see that's the same thing. So the football, the politics, the super secret stuff. And based on the channel, you can have a channel key that can even expire. Then persistency. So Emitter can store messages for a period of time. And if you've been offline or you come online, you can again retrieve those messages if you want to. Then it's lightweight. It uses the MQTT protocol which is more or less the standard in IoT. And that has very little overload. The messages are small, which is also good for your battery usage. It keeps the usage low. And finally, it's very easy to use. There's a very simple API, and I'll show you that on the next slide. It supports message filtering. I mentioned that before. And we can deal with binary messages. So that means you can send text, images, executable, whatever message type you want. You can do that with Emitter. So let's look at the API. This is the API, in this case in JavaScript. But of course, we support the most many languages. So to publish a message, you need to have, you need to tell the key of the channel and the channel yourself. So the channel, you can see it as a topic of your message. So whenever you send the message, you say the topic is, politics, football, or whatever. And then you send the message yourself. So that's all you need to publish the message. Now to subscribe, here's the API. So again, you need the key, and you need to know the name of the channel. And after subscribing, you will keep on receiving all the messages written over that channel until the moment that you unsubscribe. So that's it. Those are the APIs. Now I want to show some use cases of Emitter. So what has been built on top of Emitter. First of all, this is not something we came up with ourselves, but we were approached by a crematorium, and they have all kinds of sensors in this crematorium to measure the pressure and the temperature. And in this crematorium, they would like to have a web dashboard, and they now have it, to see is everything still going okay, are the temperatures and pressures okay everywhere. So if you look at the top part, there is a sensor in the silo. And this sensor publishes every few seconds a message over the channel, furnace one slash silo slash temperature. And here there is another sensor which publishes over furnace one slash chamber slash temperature. Now the subscriber subscribes to furnace one slash plus, and plus functions as a wildcard in Emitter, slash temperature. So that means it receives the messages of furnace one, the temperature messages of the silo, the chamber, and what other rooms there might be in furnace one that send temperature information. So the wildcards you can use anywhere in the channel, in the middle here which can be in the front, you can use multiple wildcards in one channel. That's all possible. So let's go to the next example. It's also an IoT example. It's a company in Turkey, and Turkey there are various cities that have sensors in the public waste bins to measure the filling rate. And they all send a message over their own channel, once in a while it senses a message. And there is a central system that receives all those messages. And by the way, I here left out the wildcard. If you leave it out, all the channels or sub-channels are assumed to have a wildcard in it. So there's a central system that receives all this information, and based on the geographical location and based on the filling rate, the route of the trucks are optimized. So the next one, the Bomberman game, we've all played this before probably. This is a multiplayer variant where you can online play against each other. And all the messaging here is taken care of by Emitter. So this is basically to show the latency is really very low. You can build a real-time game on top of it. Then chat. Now, not much to explain about the chat application. We all know how that works. And actually for this chat, the complete source code can be found on Emitter website on the demo pages. This is an in-browser chat, so Emitter is open source. We also have our own cloud variant. So if you use it, you can use our cloud in the back end. So you can really have it on your own website without needing any servers. All right, the next one, the stock charts. So here's an application that for each different stock, so we have Google, Apple, Amazon, there is a separate channel. And once every few seconds, a message is sent with the current stock level over that channel. And as a subscriber, you can subscribe to the ticker of your interest. And based on that, always be up to date of your stock levels. And then the next application is very similar. It's a Twitter live feed. So here, Twitter has a firehose. It's an API that sends all the tweets that are written. And there is an application that writes over each hashtag the channel is made. So it sends for each hashtag the messages over that channel. And as a user, you can subscribe to the channel of your interest. And based on that, a live feed is here made so you can really see live what's happening about a certain hashtag. So those were all the use cases I wanted to show about the mythors. Now, suppose you're now interested if you are, then here are the ways to use it. So we have an open source and we have a cloud. Everything contains the full, everything I explained. All the features are in both the cases. So open source, we have an AGPL license. We're free as in free beer. You can set it up in Mint. It's all in Docker containers, so it's very easy to roll it all out. And then you can host it on your own server or servers. But of course, then you need to have your own servers. And if you have an application that scales, then you need to be on time with adding an extra server to your own system. So the alternative is to use our cloud and you don't need to worry about maintenance, setting it up. You don't need to worry about servers. And you pay per usage. And actually, we have a generous free tier. So if you just have a small application, it's probably free forever. And as soon as you get very high usage, you will have to start paying. So that's all. Are there any questions? Yes? So your question is whether messages are stored and we can look back in history. Actually, you cannot currently connect to some specific time in the past. You can configure a storage and ask when you connect to receive the last X messages in the past, but it's X messages and you cannot currently connect to some precise point in the past. Okay. Thank you. Any other questions? Yes? Yes? How the network failures are... If you want to have high availability, you mean? Messages are... Okay, of course, all servers are aware of each other. So messages are rooted through the right servers depending on the subscription of the clients. And it's automatically finding other routes through the network if one server fails. Does that answer your question? Okay, thank you. No more questions? Well, then that's it. Thank you for your time. We'll be standing outside of this room. If you want to discuss a bit more, we'll just be standing here outside of the room for a few more minutes to answer more questions if you might have them. Thank you. Thank you.