What you need to know about Streaming APIs with Luis Weir

Kevin Montalbo

Welcome to episode 64 of the Coding Over Cocktails podcast. My name is Kevin Montalbo, and joining us from Sydney, Australia is Toro Cloud CEO and Founder, David Brown. Good day, David!

David Brown

Good day, Kevin!

Kevin Montalbo

Alright! Our guest for today is a Senior Director of Product Management at Oracle Hospitality responsible for Integration & APIs strategies for all hospitality products including the #1 PMS worldwide OPERA, which is used by more than 40,000 hotels world-wide. Prior to that, he was with Capgemini UK, serving as the CTO for the Oracle Practice and also as a global API Champion. During this time, he helped many flagship customers define and execute their global API strategies as well as implement multiple technologies to address a variety of integration and cloud-native needs.

He is the author of many articles and white papers and has authored 4 books on the topic – including the popular title Enterprise API Management (July 2019). Ladies and gentlemen, joining us for a round of cocktails is Luis Weir! 

Hi, Luis! Nice to have you on.

Luis Weir 

Hi!

David Brown

Hi, Luis!

Luis Weir

Hello!

David Brown 

Four books. That's quite a lot! We often get the comment about how challenging one book is, but four books? You're a prolific writer.

Luis Weir

Yeah, I would say I lost my hair. So, you know, it wasn't easy, but if you pick a topic that you really enjoy, that's the entry curve, you know? That's how you start, and then you go from there and then you keep going and going and going, and then you realise, wow. Four. Yes.

Kevin Montalbo 

Yeah. So let's talk about your book Enterprise API Management, you dedicated an entire chapter of it to the business-led API strategy, where you said that API programs should focus on our business outcomes. How important is it for companies to realise the business value of APIs?

Luis Weir 

Well, in my opinion, it’s the number one factor. And let me just take a step back and give you a little bit of background on why I gave so much emphasis on business in my book. I was, as you said, helping many organisations find and realise their APIs strategies. 

So, some organisations were more clear and bold as to what we're trying to achieve. For example, they're undergoing a digital transformation and they wanted to utilise and create an omnichannel strategy where experience from a user perspective was consistent across multiple channels, right? For example, if I start an order online through the web browser, I could then open my app, see the same order at some stage and then continue from there. 

So, in those organisations, the outcome that they were expecting is, “I want to digitalise my organisation, meaning that I need to  expose my information assets and my functionality such that any channel application can get access to the same information at any point in time.” 

Other organisations, however, just follow the boss, like, “API is a thing and we need to do it.” And so, organisations invest a lot on the platform and the technology aspects of it, not necessarily understanding what they were trying to do with it. Basically, an IT-driven project. And, I saw a lot of investment going into this project without really realising any business benefit. And then what happens is that these projects tend to die, right? Because, you know, what you would keep paying for is IT infrastructure that no one is using, right? 

At the end of the day, IT technology is there to help the business. And APIs are just a component of the overall technology landscape the organisations are making use of in order to be a better business. I come from an SOA background or service-oriented architectures background, and APIs really realised the basic benefits that we wanted to achieve with the “traditional,” as I called in the book, service-oriented architecture, but couldn't because we focused too much on technology and heavy governance, as opposed to what is it that these things are trying to do so the business actually benefits from it. 

So, a business-led API strategy is really just that. It's being able to understand what is the business problem we're trying to solve? What is the business outcome that the business needs in order to succeed? And how are we gonna measure that success? For example, there was an interesting discussion on Twitter the other day, precisely about this point. Not all APIs in our organisation start with an internal API,for example, to expose data or whatever. Some businesses start from the API itself like Twilio, right? So, if the business is to make some information or functionality available and then charge for that use, then it's not about what business outcome you're trying to achieve. The API is your business and everything is around it, right?

So, it's super important, as I said. And what I felt when I wrote the book is that there was not enough emphasis on that. A lot of talk was about the API as the goal and API as not what the API system means to our role. And that's why I put so much emphasis on that and why I explain a lot of different ways to understand what potential problems the API is solving and how to measure that success to make sure that you are really achieving that goal. Hope that answers your question.

David Brown 

You talk a lot about your experience with your clients when you're consulting and deploying API strategies for them. And you said some of them wanted to take a technology-led approach as opposed to identifying the business value. Could you share with us some of the stories, some of the success stories, some of the failures, you don't necessarily need to mention names, but yeah. Where do companies go wrong? Where do they go right? Are there any particular use cases which stood out to you that you could share with us?

Luis Weir 

And so, organisations invest a lot on the platform and the technology aspects of it, not necessarily understanding what they were trying to do with it.

Yeah. There are plenty. For example, I just mentioned one, they focus a lot on platforms. Like, “Let's implement a platform,” right? And without actually understanding how to enable the users of the platform to deliver value right from it. And therefore, it just ended up being a very big, expensive IT project. So that didn't succeed. 

Other organisations, for example, are more targeted as to what they're trying to do. I can talk about one very big, big supply chain organisation. They understood the value of their information and they understood that their information was locked in multiple legacy systems, right? So for them, being able to offer access to those back systems and information within which was their main asset was the number one priority. And then they wanted to build from that. So that's a typical, internal API use case where  you have all this information you're being challenged by competition that are being more digital on the cloud.

And therefore, API becomes actually part of your architecture from day one. So what do they do? This organisation is actually more than a hundred billion dollar organisation, the largest supply chain organisation. So, you can probably deduce which one I'm talking about, right? Externalise these information assets so it could be reached in a consistent way across any channel. Of course, the problem they had is that it wasn't one legacy, it's multiple legacy systems. What do you do, right? That's where architectures like CQRS, for example, Command and Query Responsibility Segregation, and even big data come into play, where you're able to use technologies, for example, streaming in order to extract data and put it into some sort of data mesh, right? Well, data mesh is now the new thing. But, you know, when I wrote the book, it was more like data lake, or big data, such that you could access that information consistently for reads. 

And then for writes, it was a little bit more complicated. But then you could still build a robust integration layer that could then do the writes and updates against the system of record for that particular record. So, that project was actually quite successful. And I then moved on from consulting to product management. But before I left, the last workshop I had with the customer was around how to monetize the data. And if you see my Chapter One in the book, I talk about the API value chain. 

And the reason I'm talking about this customer in particular is because they really did follow it. They understood that, “Okay. Information is my asset, and I need to make this asset available. Where do I start?” Okay, let's start by having a robust API layer that can be consumed by multiple channels, by multiple applications. They're internal and maybe in the future external and then build from that. 

So, they started enabling the mobility applications. They started enabling B2B portals. And then they said, “Well, hold on one second. I have these assets, and I think some of these assets might be valuable for other organisations to transact. Maybe I'm able to monetise that.” So, let's explore this a little bit more. Let's explore how a potential API monetisation strategy would look like. And how do I actually do it? What components of the architecture do I need in order to do that?

And then we started talking about [how] it's not just the API platform you're talking about, you need to understand what is your API monetisation model? Are you gonna charge for a call? Are you gonna charge on a tier basis? Are you gonna charge a base on share revenue, for example. Are you gonna charge a transaction fee? Is it gonna be a premium and so on and so forth, right? And, then you realise that, “Okay, it's not as simple as I wanna charge for APIs,” right? You really need to understand the intrinsic value of the information to the consumer of that information and what value that the consumer of that information is willing to pay for that data asset that you hold.

And then you realise that it’s business. It's not API anymore. You're talking about the business of the API and not the API itself. And the domain knowledge becomes absolutely crucial at that point. And I kind of say that now, in my new role in Oracle Hospitality, where I'm responsible for API products, and in an API monetisation strategy that's been quite successful. I could talk about that later. But it's a very good example of where the value of information and the functionality welfare is understood. 

In hospitality, getting access to the information where reservations are held and where inventory is held is absolutely crucial. I published my book in 2019 just before the pandemic. And I think, well unfortunately, my book sold a lot because API, all of a sudden, became absolutely critical. Why? Because now everything needs to be digital, right? Same with hospitality and even more. All hotels have to modernise overnight. They're like, “Okay, now I need to be able to check in online. I need to be able to check out online. I need to be able to order food online. How do you do that?” Well, APIs. 

What happened was that the hospitality industry two years ago wasn't as digital as, for example, the airline industry where you have been able to check into a flight, and go into the gate with your phone for a while. But now that's changed in hospitality. Overnight, all of a sudden, everyone wants to do that in a hotel as well. You want to go check in and go give your details, key in your phone, and then open the room key without having to even go to the front desk to talk to the agent and check in or anything like that.

But doing that means that you need access to information and functionality exposed at the property management system, which is the system used by the actual hotel to manage the hotel and the guests, right? Especially post reservation. Everyone understands that. We think of hospitality and we think of online travel agencies, like Booking.com or Expedia, but there's so much more to it. And everything; all that API network, all that API connectivity that happened behind the curtain, all integrations were enabled through APIs. So a success story as well, back to your question is for us, in Hospitality, we had to create a robust layer of APIs overnight to open operations. 

So startups and established organisations could innovate in hotels to digitalise their aim and guest experience. And that really happened overnight. Many have said that the hospitality industry underwent a 10-year transformation in two years, like the speed of transformation that has happened in hospitalities. Unbelievable. And if you look at what enabled that transformation, it was APIs.

David Brown 

Amazing. I mean, there's so many great examples there of that business-led value of the APIs and whether it be forced on the organisation through a pandemic or through strategic planning, there's some really interesting stories there. You also mentioned a couple of things about, “Oh, we used to call them data lakes. Now, the latest thing is data mesh,” and that sort of made me think with all your experience in terms of the implementation of APIs, is it the same story still going on over and over, you creating business value in the implementation of the APIs? Or have you seen any changes to the priorities of organisations or the projects that they're approaching with their APIs?

Luis Weir

Innovation is more about understanding what you can do with the APIs.

Well, I mean it depends, right? It depends what the organisation is trying to do. Again, it goes back to the API value chain and the business problem we're trying to solve. But before we answer this question, I forgot about one very good use case back to your previous question. About API regulation, I worked on a project in Sweden for a credit card company. They have to implement APIs for basically PSC II compliance, right? And this is another example where APIs are more than an enabler for transformation. It's also a necessity for compliance and regulation, and the same goes with GDPR in healthcare. You see a move to FHIR and so on and so forth. So, yeah. 

And now, back to your new question. Well, it's interesting, like, I think APIs have now, or APIs are starting to become a norm. Let’s talk about APIs. Like, if you're implementing cloud native and the shift to cloud native has been going on for a while, but I think now it's mainstream. APIs are not the thing you talk about because they’re already part of your architecture, right? APIs become part of your way of building cloud native applications. So the conversation is shifting as to what it is that we need to do as an organisation to compete. And how do we do that? And therefore, you see the conversation shifting into multiple areas. 

For example in hospitality, sure. APIs are our honey. The APIs are the thing that the bees are trying to get to, but the bees themselves represent a community and are building that community. And enriching that community and growing that community, making sure that that community has all the tools, all the information, all the aid, all the knowledge, all the understanding they need in order to take advantage of that honey, becomes as important as the honey itself. And without understanding what it takes to handle that community than a strategy overall, your digital strategy could not realise the benefits that it could. 

So, a lot of my time in my role right now, I would say like a good portion of my time goes into that. Not so much the APIs themselves, but, you know, how do we handle the community? In fact, I have a team that's just dedicated to community management because it's that important, right? How do we enable them and what tools do we give them to be successful and so on. 

And another part is about our customers trying to innovate, right? And that's another part of the answer to your question. Innovation is crucial. And how do you enable innovation? APIs are an enabler to innovation, but not the innovation itself. So, how can you enable innovation? It's more about understanding what you can do with the APIs. It's more about domain knowledge than it is about my API semantics and, “I'm using the latest and greatest APIs specification based on OAS 3,” and all the technology discussion, right? No, it's actually not about that. It's understanding the domain capabilities that your API is delivering and how to leverage that in order to deliver innovative use cases that can either disrupt, what's called a “disruptive innovation,” or just innovating a way that you are enabling an existing business to be more different and therefore keep up with the competition that's going super fast. I think I answered your question.

David Brown 

Yeah. So, it's like, they've built the foundations of digital transformation with their API strategy. Now they want their community to run with it. And so it's fostering that community to understand the value proposition they can get out of those APIs, come out with new, innovative business models and use cases from those APIs.

Luis Weir 

You realise that handling people, the communities around you is such a fundamental aspect of the API strategy and it’s overlooked in many cases.

Yeah, David. And it's understanding the communities. Like, it's not one community, it's multiple communities and different communities or different audiences that may have different perspectives and different ambitions. And they need to be treated differently. For example, our vendor community is completely different to our customer community. In fact, it's so drastically different that the conversations tend to be different as well, but we also have internal communities within the product organisation that also want to use APIs, to deliver better UX, to deliver innovation, to deliver detail assistance. And again, the conversation is different. So, you realise that handling people, the communities around you is such a fundamental aspect of the API strategy and it’s overlooked in many cases. We focus on the API itself and how good my API looks.

And sure, we're talking about API documentation a lot, but it's not just that, right? There's a lot of “people” aspect to it. My team has a lot of interactions like you and I are having right now as part of this strategy, because it's important; because you're dealing with humans at the end of the day, and you need to get the feedback, you need to understand their needs. You need to have that conversation and you need to facilitate that conversation. So, the tools that facilitate that conversation and make you more accessible, I cannot stretch enough how important that is. It's super important.

David Brown

We've talked about API strategy and business-led development with business use cases. And we've talked about adoption and fostering API communities around new, innovative uses of the API to digitally transform the organisation, take them into new business models, but we kind of skipped technology in between those two aspects. There's obviously some sort of technology to facilitate deployment to the API. And you talk a bit about architectural styles in your book. How should a developer choose between some styles, such as REST, GraphQL, gRPC, Async, you know? The list goes on.

Luis Weir 

I love this question. I wrote a book which I started in 2017 and finished in 2019. That's because I wrote another book in between. The reason I explained the date is because back then, the debate was starting, right? Like the SOAP versus REST debate was ending, GraphQL was emerging, and RPC was sort of becoming more mainstream. And funnily enough, the debate hasn't ended, right? Like, there's still a lot of debate out there. 

And that's why I decided to cover the three technologies in my book, because I wanted to go beyond. Like, it's not just REST. If you understand the evolution of APIs, you see that we have a huge history of RPC, that then was all of a sudden, disrupted by REST as a new architectural style or representational state transfer, you know? Roy Fielding and his dissertation in 2009. And now we're kind of going back to RPC, because if you look at GraphQL, it’s really an RPC-inspired — I would like to say a protocol — because I don't think they explicitly call it out as RPC, but it really is RPC-like, especially when you compare it to REST. 

I think it's super important to understand what the different technologies offer, how they do certain things differently for better or for worse. What I like about REST is the simplicity in principle, right? So if you keep it simple and you understand REST and how an API can be structured in resources in a way that they’re deducible and human readable, right? 

REST is super intuitive to start consuming. It's not like you need to be an expert in object orientation, or remote procedure calls in order to deduce what you can do with an API and the resources within. It’s so human readable that what we noticed as well is that a lot of the expertise in REST actually comes from tech writers who started working on the documentation aspects of REST and then evolved their knowledge into what REST itself is, and actually not working to define APIs itself. That’s how simple it was and that's also why there were annotations like API Blueprint, which by the way I absolutely love. It didn't gain that much popularity, but API Blueprint is an annotation.

That makes it like it's markdown. So you can describe an API by just writing markdown text. And it's really that simple, right? So I like the simplicity, the intrinsic simplicity in REST. And where I think REST starts falling short is when you need to address use-cases that require actions that are not easily modelled with a HTTP bearer. Like HTTP bearers are super straightforward, right?. But what if you need to process something, how do you express that in REST? 

And then there is a big debate on, “Yeah, well, you can use POST.” But POST is not necessarily a process, right? Like, that's not the action you're trying to express. In GraphQL or RPC, for example, you can easily model that by just explicitly calling it out what it is, right? “Process a booking,” that's your operation. Full stop. So, I like the fact that you can express intents with RPC-based protocols as opposed to trying and working around it because the standard of the architecture style is limiting you to expressing that action. 

Again, a lot of this is a little bit subjective, because you can do both with both. But I'm just trying to explain my personal choices in terms of what technology I should use. In Hospitality, in my role, for example, we actually use both. We have over 3,400 REST APIs, and they are being successfully used, but we started out with GraphQL. And what we're seeing is that GraphQL can act as a very good aggregator because our APIs are so granular, maybe with GraphQL, we can take a step back and make it more coarse-grained functions that can orchestrate multiples. 

And in fact, that's a very common use case for GraphQL, right? Where you put GraphQL as an orchestrator of APIs. It's not the only use case, but that's one that people do talk about a lot. But also, what I like about GraphQL, for example, is subscriptions. And it's not a topic that you hear a lot but you will hear it more as GraphQL starts to become more mainstream, which is what we're seeing now. So subscription basically is a streaming capability within GraphQL that enables push. How do you do that in REST? Again, it's something that you wouldn't naturally do with REST, because REST is meant to model, request, reply calls, and then the webhook came into play, which is basically a way to work around the limitation. And therefore, what you basically do is you define two APIs. One for calling another, one for calling back. 

And therefore that's how you're able to deliver push capabilities with the REST product. Of course, OAS 3.0 and Async API allow you to model that, but that wasn't there in the original spec. GraphQL, on the other hand, already has it intrinsic within the operations that you support, which is invitation and subscription. And it's super straightforward. So, I like that a lot about GraphQL. 

And gRPC, in my opinion, is a different beast altogether. gRPC uses protocol buffers, HTTP/2, and I think I said this in my book. And I expressed that in my comparison. If you want to have a good API strategy, an important factor, as it is in any API strategy, is to speak to the market. HTTP/2 and gRPC are not yet super consumer friendly. It's not like you can use your browser and start playing with it. It's not like you have a hundred clients out there. Not like GraphQ, for example, that you can just use and play around with, gRPC is a little bit more complicated. It requires a little bit more technical knowledge. And therefore, I feel that gRPC for a public API, it's not necessarily the best protocol. In fact, I don't remember actually seeing that public gRPC-based API. I'm not saying there isn't; I'm just saying I don't recall it right now.

But for internal microservice-to-microservice communication, it’s absolutely fantastic. So, what I have seen a lot is you use gRPC for your mesh communication, right? Where you have service-to-service talking amongst each other, using gRPC in both directions, because gRPC is by direction and it’s super efficient at doing that. And then they expose the capabilities with GraphQL. And this is a perfect match because GraphQL is “gRPC-oriented ,”as they call it. And therefore, you're not shifting paradigms. 

If you want to expose gRPC operations through REST, you're going into a paradigm shift and then you need to match up, right? How do you express these remote procedure calls and their actions into REST? So, you can have that mapping and that REST needs to look elegant. Otherwise, it's going to be what people call “RESTPC,” which is kind of like a Frankenstein of what REST is meant to be and RPC.

David Brown 

You briefly mentioned streaming there, in relation to GraphQL subscriptions. I know one of your passions is Streaming APIs. Can you run us through Streaming APIs in the use cases for those?

Luis Weir 

I'm going to use hospitality as an example, because that's really where I developed this passion. If I'm honest, I've always been passionate about push technology. When Async API came into play, I was quite excited as well, because now we have a way to express, to model, push interactions. But I really didn't hit any use case where this was an absolute necessity. But in hospitality, it is an absolute necessity. If you think about the hospitality life cycle, especially from a guest perspective, it's by the direction. It has to be by direction. 

When you do a booking, what do you want? You want a confirmation of your booking. How does that confirmation happen? And how is that delivered? But as you continue through the experience, you get offers to upsell. You get notifications on things like selecting your room. And then when you check in, there's so much opportunity to continue that experience in a way that creates a directional interaction as opposed to a one direction interaction. 

But also, if you go beyond and look at other use cases, things like ARI, availability rates and inventory updates. When you booked through Booking.com, how is that inventory kept in sync with a system that holds that inventory in the hotel? Like, if a room all of a sudden goes out of service, how does Expedia know about that? That inventory may be gone for a few days. But then you may get a booking and Expedia’s assuming that you have more inventory than you actually do because of various reasons, like, for example, our room going out of sales. 

So, maintaining that instant synchronisation of information in hospitality is absolutely crucial. In fact, our audience pays for it. And back to the value of information, in this case, the value of information is not just information itself, but how all up to date that information is. Another example is Forex. In Forex APIs, they will value the terrible dateness, I suppose. Like, how up to date that information is. That is the intrinsic value that you're paying for. 

And being able to deliver that has a price and the most efficient way to deliver that is through, I like to call it “real time,” although I'm corrected. Sometimes, it's not really real time. It's near real time because nothing follows, nothing goes at the speed of light. The reason I like to call it real time is because the trigger to push that data has to be real time. And then of course there will be a lack and it will take some time. But the bottomline, what I'm trying to say is that this real time integration, where you are instantly pushing as fast as you can a change, an event that happens in your system, the faster you can do it the better, right? [It] any use cases in hospitality, such as revenue management systems, which are the ones that enable us to calculate rates, because hotel rates change on a daily basis. 

But that's based on information that you get real time and based on what your room inventory looks like on a given day, for many reservations you've received and so on, but also things for upselling, right? Like, I want to know when you’re going to book because I want to make an upsell offer. Also, for example, if you are trying to improve your guest experience through communication, right? Like, there are so many different use cases in hospitality for that, which communities are willing to pay for. But also, our customers want to benefit from for multiple reasons, like having a data warehouse. And I want to keep it up to date. I don't want the daily batch of data. I want it instantly. I want to instantly have an up to date representation of all my hotels inventory in my data lake or my data mesh, which I said before is a new thing.

And therefore, real time becomes critical. So more and more, or at least what I see evolving into the modern cloud native architectures is what I call real time communication. It's not anymore about calling an API, it's about event streaming. It's about being able to have all these events updating the systems that are around it, right? So every system is in sync. And I think this also relates to your previous question about what's changing. This is one of the aspects that's changing. The event aspect is taking over more and more and more. And at least, in my context, streaming APIs have created so much enthusiasm and excitement that we're just giving it more focus, right? 

And the use cases are always huge. Like, the amount of data that we're talking about, the number of transactions that we're talking about are always huge. If you have a hundred priorities, we're talking about thousands of events a sec, right? And therefore, the infrastructure aspect, back to your technology question, becomes fundamental. You really need to have a solid infrastructure, a solid architecture that can handle those events in a consistent and efficient way. You need to think about things like not throughput only, but about pressure for example, offsets. How do you do a parallel procession of events, guarantees like delivering only once, and all of these things?

David Brown

Of course, the technology aspect is one of the challenges and there's technologies like Kafka to facilitate event streaming. But what about the standards around event streaming in terms of APIs? Because we're talking about an event streaming API. So, you mentioned Async API. We've had a previous guest talk about Cloudevents.io as a global streaming type standard. Are there any standards emerging around streaming APIs?

Luis Weir 

You touched upon two that are super important. Async API has become more popular, and I think I touched upon it before, and then Cloud Events. But for me, they are not necessarily competing standards, but more like complementary standards. Cloud Events define a good structure to model your event objects, do it consistently. And having that, adopting that standard has a benefit, because it becomes a lot easier to at least consume the metadata of your event. And then, the data of the event, to see the cloud event standard. It makes it very flexible to have any actual body for that event. Even in XML, actually. 

So, you know, I think it's nice. Especially when you're implementing cloud native solutions that make use of functions fast, being able to consume events that look similar, it's super important. For me, it's kind of like a given. I think on the other hand, it is a specification to model asynchronous communication. It's more about modelling the interaction and in modelling the interaction, you have to also model the data within. But that data within could be a cloud event, with a different data structure. So, it's up to you whether you want to make use of the Cloud Event format or whether you want to do something else, like you can model that with Async API. No problem.

I’ll mention another one, GraphQL subscription and there's another one within GraphQL that is talked about even less; it's called GraphQL live queries. As GraphQL becomes more and more mainstream, this is going to become more and more mainstream. For example, Amazon AppSync; it's a big deal. And they will be competing, offering some many other cloud providers that may use GraphQL for app synchronisation, for streaming use cases, back to my previous examples. I like GraphQL a lot because of the reasons I mentioned before, and I keep everything in one single standard. So, I don't need to have one standard for a request-response and another standard for push. I can just keep everything within one protocol.

But there are new ones. One that I spoke about in my book, and I haven't followed it recently. It's like Vulcan and also RSocket. So there are emerging technologies coming up that are not yet mainstream, but there is a lot of involvement. Another one that I really liked and I'm keeping an eye on more frequently is HTTP/3. Like, there was a big fuss about HTTP/2 being super efficient because of multiplexing communication and whatnot. But because HTTP/2 still makes use of TCP/IP, which has to acknowledge the sequence and has its limitations. There was a study that showed that the performance throughput on HTTP/2 for APIs can actually degrade as you do more and more multiplexing because the multiplexing is limited by the limitations of TCP/IP on itself.

HTTP/3, because it's moving to UDP, which is a streaming product, it's not doing the acknowledgement and all that. Therefore, you can benefit from much higher throughput. And then the sequencing, the acknowledgement aspects of the protocol is left to higher level protocols on top of UDP, which is the HTTP protocol itself and therefore, that can deliver performance. I don't want to claim,I'm an expert in HTTP/3. I just do some reading like you probably have done, but I just find this super interesting and I keep an eye on it, because I can see this evolving a lot. And I can see this becoming mainstream. So, though it's not a standard per se, it's more of a transfer protocol, I see that this is going to enable new technologies in the future that I think can disrupt. So, that’s my personal perception of where things are going.

David Brown 

I can see it enabling a fifth book.

Luis Weir 

Maybe, maybe.

David Brown

Luis, it's been a pleasure to have you on the program. Thank you very much for joining us on Coding Over Cocktails!

Luis Weir 

Pleasure! Thank you so much for the invitation, both of you.