Turning the Cloud Inside Out

Rate this content
Bookmark

GraphQL is being used in some really interesting ways in parts of the developer ecosystem that you may be surprised to hear about, including Ethereum as well as for building comprehensive graphs from various third party APIs. In this talk, I'll show how to use a similar approach to build a cloud programming interface into AWS with GraphQL and why using this approach makes sense coming from a front end developer looking to leverage their existing skillset.

36 min
14 May, 2021

AI Generated Video Summary

Today's Talk discusses turning the cloud inside out using GraphQL, highlighting its benefits such as type validation, real-time capabilities, and query efficiency. It explores the use of GraphQL as an API gateway, particularly in the context of microservices, third-party APIs, and blockchain. The talk also covers the efficient indexing and cloud integration offered by GraphQL, as well as building cloud APIs with AWS using API Gateway and AWS AppSync. It concludes with insights on deploying GraphQL APIs with tools like Amplify and CDK, and creating GraphQL APIs backed by Lambda and DynamoDB.

1. Introduction to GraphQL and Cloud Programming

Short description:

Today, I'm going to be talking about turning the cloud inside out, creating a cloud programming interface with GraphQL. 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 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. GraphQL is an open source data query and manipulation language for APIs and a runtime for fulfilling queries with existing data. It provides benefits such as type validation and checking, real-time capabilities, and query efficiency through a single endpoint.

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.

2. Benefits of GraphQL and Learning Once

Short description:

GraphQL allows you to send multiple operations in a single request, preventing overfetching and underfetching. It also auto-generates API documentation through introspection. Learning GraphQL enables developers to jump into any API and be immediately productive. GraphQL provides consistency and efficiency, similar to React's ability to build various applications. It allows developers to be efficient in different layers without having to learn new technologies.

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.

3. Using GraphQL as an API Gateway

Short description:

GraphQL is a great fit for complex system and microservices. It unifies multiple systems behind its API and hides their complexity. Developer sentiment is high for GraphQL. This talk is about using GraphQL as an API gateway and covers microservices, third-party APIs, Blockchain, and Ethereum.

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.

4. API Gateway with GraphQL and Blockchain

Short description:

API gateway with GraphQL as a popular choice. One Graph combines multiple services behind a single GraphQL endpoint, providing a consistent way to work with different APIs. It allows querying various services without the need to read extensive documentation. Another interesting topic is blockchain and Ethereum, where decentralized apps (DApps) are being built for lending, borrowing, token swaps, investments, crowdfunding, and payments. Compound, a money market protocol on Ethereum, enables earning interest by lending cryptocurrency assets. However, building applications directly on top of blockchains is currently limited.

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.

5. Efficient Indexing and Cloud Integration

Short description:

The problem with data retrieval in the web and blockchain is the lack of efficient indexing and organization. The graph solves this by offering a consistent indexing protocol using GraphQL. Companies like Compound, Uniswap, and Foundation are using the graph to easily access data. Learning GraphQL allows you to query blockchain data and work with cloud services like AWS.

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.

6. Building Cloud APIs with AWS

Short description:

I want to hit a different type of database and a machine learning service within AWS. I'm unsure how to put it all together and combine multiple data sources into a single query. AWS offers two main ways to build cloud APIs: API Gateway and AWS AppSync. In both cases, you need to understand the execution environment, permissions, and SDKs for interacting with data sources. There are two types of execution environments: serverful and serverless. Serverful environments provide full control but require more management and implementation work.

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.

7. Benefits and Downsides of Serverless with AppSync

Short description:

When using serverless, you have less control but also less work. AppSync provides built-in security, scalability, resiliency, and a serverless payment model. However, you're limited by the provided API service and long-running tasks are not suitable for serverless. I highly recommend AppSync for a serverless execution environment.

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.

8. Permissions and SDKs in AWS Cloud

Short description:

Permissions in AWS Cloud are managed using Identity and Access Management (IAM). IAM allows you to grant resources permission to perform operations on services. By setting permissions using IAM, you can interact with databases and services in your environment. Another consideration when working with execution environments is the use of SDKs. AWS provides a single SDK for various execution environments, allowing you to import the necessary client and execute operations with just a few lines of code. The AWS SDK supports a wide range of services, including machine learning services like recognition.

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.

9. Deploying GraphQL APIs with Amplify and CDK

Short description:

Let's talk about deploying GraphQL APIs using tools like Amplify and CDK. With Amplify, adding a GraphQL API is as simple as running Amplify add API. The Amplify CLI handles all the infrastructure code and wiring for you, allowing you to focus on your GraphQL schema and directives. CDK, on the other hand, provides a way to create a new project by running CDK init. This will bootstrap everything you need and create a stack for you to start writing code.

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.

10. Creating a GraphQL API with Lambda and DynamoDB

Short description:

Now let's create a GraphQL API backed by a Lambda function and a DynamoDB table. We import the AppSync library and set parameters like the name, schema location, and base authorization type. We define a data source by creating a Lambda function and mapping GraphQL operations to it. Finally, we map operations from our API into Lambda using resolvers. For more information, check out my YouTube channel, GitHub, AWS mobile blog, and Amplify docs. This is the future of API implementation in the cloud.

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.

QnA

Excitement, Introductions, and Audience Questions

Short description:

I'm really excited about it. Thank you for checking on my talk. I'm natterdabit, working in DevRel at Edge and Node. This is a great event with awesome stuff, great talks, and workshops. Thank you to all the organizers. How do you introduce yourself at parties? I introduce myself as Catalyn or Unicorn Dev. The State of JS survey had interesting responses, and full-stack devs are trending upwards. I was stunned by the number of full-stack devs here. Now, let's move on to the audience questions. John B asked for recommended sources on GraphQL and the talk. I wrote a blog post with the same title as this talk.

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.

Turning the Cloud Inside Out

Short description:

Turning the Cloud Inside Out is a culmination of the past few years in the GraphQL ecosystem. To learn more, read about GraphQL from a theoretical level and follow Sean Grove, Yuri Goldstein, and Eve Pursello. We are running out of time, but it was a pleasure to have Nadir here. Hopefully, we can meet again after the pandemic.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.