1:48 Introduction and Guest Introduction

1:48 Hello, and welcome back to the Rawkode Academy. I'm your host, Rawkode, sometimes known as David Flanagan. Today, we are continuing our exploration of the cloud native landscape and taking a look at a project that wants to make building microservices easier. That project is Dapr. And to guide us through today's journey, I am joined by my friend, Salaboy Mauricio. Hey, man. How's it going? Hey, David. How are you doing? Thank you very much for the invite. You know, I I Yeah. Didn't wanted to do something like this for for a long time, and finally, it's happening 2023.

2:23 And that's that's I'm super happy. Thank you for having me. We're squeezing the end right before the end of the year, which is fantastic. And it's nice to be able to set and do this thing with an actual friendly face. So, you know, thank you for taking the time to to join me today. Let's do it. Alright. So for anyone who's not familiar with you, which I think is impossible in our space Yeah. Could you please tell us, you know, what you've been up to, what you're doing now, and anything else that you think is interesting?

2:40 Guest Background and Dapr Experience

2:49 Yeah. Yeah. Yeah. Sure. So I've been working with Dapr for a company for a new company that's called for a year now. Like, my my anniversary was, like, a couple of days ago. And I've been getting into the Dapr community for the last year because I found Dapr like, as one of the missing pieces of, you know, building applications on top of of Kubernetes. I've been working with Kubernetes for, like, seven years now, always from that, like, developer perspective. Right? Like, just trying to help developers to get their applications up and running, but also connected to each other and, like, implementing best

3:22 practices and finding the right tools to do the right things. And I found Dapr kinda like a the Dapr project to be significant in that space. Right? Like, it's very close to developers. It's about APIs to build, you know, better cloud native applications. And, yeah, I've been trying to contribute to the project, trying to integrate the project with other projects and other communities in the CNCF landscape and outside CNCF as well. In the in the journey, in that journey, basically, I've been meeting a lot of very interesting folks and learning a lot of interesting lessons. So, you know, whatever I can share

3:53 about that, it's it's always good. Awesome. Amazing. And you didn't mention your book. Do you wanna talk about that as well? I can talk about my book as well. It's it's a funny thing, Riley, when you when you write a book. I've started writing my book, like, two years ago, and now it's titled platform engineering on Kubernetes, where I basically cover a bunch of open source projects, and how do they relate and how do they work together to just build platforms on top of Kubernetes, basically. But, because I've been writing it for the last two years, the moment that it got

4:24 printed, I had this feeling of, I don't want to talk about this anymore. But now is the time where I should be talking a lot about it, right, because it's out actually out. So yeah. So, you know, the book is all about open source tools for Kubernetes, tools for teams and application delivery teams and for operation people to build platforms that basically help teams to just get software running on top of Kubernetes, going from pipelines, from packaging, from, application development tools like Dapr, but also k native for running and auto scaling, a bunch of other things that people might

5:01 find interesting. Yeah. I mean, that's the thing with Kubernetes. Right? A lot of the tutorials out there get you to the point where you can keep control, apply an engine x deployment, and then that's it. But there is so much more that comes afterwards. And it's good that we have resources now that are starting to fill in the gaps and and actually educate people on what they need to know and to get them on the right path. One of the interesting things about the book, and I guess that the main reason why I decided to write it in the first

5:26 place, was that when you look into the CNCF landscape, right, like, are tons of projects built on top of the of the Kubernetes APIs. Right? But they are all built and designed in different ways for different purposes. So getting them to work together sometimes and at least two years ago wasn't that easy as it it is today. So for me, it was kinda like this whole exercise of making sure that I can create an example that can actually highlight, you know, 20 different projects and then see how each project is bringing something to the table and also understanding the

6:00 gaps that, you know, when you combine two or three projects together, kinda start popping up, and you will need to sort out yourself. Sweet. Awesome. Alright. Let's move on to the topic at hand then, Dapr. Can you give us the thirty to sixty second pitch? What is Dapr and why should people stay tuned? Yeah. So Dapr is a CNCF project. It was donated that's a very good question. When exactly? I don't remember the date. But but it's a it's a pretty mature project. Like, it has it was created by Microsoft in 2019. And, basically, the main purpose of the project is

6:20 Dapr's Core Purpose and APIs

6:37 to allow people to have kinda like a, like, an application level API that enable teams to interact with infrastructure without knowing where that infrastructure is or what that infrastructure is. The idea here is to provide developers APIs that they can use and enable platform teams to configure how these APIs are implemented in different environments, but at the same time providing kinda like a like a seamless experience across environments. Right? So you can have different environments configured with different infrastructure in different completely different ways, in completely different cloud providers, but the application development experience is the same

7:13 because the APIs remain stable. In order to in order to get that working Kubernetes, there are tons of things that needs to happen, and there are tons of components and building blocks that the Dapr project provides. And I guess that we can explore with that side as well. Yeah. I mean, just that paragraph that you gave us there. I mean, that's no easy mission. Right? Trying to be able to build applications in this way, make them as portable as, you know, what we have all really like from our from our stack. But as you said, we're

7:18 Dapr Building Blocks Overview

7:43 going to explore Dapr hands on and see where all the components are, how they work together. And what I'm really excited about is just can we show people a better developer experience for bells in these type missions, which are very tricky. Right? So Yeah. You need to you need to add on top of that that because we are focused on APIs, the the entire experience is is polyglot in a way. The the idea that, like, there is no language dependency coming into into the the space. Right? Like, the idea is that from any technology stack

8:15 that you're using, you should be able to consume these APIs, like, by just using, like, normal, you know, language tools. And and I feel that's pretty important, and, also, it makes the mission a little bit more complicated because now you are dealing with tons of different technologies that do things in slightly different ways, and they come with different developer experiences and different ex you know, developer workflows as well that you need to accommodate. Alright. Awesome. Okay. I'm gonna share my screen and we're gonna get started with the hands on component. And before I do that, I'll just say

8:40 Beginning the Hands-on Demo

8:45 hi to two familiar faces. John Luca and Marino, saying hi in the chat. Hey. Nice to see you. Hey, folks. Alright. Let's see. I have the correct screen shared which is always a good start. Here we have the Dapr website. You can find that at dapr.io. We're gonna dive straight into the documentation. And I'm assuming we'll install, you know, Dapr itself. I haven't done anything in advance. Everything that you see here is everything that you will need to do to be able to replicate this at home or work forever. So I'll click on get started. We're gonna

9:06 Installing Dapr CLI (and discussion)

9:21 grab the CLI. We'll do Yeah. So let me let me try to explain a little bit, like, the getting a starter experience. Right? Like, you can download the CLI. The CLI will basically help you with some developer workflows initially just to set up different environments and different the tools in different ways depending on what you are trying to achieve. In general, for developing applications, again, I don't think that having the CLI is a requirement, but just go go go ahead, please. And if you can install it, like, we can go through the getting started guys.

9:56 Alright. I just assumed that we needed it, but it's good to know that we don't. Oh, I'm late. I'm on late mode. Let me I don't wanna blind everyone at home. So I kinda I kinda love the, like, the, like, the CLI experience in general. But when I think about, like, going to different developers using different technologies, like, Node. Js or Java or or Rust, right, like, completely different text stacks, I I always think that adding a new CLI will introduce something that that developer will need to learn. Right? Each CLI will come with kinda like a different workflow, a different set

10:35 of steps that you need to execute to achieve something specifically, and that, again, will push the developer to stop doing what they are doing and start learning that specific CLI and all the arguments and all the parameters. So I tend to go without the CLI, but you will see that in the in the getting started guides, most of the exercises of will use that CLI to bootstrap Dapr itself. Nice. We're in a wonderful position where I decided to try out new shell, and I don't have any of my paths configured properly whatsoever. Nice. But I think we can

11:14 do. Would that work? Let's see. I think so. Yeah. Alright. Well, I've got oh, no. It didn't work. Oh, I appended it, but it didn't save it. Alright. Okay. So e n v dot path equals. Alright. Now I've blown away everything else. That's that's yeah. That's not the the best. But you have it there. Alright? Like, you printed it before. So Alright. Today is not the day for me to be experimenting with new shells. CSA cheese? What is it? Homebrew? It's not. I have no idea what homebrew is. Let me check. I can check my No. It's

12:01 okay. Let me You will find it. Of homebrew. Ben, yeah. Okay. So we wanna There you go. Brew. Better. Dapr. Better, cool. There you go. And one of the things I did is he's completely irrelevant. Right? Because I was trying to convince myself to switch to a new shell. I had to remove the path of least resistance, which is when it frustrates me just jump back to said shell. I knew all of my said shell configuration. So it's super vanilla. But we're not gonna. Alright. So we have to see a live. We didn't particularly need it, but that's alright. And

12:38 I'm gonna go back to the documentation where we're going to click on quick start, and we're gonna work through one of these today. And then I think you're going to show us a couple of extra things on top of that afterwards. Yeah. Yeah. Yeah. I think I think that we can do that. And it's kinda like important to see that what you will see there in the quick starts basically are, you know, the Dapr building blocks, something that the Dapr project called building blocks. And each of these building blocks is basically exposing a different set of

12:40 Exploring Dapr Quick Starts and Building Blocks

13:05 APIs to do different things. You can see the first one that it's listed there, it's called publish and subscribe. Right? That will give you APIs to emit events and consume events. Then you have the service invocation API as well that will allow allow you to do more resilient service to service communications and service discovery as well. And the management APIs will give you, like, a key value store API to store keys and values, just going through an API and not connecting to a database or or, like, a Redis or something like that. And then there are a bunch of others,

13:39 and I would like to say that workflows is the one that gets me, really, really excited. It's it's something that it has been released, like, pretty off like, pretty recently, and it's getting better and better. So I'm really keen to see how how that evolves in the future. But I think that for for this and to demonstrate what kinda like what Dapr is about, I think that we can take a look at the state management APIs. That's probably the the simplest to get. Yeah. I mean, workflows is definitely interesting. Right? I'm seeing long running Yeah. Powerful and stateful

13:54 Focusing on State Management

14:10 applications. This is this always puts me back to people trying to make temporal easier, which is such a noble mission. We need to make durable execution easier for people to host and operate themselves. But I love workflows, but you're right. Let's let's keep it chill today and come back to that. So so so this is the thing. Right? Like, because these are, like, components. What's happening with the Dapr project is that you will see that we have a lot of different component APIs, and then something like the workflow API and the workflow functionality basically builds on top of

14:40 all the components. Right? Like, we are starting to construct more higher level components that are built and relying on lower level things. Alright. Let's start off with state management. I always say on this show or in fact, in life conferences anywhere that I am. Right? If your application doesn't have state, you're not making any money. So let's cover state management. And I guess that that that's a very good point. Right? Like, if you think about applications, 80% of the applications will be doing kinda, like, reading data and storing data somewhere else. Right? Like, they are processing data and then

14:49 State Management Diagram and Sidecar Pattern

15:10 just need to store it somewhere. And I think that this is what, the state management API is all about. You can see there in the in the example in the graph. Right? You see that you have your application, in this case, like an order processor, and then you have Dapr in the middle, which is the one providing the APIs. And then you have a backing implementation in this case. Redis is an example, but there are a bunch of different implementations for the estate management APIs. Alright. Nice. Just because I forgot to mention to this to you before we went live. If you

15:40 right click on the screen where the video is and say show controls, it will allow you to fill screen it. Because I know that once I get my terminal and code up, might want it slightly bigger. It's just Oh, interesting. I don't know why that Right click on the the the video, like, where my browser is and say show controls. No? No. You don't see it here. Oh, show all controls. Yes. Yes. There you go. Now you could fill screen that. I know. Which makes There you go. Thank you very much for that. We went

16:08 through. And then when I show you a code, you're gonna be like, I have no idea. So Yeah. Yeah. Yeah. Was getting closer to my screen and thinking, okay. I think that I can read, but, yeah, I might need some glasses. Alright. Do you have a preferred language as these? I'm gonna suggest TypeScript or Go, or JavaScript or Go. Which one would you prefer? How how comfortable are you feeling with Go? Yeah. I'm I'm comfortable with Go. Let's go with Go. Let's let's let's let's do it with JavaScript, which is something that I feel very uncomfortable with. So let's let's do that.

16:44 Alright. Well, we're cloning it and it isn't all that's a JavaScript version of it. Right. Okay. Cool. Got it. Yeah. Let's let's call it a quick start then. So, we start and then we're gonna see the end to state management JavaScript So forth. Mhmm. And then we're just gonna do Dapr run. Alright. I trust you. Going to the quick search first. There we go. I don't have any of my things. This is gonna be so much fun. Alright. So this is interesting. Right? Even before I run this command, I ran the LS because I assumed

17:31 there was gonna be some sort of Dapr file that told it what to do. And there's not Let's take a look at the let's take a look at the instructions again. It just says run That per yeah. Go for it. No. Is it just gonna Just to Ah, okay. Alright. Okay. Yeah. It's there. No. That's asking you for a file. Right? Just do Dapr run. Let's see. Do you have a Docker running? I do. Yep. It is there. Interesting. Do we need do Dapr in it? Dapr in it, maybe. Yeah. Yeah. We probably skipped a step on getting started gate, didn't we?

18:27 Yeah. And it happened locally. So It's yep. Perfect. So that's gonna run, I imagine, some sort of a trigger. To create a and that might create the file that you're expecting to have there as well. Well, no. Because well, we'll see. Just do a less? I don't know. I'm not so comfortable with the with the CLI. Alright. Well, we have something to run-in. Yep. Yep. So just to explain people. Right? Like, what you're trying to do here. Right? What you're trying to do is you're trying to so, basically, just clone an application, and maybe we can

19:02 take a look at the application code first. Yep. Because in order to understand why we are running that Dapr run, I think it's important to see kinda what the application is doing anyway. There you go. Alright. Perfect. If you go to, like, the main function there. Right? So you will see that, basically, what it's doing is first of all, it's creating a Dapr client. Right? That basically means that there is an SDK being imported in some way in JavaScript. Right? Because that's, like, a like, an object from from the Dapr library. Yep. So, basically, if I guess, I'm I don't know

19:54 if you can see the import somewhere, but, yeah, in package JSON, probably, you have that kinda, like, dependency now. Like, you're including the Dapr JavaScript SDK. And the first thing that you will do is you are going to create a client, and you can see that the parameters are the host and the port, and then what protocol do you want to use for for that SDK, basically. They are, like, usually, they're, like Dapr exposes the APIs using gRPC and HTTP, and then you can just choose which one to use. But then then as soon as you create

20:23 a client, basically, then you can just start using the Dapr APIs. And in this case, as we mentioned, we are going to be looking into the state management APIs. That's why in line 40, you can see that we are doing client state save, basically. Right? Where the state variable there is just a JSON payload. It's just a JSON object. Right? Okay. Yeah. So yep. So Dapr Mhmm. Basically, I write my code for my application. And what Dapr does is give me a client with a bunch of integrations, one of them being a state store here. So we have the ability to fetch

20:50 Application Code using Dapr Client (JavaScript)

21:04 and save state. And Mhmm. I'm assuming this works because I saw in the dog logs here. Right? There's a sidecar. So this is putting my application into container, adding a safe car, or maybe it's not in a container right now. I'm not even that sure. Exactly. We have an application. We've got a Dapr sidecar or something that the Dapr client also to speak to which I'm assuming is just over some sort of loopback or localhost and it's proxying all the requests to state storage somewhere else. I'm pretty sure in the docs earlier on, we saw Redis. So it's it's that what's

21:33 happening. Right? That's what that's what happening. Right? Like, but from your application point of view, you don't have any Redis, you know, dependency. Right? And you are not even writing the code to connect to any Redis database or anything. Right? Yeah. So is it fair to say Dapr is a set of abstractions on building applications where you don't have to worry about state or you don't have to worry about workflows and whatever else is on that list. Right? PubSub. Exactly. Exactly. And I I think I think that that's the idea. But, again, it's like trying

22:06 to add this obstruction layer that will enable developers just to code whatever they need to code for their application. Would they will let a different team to worry about which components needs to be running for these APS to have, you know, the right backing implementations and the right configurations and everything else that they need for a production use case. Now is what Dapr providing purely an abstraction, or does it go a step further to provide any sort of resiliency, redundancy, retry logic? Like, what is that what is Dapr doing when I say client save this client state save? That's

22:32 Dapr Benefits: Resiliency, Observability, Security

22:43 a very that's a very good question. And, yes, it's doing all that stuff as well. Right? Like, we are building all best practices and resiliency mechanisms on top of these calls. Because, again, you have a proxy now between the application and the infrastructure. You can implement all these functionalities because it's the perfect place to do so. So now you have an abstraction to access this this in this case, this state store, like, that can be ready, so it can be, you know, whatever cloud provider supported key value store is is is supported there. Like, even you can just swap ready for

23:17 post Postgres or any other supported implementation. And, yeah, and and then you have all these other super nice features that come because, you know, you you have, like, this proxy in the middle. You have observability. You have resiliency. You have security, a bunch of other things that you will always need to implement. And most of the time, it's delegated to the application code to do so. And in this case, we are doing it at this proxy level. Okay. We have a good question from Marino in the chat. He wants to understand the cross cutting concerns of a service mesh

23:45 Dapr vs. Service Mesh (Overlap and Complementarity)

23:52 and Dapr. Like, do we still need a service mesh with Dapr? Can it work with a service mesh, or do you lose do you just not need one with Dapr? Like, how do you see them working together or not? Yeah. So there is there is definitely some overlapping functionalities, but I do tend to think that Dapr adds this application level concerns and these APIs that usually a service mesh will not have. Right? So service mesh and Dapr, I think, in my opinion, are complementary tools that you can definitely use together, and they will be providing

24:23 different things at different levels. For example, if you think about the observability. Right? The serve service mesh can provide all the networking observability, like the low level stuff, and Dapr can add on top of that all the application level metrics. So for example, how many keys are you storing per second, right, and all these things. So, again, it's like it's complementary. Dapr can do something around, like, networking observability as well and, example, NTLS and all that kind of stuff. But if you have a tool that is dedicated specifically to that, this will complement each other for sure.

24:55 Does I mean, because okay. Let's answer one question first. Precursor to my next question. Right? Yes. And then I see your question, most will get over to that in just a second. Say someone watches us today and they're so impressed by Dapr. They're like, okay, I want to start doing this. I want to make my life a little bit easier. Now, they've got like most organizations, most teams, they've probably got some existing infrastructure. Now as the approach that well, everything should be Dapr and go over the Dapr sidecar or can I build one or two services with Dapr and inject

25:30 that into existing application stacks? Yes. %. Yes. So I would I this is my personal opinion about the Dapr project. Right? Like, they're providing generic APIs to do different kind of, like, very specific behaviors, in this case, saving and retrieving, you know, key values in this case. That basically means that because we are we have an obstruction here, we are not being able to access some of the provider specific functionalities that some teams might need. Right? In my opinion, this obstruction aims to cover, you know, like, 80% of the use cases that you will implement with the key value store.

26:05 But the other 20%, it's very specific to each vendor and maybe kinda one feature that the vendor is providing that it's not being shared with all the other vendors. But, basically, we'll put you in a position where all the generic stuff that you can build, you can build it using Dapr. And all the very specific provider, you know, like, vendor specific feature that you want to use, you can separate it in a different service and then consume that via APIs or via any other interaction mechanisms. That's kinda how I've seen Dapr being used. Because, again, like, if, like, an architect is

26:36 looking into the like, into this, you know, stream and saying, well, I know that by using those generic APIs, I would not be able to implement by very, very concrete use case that it requires just to go straight to the Redis APIs, and that's perfectly fine. But if you start using for all the generic stuff that you're building, the Dapr APIs, then for all those developers, they don't actually need to know about those vendor specific features that you need to use. So you can just get newer developers, not that experienced, in this case, with or with value store,

27:08 just coding applications and building stuff. Okay. So let's push that a step further. If all of my application is Dapr, and I'm using Dapr to communicate with the other services, maybe I don't need the service mesh. Does Dapr allow me to then explore open telemetry metrics based on traffic going through all of the sidecars? You can enable that. Yes. Yeah. You can get that as well. But but this is not the case if, like, you need a service mesh or not. I guess that with Dapr, for example, it will be yeah. So for the observability point

27:41 of view, then you can ask, okay. What what kind of metrics are you getting for the service mesh, and what kind of metrics is being exposed by Dapr. Right? What kind of stuff how deep can you go, and how well integrated it is with the rest of the ecosystem? I would tend to think that companies and projects dedicated to that specific space will do much better than a project that is much more focused on the developer space. Does Dapr handle service discovery between Dapr to Dapr services, or does that rely on something like a service mesh or Kubernetes API under

28:12 the hood? So yeah. So so Dapr does service the discovery, and it allows like, it implements resiliency policies across these calls. Right? But, again, these resiliency policies can be implemented by different mechanisms, and the Dapr sidecar will have some implementations there that you can quickly configure. Right? But it again, it's just more focused on the application level concerns. Right? Like, making sure that, you know, if this service a is calling service b, you can quickly define how many retries do you want to do if something goes wrong, and you can configure that in a declarative way.

28:47 Okay. That makes sense. So there is an overlap. There is definitely an overlap there, and I think that we're we'll be we will be working with Marino to make sure that that overlap, it's it's clear for people and also that we have some very cool examples on on how one thing can complement the other and how people can actually benefit from having both. Alright. Awesome. Thank you. Mozz asked a question. Does Dapr offer any caching in case with regards to like the state management? So, you know, if I send the same request over and over and over again, is it

29:08 Incremental Adoption and Existing Infrastructure

29:19 safe car gonna go? Hey, you've already sent us and just like memoize their response. That's a very good question. I don't like from the top of my head. I don't think so that that's the case, but I can find out the more detailed answer later on. Alright. Hey, Carlos. Hey, Carlos. Thanks for joining. Okay. So, what we've seen so far, bring in the Dapr client, we create a client, we bring in the package, we create a client, and then all of a sudden we can start to call services obstructed by the client. Right? So if we do

29:56 a client dot state, maybe I don't have the packages installed yet. So let's do let's just button. Okay. So that should if I restart my server, give me auto complete. No. Alright. That goes that idea. I just wanted to I know it does. See. Okay. It does. Right? I I didn't look see. Oh, yeah. So I know that state safe. So oh, I just don't I'm not gonna know complete on the different oh, no. It's at the top. I think that's based on the strings that are there. Right? Yeah. So we got actor stuff, bindings,

30:30 Exploring Other Dapr APIs (Configuration)

30:41 configuration, crypto, focus, proxies, pubs, sub secrets, take care. Alright. That is quite a comprehensive set of APIs. So I'm just gonna pick Yeah. Two that I think are interested and then maybe we can either take a look at another quick start just to see what's going on there or we can move on to your demo. But firstly, let's try configuration. Right? Yep. I don't know why I keep starting at the bottom. So I've got subscribed, subscribed queries and get. So does this mean Yeah. I could just say that I want some mean, Configuration key. Let's call it scale scalar

31:18 number. Right? Which is just some arbitrary Exactly. Created. Mhmm. A b c. This I now have the ability to do distributed configuration across my Dapr services. Is that correct? Yeah. Yeah. Exactly. So you can access a configuration kinda configuration store. So are these gonna compare Dapr service or pair global application? That's a very good question. Yeah. So as part of the Dapr application itself, we have scopes, and that basically give you access to different components by name. So for example, when you are, like, doing a a clang state save, you will see that the first the first

31:56 thing is the Dapr state store name. Right? Yeah. Yeah. Yeah. What you can do is you can say, you know, my state store called my state store has a scope for this application or for this list of applications. Right? Like and then only these Dapr applications can access, you know, that component. Okay. So this is the store name, and then it looks like it takes a list. So now I could actually ask for my scaler number and maybe I'll see my name, some random terrible thing. Right? Exactly. So we get a promise, so we're just gonna await that. And

32:34 then I get configuration response. Exactly. And from there, I can do It will be a c. Okay. So then we get to the top. Now there was one other interesting thing there as we can do client configuration and then the resubscribe. So does this allow me to get live updates as those values change into my application? That's the idea. Yes. Nice. It's a really cool feature. And and, again, I hear that's that's kinda interesting from lots of different perspectives. Right? Like, you're getting functionality that usually you will need as you are, like, figuring out. Right? Like,

32:46 Live Configuration Updates with Subscribe

33:11 when you look at that feature and you said, okay. That's super interesting because that's something that I will need. And if you need to kinda, like, implement that and figure out how this configuration store is is doing it, then it will take time. Here, you have kinda, like, all the APIs with the most common, you know, functionality already exposed there. So just autocomplete and just figure out what what you need and then you just you just use it. Yeah. I mean, it's one of those things in Kubernetes. It's just it's been a pain in the

33:37 ass from day one. Right? It's where the content map changes, and you have to find a way to rotate that Mhmm. Point. We've done Exactly. Past via terrible annotations with hashes. We're making content maps immutable and force and deployment that way. But really, our conflict could just be delivered at run time through some system like And I love that the API is just right there for you to use even with the subscribe, which is such a nice touch. Exactly. Because think about this. Now you have this proxy that usually, like, when you start using Dapr, you would think that it's just a,

34:07 like, unidirectional. Right? Like, you're going to infrastructure and sending request to infrastructure. But because this proxy is, like, it's long running and it's running right beside your application, can also call back the application whenever it's needed. So for that subscribe mechanism, basically, you would just get the notification back into the application when something changes. The same with pops up. Right? Like, with pops up, you are interested in receiving events whenever they happen in Kafka or in or whatever, and you want to make sure that the application gets called back whenever a new event happens. I

34:40 Outbox Pattern with State and Pub/Sub

34:40 think you've you've led yourself in to a very tough question there because you put an idea in my head and that's never a good thing. Oh, no. I am a huge fan of Kafka esque APIs, that style of topic based pub sub, right, especially red panda, that's an amazing project. Right? But there's a challenge. Right? And the challenge is that we usually need some sort of two phase thing. We save something to a database, we grab our pub sub, we publish the thing. Yep. This is a transaction even though we don't treat it as a transaction. Now I'm hoping

35:13 you're tell me I can do start transaction and then wrap these two things. Is that something that Dapr is gonna solve for me, or would I still need to handle that on a case It's it's it's much better than that, my friend. I'm I'm glad I'm glad that you asked that. So there is a way to configure the the state store to actually implement the outbox pattern, which is what you're describing. You want in the same transaction to to to store a state and then immediate message with that state, with the payload. Right? So there is a way to automatically enable

35:46 that for the state store for the save. Right? So when you do save, you know that depending on the configuration of that, an an an event can be immediately in the same transaction as well. And that's not there. It's not it's not in the APIs. It's more like a configuration space, and you can you can take a look in into the website. Okay. So let's go back to the docs then because that's that's really interesting. Right? Because this is just something that's Yeah. Always been super hard. Right? Exactly. And again, this is kinda going back to

36:16 what I mentioned before. Right? Like, we are building more complex functionality based on the building blocks. Right? Like, we we can store state and we can meet events. Now we can bundle them in the same transaction if we want to. Alright. So where should I be looking? I think that now, like, basically, it will ask you to run the, like, Dapr run. Right? What what are you looking for? That configuration thing you were talking about. Oh, so we need to take a look for the, like, out outbox pattern. So if you search in the documentations,

36:51 outbox There you go. And I think that that's the configuration out there. Right? Like, that's basically the the YAML file that you're looking into is how do you configure the backing implementations. Right? Ah, right. So in this case in this case, you are using a state store that is MySQL. Right? So in this case, you are storing this key value objects into MySQL. You have, like, the connection string, of course, to the instance of the database. And then down there, like, the the the next, metadata that you have there is out outbox publish pops up.

37:29 Right? Like, that basically means every time that you do a save state, you're going to be creating a message into that pops up on the topic that basically you are defining there. Yep. That's nice. I was not expecting you to tell me it was that easy, but I'm very I'm very happy that it is that easy. And and I think that this is what makes the project really, really, really powerful in in a sense that if you start building more and more complex patterns like this one. Right? Because these are the difficult challenges that developers needs to solve.

38:02 And if you summarize all these things into some APIs and some configurations, then, actually, you can have, like, you know, less experienced developers building very complex functionality. Sweet. Alright. Let let's get back on track. So Yeah. That was cool. I'm just worried this. I bet you should it's only me that really cares, but I really love that that bit of functionality. So we're taking a look at state management. I'm just gonna see if there's anything that didn't take a look at that it's gonna cover. So run it, see it save stuff and now okay. So now we're getting the

38:17 Running the State Management Quick Start

38:41 ability to add a YAML file for multi app. That's that's I don't think that you need that right now. Let me see. Yep. Yeah. You do need that, I think. Okay. Yeah. That's you need that because that's the file. Yeah. That's the file that you need to use to basically run the the order processor, which is the application that you clone. Alright. So I probably don't want us to save any of those changes. And the filename that we need is Dapr dot YAML. Always YAML. Always YAML. And I'm gonna use button. There we go. And then you have the other file, which

39:30 is the the one that we were looking at before. Right? Like, this is the state store definition, using Redis. This YAML file, this one specifically, is the one that, basically a platform engineering team needs to define and configure, right, based on the the, like, available infrastructure that they have. Okay. So state store, we have. And now You did that already. Right? Yeah. You did that. Yeah. What is that? Yeah. Now you need to run the app, I guess. You should be able to run the app and oh, there you go. Yep. Mhmm. Just to recap. Right? Like, you are not running

40:10 Debugging the Quick Start Application

40:23 Kubernetes. In this case, you are starting Dapr outside of Kubernetes. And the Dapr CLI, it's basically configuring Dapr to have, like, an instance of Redis, I think, locally running with Docker and connecting to that one. You need to do I think that you need to do the other command. Yeah. Not that. I think that you need the the long one. That one. And Dapr Dapr run. But haven't I just Yeah. Described all this stuff? Oh, no. That's order processor. Okay. Alright. Okay. Gotcha. Exactly. We have state management, so that's a separate application together. Alright. What can we see there? Did you change

41:08 something in the app? No. That's the order processor. I have not touched the order processor. Yeah. I think it wants me to be in a different direction. Yeah. Okay. This is it actually wants me to go into that application. That's Into the other processor. Yeah. Okay. So I've I've been scrolling too fast. Right? So we set up the environment. That's right. Which Dapr run. We've seen this one run. I think we're happy that that one just worked. Right? So let's do it again. And my Dapr logs will appear here. Easy. So it looks like we ever got logs from

41:41 it. No. Because that's, like, that's not running the application. That's only starting the Dapr APIs. Right? Like, on your application is not running. That's why the other Dapr run is basically running the Dapr sidecar that you're running there plus the application at the end. You can see that there is an NPM start at the end. Not not in that command. Okay. Okay. So I can now do bun run that Mhmm. That's your that's your path again. Yeah. I hate myself so much right now. Humber a bit. You know, I I really I really don't care

42:29 because I know that you know how to fix it. If I need to fix this live, I would be struggling. Oh, okay. So there's a start, the start Dapr. We've already done the start Dapr, so I'm just going to start. Yep. Waiting for a sidecar, which should still be running. Yeah. But are you trying to start it? It's like a start the start up. Yeah. Yeah. Definitely. Just the start. I'm waiting for a sidecar. Okay. That might be because so if you do, like for example, if you do okay. So That was, a run. Update email

43:09 not supported. Uh-huh. Interesting. Is this just because I'm being an absolute pain in the ass and using BUN? Am I just I don't think so. Am I breaking your demo? Maybe. But that's what what demos are for. Right? I know. It does the same with NPM. It says that HTTP is not supported, deprecation warning. And yeah. So maybe you just found a bug or something because I guess that that the Java SDK is trying to use HTTP for some reason. So if you look at the source code in into the application, remember that there is kinda, like, a protocol

43:52 being defined on top. Right? Yeah. The thing was here. So shall we switch it to gRPC? Just switch it to gRPC. Yeah. I'm just It's checking for, like, an environment vial. Right? Yeah. Yeah. I'm just gonna cheat. So To gRPC straight away. Mhmm. Same. Configuration store is not configured. Yeah. That's because, like, if you take a look at the command in the documentation, you need to use that, like, the Dapr Dapr JAML file that you're not pointing to to start Dapr. Alright. Are you are you running Dapr in a different way or not? Like Well, no. It's

44:38 have it in a different terminal? There's a bug in your docs because it says, not your docs, you know what mean, but it says run Yeah. Run dash f, but that that's not enough. It seems to be That's not enough. And I think that the documentation is building. We are not reading all the lines, so I guess that the real command that we need to run, it's down the end. So if you check out the at the last command in the docs, I think that the code documentation is building just to make sure that you run different things.

45:07 That one. Because that one is, like, pointing to the resource paths resources. I know, but we try to find that in a Dapr dot YAML. So I feel like we shouldn't have to do that again. Yeah. Yeah. That's true. Let me see. Okay. Let's take a look at the Dapr dot YAML file. I would just want to make sure that we are pointing to the right state store YAML file. Right? Like, that's what we we should check. Alright. So does Yeah. So Is that yeah. Exactly. We need to check that that is pointing to the right place. Right?

45:48 It doesn't look like there there is any resources there. Right? Three. Oh, there you go. Oh, okay. So that's the the one there. And this is actually our date. Though that's the app ID, so the concept of application ID, it's basically giving, like, the application an identity. Right? Like, in this case, we have an application that's called order processor. And this is kinda going back to the thing that you asked before, the idea of having scopes. Okay. Hey. Oh, no. Then you oh, what's but what do you see? What is that? Configuration stores is ah, it says configuration

46:32 store. Is that can you save your source code? Are you still using the configuration APIs? Yes. There you go. Yep. David strikes. There you go. There you go. Well, it that was not an easy thing to to see about. Yeah. We need to read the error messages. There you go. You just shouldn't trust me to do demos. That's what it is. No. No. I love it. I love it. Good question for Mars. Do we not need Redis? Where's where's Redis? Like, what's happening? Yes. Yeah. What's so what's happening? It's like, remember that you run kinda like Dapr in it?

47:04 Understanding Dapr `init` and Local Redis

47:14 Mhmm. So if you do so if you stop that oh, stop that and do docker ps. Yeah. You see that there is a Redis there. Right? And, basically, what the Dapr CLI is doing is just when you do Dapr init, basically, it will create a bunch of things out of the box. An interesting thing about Redis is that Redis provides you kinda like an implementation for the state management APIs, but also for PubSub. So you can actually use, you know, Redis to kinda move events around different applications. And that's the main reason why, like, we wanted

47:47 to do kinda like a very quick easy experience for people to not even worry about Redis and start using, you know, the APIs straight away. How much of this is swappable? See, I don't want to use Riders. I wanna use CouchDB or MongoDB, Postgres. Like, is that something Dapr supports, or is it very opinionated on what the back end services are provided by? No. No. No. Like, quite the opposite. I we're just trying to support as many as we can. So if you go to the to the docs, I think that if you go to the website,

47:57 Dapr Component Reference: Supported State Stores

48:16 you will see that there there should be kind of the reference, like, section, I think. Mhmm. And then if you look for, component reference, state stores, there you go. You have, like, the link Wow. Yeah, of what it's supported. So you have stuff that is self hosted and also, like, cloud provider specific stuff. Right? I mean, I'm I'm a postgres person. I'll be just Yeah. I would just I would use postgres for everything. There you go. I then it makes total sense. But if you scroll down, you will see that you can swap Postgres for any

48:54 cloud provider supported, you know, thing. Yeah. And and and so that's pretty cool too. Mhmm. Yep. Sweet. Well, that's that's the idea. And remember, right, like, the whole point of of this thing that we are trying to show here is that developers can use these tools to build the functionality. Right? And they can trust that the APIs will behave the same in kinda, in a more serious environment that may be running Kubernetes or maybe running in a cloud provider. Because the APIs will remain the same, but the configuration on how the components are wired and

49:28 how the, you know, infrastructure is configured, it's it's, you know, the the it's the responsibility of a different team. This is cool. Good flexibility on the secret stores too. Mhmm. I'm just gonna look at everything. I'm just so curious. Yeah. So for example yeah. Because, like, that's another thing that people will need, like, distributed locks. Right? Just need, a way to say, okay. I want to have a distributed lock implementation. You can do that with that. Nice. Very cool. Alright. I I could explore this for hours, but I'm gonna try not to do But we want it we want it working. Right?

50:11 I feel that's kinda important. Like, at least they're getting a start up experience. Yeah. We did. So, you know, I always like to do little recaps, but, know, the Dapr promise here is, heck your language of which there was a few supported. Right? So you've got the buried Python, JavaScript, I'll assume TypeScript is just supported by default. Any of the dot net languages, I'm assuming Java and go. Like, what is the other plans to add more languages, like like Rust, for instance? Yeah. Yeah. So there is a Rust SDK as well. But, yeah, it's kinda community support. It really

50:51 depends on on how much community do we do we get, and if we can get, like, someone to help us to create the SDK. There were some conversations about creating some Swift also, like Apple with SDKs, which makes a lot of sense because when you think about these APIs, I do think a lot about, like, mobile as well. Right? Like, you can build an application and just use these APIs to, basically, do the back end implementations of things. So, yeah, they are, like, more I think that if you go to the GitHub repository, you will

51:21 find, like, all the SDKs as well. Let me see if I can quickly check. Yeah. DaprDapr..com Dapr Dapr. And then I think that you need to search for so sorry. No. It's like just Dapr, the org. If you go to the org and then search for repositories with SDK in Rust, c plus plus, PHP. Mhmm. So why are those those just aren't on the documentation page because their community is supported at the moment. Is that right? Yeah. And probably, they are a little bit less mature. Right? So or probably, we don't have someone, you know, like the Rask one

52:02 is marked as alpha because, again, we probably have a single community member contributing. And most of the other SDKs, are, like, different companies helping and and providing implementations and tests and making sure that the the SDKs work. So I'm guessing that the ones that are listed there are part of, like, the, like, the main project release process, and that's why they are just listed and documented all over the place. Alright. So, again, back to the recap. We have lots of supported languages, potential for more, if you're well dependent effort to work on an SDK. Once you have the client and your application,

52:05 Quick Look at Other Building Blocks (Bindings, Actors, Workflows)

52:36 you start to consume the APIs. We've seen state management or pubsub, binders and actors. Let's go back to that in a moment and have a quick conversation. Secrets management config, cool, workflow and cryptography. So what are bindings? Bindings. Think about bindings. I would like interacting with external services. Right? Like, external APIs. Imagine that you want to call, like, Stripe APIs. What is that example doing? Interacting with the cron job or something. Right? Let's take a look at the Go code this time. Don't know what Yeah. Think that's just just basically executing some external stuff. Right? Okay.

53:25 Yeah. But this is a cron to run every ten seconds. Exactly. But by things, I think that it's like it's like a an API just that enable you to create different connections to different things that are not covered by the other APIs. Right? Imagine that you want to interact with a payment service or something, and you want to use the same, you know, resiliency policies that you're using for all the other APIs. Or, like, this gives you all those mechanisms, but an extension point just to interact with whatever you want. Alright. Actors. I'm a big fan of the actor model,

54:00 so I'm hoping that Dapr is gonna make my life a lot easier there too. Yeah. So this have, like, a lot of that stuff in there. I'm not the big fan of that either, and I'm not an expert on myself. But, yeah, that provides you kinda get an actor runtime inside the sidecar itself. Yeah. .Net is really leading the charge with actor stuff, especially the Orleans project where you have got virtual actors. The idea being that every entity within your system, like, user would be a virtual actor. You could send messages to that one specific actor and then react to it.

54:30 It's such a cool part. I haven't seen anything real worldly production except for our stuff on top of New Orleans. The stuff on top of Orleans and I'd love to see other languages really get there. Alright. And then lastly, we've got workflows, which you kind of spoke about briefly, but this is durable execution. Exactly. Super exciting things. Right? Because we all want more resilient and reliable applications. So this, I love that Dapr is gonna make that easier too. Yeah. And and you can imagine, right, like, workflows needs to store a state. Workflows will emit events when they move from from different

55:04 activities, and you want to make sure that, you know, if you're trying to execute something or waiting on something for five minutes and it's not happening, then you can immediately vent. All those kind of patterns can be built with this functionality. Alright. Awesome. One thing that I wanted to one thing that I wanted to clarify on the languages, right, because I think that this is important. As I mentioned at the beginning, right, like, Dapr is exposing HTTP and gRPC endpoints. So if for some reason, you are working with a language that it's not currently supported

55:20 Using Dapr via raw HTTP/gRPC APIs

55:32 and we don't provide an SDK, you can actually craft the HTTP request or the gRPC requests by hand, and you don't actually need to add any library to your application. Oh, so I could just generate a gRPC client from the profile, so then use it in any language, really. %. Yeah. Oh, you're making me smile. I like it. Yeah. Yeah. Yeah. Yeah. This is this is pretty good. The the the main thing about, like, the SDKs is that we will try to make things even easier for developers to get started with basic stuff. Right? But, yeah, like, even you can just do

56:04 actually HTTP. Right? Like, if you're in a limit limited device where gRPC is not available or whatever, you can just go HTTP. The HTTP way will just send a post request to an URL in local host, and there you go. Alright. Do you still wish to show us something interesting? I can try to show something in in less than ten minutes, like, pretty much the same thing that you showed, but something that I've been working on that maybe it's maybe worth to discuss a little bit. Yeah. Let's go for it. If you just wanna pull

56:20 Guest Demo: Dapr Developer Experience (Spring Boot/Testcontainers)

56:33 it up, and I'll stick your screen on in just a second. Let's do it. Alright. And you see my screen? Yep. We see your terminal. Perfect. Let me see if I can find another thing that I wanted to show here. So sorry about that. So yeah. So, like, a little bit of background on this. Basically, I I'm just writing a series of blog posts, and I've started with State Store. The same reason why we started here because it's kinda, like, easy to get what it's doing. But the main thing that I'm trying to cover in this block series,

57:03 and I'm doing kinda, like, examples with that, is how do you like, the developer experience. Right? You just use the Dapr c like, the Dapr CLI. And for that, you can actually need to learn how Dapr, the APIs, and what does it means, and how Dapr works because you're starting some containers locally. And that might be a little bit too complicated for developers that are not even interested in that. They just want to use if we want to enable developers to use the APIs, we just need to integrate a little bit deeper with their ecosystem.

57:33 And I've been working kinda with some Dapr and Spring Boot integrations that basically it's they are aiming for just doing that. So the blog post basically covers kinda like the APIs. And let me show you here. So I have, like this is like a Java application using the state store APIs. Same way, same thing, basically, that what you saw. Like, we are using, you know, client. We have a Dapr client. And as soon as we have a Dapr client, we have, like, the same state API here. Right? Same thing. We need the state state store name, and then we will just

58:02 send the customer object in this case that will be serialized and stored in a key value store somewhere. And, again, two different functions, two different methods here in Java, and another one for just reading state, just getting, in this case, a customer information into the key value store. Same thing. The only big difference here is that I don't have the Dapr CLI installed, and I do not have anything Dapr related running. But with this kinda, like, integration between Spring Boot and Dapr, which is basically a dependency that we need to add to our application that I'm trying to figure out where it

58:38 is here. So there is just a dependency that you add that basically will bring some configurations using a project that's called test containers to bootstrap all the Dapr related configuration for this Spring Boot application. And what lets me what this lets me do is that I cannot only start my application and Dapr at the same time, but what I can do now is I can write some tests testing for my application that basically will use that configuration. The when when I'm starting my tests, Dapr will be started, configured, and be ready for my application to basically

59:12 call the APIs. So I have a simple application level a test here, which is basically calling my application APIs. But in the background, the test container library and the Dapr integration will bootstrap all the things that Dapr needs for for this specific application without the developer basically understanding what Dapr is or how is it configured. They only need to the only thing that they need is just what you were doing before, David, which is, like, just have the ID, just to auto complete all the operations that we have for different, you know, building blocks that we expose.

59:45 And just to show that, basically, we use Maven in in in Java. I don't know how many people is familiar with that, but what I wanted to show here is that I can do something like test run-in this case, which basically will allow me to start the application in in kind of some kind of, like, development mode. And when I run this, if I'm in the right place I'm not in the right place there. There you go. That's the customer catalog service that I built. When I run this, basically, what I would have is my application starting.

1:00:12 But as you can see here in the logs, you will see if I make it a little bit smaller, you will see that when my application start, it also brings, you know, some Dapr containers into the mix. That basically means that now my application can call these APIs, and I can send request to these, you know, to these APIs and and and just use them. There you go. Wrong wrong directory. So in this case, I'm just sending a customer to my, you know, to my h HTTP endpoint that is being exposed by the application. And this piece this is using the state

1:00:43 store API to store it in Redis or in in somewhere. Like, from the developer point of view, it doesn't really matter where it's getting stored. The only thing that it matters is that it's actually doing that. I can actually test that by just sending another request just to get that customer by ID, and and there you go. So there you have it. For we David, we haven't talked about Kubernetes at all. So if we have, kinda like, two minutes, I can show something around that space just for people to understand how it works usually. Yeah. Of course. I'll I'll also say that

1:01:04 Deploying to Kubernetes (Kind Cluster)

1:01:15 in over 200 Rawkode lives, you're the first person to ever show Java code. There you go. That's kinda interesting. And I think that that's a there is a reason behind that. I I'm a strong believer that at the beginning, kinda like Java took quite a lot of time to get into the Kubernetes land, but now more and more companies that are Java based, are Java shops, are reaching to this maturity level where they actually want their to get their Java workloads up and running. The the main reason why I'm building this integration is because we want to make sure that

1:01:49 for these teams, we just made their life easier. We're just not adding crazy new tools and new workflows. They just gonna keep doing what they're doing, building applications in the same way, and and just running these applications in Kubernetes. So what I did before is just run the application locally. What I will do now, if you don't mind, I will just use kind to create a cluster. K. Create cluster. Right? So that's for people who doesn't know, I guess, that they you know, like, just the local Kubernetes cluster. Right? Yep. Pretty simple stuff. When you use the Dapr CLI, again, we

1:02:19 Installing Dapr Control Plane (Helm)

1:02:21 were using Docker to start what we call the Dapr sidecar. That's the sidecar that will be running very close to your application with all the APIs. Right? And when you're running in Kubernetes, it's a little bit different. What we do is we install a control plane, a Dapr control plane into your cluster. And that control plane will be looking for all the workloads that are running in the cluster that contain some annotations and only enable those workloads with the Dapr APIs. So let's just do that, I guess. Let me install let's install Dapr. You install the Dapr control pane using Helm.

1:02:55 There are a couple of different alternatives. I think that we have an operator that was created for OpenShift that you can use as well, or you can use the operator for any other kind of clusters as well. So this is basically installing, you know, a health chart that contains all the Dapr control plane components that are looking for Dapr workflows and Dapr workloads and also connecting the component definitions that we have. So what we just did is that just created a new namespace, and a couple of components are running inside these reports. Alright. So that's the control plane. Right? Like,

1:03:36 there are a bunch of things running in there. And one of those things, the one that I wanted to show is this, like, this this thing that is called Dapr sidecar injector. This is basically that controller that it's looking for workloads with certain notations. When an annotation is detected, that basically means that we need to go and inject the sidecar to that application. So to run the same service that I was running locally into a Kubernetes cluster, of course, I need to create a container for that Java application. I already did that. And then the other thing that I wanted

1:04:06 to do here is one more thing that it's kinda important. It's installed Redis right, in my cluster because I want to use Redis now for the for the key value store. So I would just run this helm command to create a new Redis instance. Pretty standard stuff. As we discussed before, David, this can be PostgreSQL. It can be any of those, you know, implementations that were shared there. Whatever you want, you just install one, and then you just need to configure Dapr to understand that this is the thing that you want to use for your for one of your estate store

1:04:11 Installing Redis in Kubernetes

1:04:38 implementations. And you do that by doing something similar that we did before. Let me just refresh that. This case, I'm saying, you know, I have a new state store called t k k v store, and it's using Redis as an implementation. That's the URL of the service that it's running inside Kubernetes. And when you install the Helm chart of Redis, it creates a secret that contains the password to connect to that specific instance. Right? So we'll just apply this state store, and now I have my key value store Dapr component created. That basically means that whenever I want to

1:04:41 Configuring Dapr State Store Component in Kubernetes

1:05:13 use the state stores APIs and I'm referencing this specific state store, I will be using Redis for storing my key values. So I have everything now in my cluster for running my application, and I have Redis running. It's up and running, so that's pretty cool. And the last thing that I need to do, and I think that I can show this in Versus code, is that, basically, I need to deploy my application. Right? So I've created a container with the same application that I was running before. I'm configuring, you know, an environment variable with the name of the key value store that

1:05:34 Deploying Application to Kubernetes (with Dapr annotations)

1:05:43 I want to use. And then I have a service for the for the deployment so I can send request to this to this application later on. So let's just do that. Does that make sense, David? So far? Yeah. Yeah. Something that you want to ask or perfect. No. Let's deploy that. Sense. Yeah. Cool. Cool. And, of course, this probably will need to fetch the container from Docker Hub at some point to the cluster that I just created. And you will see that, yep, there you go. So we have, like, the customer service being deployed. And as you can see here, Dapr, the

1:06:19 Dapr control plane detected that my my application requires Dapr, and that's because I have these annotations here in my deployment, which basically are saying that, yeah, I want to enable the Dapr for this application. And then my application identity is customer service in this case. Right? So if somebody wants to call, like, the customer service application, needs to go with using that name basically later on. Remember that we saw some, like, service discovery and service to service invocation functionality? Well, that's the ID of this service now. This is how you kinda, like, define that. I guess that it would check now. K.

1:06:55 Debugging Application Deployment in Kubernetes

1:06:56 They're like we're having restarts there. That basically means that I messed up with something somewhere, which is kinda funny because I just tested this, and it was working. This this should go out tomorrow for a blog post, but let's let's do this. And if it doesn't work, that's fine, but I just wanted to show it working. Let's see. So the application is running correctly, so I'm guessing that I configured something wrong with Dapr. Oh, no. Let me see. Oh, it's running now. Yeah. So, basically, something not being connected and for some reason restarting. Let's see.

1:07:28 Application Running in Kubernetes

1:07:32 Yep. Now it's running. Okay. Perfect. Pretty cool. The last thing that I want to do so now remember, now we're we were running the application before locally as a developer. Now we basically deploy the same application into a Kubernetes cluster that has the Dapr control pane installed, and it has Redis. And it also has this resource that it's called component here that we call we call it k kv store in this case. Right? That's all all we need. And then, basically, when we configure the application to use the state store APIs, we just use that string

1:07:37 Accessing Application and Testing State Management in K8s

1:08:05 to make reference to that specific key value store. That basically means that you can have tons of different key value stores and then just make reference to each of them using kinda just the screen. And to test this, basically, we can do use CTL or forward, right, just to access the service. That's my service up and running there, and I can send exactly the same requests that I sent before, to the service that's now running on Kubernetes. Right? So now this is just running on my cluster. It might take a while. There you go for the first request.

1:08:39 But as soon as I send these and I get the 200, that basically means that, of course, that my service worked, but also that the service that it's using the state store APIs is working, and this data is stored in Redis. And I can just call the other request, cancel another request to get the HTTP, to get the customer by ID. There you go. So we have configured the same application that we were running locally into a Kubernetes cluster with maybe different back in back in services in this case. Like, for the local environment, we didn't even knew if we had Redis

1:09:02 Recap of Kubernetes Deployment

1:09:13 or something in memory or maybe even using kind of Postgres or something different. But for the environment that it's running in Kubernetes, we are using Redis, and the APIs are working kinda, like, in the same way. Hopefully, that makes some sense. I know that I rushed it a bit, but, hopefully, it kinda, like, builds up on the things that we were talking before. No. Definitely made sense. Answered a few questions I had. You know, I I like that we can deploy multiple versions of the let me get this back onto big face mode. I like the way can deploy a

1:09:44 postcards in the Redis and have multiple keys value stores, and our applications can packages the ones that make sense for the data type of restoring and then Dapr just layers on all of this extra simplicity to build and distribute applications, which, you know, again, I said at the start, it's something that we need. These these things are hard to build and more opinionated ways to do things. So little Dapr's opinionated API, but so flexible in the back end. I feel weird even just saying as opinion, know, it's it's it's nice. I think we need more stuff like this. So Yeah.

1:10:16 Final Thoughts on Dapr Architecture

1:10:16 Yeah. My my my hope for this is that the APIs becomes more robust over time. Right? Like, we add more and more and more functionality that it's being used by by people, more and more people in production, and for building more complex software. Right? We have a lot of people using the Dapr project, but we want to hear more about kinda what people wants to do with this. And, you know, if you have any questions or any follow ups, feel free to reach out. Alright. Awesome. Well, I'm gonna give everyone that's watching the two minute warning. If you do

1:10:47 have a question and you wanna answer, drop it into the comments now, and I'll throw a question at you while we we we wait for a minute or two. So you're now working for the company behind Dapr and Dagrat. Right? That's correct. Yes. You wanna what can you give us on, like, a roadmap? Like, what are what are you focuses on on a company? What's coming next for Dapr? Is it just languages? Is it maturity? Is it new APIs? Like, what does the next twelve months look like if you're if you have that information? You know that twelve months, it's it's pretty

1:11:01 Dapr Roadmap and Future Integrations

1:11:20 a long, long, long period of time in this industry. So tons of different things can happen. First of all, I'm working, for this, company that's called Diagrid, and it's not the only company behind the project. Right? Like, we have a lot of different companies participating. We have a very, very large community of companies building on top of this, including Microsoft and a bunch of other companies. So there are tons of things been happening in the community. In my specific area, I'm really looking forward to build some integrations cross cross communities using different projects. Because I'm interested in in, you

1:11:52 know, in, like, in the developer productivity space and developer tools. I think that I will be doing something around open feature, which is feature guidance. I would I would love to have, like, the API just to consume feature flags straight away from from the Dapr, you know, SDKs. That's something that I've been looking for a long time. And also because I was working and I'm still working on the k native project, I want to make sure that you can build very, very robust functions and try to build that kind of, like, Lambda experience where you can connect to infrastructure

1:12:23 pretty easily from different functions. And, for that, I'm just basically collaborating with, the project and also, they say, Chinese led project called Open Function as well. Yeah. That it's using Dapr and, you know, and and just merging a bunch of technologies that I believe that that's kinda it's pretty cool to see that they are, like, just gluing up a bunch of projects together, that it's not easy. But what I see I see there, it's a lot of opportunity to build more complex use cases and to highlight the functionality of all of these projects working together.

1:12:54 So, yeah, that's kinda like what's coming from the open source side of things. From, the company point of view, we announced at KubeCon, a new product, basically, which is some kind of, like, a Dapr as service kind of thing. Right? Like so you have the APIs in a managed service that you can just interact from your applications without running Kubernetes or Dapr itself to just interact with some APIs that you create an account. You have the APIs just to start building applications. And I think that's a pretty powerful thing. And I will Sorry. I don't mean to cut you off. Please

1:13:00 Diagrid's Managed Dapr Service

1:13:28 finish. No. No. No. Go go ahead. I think that that's pretty much it. Well, I I really like all of these, you know, very easy to consume functions as a service serverless platform. Not so much Lambda, more specifically, what Fairmain are doing with Fairmain cloud and web assembly, what Cloudflare are doing with workers, you know, Firebase functions. And I guess with a managed service Dapr and it's providing state storage and stuff like that. Like my serverless functions can be fully fledged applications and speak to these APIs and they could be, you know, have much more features

1:14:03 in them that would necessarily be difficult or would have been or I can't speak. Would have been harder or more difficult to do without such a service. Is that something you see you see growing, I guess? Yeah. Yeah. %. Right? Like, the idea here is that no matter where your applications are running, they can always access these APIs just to implement things against any infrastructure. So we we give you two things in the same way that Dapr is giving you. Right? Like, we give you the APIs, but also the possibility to configure the back end

1:14:16 Enabling Richer Serverless Functions

1:14:33 infrastructure if you want to. If not, we will give you some implementations that are there going to be very opinionated to the service itself. Right? We will say, you know, we know how to manage this implementation like this technology, so we will give you these APIs with this backing implementation and just focus on the using the APIs. Nice. And that opt that open ups the doors to, you know, like, if you're running on Google Cloud Run or or or Lambdas or whatever just to know that, you know, no matter what you're running, you just can

1:15:02 connect to those APIs. And the nice thing is that we are fully compatible with the Dapr project. That basically means that when you create a Dapr client as we did, you just put, like, an API token there. And and just like the URL, now it's not going to be localhost. It's going to be the remote service. There you go. Nice. Very, very cool. Well, we have no further questions from the chat. So with that, I'll just say thank you. I think we definitely need to schedule another session in the New Year where we try and generate a GRPC

1:15:21 Conclusion and Call to Action

1:15:33 client and rust and do something really cool. But I'll catch up with you about that after the holidays. And any final words or anything you want to share before we say goodbye? I think that, for me, it's really important to tell people that if they are open to contribute, you see that, like, this project is very polyglot. So no matter what kind of experience do you have, if you want to contribute with the SDKs or the project itself, feel free to reach out. If you are interested in in testing these new APIs that that we are building at Diagrid, also, need

1:16:03 a lot of people and a lot of eyes looking into these APIs and to the service itself. If you go to diagrid.io, you can just actually get kinda like like, trial account and just give it a try as well. And if you have any feedback, please feel free to reach out. I'm always open and happy to help people. Awesome. Thank you so much. Alright. With that, I'll say you have a wonderful day. I'll hopefully speak to you soon. Thanks to everyone watching. We'll see you later.