 Welcome everybody to the weekly firefly community call. Thank you for joining. I don't have many announcements for actually I don't have any announcements for the beginning of the call today but for today's topic for the first part of the meeting. Peter Broadhurst will be speaking on event-driven programming design or event-driven application design and how this is, you know, firefly is built with this design in mind and things just work great when applications are also built in this with this event-driven mindset and Peter's going to talk through kind of how to approach building a firefly app in an event-driven way and how firefly itself handles things in an event-driven way. So thank you Peter and I'll turn it over to you now. Thanks Nico and as per normal plan to use just I guess up until 35 plus on this piece and then just have another open forum for any topics that we want to run firefly after. Okay, so we thought it would be really good to do a session on event-driven programming because there's a sort of assumption in every piece of how firefly has evolved that the wave at the system, the wave at the multi-party system will be built is in an event-driven way and it's a particular type of programming. It's definitely not a new type of programming, but it is a particular pattern and it's not a pattern that everybody's come across. So I want to talk through that pattern from ground up really in this session and build up to talking about how event-driven programming is different in a multi-party system compared to all the other types of event-driven programming that you've done in the past and then talk about how it actually works practically in firefly. So that's the journey we're going to go through here. So to start with, I want to just really try and be clear about what I mean with event-driven programming and what it's different to. And the terms I'm going to try and use consistently throughout are request, reply, and events for the two sort of ways, fundamental ways that if you've got two run times administered separately, they might be like microservice architectures in their own way, but you've got sort of, you know, the payment system and the reconciliation system, they're separate systems. There's two really fundamental ways that you can connect them together. We're not talking about wire protocols or transports here, we're just talking about fundamentals. You can either use a request, reply approach, which is synchronous, but I'm going to try not use synchronous and asynchronous because there's so many ways that those could be used. And request, reply approach, which is like a telephone, system one wants to talk to system two, so it makes a call to system two and waits, waits for that call to complete. This is the way, you know, a REST API to the internet works. It's the fundamental way that HDP works, but you can layer stuff on top of HDP. So I, it's just like a telephone conversation, you get put on hold until they're ready, they're behind, they're going to be slow in responding to your request. And you only know that they've done the thing that you're going, that you've asked them to do, if you sit there when you wait for them to do all of that thing and come back with an answer. So the outcomes are either a success, you know, a HDP 200 okay, a failure, I've got a 500 or an hour or some kind of explicit error, and most of the time with hours you kind of know what's happened, or equally likely just nothing at all it just sort of a deadline, you know, we've all been on hold to the, you know, to the, to the wireless telephone provider and you get put on hold and it's silent and it's like, are they still there? Have I been lost? What's happened? And you just sort of eventually give up and put the phone down. How do you find out if it's worked or hasn't? Well, you kind of got to retry it and make another phone call. So that's, that's request reply approach to building applications. And there's two things. One of them is that both sites have to be available and ready to talk to each other. The other way is it's really just a one to one thing. You know, you've got one system on one side and one system on the other and one's talking to the other. It's a different way of programming and it's a fundamentally different way of programming and this is to use events. To not say that I've got a request and an exactly one reply to say I'm emitting an event, might be a request, might be a broadcast, might be anything. I'm emitting an event. And just like with a text message or an email, I can choose, I can expect that I'm going to get a response pretty quickly. But I'm not like beholden to having a response really quickly. I can go on get on with my life. I can, as an application, I can move on and do other things. And whenever the other parties ready and it's got through the, I don't know, 1000 things I've put people have put in front of it before that gets to that, that particular email in their inbox that particular text messages come to them that whenever they're ready and they respond, you process that response. And this is a very flexible pattern because you can have lots of different failure handling strategies, you know, you can send things multiple times and and we process them which is kind of the only way that you can do it for request reply messaging. And you can also have things like compensation logic to live out sagas later. And you can also just choose to ignore things that you can't, you can't process and maybe say no, I can't process it. Or, or just, just ignore it because you know it's a duplicate or you know, you know that there's a reason why it's safe to ignore it so it's a very flexible way of programming. As I said before, firefly and these are some of Nico's charts and Nico did a great, great introduction to firefly in a community session we had two to three weeks ago. So which is recorded so you can go and listen through the fundamentals here but but firefly supports both patterns fully. One is built on top of the other and this is quite common in enterprise systems the request reply capability is just a special type of events, use of events you're just sending one event and you're expecting exactly one reply. And we're going to talk a little bit more later about the actual interfaces here and how you build applications on top of firefly for for this. And we'll come back to this I promise, but I'm going to, I'm going to take a bit of a bit of a roundabout route here and talk a little bit about the history of events, because it's the topic gets my heart I've lived it since the very, very, very first day of my my career in enterprise it I worked on on the core of the messaging technologies and in IBM called the series. And the year I started this this book was was published and it's a pretty famous book in the enterprise space and the hub and wolf enterprise integration patterns and the, the website still there she can go read about them they're still super applicable patterns. And back back then, you know, to turn a bit. You know, this is evolved over about three decades so this is kind of like the end of the first decade of the evolution here. We have these patterns that were for integrating systems within an enterprise right you've got 20 different systems, you that they're all decoupled across the world. How do we integrate them together and there's a set of these really well established patterns that evolved into things like an enterprise service bus after this book came out, and they evolved into things like service oriented and then whole companies formed, you know, driving home this sort of concept of an event driven architecture, you know, famously companies like like tipcoe really really focused on that for the whole of their existence. You know, and that's that approach allowed very resilient, resilient systems in the core of organizations, you know, the payment wells of banks, but you know the core transaction processing systems of insurance companies and supply chains and healthcare were all built using these integration patterns and they generally were event driven. And all of this happened and then web services happened and West happened and HPP became the flavor and a lot of a lot of things moved to a sort of synchronous. You know, request reply based based approach after this. And then there was another way, there was another wave in the sort of mid, mid 2010s of a resurgence of the understanding of why event driven programming at its core is just this fantastic way of of being really sure you're going to get the right outcome out of the end of something. And, and this time the focus wasn't on multiple systems all connected together and services on today's structures it was about writing really good software. And these fantastic programming languages came out and frameworks like Erlang and Scala and then the ACA framework and the reactive manifesto. And I think that the pattern that really encompasses it and the best written about sort of description of like why does event driven programming, like create good applications I think is if you read about the ACTA model. So I'd encourage you this is a really great great like five minute read to really understand how event driven programming, even inside of an application like inside of one process can allow resilient engineering. Think of this picture here as multiple, multiple players in a network think of this as just, I've got bits of logic. I can instead of connecting together by having more call each other wait for each other. I can put these mailboxes in between them, and I can decouple them, and I can say one piece of logic updates its internal state and then drives another piece of logic. And, and I know everything that's happened. It's a sequence of events. And if you can just think about the way you're writing the end to end business logic, not not like how the system fits together the business logic. It's not to think about it as the set of state changes and in a state machine. And, and you can break all of those state changes back into being a set of inputs, a function that runs on them deterministic or non deterministic that's fine doesn't matter function that runs on them. It triggers one or more other items of processing that way of working happens to allow you to scale really nicely to a distributed system. Now, micro services then came came along. One of the most exciting things to happen to the way that we build applications over certain the whole of my, my, my career and we stopped building these monoliths. We stopped building these massive Java application server applications that just like we're all in a box and we started. We started writing things that the application itself needed to be decoupled and connected together and like some of it's written in Java and some of it's written in Node.js. And some of it's written in Go and maybe some of it's written in Erlang and Scala, but all of these bits are running independently and scaled independently, and a whole new generation of programmers came and performed some amazing integration and Chris Richardson that wrote some of the stuff on this slide is is a great innovator in the space and and we discovered a lot of the same challenges that the previous wave of integration system challenges and the enterprise integration that we discovered before and and and had to even inside of one application now so the one application because it split into lots of different runtimes have to worry about how do you do a sequence of events with reliable outcome. So if you if you follow this this link you'll you'll hear about the saga pattern, which is kind of multiple services had events from the beginning they thought about events from the beginning. And saga is kind of like the latest generation of how people think about. I've got a bit of logic. It needs to call another bit of logic. What, how do I cope when that follow on piece of logic doesn't doesn't complete what what does compensation look like in the modern in the modern world. If I've got a history of events, this is the critical thing I've got a history of events and something fails, I can look back at what happened and decide what to do. I can only do that. And that's why it's called a saga. If I've got this history, like it's an evolving story that's got a, you know, a story art that goes from from. photo in Hobbiton all the way through to photo coming coming coming back, having Jesus smorg, like that, all of the, the, the, all of those hundreds of pages of story up like that's what your transaction looks like. And if you've not got all of the pages in the book marked out in a way that you can look back at them it's really hard to know what to do when something goes wrong. So if you think about it as this sort of evolving saga with information about everything that happens, you can kind of cope with anything which is, which is beautiful it's, it's, it sort of feels like utopia from a programming perspective but it does have some challenges which is, and you do have to think in a slightly different way so I'd encourage you to read some of the things that I've linked to here because, you know, people who are much more than me have really talked through in a great way like why event driven programming in all of its forms is valuable. So here we are in in the 2020s and we're on the edge of a new way right this multi party system thing that's evolving that the fireflies trying to accelerate. And that is, you know, the thing that is enabled by enterprise blockchain and by these fantastic technologies like zero knowledge proofs and peer file sharing technologies like IPFS and trusted compute engines like this multi party systems revolution this next step in the journey is really exciting because some things haven't changed, but really important things happen. So let me talk about that right. So what hasn't changed the majority, the vast majority because it's already been written it's in place it's it's the existing core systems of processing is still going to be unique to each player in the system. We're connecting people together and previously we might have been using Western interfaces that aren't so event driven we might have been using event driven integration patterns between people in between organizations in the past. And there obviously everything was private because there was no shared state but even in a multi party system, you have to just bear in mind that most of what the business cares about. In terms of their processing the human decision making their business processes, even special, you know proprietary logic that they've got that they think is valuable is going to be unique to each member. And that's going to be the majority and like terms of line to code it's always going to be a majority. It may not be the most critical piece of pieces and that's why the blockchain could be so valuable but you know it's just so much logic that is going to be unique. And it's the same with the data the vast majority of the data in an enterprise situation and here it's like, it's the 99% case the data by volume at least the data is going to be really private and sensitive. If it wasn't private and sensitive there wouldn't be an interesting problem to solve like so those things have not changed, but some stuff has changed and stuff that's changed to me. That's why I got into blockchain. It's the reason why I went on the jet that Virginia we found a collider ways is suddenly you can do this stuff and that fundamentally different way because a few things have changed. So some logic, some logic can be executed deterministically. It's in a way that no one can argue on the outcome because every, you know, enough people executed it or they executed it with a proof, you know that there's a consensus or trusted compute and proof or zero knowledge proof that says look, there's no arguing about the fact that this particular data isn't happening. That's fantastic it enables tokens enables enables like critical sort of decision making processes that are at the heart of the most sophisticated transactions where it allows those to be executed to terminally across the organizations and that's fantastic and that's never been possible before. And it also allows you to store some data in a way that everybody has it and that's really cool. I mean it's kind of been possible but before, but, you know, it's really embraced in in if you use technologies like blockchain or blockchain if you can have references or the data itself stored in a in a place that everybody has got a copy of that data and that's fantastic but again bear in mind that's not going to be all your data because there's no challenges without an enterprise to get that in case. And then the thing that this all builds upon, particularly all of this, this determined execution logic is is the thing for this presentation in particular, that's transformative over every previous generation of this tech. Instead of just having an event bus that's local to one organization. We've now got a shared sequence of events, the sequence the order is agreed through a really resilient multi party consensus driven technology, a blockchain and distributed ledger. How cool is that that is just mind boggling the transformative to how event driven systems can work because suddenly now that sequence of events can be multi party systems of events. That wasn't true in the inventory of an integration age that wasn't true in the West web services. So, age for an SOA for connecting together organizations, microservices proved how powerful it was to have that inside of an application but microservices are, you know, that's about building one application inside of an individual application. Now we can do this in a way just can't be argued way it's not worth arguing that blockchain is wrong way that you're not going to have this where's my what sequence of things happen and where's my message kind of challenge that we've always had in the past so it's transformative. What that means from a solution development perspective is that you can now you can now build these multi party business processes and get some, maybe most, but some still massive of the benefits that you that you could just the things you could rely on. You're building a system inside of your organization, like you're building, you know, maybe previous generation business process management, you're modeling a business process maybe you're building a microservices you're building a solution that that that you know has a user interface has API's connects to your core systems that implement a business process gets a transaction done end to end. We do that inside of an organization, we can now do the same thing cross organization. And that's really where fireflies trying to make the job simpler, you connect together the super on chain logic the tokens that you know simple pinning as well but the custom on chain logic you connect that together with the off chain integration to the systems across multiple parties. And we've got the shared signals of events that we can actually like do the same kind of application and business process that you can do with a microservices architecture in one organization. And there is a couple of gotchas, a couple of things that just like the laws of physics are a little bit different in this environment to they were in, in just like microservices isolated environment to one organization. One difference to having seen lots of developers building this pattern as because you know we've been doing this for quite a while in the evolution of a far flying before it came to hyperledger. One of the things that's a little bit like the sort of squint how did that happen is the event bus when it's a blockchain backed event bus, when it's an event that's significant enough to sequence it across organizations. You can't just assume when you send the event that you know where it slots into the sequence on the sending side. Now that has not ever been true really in in in in messaging systems right. So I've got I've got a Kafka queue or or an MQ or tip curious be or an active MQ between me, you know my my system like we say payments and reconciliation where I've got my payment system is on the reconciliation system. I send message 123 I just sort of know that 123 is going to arrive on the other side they're going to process message 123 right that's just true. It's a little bit different here because the you're not the only one submitting the the the the apps. You can't just like even if you do you're doing horizontal scale in my services you can still often like know that you're the only one that's sending these events. The events are being sent from the other sides as well as like five parties involved they're all sending these events. You can't assume just because you sent that event but it's going to arrive first. So, here's the trick you as the sender also need to process that event in the order of the blockchain that everybody else is saying. So you end up with this sort of initiate confirm step on your own, your own logic. You have to sort of say look, I think the first, well, the first one isn't so interesting I think the second step, like, is, is, I know it's a bidding system right I want to I want to, I've received a request for a tenant I'm going to I'm going to submit. But like the first five submissions when I think that I've I'm going to submit and my submissions going to be number four, and I submit it. I looked and there was only three submissions before I submitted it well that's not good enough to know that you were number four. You can't trigger the bit of your logic that says to your users, I submitted it and your number four at that point you can't show that state yet to your users. You can't have that in your core systems, because until it's been ordered and then you process it and at the point that you're processing it. You look at the current state, and you say I'm still number four, number, you know, another number four didn't come in before me. You can't rely on that being true. So just because you sent it doesn't make you special and you have to process, you have to think of your own events being ordered, along with everybody else's. It's really like it sounds subtle but that really does just create an extra level of force in your applications, you have to do a send and then you have to process your own applications. Now one thing that we are doing in Firefly, and there's an issue tracking this one one two is we are going to make it so that if you want to Firefly will block. This is not a synchronous asynchronous because, but it because this is this is hard like this is, this is not changing the fact that this is nice synchronous event, but I'm sending. We can make it so that it will block until you've got the confirmation from the blockchain, and that event's been confirmed so you don't have to, you know, if you want to just sort of wait, and have a spinner. Then you can do that and that back there's just a few places where it's like particularly early on in development is super super easy to do that so we're going to add that at that end of our life. So there's now another difference. And I'm conscious on time and I've been waffling a bit. But there's another there's another difference here. And I think this one's really significant personally. If you squint of a messaging technology, if you squint. But there were very, very different shaped messaging technology to traditional message queuing streams. So if you've used, if you've used when you know one of those mq technologies or you've used the you know the latest generation of things like Kafka streaming. Either that's super reliable right they, they, they, they look after your messages they get them to you really from a to b really really quickly they batch they optimize they have your ability or persistence it's often called they, you know they coat with periods of downtime they're like they're awesome. Those technologies should still be used in these sort of modern systems. But but they're not like a complete history of time. I believe without exception, and I'm happy to be proof wrong on it, but I believe without exception they, they say it's really big anti pattern, even if they support like turning up the size of your q depth, you know or transaction ledger to infinity. They're not designed to be a replayable complete history of time. They're designed to be a buffer from a and B to be a mailbox. The mail goes into it. You know, the postman can fill it up to the top they can stick stuff on top of it maybe a bit they can stick stuff underneath, but eventually it becomes full. And when you want to read stuff you take it out of the mailbox and you open it. It's no longer in the mailbox anymore. That's different to the way a blockchain ledger works blockchain ledger is designed to allow you to look back in history and see the complete history of time. It's super fantastic that's, that means that things like late join and catching up and looking at the state of the state of things. You know, if you're new or you're catching up or you're going back in time you can see like a saga, you can see the complete history now, and you can build applications that can have that that history in an immutable way that that's, if you've read about the UTXO model that the the unspent transaction output a model of the way that blockchain like Bitcoin work that that's what they're built on like that that concept that you know for sure right now you can trust the right now but also you know you can prove the right now by looking back in time to be beginning of beginning of time so so anyway that's that I think is a really significant thing and just to weird away. For our flights built on this concept you kind of need both you need the private reliable messaging and you need the, you need the ledger.