 Tab in go. I'm very curious. The stage is yours. Thank you So hello, I'm Floremon and this is Tom and René. We are all three part of the emitter team and Today I'm going to introduce to you emitter I'm going to show you a few use cases and then I'm going to answer a few questions But if we don't have time for all your questions, please remember that we have a stand at building K level 2 So you can always visit us have some candy and ask us all your questions But first who are we we are a young and dedicated company based in the Benelux in Singapore and What we are dedicated to is preventing you from reinventing the wheel. We notice that in this field a lot of people try to reinvent the wheel and We all know that your drizer instead of reinventing it perfect it That's why we created emitter and we made it open source So what's the problem? We are trying to solve The problem is a basic communication and problem is that I want to talk to Tom over the internet to have a chat with him. So what could I do? I could just use a simple socket that would be easy enough That's a well-known mechanism, but still I would need to know Tom's address and I would need to be available at the same time as him on the over the internet and Also, we would need maybe to have a secure connection between us with TLS for example So that's not too bad, but that's already three problems to solve and but more problem arise if More people want to join the conversation if it's a group conversation with a third or fourth or fifth person now everybody in the group has to know the address of everybody else in the group and Everybody in the group has to remember to forward messages to everybody else in the group and then what happens if we want some kind of Authentication because we don't want anybody that has the address of some someone in the group to be able to join the conversation So that's why usually we Common solution is to introduce some space decoupling by using a published subscribe system In a published subscribe system client don't send messages to each other directly anymore they send messages to a central server called a broker and In this system, they don't need the client don't need to be aware of each other anymore they communicate through channels, which is It's a virtual pass to To a resource it looks like this. It's like a slash hello slash world slash something and The the broker takes care of authentication of authenticating people of forwarding messages to everybody and maybe of storing messages to deliver them later and Things like that. So it's a nicer solution But it's still not perfect because what happens if you have a very successful application with Millions of messages exchanged every second then maybe one server is not enough anymore You need a cluster of brokers to work together to deliver them all those messages So you need as soon as you have several servers You need to to have some some message routing to be sure that messages arrive at destination You maybe don't want to have an interruption of servers of service just because one server breaks down or even multiple server breaks down You need to be able to scale efficiently to scale up and scale down to not waste resources when you don't need that many server anymore So that's a lot of things to think about and that can become very complex very fast So wouldn't it be nice if there was enough the shelf solution to all those problems? Well, that's why we created emitter. It's a publish subscribe platform written in go and it uses the MQTT protocol As I said, it's scalable. It's built to scale horizontally. It's designed to handle high throughput It's secure. It uses TLS encryption and expirable channel keys and permission attached Persistence it's we currently provide the two mechanism for persistence one is an in-ram Store so as the name suggests it's stored messages in RAM Which means it's very fast, but messages are lost if the server breaks down the other mechanism is SSD optimized store that uses badger It's lightweight because it uses the MQTT protocol So it was designed with IOT in mind and the API is very easy to use I'm going to show you the API just after showing you a few use cases The first use case that we could think about is a real-time chat. So that's basically what we discussed so far There is not much to say about it. That's a chat You can imagine that you have a sub channel per rooms and people subscribe and publish two rooms That's by the way a sample that we have on our website So you can try it on our website and maybe use it on your own website Another use case is smart cities. We had that guy in Turkey that explained to us that in big Turkish cities garbage trucks don't go directly to the landfill. They go to intermediary bins to empty their load and So they have to monitor of course The the filling rate of each bin so they optimize the route of the garbage trucks Because they don't want of course a garbage truck to empty their load in bins that is already full so you could imagine there is a sensor in each bin and There is a dashboard That subscribed to all the bins with a filling rate slash This so this is why a wildcard that means that it subscribed to every sub channel another Another use case is OT monitoring. So we had that guy is at the crematorium so a crematorium as a various piece of machinery and Each machinery at the various sensors for example There is a silo that is a temperature sensor and there there is also a chambers that is a temperature sensor So the silo would publish to slash silo slash temperature and the chamber would publish to slash chamber slash temperature and This guy wrote dashboard in python because we have a python SDK That as for example one gouge that subscribed to plus Temperature plus is another wildcard that we use that means it replaces one level basically So it means any any level Slash temperature so it's subscribed to all temperatures and source Another use case is online games. This is a demo I wrote to demonstrate that emitter is It's very low latency. It's a bomber man. I guess we all played that game here. I'm playing with that With my brother over the internet and as you can see there is very it's very fluid And I'm using almost no pass prediction So it's really the real-time messages that are sent very fast Here I made it so there is one sub channel per game ID and one sub channel per game ID per player and each player and published to its own channel and each player also subscribed to the game ID slash all which means that Which means that they all receive messages from each other player Messages mainly of position updates Finally I'm going to show you a bit of the API So this is how the API looks like in JavaScript. You just do emitter.subscribe to subscribe You provide the key a channel of course that you want to subscribe to and and You can have an option which is the last which Provide the X number of message that you want to receive which were stored on the channel To publish you just do an emitter.publish which Where you provide the API key again that may not be the same key that could be another key with other permissions Here I publish to chat slash Floremo and of course I provide my message Which here is a string but it could be a binary message any kind of message actually and There is an option the TTL which is the number of seconds. I want the message to be stored So that that's all you need to to do to start exchanging messages with the brokers There is another Thing I want to talk about is the presence feature. It allows you to monitor Which person which devices are subscribed to a child which is of just leave very useful for lobbies for example To call presence you just do emitter of the presence you provide once again an API key Then the channel you want to monitor and then you have two Options two parameters The first parameter is status if it's set to true you will receive immediately a list of people that are subscribed to the channel The other parameter is Changes if it's set to true you are going to receive events once a person Subscribe to the channel and once a person unsubscribe to the from the channel So emitter is open source It's under a GP a license. It's not free software, but it's still free as in free beers It you can set it up in minutes using the care container and host it on your own servers Otherwise, you can use our cloud if you don't want to care about server about scaling and then you pay per usage Recently since last year we've enjoyed a lot of attention on get up As you can see it's a graph of the stargazer on github and We enjoyed a sharp increase since last year and that brought us a lot of contribution Some small some bigger some as small as type of fixes in our documentation But that's still nice to have some bigger like to the core emitter to the core of emitter so currently at the time we only had for example Keys per root channels now we we and we have keyed per sub channel So that's was an external contributions that brought us there So that that's very nice another kind of contributions that we like is Is SDKs? We currently have five SDKs in go C sharp by turn Java script and Java Some of them were extensively reviewed by the community, which is very very cool But we would like to have more SDKs So if you're interested in the project and you have a favorite language that is not listed there Please visit our website where we have a page where we describe How to communicate with our server and it's very easy so you can contribute and we'll be very happy to share your SDK now I Don't know if we have time for questions But please remember that we have the stand at level two of the building K Thank you very much. We have yes first an applause of course We have time for one burning question if someone has otherwise you can visit them at the stand Anyone who really desires to ask something? no, okay, thank you very much and Can we ask the next speaker to come to the front, please? Also another request as you see a lot of people entered the room by now Try to compress yourself as much as possible sit next to people that you don't know it's good to meet them during this event And make sure that everyone can have a seat I Use this yeah, sure. I will still need it to introduce you Afterwards if there's like time we can ask one or two questions we can run around and give the mic to the people in the audience