ASP.NET Community Standup - Dapr + .NET

[Music] [Music] do [Music] do [Music] [Applause] [Music] all right here we are welcome ryan hey john great to be back glad to be back on the show great to have you on i'm doing well so this is crazy you are actually on site on microsoft headquarters i'm actually on campus wow and you said you've seen like two people there i've seen a couple people nobody i know it's it's a little crazy my house is a construction zone right now i was telling john earlier so it's like i can have quiet or i can have good wi-fi at home um pick one so i'm here to pick two for the show and and you have your run of the place so that's nice i am in charge i'm actually in control of this whole building um that's what they told me when i came in but wow yeah it's it's it's it's different it's different being here when nobody's around yep oh man cool well as we always do i'm going to start with the community links so we'll jump right in and then i'll pass over to you and we'll hear about we'll hear about dapper which is exciting so okay here we go so here's our community links as always i share these out i will go ahead and share the links out on the stream wonderful okay so let's dig right in uh first of all i have a cool one this is uh scott hanselman sent this over to me so this is a full hour deep dive into authentication and authorization on uh asp.net core so um so pretty neat stuff this is uh it's like i'll just i'll just kind of jump through but a lot of hands-on coding so this is not a slide heavy demo this is a deep dive so really good stuff yeah off is one of those things you could definitely need an hour long deep dive on exactly it's you can scratch the surface with file new project and hook stuff up but to really kind of go deep into authentication authorization there's a lot there i've actually got a few um links this week i'll be sharing on that so uh unjust auth stuff um so this is a fun one uh john is doing a he's using blazer and docker and he's containerizing a web assembly app for 3d printed robot arm which is just crazy so i had to share that that's just what's fun with this is he does he's like got his whole parts list he shows the whole build process he's got you know i mean it's just a wacky fun exciting post so this is hands on and then ending up running all the stuff with docker and serving everything with blazer web assembly so i don't know just have fun stuff and of course ending up with a neat video so uh good stuff there got a few more here let me see um this is interesting this is a just a reminder that with a web api backend you can front anything and ethereum you know there's all this crazy hype over all kinds of you know i don't know blockchain related stuff ethereum is interesting because it actually is designed you can use it for storing information right and so it really is designed kind of as an application back end and it's so this is cool this is a multi-part series and here's the specific part where they're using smart contracts and a restful api and using that as a front reach uh building out to um support mobile applications so here they've got a multiple front end application and as you see here this is a full you know blog post series so very very cool stuff from huan um okay back with a few authentication authorization stuff so um uh i see a question in the chat can we can we have the link so i shared earlier you'll see a link that says the url list and that has all these links and then i'll share it again at the at the end of this so it's got all all the links rolled up uh this is one barry doran sent over to me we've been sharing a lot of surveys it's it's that time in the microsoft development process series where like we release stuff at the end of the year early in the year we're figuring stuff out right we're deciding what we want to build and how what our priorities are and what your priorities are so um so this is a nice short one-pager survey on what's important to you for authentication nice so yeah i saw that i saw that pop up on twitter and i kind of wanted to do it just to mess with barry and then my better my better instincts took hold usually with those they have a they have a question at the front that says are you actively using you know whatever this feature is and if you say no they just say thank you for your time they beat you out yeah no this one you can go through and fill it out and you do have comments section so you can say hello to barry for us so yeah good stuff and you know really important like figuring out what what's yeah what works and what specific types of types of applications you're building you know do you want us to invest more in like pwas or server side or client side etc yeah i mean i can say from experience working on net libraries it's we put stuff out there and we don't we don't know what people are using it for we don't know if it's great i mean we know when people log bugs but like we don't often know what's missing and these things are a great way to stay in touch so leave barry a heartwarming message if you do this will do yep uh okay more on off stuff so this is digging into azure id with asp.net core um so this is from damian bowden damian bowden has just he's been a champ blogging all kinds of stuff over the years and lately digging into uh into off stuff um so i love his posts he um you know they're very uh like plenty of code there's always a link to the repo and then one thing that he does that most people don't do is he'll go back and update the code over time which is pretty cool so here is showing um setting up app roles and this is one of the powers of azure id but it's also um can be confusing to understand how to do it they've been doing a lot over over the years to um simplify the integration with net but it's still something where you you'll kind of want to understand um this is really powerful because it decouples the role assignment and it kind of puts it in a place where somebody that's an azure id administrator can go in and can assign people the roles and it it doesn't affect you as a developer so that's that's nice so here it goes through showing a signing of api permissions exposing the api endpoints um you know assigning different people to uh to groups etc and you know then building out the code that's going to integrate that in so very cool stuff and as always we get down to the end and we'll have links to the code and stuff so great stuff part of the reason i shared a post from damian bowden is because he is also doing stuff out in the community and this is cool here he is a tech reviewer on this book so jurgen has been writing this book over time we've actually i think featured some of his posts on the community stand up what's cool is here he's compiled this into a book and update it all for net 5. so this is focused on customizing asp.net so this is all asp.net core and customizing things like logging configuration you know tag helpers all kinds of stuff so um that's something that came up a couple of weeks ago when we talked to the um talk to damian and david fowler about asp.net core and it's got all these extensibility points and a lot of them are not super well known and sometimes not deeply documented and so it's cool to see books kind of filling in some of that stuff yeah it warms my heart to see um see hosting and routing on there and i i'm amused by routing coming last [Laughter] at least from my experience one of the community's favorite things to mess with but also a good way to blow your complexity budget yeah that's true um it is really cool like endpoint routing um simplified so many things but it also there's there's kind of more to understand and yeah it's very con it's very conceptual whoever created that as a mad scientist we'll have to get them on the show some yeah sometimes yep um cool all right a few blazer ones so we've got a few more blazer ones here we've got uh wrapping js object references with blazer web assembly so uh christopher's digging into this what's what's nice when you're working with blazer it's cool that you can write stuff in c sharp you can create your own libraries you can you know do you can create new things but you also can use existing libraries and so you know i i love seeing these things where where people will take a javascript library that's already tested it's working well and just wrap it for for use so uh so here's you know just talking about that understanding things like ijs object reference um you know talking about like just understanding wrapping it and you do get into some things where you're doing things like passing in parameters and you're dealing with return js objects and stuff like that so just understanding some of that stuff for the wrapping and the kind of interaction back and forth the really cool use case that i've seen with ijs object reference that i think is pretty new is is dynamically loading scripts and that was one of the big that was one of the things with um blazer 1.0 or you know blazer 3.0 or whatever you want to call it a blazer at its initial release that was one of the things that just really didn't sit right with folks was that it it if you want to pull in all these different component libraries you have to go like pull their javascript code into your code and hard code hard code you know if you're using five component libraries you have to hard code that you're using those five scripts and that just really didn't sit right with folks because it felt like a big step back compared to this modular component framework so it's really cool to see that it might seem like a small thing but i think it's really going to make people happy and make the make the learning curve a blazer a lot easier because all the places where they touch was always a little complicated to teach people yeah yeah cool um let me see a little bit more on blazer so andrew lock who's on here pretty much every week but yeah just write so much machine so he's been doing a series on pre-rendering with blazer um and one of the things to understand with that is looking at what are the actual routable components you may have components that are written in your code but are not actually referenced they're not routable anywhere and so he talks about how you can actually go through and and find that so that you can statically pre-render them so you know he does a recap talking about some of the things he's been blogging in his his recent posts and um you know illustrate some of the points of things that you may have you're going to want to pre-render stuff you know is going to be displayed stuff that is not going to be displayed you don't have to pre-render it it can still be you know servable by your application but it doesn't need to be necessarily pre-rendered so he goes through some things and and shows how to how to find those and what he settles on here is using reflection so he's going through and using reflection to go through and find all the routable components so pretty good stuff and of course as with anything there are limitations and he talks about some of that all right a few more blazer things uh so we've got uh dave brock a few things here one is he's looking at signed http http exchanges which is a new thing and honestly this is something i have not used and and was um you know just looking at but the idea here is using cross-site cdn caches he talks about you know the value of doing that and signed http exchanges and able to to um allow for it for those uh cross cdn communications um here's the thing i always look at and this is a you know not well appreciated site but i love canius.com and there's so also some similar ones for things like mobile um and you know things that will go through and say like well what's the actual browser support so here we do have support in edge and chrome it's nice having that shared chromium um core now for edge uh so and and so you know you're still not you still have issues like with safari but but overall i'm starting to get some pretty good support so um worth looking at uh one more from dave rock so this is on uh style isolation with blazer css so this is i think really cool um css is amazing but it's also you can get you can get into you know maintainability issues when you have a ton of rules and you don't know what's used where um and especially as you're building components with blazer you want to really scope that down and so css isolation helps quite a bit with that so so you know blazer is set to build that automatically and then um it uses this kind of uh syntax and when we had steve sanderson on the show he said that was that was um you know learned from other component frameworks that do that so yeah interesting stuff okay just a few more here we've got jonathan shannon um writing on tracing in asp.net core and talking about open telemetry uh open telemetry really useful for when you're building more complex systems um including ryan probably stuff like like that you work with with dapper right so we'll see a little tracing today wonderful yeah so i've actually got two posts on on this that i'm sharing today so um jonathan digging into doing this with carter which is a really cool um system he's built been building over the years um and so uh you know just talking about integrating in open telemetry and being able to understand the entire stack you know as things go through all the way back to you know from browser all the way through your service layer and into your database so we've got one more here so this is uh muhammad raham saheed and here he's talking about open telemetry and asp.net core um so you know just talking um here this is a three-part series and in this one he's digging into optimal configuration um one thing that i always like about his posts is he he talks about he gives an opinionated view um so he's been building you know frameworks and and things over the years and you know he'll share here's here's all the different things you can do and here's how i like to do it um so uh here he's talking about you know here's here's optimal configuration in his point of view so i've got one more link and that is one that you sent me over today which is exciting so using tie with dapper and we'll share i'll share all these links back out again um but but ryan why don't you dig in and tell us where what's the deal with dapper so uh we're gonna be well do you want me to just go ahead or do you want me to talk about this page whatever you want to do the floor is here i want to call this out we're about to talk about dapper i mean that's why i'm here today but um i want to say i want to say with this um with using tide with dapper i wrote this little baby page um and one little baby example like maybe nine months ago and the sith came through one of the community members came through and really punched this up so there's like three or four samples now there's a lot more information it's way better i i was really happy to um i've been working on dapper and some other projects for a while now and i was really happy to sort of go away for a while and then come back to this and say okay let me look at some of the documentation that i wrote nine months ago and see that it's way better because somebody took the time to make it better so that made me really happy but that's all i wanted to call out with this if you're curious about the things that you're going to see today then and you're doing.net this is probably where you should start cool well how about i'll take it away then you're you are muted john thank you so we've had you on the show before but you're actually on a new team now i am actually on a new team it's it's been um i looked uh because i keep i keep all my presentation materials in a git repo and it's actually been 11 months since i've been on the show which for me is like a shocking amount of time to not not be on community stand up but i'm i'm actually on a different team now i'm part of the central incubation team in azure so i work i work with a bunch of different folks across azure um mostly still doing programming model deployment microservices open source kind of tech um in consultation with a bunch of folks across azure i can't really talk about my project that i'm involved with it's still still in stealth mode unfortunately so i can't really talk about it it'd be great to come back in a couple months and maybe talk about it um i'm also a maintainer on dapper which is another project that came from this team um which was what i'll be talking about today so it's been an interesting journey because i moved um i moved sort of at the beginning of of covid to this other org and so i've been getting to know um teammates and collaborating with some other folks uh the whole time we've been in quarantine which is pretty cool i was wow mentioning earlier it's like there's like two people on my team that i've met in person ever and i think that's the situation most people on the team are in right now so that's kind of cool but as far as dapper is concerned this is a project that i got involved in early on because it it came out of the incubations group in in azure and it's not really an azure specific technology it's more of a general microservices distributed systems kind of technology and they came to us just like they came to some other teams at microsoft and said hey we want we want help building a great.net experience for this do you wanna do you wanna help um and you know my role on the asp.net team i said this seems like a great project for us to be involved in and so i got involved and started helping um and it's really it's really grown and taken off since then you know we've had a lot of open source adoption there's some discussions happening with other cloud providers about it um lots of people have been contributing integrations both with azure aws gcp different cloud platforms different other technologies and this is this is spinning off and is on on track to become open governance open source projects so when we talk about that we mean something that's not controlled by microsoft and actually has in the rules of the project that microsoft can't control it um once it becomes mature um and the hope is that we're really building this for everybody so i'm going to be focusing on.net today because this is a net show but this is really a project for everybody any cloud any programming technology um anything you want to do in the avenue of microservices so i'm going to share my screen and take it away i've got a couple slides but i'm going to try and keep it short i feel like some i feel like some slides here are a little bit helpful to sort of get the gist of what this is and then and then we'll just we'll write some code and and do some q a so all right so i'm talking to you about dapper um you can find me on twitter i i have not uploaded my presentation materials from today uh but if you want to see them they'll be up there in a couple hours um whenever i get stuff cleaned up and push it to my repo you'll find it in the 2021 folder so i'm here today talking to you about dapper and dapper is really a uh we call it the distributed application runtime which is where the name dapper comes from but it's really this uh runtime engine for building microservices on cloud and edge and we'll talk about we'll talk about what's in that engine in a second so you think about the kinds of things that are hard about microservices this isn't an exhaustive list but some of the things that are hard about microservices and modern cloud applications as a whole so you know some people don't like the word microservices but i think it's also fair to say today um there are very few scenarios where you're just writing a three-tiered app usually usually you got aspirations to do something else so if the term microservices doesn't fit you um just think cloud native app or cloud app in general right so some of those pain points are like well you got to integrate with a bunch of stuff right all the services that you want to use all the third-party apis you want to talk to if you're doing eventing if you need a cache if you need a secret store those are all things you have to integrate with and we find that for developers and for teams building designing applications you have to make your choice or make your commitment to what technology you're using pretty early and results in coupling in your code so if you want to use redis because you need some place to cache ephemeral data or some key value store that results in you having a dependency on redis and having a redis sdk in your code and getting to know and love that redis sdk now i happen to know that stack exchange redis is great because you know the nick craver and some of the other people that are involved with that just do an awesome job but um maybe all the sdks you need to interact with aren't great right um maybe maybe there's a dependency you need to use that doesn't have a great sdk or it doesn't give you a good experience or you can't run locally for instance um and that also gives you lots of different things to figure out how to support uh tracing configuration secret management those kinds of things sorry but just just to jump in i think that's really key is that whole like getting set up to run locally and doing all the setup stuff and the secret management and hooking things together that's a huge part of it like i think people jump right to thinking about the deployment complexities but actually the getting started developing and how long does it take a new dev on your project to get set up that's a huge like it's great to be able to pull in redis and and you know different all different kinds of services and and um you know like all all these different sorts of things but then it also complex complexifies things it slows you down in some ways too your life your life can be pretty complicated then what if you need to use something that doesn't run locally or doesn't have a you know an easy getting started solution like it can be a real bummer but the fact that it's your codes problem to support all this stuff means that you've got to make that decision pretty early in your development process so um i had a clip but we cut it because i didn't i we couldn't get the sound to work but basically the you know how how i would think about this is is the homer simpson approach can't somebody else do it you know and i was going to play that clip from that great episode but like you know i have to do all this stuff to get these services integrated with my code well can't somebody else do it and that's really that's really what dapper offers so the way that you could sort of think about dapper and what it is is a technology its identity the main idea is can't someone else do it if we need to interact with a state store if we need to do pub sub if we need to trigger some blob storage or you know send an event via twilio like can't someone else do that for me can we take all these dependencies and make them into a configuration problem and then the way that that gets done is basically your application code written in any language is layered on top of either an http or grpc api and you're just talking to adapter process so i'm going to use the term sidecar if you're not coming from the kubernetes world that might be new to you and that's fine but i sort of think about this idea of like a sidecar is maybe not the best way like like maybe like a like a buddy or like a twin or i don't know like a pet like what's the thing that's gonna follow you around and help you do all the things you have to do so basically this idea of let's run another process uh next to your app let's push a bunch of complexity into that other process and out of your application code and then let's give you abstractions for all these concerns and a well-documented set of apis to talk to them and then when we look at all the things that your your code is written in here application code microservices code written in in addition to those raw http and grpc apis we also have sdks for a lot of these languages so the ones that are the sdks that are going to be going 1.0 pretty soon for us are go python.net and java php is a really interesting one that's very cool um the the maintainer of the php sdk and the main sort of uh person behind it is somebody from the community who approached us and said hey i work on wordpress and it'd be really great if i could leverage all these kinds of things in my wordpress application wow which is a pretty unique perspective because we don't we don't really think about wordpress as like microservices right but what if your wordpress application could now respond to pub sub what if you're what if your wordpress application could host actors or could interact with state management or all these other integration points and it's it's really kind of cool to rethink some of those things and uh how much you can do by having this shared core that runs as a separate process and then this very very thin layer backed by abstractions that lets you talk to all these things uh there's a there's an interesting quote here seeing this as an orm for third third-party services and i think at a high level that's kind of interesting to think about it that way yeah i think it is it's it's sort of like um a lot of people ask the question too with this um you can you can always tell who's the who's the the biggest the biggest architect the most architect architect in the room um will will always say well what if the abstraction fails what if the abstraction doesn't do what i want what if i want the ultimate bare metal performance is always one of the questions that comes up with dapper and the great the great answer is well nobody's requiring you to do any of these things so like if you need the absolute best performance from redis because you're totally bought in with redis like maybe don't use dapper for that but hopefully there's still something here that's going to help you so like you don't have to use all these pieces you can use what helps you and there's a lot of there's a lot of things so it could be something simple like i want to upload a file to blob storage or send an email via sendgrid like any of those kinds of things i think i think that is a good way to think about it it's it's nice with that sort of thing too to have kind of a just-in-time complexity approach where for maybe like let's start with assuming that we're going to be able to use redis as as you know like at the simple layer and that's going to work for most people and then if i do need to go in and like tightly control everything and host it all natively and communicate natively i can do that when i need to but let's not assume i need to in most cases you don't yeah and one of your one of your examples like you can you can swap i mean you can choose to sort of take a dependency on the semantics of one of these state stores or i'll just use state store as an example i mean no abstraction is perfect like you could choose to use redis for local development because it's really easy and that's that's the path that we send most people down and then you could choose to use something like a like a sql server or like a table storage in the cloud um because that's a better fit for what you're doing in the cloud like table storage is one of the most affordable azure services right i think i i don't know the exact pricing but it's probably cheaper than redis i'll assume that somebody will cr correct me if i'm wrong um but like maybe you're using redis for development and you're using table storage for the cloud because it's just a little bit easier those kinds of things become possible or maybe you're using service bus for messaging in the cloud and you're using rabbitmq locally because that runs really easily in a container all those kind of things work and that's the beauty of having an abstraction so this is just a list if you go to the the dapper documentation site you'll find you know all this and more and the great thing is that a lot of these things are community contributed and community maintained so the team has actually built fairly few of these i think the team has built a couple in sort of every category to make sure that we've got the abstraction right and uh most of these have just been have been contributed by people who either work on that product or are interested in having good support for it so um like i know um some of the folks from alibaba have been involved with us and they've been working on this alibaba blob storage binding um and it's cool to see you know community come together around different clouds and different technologies and those kind of things so check it out so in terms of architecture this is just a i'm not going to spend too long on this diagram but um this is sort of how to think about it right like every every one of your app processes has a sidecar they're not very big in terms of size they're pretty small in terms of memory they're like 10 to 15 megabytes of memory depending on the load and they don't really require a lot of care and feeding and you're basically using it as a proxy for accessing all these kinds of things as well as you can use it as a proxy for talking to your other services which can come with some benefits so a lot of people when they see this or when they hear about dapper for the first time they will sort of trip out about this idea of like well what about the cost of running that extra process what about the cost of that extra hop in terms of networking and the answer is that it's really it's really not that bad like if you're if you're in the millions of requests per second or the you know hundreds of thousands of requests per second per node category you already know what you're doing and you know who you are if you're not in that category it's not something that you need to be super concerned about and i would just think about like if you're running on a kubernetes or another you know hosted container pass or something like that i i can promise you there's a lot of network proxies that are in between your app and the internet um that you probably don't know about or probably don't think about you know it's it's definitely the case with kubernetes a lot of the time when you're doing networking and kubernetes you're talking through a proxy um so you're kind of already you're kind of already there in a lot of these cases you know if you're used to running on bare metal and vms you might not might not think that that's the case um and it may not be the case for your specific scenario but it largely is for the cloud there's there's often a proxy in between you and whatever you're talking to and it is not in practice a big source of issues so a couple of questions came in one one was about service fabric support sure so i've i have not heard anything about service fabric support i think you know people always are very optimistic that we'll come to um we'll come to a call like this and make announcements and um i i always love the optimism it's great um if when we have something to announce you hear about it um i think the jumping forward a little bit the the question is always what's the best place to run dapper um the best place to run dapper right now is um with some kind of container management system if you're if you're orchestrating vms or something like that or if you're you're doing like a docker compose kind of situation that works pretty well a lot of folks are doing that or on kubernetes i'm not going to announce anything today about service fabric or app service or other azure sorts of services i'll let all the product teams do that in the future it is something that's being worked on and thought about for different services i'm not going to share specific plans and let product teams announce that so if you're not quite you know if you're not quite in this space of kubernetes and containers this might be something you just want to think about and learn about right now but we're we're aware of the feedback believe me cool uh one other question is how this compares to istio sure so um service mesh versus dapper is always one of those big questions that comes up right um and the way that i would sort of think about surface match versus dapper um if you're not if you're not hip to the lingo service mesh is usually like an l7 proxy layer 7 proxy meaning it's going to understand and proxy your your http requests or your grpc requests whereas dapper does a little bit more so when you're thinking about sending http to another to another container of yours or to another app of yours that feature sounds a lot like a service mesh right because dapper is going to give you a lot of the same benefits for that case so if you're using dapper as a proxy to talk to your other service you're going to get mutual tls you're going to get tracing and observability by default and you're going to get a built-in you know service discovery basically name lookup feature which is something that service meshes also also do what service mesh is also don't do the dapper does is well service meshes don't have any concept of state stores right because they just do proxying of requests service meshes don't do pub sub because they just do proxying of requests service meshes don't have these kind of bindings and integrations because they just do proxying of requests so it's a comparison of a pretty narrow slice of dapper's functionality with the whole raison d'etre of you know another another product in another project or something like istio i think the other thing that's a big difference between these two is service meshes rely generally rely on the ability to get inside your container and change the networking environment of your container such that they can hijack all your traffic and handle it themselves and service meshes are really optimized for giving you the user a fine grain development over or fine grain control over how that traffic is shaped and how that traffic works if that's something you need it might be a great fit if you don't want to spend some time on the sort of care and feeding of your service mesh it might be more to bite off than you really want to chew for something like that in terms of how dapper works it doesn't it's not intrusive in your container so it doesn't get into your container and change the networking environment and i always sort of like to ask the question um and and somebody who who loves service meshes is probably gonna give me my comeuppance one day but like when you when you're using service meshes like what do you do when you're running locally like do you get to run the service mesh locally is it part of your development process like how does that work um dapper has sort of a clear path and a clear way that it works when you're running locally which we'll dig into in a little bit but it's not intrusive in your container it doesn't hijack your network traffic it has a scheme for how it orchestrates the communication so if you don't want something in between you and the thing you're talking to it's not there um you opt into that sort of model and it's probably not going to offer you the same depth of configuration and complexity around how that traffic flows as a service mesh would and depending on your skill set and your point of view you might view that as a good thing or a bad thing you can also definitely use service meshes with dapper so there's no reason why it has to be an or question you can use a service mesh for all your http traffic between your services you can use dapper and a service mesh for all your http traffic between services or you can segregate the functionality however you want so there's a very narrow slice of functionality that overlaps between the two okay so just in terms of service invocation just to speak to it like um you know in this example the python app wants to invoke the node app it crafts a url like this that goes through dapper goes to another dapper instance the dapper instance that belongs to the node app which then will proxy the request it sort of reinterprets the request into the url scheme of the node app and then comes back you know via the reverse the reverse flow as far as crafting these requests and getting this url scheme right that's sort of where the sdks enter the picture and can make this really easy if you want to use it or you don't have to use this it's just one feature that dapper has another one of the the building blocks that i just want to highlight real quick with a diagram because this is something we will be talking about and looking at today is well you can publish events to pub sub like a message queue or any other kind of technology like that via this url so you do an http post to the dapper sidecar which again the sdks help make this really easy to get right and then the subscribing side on the other end is basically your app advertises what topics it wants to listen to and then dapper will call you back with a post so you get this pub sub experience over http and you can basically use asp.net core mvc to do message queues or carter to do message queues or anything like that which i think is pretty neat so a lot of these kinds of things bindings are another one you can do triggering based on events or do pub sub uh all based on http without any new sdks or any new technologies so in terms of how to run dapper i'm going to show this on a slide i'm not going to actually spend any time doing it because as done at developers we have a we have a better thing called tie but basically how to run dapper dapper comes with its own cli and if you do dapper run and then pass in things like configuration usually you just need an app id and an app port so what's the logical name of my app and what's the port i'm listening on which by default for asp.net in local that's going to be 5000 and then pass it a command to run which would just be done at run that's like a good way to run a single process i'm going to be using dot thai which is another great project because tai has good dapper integration but this is this is how the dapper docs will tell you how to do it as a dot-net developer you have a slightly better way and that's it for slides i want to okay show some code well just you know generally like i don't know if you're gonna dig into thai and dapper and how it integrates we've had tai on the show a good amount and so like some of the things you talk about like configuring like app discovery and and so like knowing where dapper and ty integrate would be helpful okay well we'll talk about that what i'm going to do first is i'm just going to run the app so we can see what we're sort of talking about here and then um we'll we'll dig into those and make sure we take some questions and make it really crystal clear so i'm just going to do a tie run i'm in this i'm in this directory that you're seeing in vs code and i've got three projects here so i've got a front end which is a blazer server i've got a back end like rest api which is my bank server and then i've got a bank auditor which we won't we won't see any of that first we'll see that a little bit later and i've done a tie run at the command line and if you're new to tai you can sort of think about tai as dot net run but for a solution and the other great thing about tie is you can include dependencies which is going to be super relevant in this case so i've launched tai it starts all those applications also start some containers it starts a bunch of other stuff we'll see and i'm just going to go ahead and open the dashboard so this is the thai dashboard and this is sort of like your your home page for tie shows you what's running and the really cool thing about this is is these so we talked about side cars and we talked about the need to have those processes well wouldn't it be great if tai could manage those and that's exactly what's here so this is a dapper sidecar with its logs you don't need to understand what's here i just want to prove that it's doing something it started running my three aspirin at core projects and it started running my three dapper sidecars as well as i have redis as a dependency and then placement is just another dapper service that sort of gets injected when you're using the dapper integration so let's look at what's in the tide.yaml since i just told you what what happened um so what's in here is this is my this is my tie.yaml and the thing that makes it do dapper is i added this extension so tai tai has an extensibility model i think dapper dapper and tracing are the only extensions we've got but i said let's do dapper i gave it a components path which is sort of like the configuration for what dapper is going to talk to and then a config which is sort of like what's the configuration for dapper itself we will look at that in a couple minutes but for now just accept that there's some configuration and then here in the services it just lists my three it just lists my three cs projects and thai because tyunderstands.net it knows how to run and containerize these projects without me doing anything else so i just have to say hey i'm running these three and then i've also added redis as a container and a lot of people the first time they see this they get confused and they think that time must have some special knowledge of redis the really cool thing is that it doesn't so i've just created a service called redis i've said run the redis container image that's literally what the said and i've said oh by the way it's gonna listen on port 6379 which is like the standard port for redis so i just basically said run these three projects run redis oh by the way also do dapper and then out the other end it's going to orchestrate all this complexity for me so you could compare this to doing dapper run dapper run dapper run three times as well as running redis in a container that's what tie gives me which is very powerful so i'm going to go ahead and just let's do a really quick demo of what's in the app i will embig in this so that you all can see so i've got a bank this is i think where steve sanderson does all his banking so i'll just log in i'll just log into steve um and then right now he's got zero pounds oh no count which is terrible um steve is the creator of blazer i'm sure that he got uh a million pounds for that so let's deposit some money okay steve's got him i like this bank by the way yeah it's crazy it's yeah it's the easiest bank it's like uh you know how they have those apps where you can scan a check and and you know they'll deposit it for you this is just like that but you don't have to scan the check and the check doesn't have to be real so yeah just deposit a million dollars and then i know that steve probably bought a bunch of gamestop stock so let's let's withdraw some money for that um and you know let's let's withdraw some more buy more gamestop stock you know surely it will go higher so steve's in the negative now this bank doesn't really care there's very little business logic here but but anyway um this is just my simple app um this is going and talking to that back end and then we'll we'll introduce the auditor service uh when that comes up so we talked about how to run this we talked about the integration with tai let's take a look at some code and uh this is this is the heart of this this is sort of where the magic happens or where i want to focus our attention and i'm not going to spend a lot of time on this because this is not a blazer talk but so i've got i've got my little form here for the bank account i've got some state that i need and then the three things that i'm doing here that interact with networking or interact with my other microservices i'm going to use http client to get jason uh get the basically the account status um this is pretty cool i found a found an interesting bug while building this which is it's always great to find a find an interesting bug when you're building something handling deposit i call deposit endpoint on some controller somewhere handling withdraw i call withdraw on an endpoint somewhere which is all pretty cool right so you're you're storing all the money for the bank and rattis is that i am i am right now so we'll take a look at that as well so notice that i just i'm just using http client here right um there's nothing really tricky happening i'm just using http client to talk to another service and the way that i'm doing this right now there's actually very little dapper involved um because the way the way i sort of like to think about it is you don't really build dapper applications right you build your application and maybe you use dapper so for instance i'm just using a vanilla http client here i'm using thai service discovery so tai has service discovery features um basically the fact that you know the summary of it would be the fact that i have an entry for bank server in my tie.yaml so i have bank server here means that i can do this i can say get service uri and it will give me a uri for the bank server that's tie service discovery in a nutshell right so that that is that is a feature that tai has in and i'm actually not using dapper to invoke this service at all i'm just using it i'm just using a vanilla http client with no tricks let's take a look at the bank controller and i am using a little bit of dapper here so i'm using the dapper state store and my state store in this case is redis now i'm not going to get into a lengthy debate with people in the comments though i would like to about whether or not redis is a good use case for this i think you could argue that a sql a sql database or some kind of rbdms is a better fit for this use case and i would concede the point because i think you're right but i still wanted an example of the state store so i think about the dapper state store abstraction and things like redis in general as being good for like when you need key value pairs or when you need to represent some rapidly changing piece of data and memory or those kinds of things your your caches your your hot data that sort of thing it's not really for your oltp sort of things i would still use sql server a traditional database for that but i'm going to use it in this case because i want to demonstrate some things about how it works and demonstrate some of the integration that we've got so i'm getting a dapper client i injected that from my startup here so inside my bank server application i just had to say add controller's adapter that will inject adapter client into my service collection and it also powers a couple features so there's some additional integrations with mvc that i'm not using here so for instance i could do something like i could say from state and model bind things from the state store as well which i think is pretty cool i'm not using it here because it's not a great fit for my use case but check it out if you're interested you have model binding of things that come from dapper that's one of the mvc integrations and the logic here is pretty simple so i'm going to get a state entry from the database and you can think of a state entry as basically like get this object and then give me an object that represents both the value and some other details about the state so this state entry has things like an etag for its freshness it has things like the store store name and the other thing that you can do with it is you can ask the state entry to save itself so it's kind of like an object-oriented way to do these sort of state interactions and i don't think that there's anything too tricky about any of the things we're doing here we're getting a state entry we're getting a state entry and we're saving it we're getting a state entry and we're saving it so this is all the kind of stuff that you might expect you could do with a with a database kind of thing or with a cache kind of thing and there's nothing too tricky dapper is using json in this case so most of the apis on dapper client sort of just assume json and use the the newer system text json serializer so you use this with types that are serializable to and from json most of these kind of cache key value store sort of databases really just work with strings or work with json or or simple objects or things like that so it's really a good fit for that use case and this is all my persistence this is how all this stuff is working well you mentioned jason we did have a question earlier about grpc and sure you know like does it are we going to be assuming rest and jason or you know how how much of this how how well do we work with grpc if we want to sure so i think the thing the message that i would give folks for grpc especially if you're talking about uh grpc between services there's really two messages here for grpc for services between your services i can talk dapper does not yet support working with the generated grpc clients and servers and i think when people ask about grpc support that's probably what they're asking for there are ways to do grpc with dapper for your services it's not as elegant as if we could support the generated um generated clients and servers it's something we're talking about that's on the roadmap it's not going to be part of 1.0 so it's not gonna be like in the next month we have it but i think we all agree that it's the best best thing we could add that we don't have right now um and so i'm kind of keen to see that happen um in terms of in terms of how to invoke your services rest and rest and json and things like that i think that there's a couple ways that you could approach that i think that jason is a good sort of starting point for right now if you want to build something and you want to use dapper you can do as much or as little rest as you want and i'm going to show i'm going to peel back the cover on what i mean about that in just a second but take me at my word you could write really simple rpc style apis and a lot of people really like that about about the client api the dapper surfaces but you can also write these rich restful apis and dapper's not going to get in your way so either of those i think is a good approach it's down to what you want for grpc i would say the best thing we could do is is if we can support um is if we can support the all the tooling and experiences that people already know about with grpc if you want to you can investigate what's there there is a model for doing grpc with dapper i would say come to your own conclusion about whether or not you think that's something you want to use because i think that most people ask about grpc they are thinking about generated clients and servers okay so so in general if i am using grpc i might use that between services or between things that i know are on my like on my network i control the profile i control all the stuff and i may just use straight grpc with that and use um dapper for more of the kind of i don't know like interactions with other things i may not control as much your other your other interactions with other services or your integration with a secret store or your interaction with pub sub or things like that i i think it's it's it would be a little bit glib it's a little bit glib but like i'll sort of say it i think it's easy to look at a technology like dapper and say if you're doing rest apis in sql server and say i'm doing rest apis in sql server what does this offer me and i think the answer is it offers you an easier way to do some things that you're not doing today but you might need to do in terms of making your rest apis and sql server better there's a couple ways i think the dapper can make that better mostly around encryption and observability but it's probably not going to change your life i think some of the things that offer you a lot of power that you don't have access to to do today are outside of the world of rest apis and sql server so i think as you look at building more cloud native and more micro services kinds of apps or you look at building systems that are event driven or triggered or need to integrate with a lot of different kinds of services that's where a lot of the non-obvious value is if you haven't tried building stuff like that and tried to use a like a truly bad sdk for something like it it just feels bad man so like i would think more about those kind of things um you should you should look at you should still look at dapper if you're doing rest apis or sql server but um i think the main idea is that it makes things a little bit better and it makes a whole lot of things a lot better but maybe not in the rest api and sql server category okay but speaking of rest apis in sql server dapper does come with a tracing dashboard so when you when you install dapper which i haven't shown yet and i'll return to you in a second um when you install dapper dapper will run a local zipkin tracing dashboard and so let's let's open that up so i've just got zipkin running here in a container and you can see that there's some there's some tracing happening here already even though i didn't like manually wire anything up and you can see that all of these calls to do with state um are getting are getting traced here which is kind of cool even though i didn't wire anything up and what i want to do now is i'm going to change this i'm going to change the my front end application to use dapper for its service invocation and see what what else we can do so you ready watch this i'm going to change this to use dapper so i will comment that out and this is how i change it to use dapper that's it i'm done whoa so what this is doing i i added this recently actually what this is doing is instead of my http client being a vanilla one um i'm creating a special http client and i'm giving it the logical i'm giving it the logical name this is basically the equivalent to this base address this is basically the equivalent to these three lines of code so instead of tie service discovery this is going to do dapper service discovery and this special http client is going to rewrite all the requests that i send to have the appropriate url format for them to use dapper as a backplane so something that i think is pretty cool about this is because under the covers it's just http and just the protocol you already know how to speak is all the integrations that work with http client work with this so if you're using refit uh if you're using floral if you're using gosh what's the other one resharp i pulled people on twitter the other day about what libraries they like to use with hp client if you're using any of the great libraries out there that integrate with http client you can just do this instead and now you've got an http client that uses dapper as its backplane so i didn't have to actually change any of this code if i already like these apis and i already know how they work i don't have to change anything to use these which is pretty cool the other thing that i would show you about this and some people really like this i think we talked about how to build um i think we talked about how to build apis if you're trying to do dapper and you really have a choice to build simple rpc style apis or if you have a choice to build these rich rest apis there is a set of functionality on dapper client and it's all named with like invoke method so these invoke method apis are really optimized for speaking the language and the terminology of dapper so you can see app id method name there's http method app id method name app id method name t request data right so these are really optimized for that simple rpc style where you're not going to use a lot of like headers you're not going to use a lot of really rich http uh kind of information and you're just doing very something very simple and rpc oriented these methods are going to work pretty well for that you also have the option to use http client which i think is pretty cool you also have the option to do things like this say i want to create and invoke method request this will give me back an http request message so var request equals that right and then i can say request.headers.you know do whatever so if you there's a couple different ways to go as far as how you do it if you really like http client as an abstraction and you like writing code to that you should continue to do that if you have another library that you like like floral or resharp or refit you should continue to do that or if you want to check this out and you think it's a good fit for what you're doing then you should do that if it makes you happy so the good news is because the underlying protocol is something we all already know how to speak it's really easy to adapt to some of these other scenarios and support a bunch of different use cases so i am going to restart this having dapperized it it's just going to take a little bit of time to shut down all these proxy containers that that tie injects so doing a tie run again this is going to build and relaunch my application and i just have to come back over here and refresh and this will give me a new set of a new set of ports here and that's not happy okay welcome to the bank this time will be john john you know john is not the creator of blazer so he's only going to get 999 999 we can deposit more money this is his check for having me on the community stand up cool so then let's come back over to our tracing dashboard and we can see that we've got some traces here and this information has changed a little bit so there is a bug that i found that i'm currently investigating here where not all the spans are showing up and i think it's just i think it's just a ui bug because zipkin does still have all the information and i checked and it's in the json so all that stuff about the state store is still there everything that dapper is involved with does get traced by default which is one of the benefits so if you're using say dapper state store or dapper's pub sub or dapper's azure blob storage integration all those things have tracing built in by default which if you just grabbed the blob storage sdk might not do tracing and might not know how to talk to your tracing server and might require you to instrument the code like for instance um i'll go back to stack exchange because redis because i think it's great um like stack exchange redis has tracing support right um and i've used that before and it's a great demo but like not every library you're gonna use not every technology you're gonna use has those things built in so we're now getting like way more first class tracing uh because we're using dapper to do that sort of integration so this is an alternative to the approach of having like a tracing provider in your app that's going to push those spans there notice that i didn't have to add that so like going back to my startup code and seeing um here like there's no zip can anywhere here there's no tracing code anywhere here which i think is pretty cool if you've already adopted that and you like it i don't don't look at this as an ore question um because having all of that stuff get traced would ultimately be the best experience would give you the most complete picture so the cool thing about that i think about dapper doing this is for the service to service invocation if you're using it it's a really easy way to get tracing with very small investment for the other things that are your dependencies you also get tracing of those things for free which i think is pretty sweet so i want to do some more coding how are we doing on time john uh we're doing pretty good probably get 10 maybe 15 more minutes if you want okay i want to show a couple more things just because we haven't we haven't fully done everything yet so i want to do a couple more things so ultimately we want to create a transaction history of all of our bank traffic right what kind of bank would we be if we didn't keep track of of who's doing what right so i want to take this transaction history and i want to push it to a message queue because multiple people might want to listen to that um multiple services might want to get that get those records and do some kind of arbitrary processing on processing on them and i can use dapper to do that so i've already created the transaction history this is just a really simple dto type object that is a transaction record you can see i'm getting the ending balance here let's push that somewhere so i'll do that i'm going to use a dapper client to do this so this dapper client by the way this dot is the best coding style you can you can discuss while i'm typing this and we're going to say publish event async and i'm going to pass in here i need a pub sub name so that's basically the what's the pub sub that i'm talking to and then i need a topic name which topic within the pub sub and i think i called it history if i'm wrong it will be embarrassing um and then i need my data my data is just going to be my history data and that's all i need to do to do a pub sub and i need to await it's a good idea to wait david's not on the stream but he will get me later if i don't and then i'll do the same thing here and then notice i'm doing this only after i save this date because that could that could come up later so i'll publish this as well for a publish this as well for both withdrawals and deposits and then i want to i want to highlight some of the configurations so we haven't looked at the dapper configuration yet i'm just going to highlight that real quick so the way the tie integration works is you give it a components path and the components path is where just basically a folder where all your configuration files are going to live now they are yaml they are kubernetes style yaml you don't have to be using kubernetes to do that for so if you were using kubernetes these would all just be things in these would all just be kubernetes objects in kubernetes if you're not using kubernetes these all just be files on disk somewhere so the format is the same regardless of what you're using and basically this is the configuration in here to say this pub sub is backed by redis here's how to authenticate with redis so the cool thing about this again this is a logical name there's nothing in this code that says redis this is using reddit streams for pub sub by the way in case you didn't know redis could do message queues it can do everything it's a swiss army knife the cool thing is that i could change this i could change this to pubsub.azure.servicebus ooh that was a bad typo right um i would have to change all this stuff because the configuration for service bus is different but i wouldn't have to change my code so that's pretty cool you can you can occasionally oh goodness what did i do you can occasionally get into situations where you do care about some of the knobs and dials that are specific to each provider and you can have those things leak into your code in some advanced scenarios but in general it's not something you think about for most use cases so my pub sub is configured with redis this is my state store we didn't look at it earlier i'm not going to show you this audit store thing because it's got a real credential in it um these yamls can integrate with kiva with secret stores as well so you don't have to hard code credentials i was being lazy and i was going to just say hey i'm lazy and not show it on stream which i will do okay so the other side of this pub sub is that's what this auditor application does and the way that we do pub sub you know just show the dto the way that we do pub sub and dapper is a couple things first of all you have this subscribe handler so this uses endpoint routing and what the subscribe handler will do is it's a it's a little endpoint on your app that will tell dapper what are all the topics you're interested in and what are their routes so dapper will call the endpoint that comes that's registered here and then use that information to hook up your subscriptions for you there's the use cloud events middleware which i'm not going to explain in depth pub sub uses a standard called cloud events it's an open spec it's a community kind of open source project to describe the messaging format that we use for pub sub events this middleware will unwrap that format and replace the message body of the request with just the payload of the event so that i can read the request body as json in my transaction history so to make sure i'm understanding that right pub sub inside of dapper we had a question on oops uh well that's another question but pub sub internally and dapper is not using some other message queuing system or whatever it's it's internally implemented using um like it's it's it's into it's a native implementation right uh so pub sub and dapper uses all these different things um so going back to this slide pub sub uses redis or nats or i assume this is a google icon of some variety some underlying message queue implementation as its backplane so what will happen in this case to be really specific is this this application the bank controller where i'm publishing this will tell its sidecar hey publish the event the sidecar for bank controller then connects to redis and says push this event on this queue the sidecar for bank auditor which is subscribing it wakes up it calls this it sees that we have metadata here that says i want to listen to pub sub topic history and then it wires up a subscription so the sidecar for bank auditor will understand this through the magic of http and then we'll start listening for events on that redis on this topic and then when it sees an event it will call history so the the great thing about that is you get fan out uh you get resiliency like if this has crashed at the time i published the event or something like that like you're using a real message queue as the implementation and you can control the semantics of how you interact with that message queue through some advanced features that i'm not going to have in this demo but okay there's a real message queue it's not a it's not a feature that's bolted to dapper the intent is the dapper layers on top of existing technologies got it okay so then here this cloud events middleware is what allows me to read the transaction history directly from the body and then what i want to do is basically say you know anytime we're seeing a big withdrawal um we want to keep a record of that so let's let's do that so what i'm going to do is i'm going to push this to blob storage and so what i'm going to do is i'm going to say this or dapper client it's it's di in this case dapper client dot um invoke binding and you can think of binding as sort of this catch-all so a binding is sort of like a extensible abstraction for the things that don't neatly fit into a category like pub sub or state store is i want to do this thing to this thing and so my binding in this case i think i called it what i call it i always make these names the same uh named the same in the yaml as they are on the file so this would be called audit store again not showing that because it's got a real credential in it we're doing things by the seat of the bands here today audit store and it's backed by a real storage account and then the operation is create because i'm going to create a file and then to this this is this part is actually not amazing and it's specific to the blob storage thing i i have some ideas about how to make it better but we'll just sort of soldier on for today we need to take that content and need to get it in here and i actually don't want to do it this way i want to create a request so var request equals new binding request so this is just a simple little dto for binding and this is where i put these things in audit store and create because i'm going to create a file and then i need to give this a payload and that's what i've got down here so data equals create upload history and so what this is going to do is this is going to base64 encode that json it's not going to be impressive to look at or anything but i just want to prove that it can do something it's going to base64 encode that json and then push it to the server okay so there so now we've got our application using http client to do a service invocation request to our bank controller our bank controller using pub sub to push an event on a message queue our auditor application subscribing to pub sub via endpoint routing you could use a controller for this as well as you want with a topic attribute and then taking that event and if it's a big withdrawal keeping a record of that in our audit log which is backed by blob storage and all of these pieces are going to come together so let me run this and we'll just do the demo real quick and hopefully i got this right the other thing that i want to call out i'm going to say it twice so this will be the first time i say it we're getting very close to 1.0 release with dapper so everybody always wants to know when's 1.0 when's 1.0 um we're getting very very close to that i think the date we're talking about now is like february um like mid-february kind of date um there's a couple books that have been written about dapper already which are pretty great so um there's there's two dot-net focus ones that are out there um one has been written by an mvp that i know the other one has been written by somebody else who i'm sure is great um and so we're getting pretty mature we're getting pretty close to release which is a very exciting time because i've been involved with this project for a little while and have really seen the.net sdk grow and get get some usage here so i'll go ahead and open this up again and let's check this out so this time it will be me um i was not the creator of dapper so i get 999.999 oops and then let's spend you know two thousand dollars so there i spent two thousand dollars we should be able to see a trace here again i think this is a ui bug i'm sort of investigating it here you can see that we've now got three services involved here it's not going to show all the spans because that issue that i was talking to you about before and then let's see if we actually got something in blob storage here none of this is production data so i think i'm okay to show it hopefully and so the bank auditor should have noticed a large spend and should have so yeah so now we have a file here and that came from you can see that that was just about now um and then i think the other cool thing here because we're doing tai we have all the logs for these things at a glance so here are the logs for my bank auditor and you can see that we're getting these cloud events requests yeah whoa there ryan is a big spender right so you can see we're getting these cloud events uh json payloads coming from pub sub and then we're able to do the interaction with blob store and that's what i got that's what i got for a demo whoa well i think that was good i liked the um the part where i made a lot of money yeah um we did have a few questions because it is a good demo we had a few questions if people will if if they can get hold of this code uh yeah so um i will push this so i have not pushed it yet i will do i will not show my last pass on stream that has happened before uh somebody did it in a i'm not gonna out who it was somebody did it in an api review and then he re-watched it to take notes um he rewatched it to take notes after uploading the video and i have so many security vulnerabilities oh my gosh so this is my repo um i will push my content here after and ncd oslo oops i will push my content here slightly later today um there will be a 2021 folder and you can find it under there i try to be at least a little bit organized okay i will add that into the um community links listing too the other thing i want to i want to show real quick um i didn't have to install because i've already got dapper but there's a really easy set of getting started instructions and tutorials here so you know classic curl and bash to install the cli uh or you can do homebrew which i like uh if you're on mac and then there's uh dapper init basically will grab the latest the latest version of the runtime so windows commands really really similar linux commands really really similar we do not have wind yet yet if somebody wants to help out with that it would be awesome but basically the cli and the redis are separated and we give you a pretty good like dev setup here by default so you get a terminal you say dapper init that will install the latest runtime and we're really getting close to release so we have a couple customers already doing dapper in production and things are getting pretty stable and pretty mature we have another question um gosh let me see we have had a few trying to look here give me the best one well i'll give you a few the best best practices on not logging like there you had bank account information how do we um control that because there is this logging and stuff yeah i mean that's not really dapper it's sort of a generic question um i think there's an extensibility point for that david will shout at me if i'm wrong um i think somebody added an extensibility point that lets you redact data um my advice or at least the way that we treat this in the framework in the framework we use the trace level we use trace level diagnostics for anything that might be pii might be sensitive information so if we do have to log things like account numbers like i think um some of the blazer server artifacts like circuit ids and things like that fall into this category where we we say we can't really tell if this is sensitive or not so we log it at trace and so if you've seen debug and trace in the logging settings that's how we think about the difference debug is troubleshooting logs trace is troubleshooting logs that might have sensitive information so i have seen people write um i've seen people write conventions like like for instance i had that key value pair like username i've seen people use conventions where they say every key that's called username redact it in the logs and i think there's an extensibility point for that now um it was something we talked about with another team at microsoft who was using extensions logging best advice that i would have would be to not do it um the the better i think the the problem is that you are the only person who knows what domain knowledge is sensitive right yeah because it's part of your business problem um we inside the framework treat things like uh query strings as sensitive we treat things like form bodies are sensitive we don't log them by default um if you do your own logging of frame my my advice to anybody is always use the frameworks logging understand how to configure the frameworks logging and rely on that for things that aren't your business concerns so if you do end up having to write your own logging for things like query strings things like form bodies things like headers know that inside the framework we have we have a set of assumptions that are pretty strict about what is considered sensitive versus what's not like we don't we don't consider url paths to generally be sensitive but we do consider we do consider things like query strings or form bodies okay i'll give you one last question that is a bit repetitive but i do think is good as we're kind of stepping back and like now that we've learned all this stuff so question here on how do we think about this related to some of the other things istio akka orleans and then also another one um that somebody else mentioned in a question is steel toe yeah which is also you know like a.net so what's kind of the elevator pitch as we kind of walk away from sure i think the thing that is unique about dapper that those other systems don't have is this philosophy of we're trying to become the easiest way to do integration with a lot of different things and i mean third-party services like like that list i showed you if you go to the dapper docs there's a list of supported components there and it includes things like sendgrid like twilio like different third-party services or sas services i think the the thing that's really really cool and powerful about dapper is this idea of let's not have sdks in the app let's not have credentials in the app let's not have integrations with third-party services or blob storage or things like that in the app and that's a unique idea that i don't see these other things doing i think there's a lot of overlap in other areas so for instance dapper has an actor framework we weren't talking about it today because that's that's a pretty deep rabbit hole actors are not not necessarily a casual thing so i don't leave with that um but like so does zach and so does orleans um i think the cool thing about dapper is that you know dapper has a dapper has a team behind it um we're working on service integrations for dapper which you might not get with those other things i don't want to slander i don't slander akka and orleans because they're good projects but like we have a team behind it we're working on integrations we're getting a lot of contributions and partnerships from the open source ecosystem around dapper which i think is really awesome um comparing to something like k-native like um there is some overlap with k-native kdav if you haven't seen it as sort of a opinionated programming model an app model for rest apis for pub sub for these kind of things again k native doesn't quite decay native doesn't have that integration with the bindings and the blob storage and the twilio and all those kinds of things or secret stores it's not the problem they're trying to solve by doing that so there's a narrow slice that overlaps which is things like service invocation okay or service discovery or tracing or scaling but they're sort of disjoint sets right if you drew the venn diagram with all these technologies i think there's no matter which one you're comparing to there's always a lot of value that's on the outside of that venn diagram that's just in the dapper only category so like again comparing to envoy or istio um you know envoy as a proxy and istio as a service mesh based on envoy um you're comparing a pretty narrow feature slice of dapper which is the traffic routing service discovery tracing encryption piece um and there's a whole set of other things that dapper provides that aren't covered by that so um as with all these things it's up to you to make your own judgments and say what gives me the value what are the tools we want to adopt as an organization i think it's always a hard decision for people to adopt a dependency and and i agree with sean it's the right tool for the job and it's also the right tool for you or the right tools for you there's nothing telling you you can't use istio and dapper or akka and dapper because there's large parts of these feature sets that are disjoint that are not competitors to each other so you know i think when you ask me my philosophy about these things we're always just trying to make cool tech like we're always just trying to make good tech so like love to hear from you if there's something you think is not good or if there's something you think is great because ultimately we're just trying to make people happy and if making using istio makes you happy because you're fully bought into that like rock on you know that's cool that's cool well this is really helpful for me to understand i was i've been using tai a good amount and i've seen a lot of thai presentations and it's interesting for now i finally get it kind of the how they fit together and how they're different and stuff and and so yeah very cool well one last one i'd love to wrap up here one comment from yum yum cake monster it's been a long time it was great to have you back on i'm looking forward to to more updates thanks i think the other thing that maybe is a specific call to action for net um uh maybe i'll maybe i'll throw up uh maybe i can throw up a page here real quick sure um i'll find it um i'll try to talk while i'm i'm finding it um dapper as an open source project is a little a little different from some of the other open source projects that were like sort of seeded by microsoft or maybe a little bit different than some of the donut foundation projects and i don't mean this in like a really bad way we're a little bit more in that style of project like a kubernetes or like one of these cncf kind of projects where there is this concept of there is this concept of membership right so like by making contributions um you can become a member and i think i didn't find the right page but you can become a member um the istio or the uh sorry that i have istio on the brain now the php sdk maintainer is someone who um is someone who just approached us and said hey i want to do a project within the umbrella here is the community membership page i want to do a project within the umbrella of dapper and i'm gonna do the work and i'm gonna be responsible for and we said yeah like that sounds amazing we'd love to have a php sdk we'd love to have more perspectives on what we see as the team so they're you know the steering the steering committee right now is some microsoft folks but long term the plan is for dapper to be an open governance project where there's involvement in stakeholders that represent a bunch of different organizations and a bunch of different interests so if you're interested in getting involved in an open source project that's a little bit more in that cncf sort of vein like we're looking for people who want to contribute who want to take responsibility for areas of functionality who want to propose features and drive them to completion as sort of independent people and earn your stripes as a member of the project a contributor to the project or a maintainer of the project and so like right now i'm the i think the solo maintainer for the.net sdk like it would be awesome to say have somebody that loves f sharp show up and become a co-maintainer of net focusing on f sharp like it would be awesome to have somebody who loves actors show up and say hey there's a bunch of functionality that we should add to actors i wanted i want to build that with the support of a community and a partnership with a community so if you want to work hands-on with some other folks if you want to drive open source projects forward if you want to contribute to something like this or you have ideas that you'd like to spike i think we're we're positioned with the structure of dapper to say yes to more of that stuff so i would love to see more involvement from the net community and what we're doing and i'd love to get some more you know build a more active community of people around this i think that'd be amazing awesome okay well great uh we're definitely a time so good good place to wrap up i'm looking for uh so we will i will add the links to your demo code when you get that in i'll add that to the community links and i will keep be keeping an eye out for the the 100 release which is exciting and and definitely let me know when when uh you'd like to you know come back on and show us more stuff well hopefully i can get my personal uh my personal focus out of stealth mode and get get back over here because i think i think if you liked tai you'll like what i'm doing now awesome okay all right well that's all thanks a bunch folks thanks bye everybody thanks [Music] [Music] [Music] you

Channel: dotNET

Views: 8,117

Rating: 4.9764705 out of 5

Keywords:

Id: VkJQR854S1s

Length: 89min 34sec (5374 seconds)

Published: Tue Feb 02 2021