gRPC over HTTP/3 is finally a thing | Backend Engineering Show

the grpc team has just submitted a proposal to support http 3 underneath the grpc protocol this is exciting let's discuss what does that mean for all of you grpc users let's just jump into it welcome to the backend engineering show with your host hussein nasser and grpc guys it is described as this ultimate universal rpc or remote procedural call protocol or really the a way for a communication between two peers um so many protocols have came before grpc grpc kinda people might disagree with that but and i put the nail on the coffin for to communication between two parties two computers a standardized way of communication right and i talked about why grpc was kind of the winner and uh and why you would pick a grpc over any other protocols it's it's really mainly because of the use of the protocol buffers which makes the kind of the communication kind of standardized and the support of languages right you see the more the most critical and really painful [Music] thing for a developer to maintain is a client library to communicate between two parties right that was like the ugliest thing because if you picked a protocol x to communicate in x you need to understand how to talk x right whether x is tcp http http 2 uh udp so pressed doesn't matter right you need to understand how to talk that language and in order to understand that you need this language translator right that talks in that protocol so thus you can bake this into your application or create an application library client library that knows how to to how to talk grpc or how to talk tcp or how to talk http or http or whatever and that and people use use just to import these libraries and then call in uh into these libraries all right that was painful because anytime you want to upgrade you need to find a library that is supported right that is maintained that people upgrade with it or you need to fix it yourself which people don't have time for i'm i'm already busy maintaining my own application why would i start why do i need to uh start managing the http library4.net3o right or whatever right so you you find yourself always upgrading and and and uh finding a compatible library and that was a challenge sometimes you have things break when you want to move so so it was a sticky thing grpc changed that and i talked about it in my grpc video go watch that video if you want it's a lengthy video detailing all of that stuff with examples and stuff like that so grpc once you pick grpc you're set right you will build the you will build your protofile this is your schema that you need to talk through and then you would basically pick the language and it will literally stub out what the functions that you need to call in and it will take care of how to talk in grpc language right and then you get all the feature for free like the bi-directional streaming the unidirectional streaming and then multiplexing all this beautiful stuff right so we know that why people pick grpc i know a lot of people especially spotify for example they wrote their own protocol that before grpc days right that is arguably even better than grpc but and it was it was working perfectly for them there was no problems with their protocol i think it's called hermes right and they ditched it why because no one no one else know what hermes was it's hard to learn or teach people about hermes because it's not a public thing i don't believe it's open source maybe it was but it's not popular if it's something is not popular nobody knows about it so you need to train people about this new thing that you only knows about know about that's why they ditched it for grpc right it tells you why popularity is an important thing right in in programming and software engineering sometimes you adopt something just because it's popular and because it's widely used because it's cheaper so grpc is built on top of http 2. why is that because it had the idea of streams like these individual streams in a given connection so you'd open a connection and then in a given connection you can pick a stream and and you can stream content on that stream while you can send a request response in another stream while you can on the third stream you can do a bi-directional communication while the third fourth one you can do a server sent event kind of a situation where the server only send you logs right you can you can do all of that stuff in in hdb2 right so grpc team built all of this low level control on top of http 2 right i talked about http so guys if you want to learn about more about them that is as a pose of opening a tcp connection opening a connection for every single thing that you want to do right which is expensive we know how expensive opening tcp connections are grpc was built on top of hdtv tools where it's working perfectly people love it you don't even know or need you don't even need to understand that http 2 is under the hood because that's another property of grpc it's hiding the implementation for you it's just hiding this stuff for you you don't really care if it's using hdb2 or not you ask grpc hey i want a channel that is a bi-directional to the server and we'll open one and if you want another channel it will open another i don't know what it's called i forgot been a long time since i built their grpc content but you you basically built multiple channels or streams on top of one connection and that's that's the multiplexion multiplexing concept is what's powerful here it's the flexibility you you almost have everything you need in one protocol and who can say no to that so you're busy using hdb2 for this reason for the longest time i've been following an issue right in github someone asking it's like okay guys when are you going to support http 3 and you might say i'm saying who cares hdb2 is working why would you need support http 2 and that why do we need to support http 3 and that is the question grpc team asking themselves is it really do we really need to move grpc and they were they were really seems like they didn't comment at all about this they let the community talk about themselves like oh whether we need grpc or not on top of http 3 do we what is the value here are people are really having problem with http 2 and stuff like that and i'm going to summarize this is a show anyway right this is a lengthy show so i talk about one topic in a length manner so that's why this is not a one minute or two minute show right so i always like to do the to do these shows because i have the freedom to talk about a topic as as lengthy and go to tangent as long as they are relevant as far as i want or and as long as i want and then that flexibility or i really enjoy this right so let's talk about what is wrong with http 2 to begin with all right i kind of made a video about http 2 this detailing this but it doesn't hurt to repeat right we have a uh we have an item in arabic it's called uh uh but it means that if you repeat something it sticks that's what it means in a nutshell but http 2 guys um is built in itself on top of the tcp protocol just like http1 and the reason it was built is because of the the idea that a client is making a flux of requests to the same server one client's making a lot of requests to the same server and these are requests are stateless and usually they are not dependent on each other so it is fine to send them in parallel and it is fine to the server to execute one after another or execute them not in order particularly so and this is the nature of the web if you you notice you visit national geographic you're flooded by a lot of resources that you have to download what do you do you have to turn around and request all this stuff it doesn't matter if the image comes before that well the some front end engineer will say no i'm saying it does i really want uh my layout to be perfect and i don't want like the image to show come before the css so that this the page starts shuffling you know changing on you some people don't like that but it doesn't really matter you can't control this in the client side i believe but it doesn't matter what you download these things once you have everything you want to receive these resources as fast as possible so you can make these decisions you can't do that with tcp why because well tcp is a single channel right single path and if you send your first request right in this tcp you can follow it with multiple requests and a request here is really if you think about it it's a bunch of strings http strings that will be packaged into tcp segments so one request will equal i don't know 10 tcp segments right so they will be just flu one after the other right and the server will receive them and they have the server has to use like parse bars parse powerpoint oh this is our one request stop oh this is the second request stop oh there is one tcp segment lost let me wait it has to do this work and they received an order but the problem is the server is for for long history reason that i don't want to go about has to also execute them in order right it cannot it cannot just ex start it receives all the three requests but it cannot say oh request one i receive request one two three in order i'm gonna execute request three and two and one right it will it might execute the three of them at the same time asynchronously right on the back end but it has to respond in the same order that receives them this is just this is the way it has to because otherwise proxies and middle boxes in the middle will will says okay you respond with the request too but how do i know that response two is actually belong to this request too i have there is no knowledge no links between those requests and response right in the http standard so you you would end up with with uh within the order effectively right and that that that's that's a problem so you end up with this hit of line blocking so request one will be sent two and three and the server will have to execute response one response to unresponsive and execute and and send them in this order exactly even if response three takes less time even if response three finishes first it has to wait for response one and two to finish so this is called head of line blocking and this is a problem in http one which right http tool solved code and code solved and says ah really we don't really care because request three has nothing to do with request one so i want the ability to send request threes response even if request one didn't finish i don't want this blocking thing i don't want to be blocked so hdb2 had the idea of actually structuring requests in in an actual header forms like it down the wire header form so the hd2 is actually a breaking change when you look at the content right from the client's perspective it doesn't nothing changed it's a completely non-breakable change but when you look at the tcp what is the content sent is a completely different thing so now we start tagging with stream id so if i send a request one i'm gonna tag it with a stream id right or think of it as like a channel i like the name channel better than that so request one will be tagged with channel one request two will be tackles channel two and request three will be tagged with channel three or stream three so now if if if these three segments or if these three requests are arriving they are arrived and they are tagged properly so if the server receives request three and two and one and finished request three first it can just respond because it will be tagged properly with stream three or channel three right so this the client will know oh yeah i sent that but it's actually response three okay i know the client knows this and the beauty of this all of these are in a single tcp connection we don't have to open multiple tcp connection to achieve this parallelism if you will all right that's what http1 did because it didn't have a choice it used to open six tcp connections that's the default in browsers they open 1060p connection http1 and then flood everyone so that's how you need they uniquely tag a request right one request per connection at a given time right so yeah http 2 was awesome people loved it all right this streaming and obviously they went through a lot of repetition and a lot of revisions until it was kind of polished and finalized so what's good what's wrong with it ironically the head of line blocking while was solved at the logical level from a request response perspective i can still response number three can still be sent even if response number one was not completed all of this is sent on a single tcp connection so that means if request number one request number two request number three are being sent even tagged with these streams at the end of the day it is nothing but tcp segments at layer 4. when you look at the lens and layer 4 it's just a bunch of tcp segments well might as well are encrypted sure but they are just the segments they are sequence they have a sequence number and they better that that sequence number they better reach an order why jose you just said no order doesn't matter well i said order doesn't matter the application side but i didn't say anything about the tcp tcp still say hey you're sending packets one through let's say one through nine let's say every request has three segments for simple for simplicity right so packet one two three belong to request number one packet four five six belong to request number two packet uh what do you say four five six packet seven eight nine belong to request number three right so they are stringed one to nine these are the serial representation of the sequences in the tcp stack all right let's take this scenario let's say the client sends all the packets right from one to nine right and the server receives all the segments right one to nine but number four was missing it didn't it didn't arrive well it went to a path and it took too long what would the server do will the server size well segment number four is missing but one two three is there so that's request number one and request number three is actually seven eight nine so that also i got that will the server do that no remember the server is just tcp at the end of the day these segments to the to the server this is an incomplete uh packets this is an incomplete transmission they will say wait a second the whole thing is blocked the whole thing is blocked i'm not going to send anything to the application the application being the actual server listening to port 443 right it says no i'm not going to do any of that stuff http 2 or not it doesn't care it cares about the tcp transmission right so packet number 4 is missing i'm gonna ask for a retransmission and i'm gonna sit here and wait and then let's say it got lost again right yeah yeah send it in wait and if more packets are lost for for congestion reasons or any any reason really the the iep packets underneath tcp segments are taking different routes for because they have a mind of their own and they decide to arrive out of order or so you will have to wait this blocking time is called head of line blocking but it's called the tcp head of line blocking in this case so we solved the hidden vlog blocking at one end right but we still have another tcp head of line blocking because now this streams are just they the tcp has no idea of what a stream is or what a channel is to them to this tcp this is just a bunch of segments that it needs to arrive in order it kills you as a developer as an engineer that sees that oh but one two three is there please process one two three one two three is actually request one and that's one big limitation http two and hey hussein from editing as i was listening to that i might think that request one will be actually delivered to the application because segment one two three has actually arrived in order what will not be delivered actually uh request two and request three they will definitely be blocked right because well request2 is missing a packet and request three well you cannot deliver that because there is missing packet so the tcp's uh transmission is thinking well it's trying to be smart as well there's a missing packet i can't just send that right so just just a clarification here back to the video or show right now i gotta be honest with you i don't know to what extent this is actually a problem maybe people who actually built real-time applications on top of grpc using hdb2 they feel that especially i mean in a lan communication who cares right in if you're in a lan what packets or what segments are being lost right and almost none in a cloud maybe multi-region i understand if you're sending between china and i don't know california some data well yeah some sex segments will be around or there but to me i didn't see uh i don't know what to what extent this is a problem for the grpc team to actually take action does that make sense especially that grpc is used in a high network bandwidth environment so i don't think this is a problem right but that eventually the main problem is hdb2 is built on top of uh essentially the grpc being built on top of hdb2 the main problem is the out-of-line order but this is not even a problem they mentioned in their proposal uh grpc3 they just we don't really care about this but i i thought i mentioned that this is a problem so if you decide to go grpc and i know a lot of you in my comments actually mentioned that they had are using grpc take a look at where are your clients and server are they tightly tucked in together or are they far apart and they have the internet uh in the middle so that's a that's one thing we need to kind of understand so the second thing that http 2 problem has well here's the thing it's not really a problem it's it is it is a feature that http 3 makes it look better you know you know the feeling where you're really satisfied with it what you what with what you have but when something shiny comes in it says oh i want that because it's better that i just didn't realize that there is something better than what i have do you know how they're feeling i don't like like you're you're happy with your computer right and it's fast but you got something really faster than your computer it's like wait a second now i realize my computer is actually slow you know i feel like that that's exactly how i describe this feature the next feature that i'm talking about http 2 hd2 is built on on top of tcp right and because the table built of knob of tcp right there is and uh it is an http protocol so by default it was listening on port 80 right that's the default http communication but guess what when people actually started doing this this thing right listening on http to http 2 port 80 unencrypted when people did that the whole protocol started crippling when when they actually host it on the internet you might say why since this http yeah we changed you didn't change anything from clients just http well we didn't change that but the we did remember http 2 is a breaking change from the http protocol breaking change when it comes to the under why in wire transmission i'm i have to i have to always say that because otherwise people get mad right yeah it's not a breaking change when you would api your fetch api your axios a lot of people love axios for some reason right your axios didn't change your your http request didn't change till you said and get past this thing these verbs but the end the in wire is completely different so middle boxes and that the routes ip packets for some reason especially your nat ones isp stuff like that well those middle boxes do it actually parse the packets and says oh this is port 80. that means it must be http that means here's how http should look like beats me why are they validating ip packets beats me but some middle boxes do and when they find out that oh port 80 is is not re this doesn't look like http that i know when i was built in 1881 no wrote that was about building 1881 1981 whatever that router was built in http right wait a second isn't it released in the 90s yeah i don't know what i'm saying but you you get my idea right so http was really this is how it looks like so it was built to be verifying and validating packets of http that looks like this so when htv2 was sent in the wire the router freaked out and dropped the packets so that's why hdb2 on unencrypted didn't work it just didn't work it stopped working so people had to as why http2 must be encrypted if you notice you have to host your server and server tls and just do a certificate and people hate when to do all that stuff because they have to learn things that they they weren't supposed to learn which is actually a good thing you need to know tls if you are back in your name if you don't know tls you should you should know dls you should understand the cost of tls to the cost of the ciphers the cost of the signature algorithm every single thing you need to understand how you're dealing with this stuff so this is tls i talked about tls i'm not going to go through but tls encrypts this stuff right which means there is additional work to establish a connection then we didn't have to so there's the ccp which is three-way handshake right send snack ack then on top of that you still have to do the client hello right which is the tls if you're 1.2 god knows god hopes that you don't use ts 1.1 or 1.0 because these are obsolete and check your server ts 1.2 is actually four requests two round trips right so it's there's a tls hello there's a client hello and then server hello and then they change cyber suite and then change diversity right so this is two round trip so one two three four five six seven seven things until i can send data several transmission seven transmission and any any segment that is lost you gotta retranslate more and if nigel algorithm is enabled you know the the the the 40 minute delay delay thingy right the where where where where uh where the tcp client actually waits for more data to to to arrive from the client to actually send data that even adds more uh more more delay right that's why curl disabled nigel algorithm so you know tcp no delay 2016. carl said the author daniel stumber said you know what this tcp no delay is stupid we don't care we're not using telnet anymore right we're we want i if i send you something you better send don't wait don't wait for this window size thingy to grow no just i sell i tell you send send just like the disk i tell you to flush flush right fsync right that's why databases and operating systems like hey oh please don't try to be smart and i tell you to write something to this write it but operating systems you know try to be efficient and write to the cache that's why when you write and you think you raw but you didn't uh durability can suffer as a result why am i talking about databases again guys we're going all over the place if you like this stuff like and comments is saying i like this stuff or if you don't like him say hussein why are you going to talk about database when we're talking about grpc http 3 stop this nonsense hussain write in the comment section below syllabus now we're talking about yeah tls a lot a lot a lot of delays in tcp with hdb2 hdb2 is suffering because it was built on the on top of tcp so there is this additional delays stuff like that so quick and http 3 came back to the action actually hdb3 was about to be built right but the idea was mainly to solve the tcp head of line blocking this this streaming thing i want the stream i want if i receive segment one two three and i want the client to the server to understand that this belongs to something that is completely irrelevant of the rest of the stuff so treat it as one unit treat these three segments as one thing right don't wait for other stuff just just these are in order it's all right just go go your merry way okay so quick was invented as a result you might say you're saying why don't why didn't they just build hdb3 on top of udp right and and solve this question right so they'll say why do we need quick well they they thought i was like okay i want to i love this idea of streams in http 2 but i don't want i don't care about http as a protocol it's a text protocol i don't care about these verbs i love the idea of streams give me that without the overhead of http right and databases love this stuff no no database very few databases implement http because there's like an overhead who cares i don't care about headers hdb headers this is stuff that is i don't care about i want my product to be tight http 2 was was pushed down on top of udp but they built it on as a layer 4 protocols is without the http concepts and then this is where quick came into the picture i'm going to make another video just talking about quick the idea is just to solve to introduce streams on top of udp so let's use udp which is there is no guarantee there is no conjunction where there is nothing there is no only transmission packets are sent as packets right let's build our stuff on top of that let's build our con streams on top of udp so if udp packets one two three arrive i know that this belong to a stream so i'm gonna isolate these things so quick was born on top of udp effectively but is it has the features of free transmission if something is is is is bad then it will be retransmitted but only retransmitted if it belongs to the same channel or stream so now if i send packet one two three and this belongs to a stream right then and and packet two was missing then packet two will be resent right uh ask for it for a three transmission but if packet four which belongs to stream two or channel two has nothing to do with it so i don't have to wait in that situation so udp basically was built and quick was built and all that stuff right and then when we built that well all the work was done for us let's build http 3 as a thin layer on top of quick but before we jump to hdb3 there's quick also said okay so we do udp we're going to do the handshake we still because you quick it's still a is a connection system this is a connection based protocol so we need this idea of a connection we need we still need sequences and stuff like that so if we're going to build that then we need and establish a connection so there's a send or synack concept but guess what i also they decided that quick should be encrypted by default smart choice so now quick is all is a connection system right is a connection based but is also encrypted so now if i ask quick to establish a quick connection i can ask that and in the same packet i asked to encrypt so you do tls 1.3 which is the just a single uh just a single round trip i didn't talk about that but you probably know about that all right tls 1.3 is this is just a single round trip instead of ts 1.2 which is two right so now quick establishes connection and tls in a single connection it's a single single round trip and there is this something called zero rtt which is a zero round trip in quick that allows you to send encrypted data in the same first handshake with the request to resume an existing session and that is the most powerful thing if you can cloudflare i think is started supporting that and then they're backing right so you can do zero beautiful rtt in a single quick can actually so how fast this thing is bubble that's my kid sometimes he just goes into her and starts screaming or nothing alright so http was built on top of this beautiful already encrypted fast connection setup man who doesn't want to use that so grpc came into the picture and says all right let's propose using that for these reasons right so yeah http 3 is built on top of quick there is it's not a thin layer you might say all the work has been done and quick why do we need http 3 http should be really just a call in into this existing functionality but now there is the compression layer uh which is called i think q pack that's completely different so they have to reload the whole thing into a new new protocol so that that kind of changed that makes http 3 a little bit more complex it's not as it's not as easy as just let's let quick do all the work unfortunately right so quick was also built with the idea of uh tagging the connection id in the in every in every request so now you know that there is a connection concept with each packet it's almost like stateless but not really stateless it's just very interesting because every packet has the knowledge about a connection id so get this if you are on your wi-fi and you transmit to a 4g that's absolutely fine your ip addresses change so the udp packet will def have a different ip errors but the content will have a connection id that the server can use to resume the existing connection that he he he i don't know why servers he they has dropped so if the connection is dropped it will be resumed very nicely and smoothly this is called connection migration or connection transition right so this is a really a huge sell so grpc implement http 3 will get all these beautiful features for free so this will still work the proposal is still going uh i'm gonna have a link below uh in the show notes you can click on that and and visit uh let me know guys what do you think i think this is a good change and grpc uh might say if i want final thought before i before i end the show is saying you always talk about new shiny things and a lot of people talk about new shiny thing as they're the ultimate things are there problems with hdb3 obviously nobody can say and what our pro the problem with gb3 unless we start using it and and we barely start using it facebook i mean facebook moved too quick completely on their back end right i guess a year ago or so now all their backing is quick but we don't know there might be problems that they will every solution will have its own problem this is just the nature of human being give me a give me something that a human being built that didn't doesn't have a problem doesn't exist right anything that we build inherits problems and hdb3 is um an hdb2 for that matter and hdb3 is less so one problem that we are we are aware of for http 3 and quick is uh the cpu usage i say i said what why why why would quick take more cpu than than tcp or or for that matter just http right well remember guys the thing i told you about streams and and parsing the packets and way checking if this packets are in order and clicking oh these are three packets belong to stream one these pre packets belong to stream two this is not free this these are things that we never had to do with db1 one http 101 the content in the tcp is the content what you get is what you see is that is that the same what do you see is what you get something like that right what you see is what you get that is it there is zero additional processing uh minus the frames and and the osi model you know just the oh sorry it takes the frames and the packets and the tcp and that's it but you don't do additional processing at the content of the tcp segments you just assemble them and then you go anyway but now with hdb2 and quick we're doing additional work that we didn't have to do i this is what i want you to think about guys nothing is free in this world if someone asks you to do something there is always an intrinsic you know purpose behind it there's always something there's always something guys there's always something so hdb3 is a cpu hungry right and then uh well grpc god knows what grpc is building on top of that so grpc in general it's already cpu hungry i know of that because just about the work it's doing right this is it's not just doing http or it's using http as a down but http is doing its own work but grpc is doing more work on top of http so it gotta be cpu consumption i didn't see it but i know it is it's just logical you see you see smoke there is fire okay so with hdb3 i have no idea if it will be more or less well it depends right it depends on how quick and are being implemented and the quick implementation and it's being improved every single day sometimes i attend the live streams of the quick rfc committees and just to watch them what did they do they they they show us like every month oh last month we were using i don't know eighty percent of the cpu now we're down to sixty percent or now we're down to i don't know same same workload we're down the cpu usage so it's getting better and better um but yeah i think it's in general it's going to become better and better as we as our machines become more powerful right but it always comes to me i always think about this you know my machine my macbook right is from 2015. it's a 16 gigabyte ram uh quad core each core is a single processor quad-core each core is 2.4 gigahertz so you might i don't know if you're a hardware guy you might say this is bad old but to me that's that's powerful stuff right there but guess what obs is struggling now i had to add like 300 millisecond delay to sync the audio browser brave is dying it's like what is going on in this world how much power do you need and that's the slippery slope if you crave power you just crave more power and that's what's happening it's like why do iphones and all these mobile device need need i know three gigabyte of ram two gigabyte of ram to do these simple things but apparently these simple things are getting improved sometimes you have to ask yourself is this improvement worth it or not it's always a cost right i you want to solve the tcp header problem right head of law of line blocking so you need to process you need to add the idea of streams hdb2 hdb3 that if you want that then you need more cpu to run that so you might say okay i'm really happy with http11 on top of tcp and that's what i i think will happen eventually we're gonna go into this rabbit hole of us improving improving improving trying to improve something that we don't really need to improve at the end of the day and we'll end up back to just normal simple things right remember when i started this show what did i say http in natural the nature of hdb was a client sending a lot of requests to the same server that was the use case right and we improved on that usage so if you don't have that problem if you're singing one request to your server every i don't know a few minutes then you don't need any of this crap to be honest that's what i want you to think i want you to go back to the basic and the fundamentals and think there stop there and just build it up right you might need any of that stuff and as a result you're going to consume less memory you might be uh you know what's the word you might be just completely out of the left field and say you know what i'm not i don't need any of that stuff i've got to build my own protocol on top of edp that's what gamers do gamers just like build their own program into a beauty because like i don't need it it's like yeah it's custom who cares nobody's gonna interface with my game right i don't need nice api hey is this udp i'm gonna send the packet if it arrives that alright if it didn't sure i'm gonna uh solve the problem on the server side and i'm gonna deal with this delay right organic retracement in certain situation even the idea of feature or free transmission sometimes you don't need it that's why video always try to go through the udp path right video is very hard to go video through the tcv because like yeah if if a frame is missing from a video sure right who cares right it's like one glitch but the text and the other one sometimes you have you need the transmission that's why i want you just to have this framework of understanding look into your use case and see why am i doing this why am i entering http 3 why i need the grpc why do i need all that stuff you might you you might have answer you might your answer might be oh because it's hype if that that's your answer then probably you have to rethink all what you're doing i'm going to end it here i think i've been babbling a lot but yeah thank you so much guys for checking out this content and make sure to check out the other content this channel i have over 600 videos by the way some someone comment is like oh jose i love your content but you don't have enough videos it's like what 600 videos is not enough i mean i talk a lot i mean okay maybe youtube is not recommending my content enough but anyway check out the content uh check out the show it's the same thing is available on spotify podcast apple podcast all that jazz um go to husseinus.com podcast to get to get the show if you prefer to listen instead of watching on youtube bye damn love you so much if you reached until the end write a comment it's like hey i already end because this was this way i know it's like some some of you are dedicated watching 30 minutes i don't even know how long this video is but yeah appreciate you guys love you so much i'm gonna see you in the next one you guys say awesome all this good dobayo masala

Channel: Hussein Nasser

Views: 13,047

Keywords: hussein nasser, backend engineering, grpc, grpc http/2, http/2, http/3, quic, grpc google, grpc protobuff, grpc http/3, grpc h3

Id: pV06O5FIeuU

Length: 47min 6sec (2826 seconds)

Published: Thu Sep 02 2021