Turning the Cloud Inside Out

Today, I'm going to be talking about turning the cloud inside out, creating a cloud programming interface with GraphQL. This is kind of my approach as a front-end developer coming into building cloud apps using GraphQL with AWS and kind of the stuff I've learned over the past few years when I was working at AWS.

So who am I? My name is Nader Dhabit. I currently and just started working at a new company called Edge and Node. Edge and Node kind of creates and supports protocols and apps and dApps in the Web 3 and DeFi ecosystem. If you're interested in learning more about what I'm doing now, hit me up on Twitter, dhabit3. I'm also a web and mobile developer by trade. I do a lot of teaching. I do a lot of writing, and I do a fair amount of open source.

So what is this talk going to be kind of broken up? We're going to be kind of first talking about why GraphQL, like why people are using GraphQL and maybe the current state of the GraphQL ecosystem. We're going to talk about the philosophy around some of the stuff I'm going to be presenting today. We're going to look at some way to kind of implement what I'm talking about into the cloud and kind of turn the cloud inside out with a GraphQL schema representation. And then we're going to look at a little bit of code.

So let's first talk about GraphQL. I'm not going to kind of talk about what GraphQL is, in the sense of like the technology and how it works together. Instead, I'm going to be talking about more of like the benefits of why people might use GraphQL, as well as where GraphQL currently is in the ecosystem. So GraphQL, what is it? It's an open source data query and manipulation language for APIs and a runtime for fulfilling queries with existing data. By now you've probably heard a lot about GraphQL, so I don't want to bore you with a ton of the details here. Just think of GraphQL as kind of like a replacement or another option besides Rust. We're going to talk about some of the benefits. And these are kind of known benefits, but also a little bit of spin on like why I like GraphQL and why I've seen a lot of people picking it up, especially when I was working Type checking. You get type validation and checking out of the box. This works really well with a lot of the applications that I'm building these days with things like TypeScript and Dart with Flutter. Real time is part of the actual specification. Instead of figuring out whether you want to implement WebSockets, polling, servers and events, GraphQL typically has a specification on how you can actually do this. The implementation details are up to you, but a lot of people are typically using WebSockets to implement subscriptions, but when I go into a GraphQL schema, I can look at the subscriptions and understand how to actually take advantage of those. As a front end developer, I don't really need to understand anyone's own implementation details under the hood. It makes it easy to go between APIs and understand how the real time part of it works. Query efficiency, you end up with a single GraphQL endpoint, first of all, but with that GraphQL endpoint you can send as many requests as you would like into a single request. So there's a couple of things that come out of this.

First of all, if I want to maybe do an own load event when my app loads, I can send multiple operations in a single GraphQL operation. So I can say query for the user's data, maybe query for the data for the products for like an e-commerce store that I won't render on the page. Maybe even get like a shopping cart data that I need. All of this can be sent in a single request as opposed to multiple requests. But also it prevents overfetching and underfetching in the sense that once you've built out your GraphQL queries and mutations, I guess in this case it would be queries, you can ask for exactly the data that you would like without having to write any additional code on the back end. So for a app that has multiple views, so maybe something that has a web interface as well as a mobile interface, instead of having to write different API endpoints, you can have a single API endpoint, fetch the lighter data on the mobile app and then the heavier data on the web app, and it all just kind of works without you having to write any more code.

A really cool thing about GraphQL is that it's self-documenting. It auto-generates your API documentation. This is done using GraphQL introspection. Introspection is essentially the ability to query which resources are available in the current API schema, and once you're kind of given the API via introspection, you can see the queries, types, fields, and directives that it supports. One of the big things that I'm going to be kind of driving in this talk today is consistency. So for me, a big thing about building software and learning how to be a developer, an efficient and good developer, for me, and my career has been finding things that allow me to learn once and use in multiple places and be efficient. So for one of those things is React. As a React developer, I learn React, I can now build web apps, but I can also build mobile apps, desktop apps, all kinds of stuff people are doing with React. Someone, you know, is presenting how to actually build, you know, not only slides, but in a video editing software, stuff like that. You learn React, you do a lot of stuff. GraphQL, I kind of bucket in a similar way in the sense that once you learn GraphQL, you can actually jump into anyone's API, not only within your own company, but within any company. So you leave, you join another company, you know how to use GraphQL, you can immediately become productive. You look at the graph, you know what's going on. But what's even more interesting is some of the things that I'm gonna look at and show you in just a moment where people are implementing these larger and more interesting implementations of graphs and different ecosystems, and me as a GraphQL developer, I can actually go ahead and be very, very efficient in those different layers without having to learn anything. And this is something I tweeted out not too long ago, GraphQL, learn once, create, read, update, delete and subscribe anywhere. That's kind of a play on the React, learn once, you know write anywhere or whatever. I'm sorry, that was React Native. Generally, it's the same idea.

And then the second thing I'm going to be really driving home, it's that consistency but also the implementation of GraphQL in a microservice architecture. GraphQL is a great fit for complex system and microservices like I laid out here. But essentially by integrating multiple systems behind its API, GraphQL unifies them and hides their complexity behind this graph. The GraphQL server is the thing that's then responsible for fetching the data from the existing systems and packaging up in the GraphQL response format.

Now let's take a look at GraphQL. At this point, GraphQL is definitely mainstream. AWS, Netflix, Twitter, Peloton, Reddit, Twilio, GitLab, Twitch, PayPal, Spotify. I mean, you name it, most companies these days that are large companies, somewhere, they're either using it for mission-critical stuff or they are using it somewhere at least. So you're seeing a lot more of this widespread adoption. It's kind of mainstream at this point.

Something that is really interesting to me is developer sentiment. I guess developer sentiment is important to me, engaging what will continue to be a thing and what will eventually die out. At the end of the day, if developers enjoy doing or using a certain thing, it's much more likely to not only stick around but get even better. As the tooling gets better, more people are in the ecosystem, more feedback is coming in to the people that are building stuff and they're making it better. Developer sentiment is really high across the board for GraphQL and all of the different surveys that I look at. These surveys don't really, of course, tell you the entire story, but what they do tell me is that developers enjoy using GraphQL, and that kind of tells me a lot. I do care about what developers care about because I care about understanding where the industry is headed, so that I too am headed in the same direction. That's kind of a personal preference because everyone is different, right? Like, whatever, do the things that work for you. But for me, what's worked is heading in a direction where I know that if I spend some time investing and learning and doing something, I'm going to be able to kind of get my money's worth out of it in the future, meaning maybe I'll get a job using this skill set or I'll do some consulting or whatever. Maybe I'll write a book.

That being said, what really this talk is about is the idea of using GraphQL as an API gateway. I'm going to talk about doing this in a few different ways before I get to Cloud. I'm going to talk a little bit more about microservices. I'm going to talk about an interesting use case around third-party APIs, and then I also want to talk about Blockchain and Ethereum. This has a little bit to do with the job that I currently have. Let's talk about microservices. You can think of microservice architectures in a few different ways. A very naive implementation might be to take a bunch of different endpoints that you have and make them accessible within your app, and you're hitting this one endpoint in AWS. Maybe this one endpoint that was set up in DigitalOcean or whatever, or maybe you have different services that you're using, but they're all different microservices and they're all different endpoints and they all have different APIs. This isn't typically the proper way to do it, because what you end up with is a very inconsistent client-side developer experience, and you don't understand how anything is done because everything is done a little differently.

What you tend to see is someone putting an API gateway in front of all of these microservices. You end up with a consistent API endpoint, and then you're using different payloads, different URL parameters, stuff like that. Some of that stuff is abstracted behind this API gateway, and you're able to kind of have a little bit more consistency, I would say. But really what's becoming really popular within AWS and a lot of customers that I'm seeing using it, but also outside of AWS, this is becoming more and more of a popular thing, is just dropping in GraphQL as your API gateway. Because when you do this, you're kind of getting all of the typical benefits that you get out of a traditional REST API gateway, but with all the different benefits that GraphQL has to offer. Definitely the type checking in the real time that come out of the box from any mutation, which is really awesome, query efficiency, API documentation, all the stuff that we talked about already.

Now, that's cool and everything, people are doing that though. Let's talk about some more interesting use cases. One of them is which Sean Grove is doing over there at One Graph with third party APIs. One Graph is really cool because it puts together a bunch of different services behind a single GraphQL endpoint, a bunch of different APIs that were traditionally REST APIs. Some of them might actually be GraphQL APIs as well, but the idea is that you have this single Graph that you're able to work with. Now what that means to me as a developer, if you've ever worked with something like the Twitter API or the YouTube API or Netlify, Salesforce, Air Table, any of these APIs, they're all going to be implemented a little differently, right? But what if there was a single way to actually do this? What if every single company was implementing their API layer in the same way? Well that's kind of what One Graph does, and that is what you can now do with One Graph. So you can query APIs like Air Table, Salesforce, CloudFlare, Dev.to, Dribbble, Dropbox, MailChimp, Google, YouTube, Twitter, Trello, Stripe, all kinds of services. I think there's dozens of services that you can query all from this single graph. So it's really interesting. I really recommend you trying it out because me as a developer, I can now jump into this graph and become immediately successful without having to read any documentation, and whatever documentation I need is right there with that GraphQL schema introspection like I mentioned earlier. It's self-documenting. It's super nice. So check out One Graph. I really like the idea of kind of doing this, and I think that there may be even a couple of other people doing similar things with these third party APIs.

The next thing I want to talk about is blockchain and Ethereum. And within this space, within the decentralized finance space and the Web 3 space, you have this idea of decentralized apps or what are known as DApps. You know, with all of this ecosystem, there are all types of different applications kind of like coming out, being built in this way using these technologies, I guess you could say. So things around lending and borrowing, token swaps, meaning kind of like changing currency with each other, investments, crowdfunding, payments, all types of stuff. So this is a really, really interesting space, you know, something that's interested me a lot. So let's take a look at one of these Compound. Compound is a money market protocol that's built with Ethereum. It allows anybody to or anybody or any machine even to easily earn interest by lending their cryptocurrency assets. The lent assets can then be used as collateral to borrow other assets locked in the protocol. As it stands, you can't really build great applications directly on top of blockchains though.

The problem is that you need to actually have data indexed and organized for efficient retrieval. So think about the web and what you might need to do if something like a search engine wasn't around. How would you find all of this data? You probably have to do a lot of work. Similarly with blockchain data, if you want to kind of get data out of the blockchain, it's a lot of time and a lot of work and a lot of effort. And most people, most companies end up indexing it on their own server, which kind of breaks the idea of decentralization.

So with blockchain, this indexing layer, that's traditionally the work that databases do in this decentralized tech stack. But that indexing layer was missing in the Web3 stack. And that's kind of where the graph comes into play. And the graph is an indexing protocol for querying networks, like Ethereum, IPFS, and the future other blockchains. So with the graph, anyone can build and publish these open APIs that are called subgraphs, making data easily accessible in the form of a GraphQL API. Before the graph teams had to develop and operate proprietary indexing servers themselves, which not only requires significant engineering and hardware resources, but it actually broke this important security property, or all of the security properties required for decentralization.

And the graph kind of solves that problem by offering this consistent indexing protocol. And it does this using GraphQL. Anyone can now build and publish these open APIs that are called subgraphs using this more easily accessible data. a lot of companies are using the graph now. A lot of different companies that are very, very popular have a lot of scale, I guess you could say at this point. So Compound, Uniswap, a lot of those NFT platforms are kind of using that, including Foundation, which is a pretty cool NFT platform for buying NFTs and art and stuff like that. So this is like another application of GraphQL. If you learn GraphQL, you can not only jump into all of these other APIs that I was looking at with OneGraph, plus all the stuff you might be doing in your day to day work, you can now also query blockchain data, which I thought is really cool. In addition to that, what about the cloud? This is really what I'm here to talk about. I as a front end developer started at AWS and I looked at the management console from AWS and I got really intimidated. Even as someone who has been working at AWS for over three years, I still am kind of intimidated by this dashboard. What I really would like to do, I want to create a schema like I want to do with my typical GraphQL APIs. I want to be able to kind of define the data that I would like to work with. So in this case, let's take a basic example again, we're going to look at a product type and a label type. And I want to have a couple of operations that interact with some data layer that kind of brings back this information. So how do I get something like this working within AWS, right? That's kind of the question I wanted to know.

I want to hit a different type of database for the search products query. And I want to hit a machine learning service even for my detect labels for image query. So how do I get something like this working within AWS, right? That's kind of the question I wanted to know. I enjoy using GraphQL, but I don't know how to put all this stuff together. Maybe even I want to do something more complicated where I have this get account information query, where we combine multiple different types of data sources, databases, and it all kind of returns into this single query. Just like the stuff you typically would do with GraphQL, how are we going to get this done in AWS, taking advantage of a lot of these different AWS services and stuff.

We're talking about building cloud APIs at this point. How do you build APIs in the cloud? There's two main ways that you do that with something like AWS. There's the API Gateway service, which is a REST API service, and then there's AWS AppSync, which is a managed GraphQL service. I'm going to talk a little bit about both of those. And within both of those, there are three main pieces, in my opinion, that you kind of need to understand how to work with. One is the execution environment. The execution environment is where you actually have your code running. This could be a server or it could be a serverless function. And then you have your permissions. So how do I have my function code talk to this database? And how do I kind of get that working? How do I set that up? And then finally, what are the different SDKs that I need to interact with these data sources? So I'm in this function, I'm writing TypeScript. I want to interact with this database. How do I actually do that? So those are the three things I want to kind of break apart here.

As far as the execution environment is concerned, you have two main types of execution environments. You have server full, which means you're running in a server that you maintain. And then you have serverless, meaning you're working in a serverless function. And serverful environment, you do have benefits. There's trade-offs in everything, right? When you're managing your own server, you do have full control over everything, meaning that you have the whole execution environment. There's no limitations other than the system that your server is running on, you could think, right? Which is good and bad, because you have more things that you have to kind of take into consideration as well. And the downsides though are that you have to actually do all this stuff and write it yourself. So you have to implement subscriptions yourself. You have to understand how to scale these subscriptions. You have to understand how to scale your API in general. You might have to implement caching. You also have to deal with the servers themselves, and all of the stuff around security, authentication, authorization.

And you have to think about all the GraphQL specific stuff, like malicious queries. So all this stuff, those are just things that you have to implement yourself. So trade-offs again.

Then you are gonna be talking about, we've talked about the server full. Let's talk about serverless. So there's two main ways that you can do this in AWS at least. One is using AppSync, which is a managed GraphQL service. And then the other is using Amazon API Gateway in AWS Lambda, which isn't really built for GraphQL. So I'm gonna kind of focus on AppSync. And this is a service that I'm a big fan of. If you've seen my YouTube channel, I don't work at AWS anymore, but it's still like my favorite cloud service to work with and it will be. AppSync is a managed GraphQL API service. Definitely recommend checking it out. But all what I'm gonna talk about kind of is gonna be using AppSync.

So what are some of the benefits of using serverless? The benefits of serverful, we kind of talked about you own the execution environment, but you have to do a lot more work. I think serverless kind of flips that on its head in the sense that you do less work, but you also have less control over things that aren't currently supported. So for instance, working with AppSync, you have built-in security, authentication and authorization. You have built-in subscriptions that scale up to tens of millions of connected clients, scalability, resiliency, all this stuff is taken into consideration. Caching is built in. You don't have to manage your servers. You have less code that you have to deal with and you're dealing with a serverless payment model. So instead of paying for this capital expense, this consistent expense, you're trading that for a variable expense, meaning that you're paying for the compute that's being used. If it's idle, you're not being charged.

So what are the downsides of using something like AppSync? You're limited by the API service that's provided to you. So if AppSync doesn't offer this and you need something, you're kind of out of luck. If you know your high-scale consistency, consistently over time, it could be cheaper to actually manage your own servers. I think serverless is especially well suited for dynamic environments where your traffic is going up and down, and you're not sure about what your traffic is going to be as far as on a cost model. Then also if you need any really long-running tasks, serverless is not a good environment for that. You need your own server for something like that typically. My recommendation, based on everything that I've done, everything I've worked with, I'm a big fan of serverless execution environment, AppSync in particular.

So take that with a grain of salt. I would try whatever you want yourself before I would make any decisions there.

The next thing is permissions. So now that we understand we want to use this or that server or serverless implementation, how are we going to now deal with things like permissions? In AWS, in Cloud, you have this idea typically of IAM, which stands for Identity and Access Management. Identity Access Management sounds more complicated, I think, than it is. So let's take a look at what that actually means.

Let's say I've spun up a environment, I've created this lambda function where I can write some Typescript. I have this DynamoDB table and I want to make an API call from, or I want to make a database query, I guess you could say, from my function to this database table. Now, by default, you have restricted access. So deny by default is what you're given for most Cloud environments. Meaning that if I try to access something and I haven't given it these permissions, then by default, it's going to say, no, you can't do that.

All IAM is saying, I'm going to give this resource permission to do these different operations on this service. I might say I want my lambda function to be able to create, update, and delete, and read from this table. Then once that permission is set using IAM, I can now start interacting with this database. We're going to look at how this looks in code in just a second now.

Then the last thing that you have to take into consideration, if you're working with one of these execution environments, is the SDKs. The good thing about this idea of SDKs is there's really just one main SDK you have to deal with on the server. Now, if you're working with AppSync, you can talk directly to some database like DynamoDB, Elasticsearch, or Serverless Aurora, or you can map your operations into this execution environment like Lambda and talk to any of the services that you like. You can run Node.js, you can run Python, you can run Go. All of these different execution environments have a AWS SDK that support all the other services. All you would need to do would be to import the AWS SDK and Node.js, and you can do something like this.

You want to talk to DynamoDB, we would go ahead and import the DynamoDB client and we would create our command saying we want to do something like scan, in this case, scan command. Then in four lines of code including the imports, not including the handler, we're able to scan this table and get all of the data that we want out of the table. There are hundreds of services that you can work with from this AWS SDK of pretty massive project. Let's say you want to work with the machine learning service like recognition. All you need to do is go ahead and import the AWS SDK. We're going to import the recognition client and the detect labels command. We construct our command, passing in the parameters. In this case, we want to specify the S3 bucket and the image that we want to detect labels of. Then we execute the operation and we have that return data, which is in JSON format in this example.

With that being said, I'm still confused because how do we actually put all this stuff together? We understand maybe that you need all these things, but putting it together is still very, very hard in my head at this moment. Let's talk about making this a little easier by tying all the stuff together and deploying something. This is where a lot of the tooling and stuff that we've been working on when I was AWS to make this easier, it's going to come into play.

There are a couple of different deployment options. Of course, you can go directly in the AWS dashboard and do all this stuff, but that's to me more complicated than using some of these tools that are out there. In particular with AppSync, AWS CDK, AWS SAM, AWS Amplify, and serverless framework are pretty, I would say, some of the easier ones to get up and running with. You can also use CloudFormation, which is a very robust, but it's also a very verbose way of doing this. I would recommend either using Amplify, serverless framework, maybe CDK if you're getting started. I'm going to talk about both Amplify and CDK to give you an overview of two different ways to do this.

With Amplify, if you want to add a GraphQL API, you just run Amplify add API. You don't actually have to spin up all of these different services. You don't have to deal with permissions. The Amplify CLI is going to write all of this infrastructure's code for you and wire this up together for you. Then from there, all you need to deal with is your GraphQL schema, and in your schema, you can then use these directives that are part of what's called the GraphQL transform library to model and deal with a lot of this other stuff for you as well. So let's say we want to have a post database in a DynamoDB table. All we need to add is this at model directive, and we're going to have now our table that's created as well as all of the resolvers that we're going to need for CRUD operations, list operations, and subscriptions. And then from there, we can modify our resolver code if we would like to. We also can model authorization rules. So in this case, I have this at auth rules directive that is going to give owner permissions to the item that's created. And there are all types of different rules that you can set here. In fact, there's I think seven rate directives that you can do other stuff with as well like modeling relationships between data. We can also say, oh, I want to map a GraphQL query or mutation to a Lambda function. And then within this function, we have that full execution environment. Now, all you have to do is add this at function directive and the GraphQL transform library will wire everything up for you using the amplify CLI. So as long as we have this function created, we can now go into this function, write all the business logic that we need and return an array of images. As long as it's coming back in the structure that our schema is defined in, then we're good to go. A super powerful using the add function directive. I'm a big fan of that.

So let's take a look at some actual code and in the code we're gonna look at a CDK. So with CDK, you might want to create a new project to do this, you just run CDK init, this will bootstrap everything you need for you and it will create a stack for you to get started writing some code.

Now let's take a look at how we might create a GraphQL API backed by a Lambda function and a DynamoDB table. We will say, hey, we want to create a new API. So we're gonna import the AppSync library and call AppSync.GraphQLAPI. We can now set a couple of different parameters like the name, the schema location and any additional things like our base authorization type. In this case, we want a public API with an API key. This will deploy our API. We can just run this code by itself and we now have our API.

The API isn't gonna do anything though because we don't have an actual, we haven't defined where our resolvers need to map to and we haven't defined a data source. So next we might wanna go ahead and define our data source. We might wanna say we wanna have a Lambda function as a data source, meaning we're gonna map our GraphQL operations into the Lambda. But in order to do that, we first need to go ahead and create our Lambda function. So we're doing that here. We're setting the runtime to node.js. We're defining our memory size and we're defining the code location for the code that we're gonna be executing. And then finally, we now have our schema. We have our API and we have our Lambda function and we have our data source.

Now we can start mapping operations that we defined in our schema into this data source. All we need to do is say create resolver. We set the type name and the field name. So in this case we're saying, we want a query of list posts, a mutation of create posts, and a query of search images. And now we're kind of mapping these operations from Lambda into, I'm sorry, from our API into Lambda. So with that being said, I would say if you wanna learn more about how to do this, check out my YouTube channel. I have a bunch of videos on how to build out this type of architecture. youtube.com slash you slash natterdabit. I would also check out my GitHub, github.com slash dabit3. Check out the AWS mobile blog, the Amplify docs. I really feel like this is kind of the future of API Implementation in the cloud going forward. We're gonna see a lot more adoption. I'm a big fan of this. If you can't tell, I really do care about this stuff.

I'm really excited about it. Yeah, so thank you for checking on my talk. Once again, I'm natterdabit. I'm working in DevRel at Edge and Node. Check out Edge and Node. It's my new company. I'm pretty excited about that as well. And thank you so much for checking on my talk. I will see you around.

I'm really, really happy to be here and this is a great event. I mean, this is like just an amazing, like I would just... It's hard to put into words how much awesome stuff has happened during all of this, between the panel discussions, all the great talks, the workshops. I mean, a really great job to all of the organizers. That's all I have to say because I know this has to be a lot of work. Yeah, thank you so much. Yeah, it's a really nice conference, that's for sure. It's the first time when I'm seeing it. Hopefully I'll do it in the future, you'll never know, but it's so nice to see, like everyone is doing a lot of work and, of course, inviting really great speakers like you.

So, you asked the question in the first place, and how do you introduce yourself at parties? I can answer that, I will introduce myself as Catalyn or Unicorn Dev, but you left a couple of points there, like, web dev, it seems that it's winning with 51%. What do you think about that? Yeah, that's pretty cool. Like, this was a question that was asked in the State of JS survey that I thought had some interesting responses, but I think that's very front-end focused, just like this event. But I was curious how the distribution between front-end developers versus full-stack devs like come to these types of events, but also who is like maybe wanting to get into front-end that might come here, and then someone that's more like a programmer, but they're more like the C level. So like, that's typically gonna be like a CTO. So I thought that was a really nice variety of questions. But I was really actually kind of stunned to see how many full-stack devs are that there are here, but I think that is trending more upwards with all of this full-stack serverless and full-stack cloud and Vercel and all of this other stuff that's coming out that allows developers to kind of get into full-stack. A lot of the stuff that I've really been focusing on in my career, also the last couple of years kind of seeks towards that as well. So that's good, interesting results. Nice.

So we have some questions from the audience. I will start with the question addressed by John B, do you have any recommended sources for more information on these topics? Maybe GraphQL or the talk that you gave? Yeah, I mean, the one thing I would easily reach out to and kind of show you is I wrote a blog post that is literally called the exact same thing as this talk.

It's called Turning the Cloud Inside Out. So let me paste the link to that in the discord there. But, I mean, really this is kind of a culmination of all of the stuff that's happened in the ecosystem I would say in the past few years. So anything like that's been written about GraphQL from a theoretical level would probably be good to read as well.

If you wanna follow some interesting folks, there's a ton of people, but maybe people that are into this space is Sean Grove of OneGraph, I mentioned him in the talk. He is always doing really bleeding edge stuff. Yuri Goldstein is also doing really cool stuff that is kind of in the tooling space around GraphQL. Eve Pursello is kind of like by far the best teacher in the space, maybe because she's written books, she has a big head course coming out, a lot of cool stuff. So if you follow those three people and see some of the work that they've done, you'll learn a lot about GraphQL.

Great, I'm not sure if we are running out of time. Do we have any? Alright so we are running out of time. Nadir was a pleasure, I truly miss you. Hopefully this pandemic will end up and we can meet again, drinking something and just discussing in general. Thank you so much for your talk. It was a bless to have you here. Thanks.