What if you could work with some of the world's most innovative companies, all from the comfort of a remote workplace? Andela has matched thousands of technologists across the globe to their next career adventure. We're empowering new talent worldwide, from Sao Paulo to Egypt and Lagos to Warsaw. Now the future of work is yours to create. Anytime, anywhere, the world is at your fingertips. This is Andela. Hey everyone, my name is Tamimi. Thanks for coming to my talk. I'm super excited for today's presentation because it's a topic that is near and dear to my heart. We're going to be talking about gopher in an event driven playground and hopefully you'll have a combination of slides and hands on demo and then some interactions on the Discord channel. So let's get right into it. I'm hoping towards the end of this talk you will get an idea on what is an event driven system, how go fits in an event driven world by talking about existing messaging protocols, frameworks and tools that can be used in Golang, highlight the potential challenges behind using go and the existing messaging graph protocols, and finally, showcase the new solace pubsa plus messaging API for Golang and how y'all can get your hands on it. Today's topic will be pretty light hearted and fun. So let's assume that our cute little gopher is walking around in a playground. In the real world, there are other animals that communicate in different languages and protocols. Some animals are not even on the ground and they're just hovering in the clouds. And gopher is wondering, how can I communicate with these other animals? How can I send and receive information from these creatures? So these animals could be other microservices and applications either within the same ecosystem or other ecosystems. There are different languages, whether it's Java, Python, C, Ruby, JavaScript, or even go from these microservices. These microservices communicate with different protocols, whether it's rest over HTTP, MQTT, AMQP, there's open standards like JMS. There are other things around as well that communicate. Whether there are sensors, there are applications that are on ground or on cloud. So Gopher is wandering around in this playground looking for friends to help him answer the question. And he meets Soli the Otter and starts the conversation. Hi Soli, how can I accomplish a language and protocol agnostic real time communication with other microservices? You can use an event driven architecture approach, but what is an event driven architecture? Follow along. Let me tell you what event driven architecture is. Event driven architectures involve asynchronous communication between applications via publishing and subscribing to events over an event broker using a messaging protocol. Gopher is getting a bit interested. Messaging protocol basically is a structured way for applications to exchange payloads with other applications. These protocols can describe the way that the message being processed, prioritization, routing, security, access control are some of the many things that a messaging protocol is involved with. So in a nutshell, to animate this concept, you have publishers that publish messages on a predefined topic to brokers and subscribers subscribe to topics and the brokers can handle the routing. So this is fundamentally what a pub sub system at its base looks like. A real world use case of an event driven architecture involves several applications, multiple protocols, applications that are developed in different languages and different form factors of deployment between on premise public cloud and private cloud deployment. So think of the green lines you can see here on the diagram as a central nervous system for everything that happens across your business, whether you have different forms of deployment. This is basically the interaction between the different form factors. All right, so let's go back to the conversation between Gopher and Sally. Gopher wants real world examples. Do you do any online shopping? Do you trade on the stock market? Do you track airplanes in real time? All these are examples of event driven architectures. Another example of a scenario where event driven architectures are deployed. So let's pretend that there's a customer that places an order on a mobile phone, they click the but button and that triggers a series of actions. Behind the scenes digital events are being triggered. So let's say to check and confirm and update the back end inventory system, you have a payment that needs to be authorized, you need to start a shipment process. What if the company that you're working with has a loyalty program that also gets triggered at every purchase order and we want to update the customer data platform. So all this happens in real time and triggered from one event. So these applications that you look at. So another example, let's say that you have event producers that generate events through purchase requires the mobile application, the point of sale system, ecommerce websites, they're all different microservices that publishes events. These microservices or applications, keep in mind, could be developed in different languages, communicate over different protocols, but they all publish events to a network of event brokers. And this is what we're going to call an event mesh. On the other side, there are other microservices that subscribe to these events, whether you're a warehouse, database, finance, microservices, customer service. And these are event consumers that subscribe to relevant topics and react based on whatever the topic is and the payload of the topic is. So let's talk about kind of MQTT and this is one of the many messaging protocols, open standard messaging protocols that could be used in an event driven architecture. So Soli is coming here to talk about what MQTT is. It's a simple lightweight messaging protocol based on the pubsub model. It is an Oasis standard messaging protocol for IAT devices. You can read more about it@mqtt.org and I'm going to give you a quick hands on demo on how to use mqtt using the Paho Go mqtt library and have a simple pub sub application written in go. So basically what I'll be doing is I will be initializing a directory and installing the go MqtT library. From there I will configure my application to connect to an MQtT broker, subscribe to a topic, publish messaging on a topic and show what message handlers are all about and callback functions. So let's go ahead into this demo and I'll be back. Let's go ahead and create a new directory and call it conf 42 demo navigate to it. I'm going to initialize this as a go project and install the dependency go get so what I did right now is installed the Paho mqtt Golang. Let's open this project. So what I will do is create a new file, call it main go. In this file I will import the packages that I want. So this is a package main and I will be using mqtt from the Paho mqtt Golang package. I have a main program, a very simple main programming written here. So I define the broker as a MqtT broker. I'm using a solace cloud instance and the port one eight three is the exposed mqtt port. I set the username password and assign a callback functions right here for the MqtT client. These callback functions, I will define them shortly. They are callback functions for when successful connection happens and any message comes in. So let's go ahead and define these callback functions. So what do we have? Right here is a message handler for every time the MQtc client receives a message. We have callback functions for successful connection and lost connection to the broker. So right now after this, what we want to do is define a publish and subscribe functions. So let's go ahead and create this. So my publish function basically takes an MQtT client and publishes ten messages with a 1 second sleep. And the body of the message is the number that this message is in the subscribe function. Basically subscribes to a topic, mind you. Here as well, I want to point out that in the publish function we are publishing to this particular topic, conf 42 Go. And in the subscribe function I'm subscribing to Conf 42 Poundkey and this is a wildcard. You can read more about MQTT wildcards. So now that I have the publish and subscribe methods already done, let's go ahead in our main loop and what we're going to do is we're going to start the main loop by subscribing to the topic of choice, and then we start the publishing. After we publish ten messages in a loop, we go ahead and disconnect the client. So let's go ahead and run this, go back to my terminal, I'm going to do go run main so what happened? Right here it says we're connected to the message broker and we subscribe to this topic. Now the publisher behind the scene is publishing ten messages from zero to nine, and the subscriber receives messages on the topic of choice. Cool. Now that we had this demo, Sal is still wondering. Great. Now I know how to use go with messaging protocols. I'm still not sure how I can achieve a protocol and language agnostic approach. That's when you use abstraction frameworks or even an advanced message broker. So let's delve into details about what an event driven architecture framework is in go. These are pretty much go libraries that abstract the underlying implementation of an event driven technology via APIs. Let's take a look at an example. So basically we would have an interface that abstracts all the different integrations of different messaging APIs. An example to this framework is Watermill, and Watermill IO has several integrations that abstracts the implementation of the messaging system, the pub messaging system. At its core, Watermill has two interfaces. You have a publish interface and a subscribe interface. And you can see here that the different integrations, they follow the two interfaces, whether the publish or the subscribe interface. Keep in mind that things library only allows protocols communication on the supported integrations and it's isolated for go applications. So you would have a publisher that publishes messages and a subscriber that listens for incoming messages and reacts to them. So pretty much you got a publisher. Regardless what this publisher is, it's abstracted. It will publish messages on a predefined topic and the subscriber subscribes to the predefined topic, as you know, further abstraction on the implementation of the understanding pub messaging API you've got. For example, let's say you want to have an AMQP publisher. All you got to do is define a new AMQP publisher and then publish messages using the publish and subscribe interface. So it's basic at its implementation you have a publish and subscribe interface. So sometimes you want to think about how can I achieve protocol and multilanguage EDA microservices? And this is where we would have to look into advanced message brokers that support multiple languages and protocols. When you use a library or a tool that has a basic publish and subscribe interfaces or operations, you could achieve what you want. You could achieve an event driven architecture. But then if you want to expand this further to other things that you want to use, think about security, think about role based access control, think about governance of your EDA architecture. Think about, as you can see here, multi protocol and a multi language EDA microservices. Let's say that you even have some legacy infrastructure and legacy tools and you want them to interact with your Go microservices. I'll quickly cover what Solace Pubsub plus Eventdriven is all about. One of the advantages or benefits of the Solace Pubsub plus Eventdriven is the protocol interoperability and the protocol translation. So you can see here, I've highlighted in the diagram below that one of the solace native APIs, languages, Go is one of them. So you can communicate with the solace broker using Go, the pubsublus messaging API for Go and publish or subscribe to messages on the broker. There's other microservices and languages that are involved. Let's say, for example, that you have another web browser, microservice, that is publishing messages using an open standard protocol like MQTT using JavaScript. So with the benefits of using an advanced message broker in the middle of your architecture, in your infrastructure, you leverage the interoperability feature and the protocol translation feature of this brokerage. So let's have a wants on demo using the Solace hub subplus messaging API for go and we will come back to this. Now back to our conf 42 demo directory. I'm going to install the solace go API through Gogetsollas Devgo messaging. Once I execute this command, it will download the solace go API. I will not run it because I ran it previously. So let's go ahead and open up this directory. I'm going to create a new file over here and call it, I will call it Solacepublisher. Go. Let me make this bigger and increase the size over here. So this is package main and I will go ahead and start my main program. So what I'm going to do at first I'm going to define my configuration parameters to connect to the broker. So our host is tcpublic messaging solace cloud. There's a typo VPN name is public, username is Conf fourty two and the password is public. Then what I'm going to do is create a messaging service and start that messaging service. Note that the Solisco API is built on a builder pattern. So right now what I'm going to do is that created a messaging service and started the messaging service from the messaging service. I want to build a direct message builder because right now what we wants to do is have a publisher that publishes messages to a solace broker using the solace native API. So what I'm going to do over here is I have a direct publisher. I'm going to create a direct message publisher from the messaging service and start that messaging publisher. And now let's go ahead and create the message that we want to be sending. So I will be creating the message right now. So what we have over here is I'm going to create a message sequence number so I can dynamically have or build the payload of the body. The message body will be let's say hello from Conf 42 and I'm creating a message through a message builder. I'm creating a message builder basically from the messaging service and adding different properties to the message. Right now what I wants to do is I want to have an infinite program that publishes messages every second. So this is what I will be doing. Let me put a new line here to make it look better. So I'm going to run forever until can interrupt signal is received. What I'll be doing is I have my message sequence number variable. Incrementing it, I'm going to be creating a message that has the payload of the message is the message body hello from conf fourty two and I'm just going to add concatenate to it the message sequence number to have dynamic message body. And then I'm golang to create a topic. So I will be sending a message on the following topic, the Conf 42 solace go and also concatenating elements to the topics to show how we can create dynamic topics in here. All right, and then what I will be doing is publishing the message on the predefined topic and then sleeping for a second. And that's about it. We're going to be doing this going in an infinite loop over here until an interrupt is received. What I will do is I'm going to handle the interrupt using Go channels. This is one way to handle interrupts. So what I did is I created a channel that listens to an operating system signal interrupt. So I will block the program until an interrupt is received. And once we're done with the program, for good practice, what I'll be doing is terminating the messaging service and quitting the publisher. So that's about it. So what this program will do is connect to the messaging service on the predefined host and from here publishes messages. So what I'm trying to do is if you recall this diagram, we have the go application using the solace native API. We'll be connecting to the solace broker and publishing messages every second. It'll be cool to connect to the broker using any other API. So let's say I'm going to use an open protocol MQTT Javascript MQTT application and connect to the broker that way. So I have prepared a public MQTT broker provided by Hive MQ. So this MQTT broker connects to any MQTT broker using MQTT Javascript. So our host is public messaging messaging solace cloud on port 8000, username is Conf 42, password is public, I will connect to it. There you go. I am connected to the broker and the subscription that I want to add is Conf 42 greater than. So this means I want to subscribe to any topic that comes to any message that comes to this topic. So let's go ahead to our program over here, open my terminal again and I'm going to run the solace publisher, the application that was just created. So what I'm doing right here is I'm publishing messages on this topic to the solace broker. So it's coming from the microservice that we have written in the Go native solace API into the solace broker. And then I have here another application, another client that is connected to the solace broker using an MQTT open protocol and subscribing to the topic of choice. So this showcase a multilingual, multi protocol, event driven architecture where we have one language using Go and connect it to solace using a solace message protocol. And then we have another protocol and another microservice which is this client the web browser connected to the same broker, using a different protocol and a different programming language, JavaScript, and still receiving the same messages that were sent by the original application. Keep in mind that the solid pub supplies messaging API for Go is available for download on April 1 and I promise this is not an API fool's joke. So final remarks I want to cover just before we end it. This was kind of a very quick, light hearted talk and presentation to talk about what event driven architectures are about how Go can fit in an event driven architecture system. A couple of know when we think about event driven at an enterprise, I want to encourage you to step back and take a look at EdA in general. Whether you're using Go or any other programming languages, there are a lot of things that are involved and a lot of moving parts are involved. When it comes to dealing with event driven architectures, you have complex environments, whether it's hybrid, cloud, multicloud or multiple geographical locations. You got diverse set of technologies. So you have the microservices, IoT devices, cloud native services, you got legacy technologies, infrastructure platform as surface ipasses and you want to communicate with these. You even have like enterprise demands. Do you have the performance, scalability, security? There are other capabilities that are required. So when you think about event driven architectures and can event driven system, you have to take into account the design of that system, the documentation, the discovery, the governance, the access control on that system. So event driven architecture is not just about pub sub, it's not just about how you publish messages and subscribe to messaging. There are other factors that take into account to deploy an event driven architecture in an enterprise and production ready level. So you can use go in different programming and different programming languages in this and I showcased how this is done. So all that to say, I wanted to mention that it's a lot to think about. It can feel daunting at first, but it's all necessary to do this well at skills. So this is something that I wanted to keep in mind. What next? Before we head out and call it a day for this presentation, a couple of things I want to point out. We have a live coding event on API twelveth. So mark your calendars. It will be live streamed on YouTube and LinkedIn and I'll probably also be live streaming it on Twitter. I'll be using the solace type supplies messaging API on a live coding session. So getting a lot of feedback and questions from the audience is great. Solace community join the solace community. We have an Easter egg hunt event that is starting very soon, so stay tuned. There's a lot of prizes, a lot of giveaways for this. Follow us on Twitter at solace devs and at tweet to mimi. And finally, if you're interested in event driven architectures, there's an EDA summit coming up on May 4 at edasummit.com. So you can take a look at that, check it out and see if you have any other questions there. So that is pretty much it, folks. Thanks again for tuning in. I am more, more than happy to take any questions. If anybody has any questions, feel free to ask on the Discord channel. Or if you're watching this recording after the conference, feel free to reach out to me on Twitter at tweet to Tamimi or at solace devs, and I will make sure to answer your questions. Thank you. Take care.