 Thanks a lot for having me and no pressure like 500 people in there another 500 out there cool And that works, right? so We're gonna talking a little bit about networking just to get an idea who has been using go six months or less oh shit a Year or less Okay, and the rest of you since the beginning, okay, cool The only interesting bit of information on that slide is probably that I'm a developer turned ops. I've been doing software for a few years now and Since 2014 essentially I'm a gopher. I'm doing everything in go If you want to follow along follow up and given the new setup I'm not actually gonna type this stuff in there wouldn't have been possible with that Mike anyways So you would just trust me that the code that I show you actually execute you can also grab the code and The commands I'm using from that URL here. So everything is there. Everything's online. That's the reason why I can present now All right quick look at the agenda looks more than it really is Unfortunately, because it's only half an hour. I don't really have the time to go into really deep detail But if you are interested in you know, hit me up. I'm here until one day All right, the net package the TLDR of that talk is essentially how Forking awesome Go is because it brings so many things already, you know, typically in the standard library and has awesome packages for everything else So this is a kind of very high level overview of the net package. Not very useful just a screenshot There are things that you would expect like, you know, HTTP URL RPC Mail as mtp and so on and so forth and I thought about how can you actually I Try to come up with a visualization that makes more sense if you're coming from networking sites. So who of you is Comfortable with looking at that network layer stack Pretty much everybody, right? Cool. Awesome. So then we can just you know, I just you know I'm not gonna explain what these things are just one anecdotal thing. I think it was windsurf who said We won because we focused on the implementation not only documentation. Otherwise would be looking at the OSI 7 layers But yeah, that's where we are So on the physical Layer there obviously dot-net interface and hardware address the thing here. I don't know if that pointer works Yeah, that is pretty kick-ass I had a look at that Essentially allows you to dig into the the ethernet packages and so on. So if you if you're down there Iot or whatever and you really want to look at packages and that level Go and have a look at that networking layer you have multiple things to represent IPv4 or 6 addresses and then You know some masking and so on so forth and then go packet, which is kind of like Google's go packet Which is kind of like on that layer as well Moving up the stack transport layer You have connection IP connection and Then the application layer pretty rich and as you can see sort of black stuff is part of the standard lip and the blue stuff is You know not yet part of the standard lip Yeah, so as I said already things like HDB URL and some all of that is is built in and then there are a few things Which I wish that would be built in and I believe correct me from wrong Who is here from the go team who might be able to clarify that some I heard someone earlier? No So is there any good reason why WebSocket is not in the standard library? Okay, who of you wants to have WebSocket in the standard library give me a yay That will probably be 1.15. All right, so I keep using Gorilla WebSocket there probably others as well Yeah, we're gonna have a look at that later. So I think I personally think This does not totally suck, but probably there are better ways to visualize it But at least you get an idea on which layer certain packages work If you have any question, you know feel free So the first example we're gonna have a look at is a curl mini curl really in a few lines of code essentially Focusing on on this part here, right? So you we do a HTTP get here with the URL provided by the argument and then using HTTP utl dump response to just Have a look at the at the result and This I mean obviously the curl has a few more features But this already kind of like shows you the power of the actual build in the standard lip stuff Um Yeah, okay, so second part here that actually you know pulls out the stuff from the the body And then in this case the the example used here essentially allows you to specify the the amount of like payloads and invites that you actually want to display then Just to show you how you can you know read or read only partial responses there Next example would be an app server So some something that has an HTTP API and response with hopefully something useful So in this case Actually, that would already be to foster them go there from with 3000 if they would fit in so in this case you essentially just using the the standard vanilla HTTP handle fun and Provide the path so whenever I do a curl or HTTP on You know, it's running on nine eight seven six the port slash about then I would expect to get back this This struck in in chasing code in chasing and believe me, you know if I would have my own laptop I would now do curl and you would see that chasing there Again pretty pretty straightforward the only thing and I'm gonna talk about that a little bit later on the best practices is that This here is a little bit too convenient a little bit too like the defaults could be a little bit better Again, if you disagree with anything here, you know, please tell me later This is essentially what I'm kind of criticized like if you if you're doing that Right, you're probably doing something wrong what you really should be doing and someone Thankfully put together a gist so I didn't have to do that and that's the kind of like the Gist of the whole the gist of the gist The real thing here. So you really want to set timeouts here You really you can have Handler here for tracing the request in here an error logger and so on and so forth. So really Like it's there. So please use it. It is in the standard library. Please use it. Do use timeouts Do use retries the next example that I had is around a very very like Silly stupid simple RPC client server that essentially in this case, it's really just, you know a fixed call So have a look at the server here Essentially is listening again on a certain port in our case one two three four and then just waits for for incoming connection and then executes on the server side a certain method here and the method is Essentially just a multiplication. So it takes two input parameters and then multiplies them and gives them back And the third that was the client. Oops. That was the client on the server side effectively just Yeah sits there and waits until client connects an RPC client connects and calls a certain function That is great. I'm I'm kind of like on the fence here with the RPC built-in standard library. It's it's you know Good enough, but there are I'm gonna come back to that in a moment Better options or more flexible more powerful options any questions so far second-level programming I Love that. I didn't put the link to the video there. I think it was Linux con Australia or something like that a guy giving a talk about Yeah, essentially IPv6 and that that really like took a snap of that that really fascinated me So if you compare IPv4 with IPv6 just a summary here just to get everyone on the same page This one here is the real the real thing, right? So if you assign every IP address essentially some weight it would be 75 milligrams for all the IPv4 addresses that we have and Roughly the the mass of the earth that IPv6 has which means that's quite a lot of addresses, right? So a lot of things are possible and will change But unfortunately, which I'm still pointing out there, you know It's a bit like the the year of Linux desktop, right? It's any every every year it will happen and Yep, still 2018. We're still using IPv4 like how? anyways Quick reminder recap regarding ports Everyone familiar with ports and those different ranges here privileged well-known ports. I am a registered ones and the femoral ones. Yeah Okay, cool And you know for next slide essentially just we more or less distinguish between connection-oriented TCP for example that's used by thank you by HDB and many many others and connection less or broadcast types like EDP Which is still used by by DNS But I would argue that many many Layer for protocols nowadays actually use TCP So in this case what you would see if I would type it in here would essentially be a HTTP get using the low-level functionality That the standard library provides so we are actually the main things here. We first resolve The address then we use net.dale tcp to get there actually send the head request So not to get but a head sorry head with for a HDB 1 0 and then the rest is more or less the same as we have seen earlier on getting the the response back and parsing that and printing it out so obviously For HDB probably don't want that but you can use that pattern for for other Layer for protocols to just you know build your own Client or whatever using these low-level primitives can be very useful So I'm halfway through the time and my talk. That's awesome. So Let's see Timeout and retries. So who has who has not Used either timeouts or retries in their production code Everyone you liars come on I I'm raising my hand. I am guilty So it is still very much the case and given you know cloud public cloud and this and that that You know either the network between you and you know your favorite Cloud provider or within the cloud provider or any third-party services that might you might be calling out to which is increasingly so the case This is not reliable. So you will run into Things that you know, it just times out and if your code is not aware of that Well, you're probably gonna debug and then you probably should use stealth And it's really it's like there is it's minimal overhead It's not like that you need to to invest a lot of time and pretty much natively support it within the standard library So please please do use timeouts. Do use retries for that And to me like I nowadays would say this is really a hard requirement for production level Production quality software. If you don't do that the code review should be should point that out There are three resources I found Reviewed many but these three I cut it down to these three that I personally think really are very very helpful If any one of you is in the audience or is looking live. Hello Thank you for putting that together. That's very very helpful Security who doesn't like security? I Must say I'm pretty again Very very impressed when I had to look first when I came to go To what extent go really provides security related features We know crypto And there are many many things that you can use out of the box or or you know packages that are available Essentially again pretty much like with the timeouts and retries if you don't leverage that if you you know Don't use till as many many other things around there. Then you know, don't come and complain. It's not the ghost fold DNS that that is probably my most favorite topic and maybe Either now or over a beer someone can explain to me like my hunch would be it's probably due to portability reasons But why the fork does go have two options here? Why does it, you know, have the pure go resolver and the seagulls based resolver there? I have no idea if you know the answer Please hit me up or yell at me now. I'm more than happy to learn Essentially what it means is a very very simple example just to you know, grab something FQDN and look it up and luckily I put the the result here as well So if I do that on my local laptop with the go debug net DNS set to seago I actually can resolve. I don't know if you see it here That's the name of my you know dot local domain on my machine Not my machine, but you know the one that doesn't work and I would actually get An IP address here. So the DNS look up here would work if I do the same With net DNS go It panics Right. So I'm not like I'm not judging that fact. I'm just Really really really if every if you forget everything else, but please remember that and it will probably save you few gray hairs or a couple of your life a couple of hours of your life getting back if you're Running into that issue in whatever setup. It certainly did for me Yes, so my favorite topic is gone coming back to RPC getting more and more interesting and thank you You know The the rest hype if you wish seeing a little bit of Yeah Competition here from RPC. So as I said, it's perfectly okay I think to use what the standard library offers you in terms of RPC if that doesn't Help you or if you're limited by that here. You have two great choices cheer PC Originally created by Google and I believe it's pretty much the same that they're using internally. It's now a CNCF project that cloud native Computing foundation project. It's very fast and powerful I guess the only reason that twitch came up with To work here is that it requires HDB to so which apparently was initially a chpc user And then said well, we'd really like to use a HDB 1.1 and we would like to have a non binary JSON representation which makes it easier to debug and That's why they came up with twerp pretty new Couple of weeks or so old so I didn't really have a chance to go deep into into that So I can't really answer questions around that if anyone from twitch or who has used that already is here Love to talk with you and then there are a bunch of other Non-standard lip libraries or packages that I encourage you to check out We already had the web socket there and and the epics gateway DNS FS is a pretty cool hack Implementing a file system on DNS. That's pretty nice We had Google go packet packet inspection and for low-level stuff either the packet packets this one here So depending on your use case and the situation you're in you find yourself in you probably want to have a look at You know before you write it yourself. Maybe have a look at those things. They they're pretty kick-ass Web frameworks, this is probably my second favorite slide on on that back And I could you know if I'd be in my laptop I could actually actually go present still doesn't support Videos that's a feature request, right? We should really have videos in go present. It does but not which one I Love you Francesc. So this is an animation where this guy goes like into that, you know Time-sink, so if you must if you typically if you come from another environment if you're you know Ruby on rails or whatever and go like Go doesn't have you know or what are the frameworks? Well, you know someone put together the top six and actually that's a very nice very nicely done So there are of course there are you know people especially coming from different languages Put together these and you know as you can tell from the stars and forks and whatnot pretty popular But I also encourage you to read that one here because it is Quite often true. You don't necessarily need Stuff like that Little bit on the fence probably I'm doing the wrong kind of things to actually depend on that But it's there if you want it quick recap or summary of best practices writing network applications In general There is this old, you know the fallacies of distributed computing gave it go for contact last year About that and it's again. It's still very valid and probably even more so so be aware of the fallacies there There is a very nice Context package. I didn't really go into great detail early on so do use the context package wisely and again reminder Do use timeouts to use retries and Obviously the three T's test test test And in terms of and I am coming from the communities land So this kind of like health checking probing is kind of like you know built in there are two kind of philosophies there or two Ways to approach that you can either Subscribe to the idea that you pushed instrumentation to the developer. So it's you actually writing instrument to code People off there's go metrics whatever or you kind of like outsource that to a service mesh like Hysteric on it. They have sidecars and they essentially Do that stuff for you? Whatever you do Please do it any any kind of metrics either the developer themselves or some other Thing that sits on the sides and does it for you It's really useful. You're really helpful And with that I'm already on the last slide and happy to have a discussion a number of things that Are very very useful if you are not that deep into networking with go I Based many of the examples on this wonderful online Available book network program with go by young and then there are a couple of other You know blog posts and so on that that I really You know depending on what you're into to your PC or whatever level would encourage you to read and With that I'm open for questions. Thank you Before we do the Q&A quick reminder if you're in between my face and the camera you're on the video We're gonna do Q&A and afterwards I'm going to have to kick every single person that is standing up out of the room It's not my rules So please make sure that there's no free seats anywhere. I remove all my stuff from my seat So if someone wants to use my seat, I will be just chilling here. So please try to do that and now Q&A Any questions? Yes, please quick comment Q&A. So we're gonna accept only questions especially because we cannot hear you So if you have a question, please go for it. Thank you Just to quickly recap what you said. It's essentially the DNS stuff that I mentioned. They're essentially More or less to be more flexible to accommodate a range of different naming resolution systems. Okay. Thanks I'm gonna build that in any other questions That seems not the case. You're just scratching yourself, right? Okay, cool. Okay Yeah, the question was if I rec if I have any recommendations for libraries like pick up and yes the the answer is it is in that slide it was the Go pack. Yeah, thank you. So have a look at that and I tried it out. It's it's pretty pretty kick ass Okay, thank you