As a bit of introduction, my name is Emmanuel Skulet, and with my colleague Miguel Tastana, we're gonna walk you through the <a href="/tags/workshop">workshop</a> today. We're gonna build a nice application together that relies on <a href="/tags/graphql">GraphQL</a> API. And we will see how that can be done in <a href="/tags/aws">AWS</a>.And we have prepared everything for you, so there's no need for you to have any sort of software installed on your computer. We will run everything in a sort of virtual environment. We're both part of <a href="/tags/aws">AWS</a> professional service team, in case you're not familiar with that. That's the consulting arm of <a href="/tags/aws">AWS</a>. So we work directly with actually both of us, quite a biggest customers that we have in <a href="/tags/aws">AWS</a>. And for quite some years now, we have been building applications with customers. And we can share also with you some of the trends that we see and why it's kind of important that we get to learn the latest technology and see how this can be adopted for enterprises and startups as well actually.So on the agenda today, we'll walk you through a little bit of some of the strengths that we see in terms of modern applications in 2024. We'll talk about what is <a href="/tags/graphql">GraphQL</a>, how does that work, and then the <a href="/tags/graphql">GraphQL</a> implementation on <a href="/tags/aws">AWS</a>, which is a service called <a href="/tags/aws">AWS</a> AppSync. Again, no knowledge of the services required. It's just an implementation of the specification and we will use it throughout the <a href="/tags/workshop">workshop</a>. And after that, we will go through the <a href="/tags/workshop">workshop</a> itself where we're going to build an application, we're going to build an API, we're going to secure that API, and see how that end to end flow actually works. And then at the end, we'll leave you with a couple of takeaways. Hopefully, this session will be very useful and you could apply the learnings out of it right after this one. So very curious how your feedback is going to be.

So that being said, I want to talk a little bit about what is a modern application in 2024. I don't know about you, but in my early days, I started building applications on premise. And back in the days, it was quite complicated because you had to request VMs in advance and load balancers in advance and DNS entries and so on. So that took just a long time, weeks and months if I remember even, to get just the infrastructure before you could even get started. And if you start building <a href="/tags/microservices">microservices</a>, you're going to need a lot of infrastructure for that.So these days, when you build an application, expect that infrastructure should be readily available. And you should be able to provision that within seconds, you should be able to expect that to deploy it globally so that you can reach customers everywhere without a lot of overhead. Obviously, if you look at some of those super large applications that probably all of us are using today, like I don't know, Instagram or Uber or TikTok and whatnot, those applications respond super quickly, right? So it's become an expectation that we build applications in that way.And obviously, no one is doing releases or well, not no one but many enterprises and many customers want to release as frequent as possible to their own customers, so that they have features shipped out of the door as soon as possible. So all of this kind of together are things that we expect to have in applications in 2024. And going maybe the next level of detail in here, I can change the slide, we expect that we have the lowest possible latency while we serve users globally, we should be able to <a href="/tags/scalability">scale</a> to meet big workloads, right? If you think about an e commerce platform like amazon.com, right? We expect that during Black Friday events, the website doesn't go down, right? So to manage such an undertaking requires quite a bit of piece of engineering, but that is kind of becoming an expectancy that we don't need to necessarily do something for that specific, specific event, the application should be able to do it by itself. We should be able to obviously do it with a reasonable amount of cost, right? We don't want to explode our costs beyond our own control. And that cost should also be predictable, right? We don't want to have, you know, million dollars of applicable infrastructure costs when we when we build such applications. And, of course, and as you see, these days, there's a huge trend with GNI, but this has been the case in the past as well, like, in the past, we had also a lot of <a href="/tags/data">data</a> engineering and <a href="/tags/data">data</a> analytics types of applications, a lot of applicants or user engagement traffic.So there's a lot of trends coming every some years, this year is and last year have been a lot on GNI. So also customers want to experiment with those latest technologies in this application, so we should make it as seamless as as we can. And when it comes to front ends, a lot of the trends that we see, obviously is that we have a couple of winners here. And there's been I think, a bit of debate about what's happening in, I think, upcoming years. So at the top right now is <a href="/tags/react-components">React</a>. There is quite still a bit of traction around <a href="/tags/angular">Angular</a>, but there's some new upcoming <a href="/tags/frameworks">frameworks</a> that are also getting some attention. We'll see which ones becoming dominant in the next couple of years. But the idea behind it is that we should not necessarily be stuck with a specific technology that maybe works today. And we should be able to iterate and evolve those technologies as we see fit for a specific use case that we might have.If you ask yourself, you know, don't we have enough applications already? I think we built, both in the, let's say, consumer facing, but also in the <a href="/tags/enterprise">enterprise</a> space, a lot of those. And why are everyone still interested in building such application? As I mentioned, people talk a lot these days about JNI applications, but there's so many other use cases that maybe are not so, let's say, hot or not as visible in the market, but they're definitely happening. So one big reason for why customers build applications is because they want to accelerate the <a href="/tags/innovation">innovation</a> space, and they want to get a lot more insights into the <a href="/tags/data">data</a> that they already have. So if you think about pharma companies or energy companies, they started gathering since a couple of decades now, a lot of <a href="/tags/data">data</a>. Let's say they're still behind on making use of that <a href="/tags/data">data</a> to develop new products.Maybe you have noticed that during the COVID time, right, I think this was kind of a big moment for the pharma industry where they started evolving and using <a href="/tags/data">data</a> to essentially do experiments and simulations. And that's one of the reasons why they were able to innovate so fast on those vaccines. So this is a big driver, right? Customers sit on a lot of <a href="/tags/data">data</a>, terabytes, sometimes petabytes, and they still want to build applications around those to drive new business insights and identify new opportunities to build new products or refine existing products. And as I mentioned, right, this year, we have the JNI trend. So they still want to take advantage, actually, I have tons of conversations with my customers around this topic on how they can put JNI into existing applications to simplify workflows even more, and automate some of them, right, so then they can focus their resources and people in other parts of the business.So those are all big drivers into why customers build applications, and you will see also kind of the trends on what type of applications they're building. Looking at some of the use cases, we classified them in a couple of categories here. So one big class of applications are those in the <a href="/tags/iot">IoT</a> space. So if you think all about industrials and smart meters, and device management, right, and you were talking also about consumer devices, you see these days that more and more appliances are becoming smart, for better or worse, some of them in my view, not necessarily a great addition. But you see definitely smart fridges, there's like smart washing machines, cookers and whatnot. So there's and everything behind it, right, there's some sort of an application, some sort of a system, it might be complex, there's obviously lots of interaction between those applications and so on. But there's a lot, a lot of those and it keeps growing, right, there's at some point it gets through like an activity, as there is an app for every manufacturer for every device. So also consumers, customers, our customers are looking at how to simplify those and build like more unified experiences.And then there's also a lot of applications in the industrial world, you think about factories, and a lot of process <a href="/tags/optimization">optimization</a>, this comes into the industrial world where people or customers are looking to make, let's say, processes more efficient to gain more insights when things get stuck and why, and even do predictive maintenance, right, so they're able to solve issues before they even appear and thus not having any sort of downtime in the factories. Another big class of applications are those in the analytics space, and as I said, this is like a never growing and expanding realm with now with GNI, but as I mentioned, customers sit on a lot of <a href="/tags/data">data</a>, whether that's like sales <a href="/tags/data">data</a>, or trying to do any sort of business intelligence about how their marketing campaigns are going, so there's a lot of opportunities in this space, and it's a big driver for building such applications.Then you have this <a href="/tags/creativity">creativity</a> and <a href="/tags/artificial-intelligence">AI</a> powered, kind of connected, so I think there was two, three years ago, there was like a frenzy with recommendation engines, because of the Netflix, let's say, that started this trend. So everyone was looking for recommendation engine, and I had colleagues, they were working in the media and entertainment space, and they were doing that for newspapers, they were looking at Google Trends, and they were even automating how newspapers were writing articles. So that's still, I think, going on, there's a lot of translations, so automated translations here, so if you want to build an application that is reachable by all types of customers across the globe, often with many different languages, you can do all of that without necessarily having people that are sitting in between and having those delays when you're deploying applications.So there's a lot of <a href="/tags/automation">automation</a> being put in place, and that's yet another big driver. And then we're talking about platforms type of applications, those are like maybe the biggest in terms of complexity, the biggest types of applications, and here we can think about document processing, autonomous driving systems, those are huge platforms that require a lot of <a href="/tags/data">data</a> and require a lot of infrastructure to be able to operate, marketplaces, ticketing and reservation systems, and so on. So those are kind of the categories of application use cases that we kind of see as being the main drivers and the main making a push for adoption.Now, looking at some of the application trends we have seen in the last couple of years, well we definitely see still a lot of <a href="/tags/cross-platform">cross-platform</a> application development, mainly with iOS and Android, and if you're a startup or maybe you have your resource constraint, this is a big driver. So we have a couple of <a href="/tags/frameworks">frameworks</a> here with Flutter and <a href="/tags/react-components">React</a> Native that is kind of keeping at the top. And then maybe of interest for this session today as well is that lots of enterprises are looking into adopting <a href="/tags/graphql">GraphQL</a>, and the reason that is, it's connected to this data-heavy applications, because <a href="/tags/graphql">GraphQL</a>, that's exactly the realm where it really shines.So even with one of my biggest customers, last year we had a big adoption of <a href="/tags/graphql">GraphQL</a> and I remember when I first talked to them about the technology, they were a bit skeptical because they didn't really have any sort of expertise in-house. But now, one year later, they're super happy with it and it's become a default choice for the, as I said, data-heavy analytics types of applications. And as I put here as the last point, and one of the main reasons why we're doing this session today is because there's still a huge shortage of developers. Enterprises are still looking for those. I remember another customer of mine was looking for hundreds of people with specific skills and they have a hard time finding those in the market because many developers, once they learn a technology, they remain with that for so many years. And the technology's landscape is evolving very, very fast. You see from five years ago, <a href="/tags/frameworks">frameworks</a> and maybe languages disappear. For me, for example, I don't even see a place, a big place, let's say, for Java going forward or languages like that. So technologies evolving, you may disagree with that, but it's basically on what we see a lot, right? And what's happening in the world, there's obviously trends and obviously, many enterprises also want to be relevant in the job market, right? So they try to adopt these technologies as well, as well as also being a big driver for them to be relevant.Now, if we're to look into what are the challenges when we're building APIs, we have different types of applications, as we discussed, in different types of industries, with different types of use cases, and we have a couple of API technologies that power all of these applications, right? So for those of us who are maybe a bit older in the industry, we all maybe have heard or have seen SOAP APIs, do not recommend, and therefore we have moved from that world, although again, those still exist. So do not count them out just yet, but as I said, technology is evolving. And then we have, I think, two dominant forces in the API world. One is kind of still the default, which is the REST types of APIs, and then we have kind of the new kid on the block, although it's not that new anymore, but still, let's say, emerging technology, which is <a href="/tags/graphql">GraphQL</a>. And then we have various flavors of RPCs. And those cases are kind of niche type of use cases for super efficient, super fast APIs that have a specific, let's say, very specific use case.The thing with REST, right, is that it's great. It works for the most part, but for those data-heavy applications, there's some issues with it. And I think my colleague, Miguel, will walk you through what are the concerns with the REST APIs and how <a href="/tags/graphql">GraphQL</a> actually solves many of those.

So with that, I would like to pass it over to my colleague, Miguel, who's going to talk about those things. Thank you, Manuel. Great introduction. Just before I stop there, thank you, everyone, for joining our session. We really appreciate you really investing this time to hear us out. Hopefully, we don't disappoint you. So really following the logic path that Manuel or the starting line that Manuel told you so far with <a href="/tags/graphql">GraphQL</a>, why did <a href="/tags/graphql">GraphQL</a> all of a sudden started appearing and started getting resurgence? It's true that REST is still the default because it's really, it's approachable. It's something that it's standardized across the internet. It's the interface contract that is defined for a lot of applications. And I don't see a future where REST disappears. No, that's not the case. But there are more options. And that's what's so great about technology is that you can have a huge set of technologies that are fits, that can be specifically chosen for your use case. And but before, what we want to do here today is actually run an exercise of where REST and where <a href="/tags/graphql">GraphQL</a> shine and why <a href="/tags/graphql">GraphQL</a> gained so much power in certain types of applications and use cases.The first one, and we're going to essentially divide it in two categories. So there's a technical issue that made people lean towards <a href="/tags/graphql">GraphQL</a>, and Facebook developed <a href="/tags/graphql">GraphQL</a>. And then there's also the organizational problem. But focusing first on the tech on the technology side, and you go to the next slide Emanuel, is the underfetching use case. And what does it mean by underfetching? I'm sure that there will be people in the chat that already heard this topic, but just to make sure that everyone is on the same page. So with underfetching, we're describing a situation that's fairly common in more complex APIs, REST APIs, where a single network request is unable to satisfy all the <a href="/tags/data">data</a> that you require. An example of this is you're developing a web page or a page for your user profile in your mobile application. And it's common that you need to fetch for you to fetch this information from different <a href="/tags/data">data</a> stores, different services, maybe things owned by different teams. So you end up in this situation where you need to make multiple requests, and you need to find <a href="/tags/data">data</a> that is scattered around multiple systems by multiple teams, just to provide a consistent view. And the thing that <a href="/tags/graphql">GraphQL</a> really pushes for is a simplification of this complexity to the client.

So if we go to the next slide Emanuel, and I think maybe we can switch between the two. But the idea is that instead of having all this complexity on the client side, and you having to do this complex client side joins, and request dependencies, wait for one to have the ID to make the another one. Instead of having all this complexity, you are essentially able to offload or abstract that complexity to <a href="/tags/graphql">GraphQL</a>. And we're going to explain how do you do it. But this is a conceptual model beyond <a href="/tags/graphql">GraphQL</a> is allowing your queries to be closer to the <a href="/tags/data">data</a> and less tied to your API contract and how it is in limited by the way that it was designed.So, in your <a href="/tags/graphql">GraphQL</a> schema, you'll be defining what are your object types. So, if for OOP people, this would be your classes. So here we have an object type book, an object type previews. And then when you're making queries, instead of making a slot, a get slash books, you would do a list books. And the main difference is that instead of getting all this information that a book is able to return, we can select at runtime when we're making the query, we get just the <a href="/tags/data">data</a> that we need. So this means, if I need, then this is actually quite simple one, but imagine that the book had like 50 reviews in a typical REST system, we would get the ID, the title of the author, and then the 50 reviews. Maybe if we did some pagination, it would be cut out to some limits, but you can see, we could get all this, we could have this entire payload. But if we, what if we just needed the title and the author, because we just needed an overview. We're just getting unnecessary <a href="/tags/data">data</a> through the network, just making or just requesting additional <a href="/tags/data">data</a> that it's not needed, making requests slower because you need to pass more <a href="/tags/data">data</a> around over the wire. And with <a href="/tags/graphql">GraphQL</a>, you don't have to do that. You can just really request the <a href="/tags/data">data</a> that you need at runtime.So, in terms of operations, we have, I, and this is very similar to how REST works, but with different names. So queries would be your gets, your reads, and you have mutations to do anything that it's writing, updating, deleting. And then additionally, you have something that's not in REST, at least the specification, which is subscriptions. And this is extremely useful. It's a real-time pubstep mechanism, which is really good to get, to build real-time experiences. So you need to send <a href="/tags/data">data</a>, you need to subscribe that and get live updates, which is common, for example, in a lot of sports events where you need to be sending <a href="/tags/data">data</a>, the latest available <a href="/tags/data">data</a> on, for a specific widget or a specific driver, these type of things, real <a href="/tags/data">data</a>, getting real <a href="/tags/data">data</a> over the wire. It's something where <a href="/tags/graphql">GraphQL</a> really shines because it's able to do it at <a href="/tags/scalability">scale</a>.

But on a very simplified manner, instead, so let's use maybe REST as an example. The way you describe what's available for your API would be through your interface contract, which is very common, like an open API schema, and where you describe your allowed actions, the resources that you can operate on and so on. With <a href="/tags/graphql">GraphQL</a>, you still have an interface contract. But the way you describe your available operations and your resources is instead of doing it on an open API schema, you do it via <a href="/tags/graphql">GraphQL</a> schema. And you will see the power the power that is unlocked behind these things. But if you just have, like a quick glimpse at the the slide that we have here, you can see that the way we describe types looks oddly similar to how we map <a href="/tags/data">data</a> on our <a href="/tags/data">data</a> on our databases. And this, this is where you will see that <a href="/tags/graphql">GraphQL</a> resembles really, it's really good connecting your query engine to the <a href="/tags/data">data</a>, because you have these closer integration, which just makes things easier at the end of the day.So, in your <a href="/tags/graphql">GraphQL</a> schema, you'll be, you'll be defining what are your object types. So, if for OOP people, this would be your classes. So here we have an object type book, an object type previews. And then when you're making queries, instead of making a slot, a get slash books, you would do a list books. And the main difference is that instead of getting all this information that a book is able to return, we can select at runtime when we're making the query, we get just the <a href="/tags/data">data</a> that we need. So this means, if I need, then this is actually quite simple one, but imagine that the book had like 50 reviews in a typical REST system, we would get the ID, the title of the author, and then the 50 reviews. Maybe if we did some pagination, it would be cut out to some limits, but you can see, we could get all this, we could have this entire payload. But if we, what if we just needed the title and the author, because we just needed an overview. We're just getting unnecessary <a href="/tags/data">data</a> through the network, just making or just requesting additional <a href="/tags/data">data</a> that it's not needed, making requests slower because you need to pass more <a href="/tags/data">data</a> around over the wire. And with <a href="/tags/graphql">GraphQL</a>, you don't have to do that. You can just really request the <a href="/tags/data">data</a> that you need at runtime. And when we do in the <a href="/tags/workshop">workshop</a>, we have some, we'll have some actual examples where you will be able to test out some of these, the flexibility in the query <a href="/tags/patterns">patterns</a> that you can achieve with <a href="/tags/graphql">GraphQL</a>.

And then in terms of operations, we have, I, and this is very similar to how REST works, but with different names. So queries would be your gets, your reads, and you have mutations to do anything that it's writing, updating, deleting. And then additionally, you have something that's not in REST, at least the specification, which is subscriptions. And this is extremely useful. It's a real-time pubstep mechanism, which is really good to get, to build real-time experiences. So you need to send <a href="/tags/data">data</a>, you need to subscribe that and get live updates, which is common, for example, in a lot of sports events where you need to be sending <a href="/tags/data">data</a>, the latest available <a href="/tags/data">data</a> on, for a specific widget or a specific driver, these type of things, real <a href="/tags/data">data</a>, getting real <a href="/tags/data">data</a> over the wire. It's something where <a href="/tags/graphql">GraphQL</a> really shines because it's able to do it at <a href="/tags/scalability">scale</a>.Now, beyond the scenes, we go to the next slide, Emmanuel. So beyond the scenes, what we have is this schema, that the schema is what clients see. And then we tie types to resolvers. And what are resolvers? You can think of resolvers as really well-defined purpose-built compute units for fetching that specific type of <a href="/tags/data">data</a>. So what this means is that for the book <a href="/tags/data">data</a>, we can have a book resolver, which really it's just focused and it's just built to interact with a book <a href="/tags/data">data</a> store and get that <a href="/tags/data">data</a> back to you. At the same time, because the way that <a href="/tags/graphql">GraphQL</a> works, you can see that book as an attribute which is reused. However, review, it's its own type. And book, the book resolver is only responsible for fetching book information. So what happens is that the reviews are actually fetched by a reviews resolver. The way that this is handled is that it's managed automatically by the <a href="/tags/graphql">GraphQL</a> engine, because you don't need to do it. And as the name says, it's like a graph query language. So all these, the way that you model your schema with all these dependencies, all this then, as soon as, as long as you map your types correctly to the <a href="/tags/data">data</a> sources, all these dependencies and graphs will be sorted out for you automatically at runtime when you're making your queries. So in this case, if we asked for a book information and its reviews, the specific resolver will be triggered, get the <a href="/tags/data">data</a> from the specific <a href="/tags/data">data</a> sources and return back to you in a single response, all automatically, no complex joining on your Express API or something like that. No, just all managed seamlessly to you.So the way that AppSync works, and you'll see that it's really just a <a href="/tags/graphql">GraphQL</a> implementation, but fit to the <a href="/tags/aws">AWS</a> <a href="/tags/ecosystem">ecosystem</a>, but I want to highlight maybe the things which are built on top of it. So the, these integrations with some of the other services. So the computing units, which is called the resolvers, the one that do the <a href="/tags/data">data</a> fetching through your <a href="/tags/data">data</a> sources and send back the request to your clients is handled by one of the resolvers. So the <a href="/tags/aws">AWS</a> currently supports two ones. The first one is <a href="/tags/javascript">JavaScript</a> resolvers and <a href="/tags/javascript">JavaScript</a> resolvers are in, are the, have the power of being built in into the AppSync engine. So there's no additional charge, you don't need to worry about configuring memory capacity, which is sometimes what you have to do with <a href="/tags/serverless">serverless</a>, but there's still some configuration parameters.

So when you're developing in REST, you define, you define one of the first things that you define is, okay, what will be the, my interface contract, because this, and this needs to be stable. It's usually attached to a version so that you can reliably distribute this to your clients. You can have multiple clients, not only your front end, you can have maybe your API is a <a href="/tags/data">data</a> API that's also serving other applications. So this stability of your interface contract is extremely, is extremely important. Otherwise you run into a situation where your clients are trying to access something that is not available. So this is, this planning ahead, it's extremely hard and it's, it becomes even harder at <a href="/tags/scalability">scale</a> because different teams have different agendas at different roadmaps. And it's always really hard to prioritize when you need, oh, but I know I need a new parameter. I need a new resource. And you, you run into this situation where teams are constrained by how flexible they <a href="/tags/creativity">design</a> their APIs. If you compare this with <a href="/tags/graphql">GraphQL</a>, if you look next slide, thank you. If though the way that <a href="/tags/graphql">GraphQL</a> does this is it tries to decouple from this constraint by building or promoting a versionless, a versionless system. So this means that your clients are able to, at while they are developing, they are able to introspect what is the available schema. So this is a feature that is extremely powerful in <a href="/tags/graphql">GraphQL</a> where you are able to get all the supported types, the supported queries, like the operations for the reads and the writes. You are able to get this using, from your client. So you do not need to communicate and you do not need to sync with, with a specific team. Hey, can you send me the interface contract or why is this not working? Because you don't even need to communicate. You just pull this, this schema while you are developing. And this makes things way easier. The fact that this is schema introspection is the schema introspection feature is what made the <a href="/tags/graphql">GraphQL</a> team really say, look, I think in this use case, you can really push for versionless APIs because you know always what's available. So every time, what you're consuming is always stable. And this, I think this, this developed, this mental model is, is a huge paradigm shift between what is what was rest and what is <a href="/tags/graphql">GraphQL</a> because rest felt, felt, feels like a stable, it's stable. Whereas <a href="/tags/graphql">GraphQL</a> feels something like it's an evolving system, that it's always, always dynamically evolving. And then you also have the, but with rest one of the things that it's, I wouldn't say competitively worse, but it's something that you have to take into consideration is the weak <a href="/tags/data">data</a> typings in comparison with <a href="/tags/graphql">GraphQL</a>, because you assume that you assume that the, the interface contract is respected, of course, but you still need to run some, you probably need to run some <a href="/tags/validation">validation</a> on, on your clients and also on your service, if you're doing posts or gets, but you're, you probably need to run some additional <a href="/tags/validation">validation</a> to check if the <a href="/tags/data">data</a> type from that came from the server or came from your clients are the expected ones. And with, with the <a href="/tags/graphql">GraphQL</a> schema, because the schema is essentially distributed to both parties, the stability, the, the, the <a href="/tags/data">data</a> typing is enforced by default. So it's something that it's not a concern.

Now, what next slide, please. So the, this covers very briefly <a href="/tags/graphql">GraphQL</a> and <a href="/tags/graphql">GraphQL</a> is part of the reason why, why we're talking here. The other part is we want to show you how you could build <a href="/tags/graphql">GraphQL</a> and benefits from <a href="/tags/graphql">GraphQL</a>, but within <a href="/tags/aws">AWS</a>. And fortunately we have an extremely powerful, maybe biased, but extremely powerful service for this, which is <a href="/tags/aws">AWS</a> AppSync. And like Emmanuel mentioned, it's like, it's an implementation of the, of the original <a href="/tags/graphql">GraphQL</a> specification, but with all the benefits of being a managed service. So the main benefits is that you get it's <a href="/tags/serverless">serverless</a>, so you do not need to worry about <a href="/tags/scalability">scaling</a>. You do not need to worry about provisioning computing capacity. You have built-in integration with a lot of other <a href="/tags/aws">AWS</a> services. So all of these nice features that are built into the <a href="/tags/aws">AWS</a> <a href="/tags/ecosystem">ecosystem</a> are just available to you by opting in with <a href="/tags/aws">AWS</a> AppSync. Whereas if you wanted to build your own AppSync, AppSync implementations and resolvers, which you can do, you can do it in <a href="/tags/apollo">Apollo</a>. You can do it in what was it? Relay? I think it was Relay. So there's a couple of also <a href="/tags/graphql">GraphQL</a>, <a href="/tags/graphql">GraphQL</a> implementations are also extremely powerful and popular, but they lack this ends off approach that AppSync promotes, where you just focus on your business logic, which is probably what your team wants anyway. So if you go over to the next slide, Emmanuel, the way that AppSync works, and you'll see that it's really just a <a href="/tags/graphql">GraphQL</a> implementation, but fit to the <a href="/tags/aws">AWS</a> <a href="/tags/ecosystem">ecosystem</a>, but I want to highlight maybe the things which are built on top of it. So the, these integrations with some of the other services. So the computing units, which is called the resolvers, the one that do the <a href="/tags/data">data</a> fetching through your <a href="/tags/data">data</a> sources and send back the request to your clients is handled by one of the resolvers. So the <a href="/tags/aws">AWS</a> currently supports two ones. The first one is <a href="/tags/javascript">JavaScript</a> resolvers and <a href="/tags/javascript">JavaScript</a> resolvers are in, are the, have the power of being built in into the AppSync engine. So there's no additional charge, you don't need to worry about configuring memory capacity, which is sometimes what you have to do with <a href="/tags/serverless">serverless</a>, but there's still some configuration parameters. With <a href="/tags/javascript">JavaScript</a> resolvers, this is none of your concern, you just throw in your, you just build your business logic on top of the <a href="/tags/javascript">JavaScript</a> resolvers, and this runs automatically. This, this, this simplicity also comes with its own set of challenges. So the <a href="/tags/javascript">JavaScript</a> resolvers, because they are really meant to be lightweight and very simple, you are not meant to build or to pull in external dependencies. So if you wanted, for example, with <a href="/tags/javascript">JavaScript</a>, if you wanted to bring like <a href="/tags/npm">NPM</a> dependencies, dependencies is something that would not be possible. However, you could do so with <a href="/tags/lambda">Lambda</a> resolvers. Yeah, it's fine. I think it was good transitioning. So with <a href="/tags/lambda">Lambda</a> resolvers, you would actually be able to, if you have this need to, oh no, but I need to use this library for doing open ID connect, or like a web socket implementation, or I don't know. If you see that you need to build in your <a href="/tags/npm">NPM</a> packages, maybe from your team, <a href="/tags/lambda">Lambda</a> could be an alternative, but you have to take into consideration what comes with <a href="/tags/lambda">Lambda</a>. And for the ones that do not know what <a href="/tags/lambda">Lambda</a> is, <a href="/tags/lambda">Lambda</a> is the, it's the function, it's a function as a service that is made available by <a href="/tags/aws">AWS</a>. And you can think of it as running really small, well-packaged compute units that do not need any provisioning. And the way that <a href="/tags/lambda">Lambda</a> works is that it's able to <a href="/tags/scalability">scale</a> by thousands of <a href="/tags/concurrent-rendering">concurrent</a> executions without you having to worry about it. And it supports, you can build Lambdas in, where does we <a href="/tags/javascript">JavaScript</a> resolvers. That's the name says it, you are tied to <a href="/tags/javascript">JavaScript</a>. <a href="/tags/lambda">Lambda</a> resolvers currently support most of the popular runtime. So you can build in go, in <a href="/tags/rust">Rust</a>, in Java. Yes, Java, in <a href="/tags/javascript">JavaScript</a>. So the list is ever-growing. And it's one of the most common compute solutions that people rely on, and our customers rely on because the buying is really super low.So just quickly, some of the benefits of doing the <a href="/tags/serverless">serverless</a>. And I think this is with this, with <a href="/tags/aws">AWS</a> AppSync, with the <a href="/tags/javascript">JavaScript</a> resolvers, with <a href="/tags/lambda">Lambda</a> resolvers, everything that it's <a href="/tags/serverless">serverless</a>. And we try to really push through what are the key selling points of using <a href="/tags/serverless">serverless</a> at <a href="/tags/aws">AWS</a>. And at the end, it can all be centered down to allowing you to focus on building what matters. So you probably, yes, it is important to worry about <a href="/tags/automated-security">security</a> and to worry about <a href="/tags/scalability">scalability</a> and to worry about high availability. But what you really need is to build that function, and you need to deploy today, and you need it to be fast, and you don't want to worry about having to have this burden all over the front because you just want to build a POC or you just want to test something. <a href="/tags/serverless">Serverless</a> gives you this power, and don't get me wrong, it's not just for POCs. There's a lot of our customers building and using <a href="/tags/lambda">Lambda</a> in production. So yeah, it's definitely scalable to a certain extent. Now... I would say maybe... We will switch at this point to the <a href="/tags/workshop">workshop</a>, so to the hands-on part. I just want to ask if there's any sort of questions before we transition to that one. If not, we'll move directly into it. Maybe we can check the chat. Okay, I'll take that as a no. You can always ask questions in the chat as well. So with that being said, I will post in the chat also those things so that you can log in. Maybe I need to stop sharing for one second. We will anyways not need the slides from here on, so I will put a link in the chat and then access <a href="/tags/code">code</a>. Once you go on that link, it will ask you to register. You can use the first option, which is the one-time PIN <a href="/tags/code">code</a> on your email. And after you do that, you will be able to log in into the <a href="/tags/workshop">workshop</a> itself. Exactly. This is the first screen that you're going to see. So you'll do the email one-time password. Once you get that on the email, you can sign in. And after that, you will have to introduce this PIN <a href="/tags/code">code</a> that we just gave you into the chat, and then we can get started. Please write in the chat when you're maybe ready so that we can continue. We'll give you maybe five minutes for that part, and then we start with the hands-on part. And as I mentioned, there will be no need for you to install anything on your computer. There will be a virtual environment where we can work. Yeah.

And if you prefer to just listen, because we're going to actually go step by step on the <a href="/tags/workshop">workshop</a>. So if you prefer to stay hands-off and then do it later, it's also a possibility. If you want to do it as we do it, it's also fine. I think we're going to go slow enough that everyone can catch up. So I think it should be fine.Now it comes the interactive part of the presentation. Now that we already introduced you to our Databrief introduction into <a href="/tags/graphql">GraphQL</a>, into AppSync, we're actually going to go hands-on, which I think it's always the cool part. So the app that we're building, funny enough, Emmanuel did the plug. I don't know if it was random or not about Netflix and the recommendation engine. It's funny because we're actually building a book recommendation website entirely with <a href="/tags/aws">AWS</a>. So we're going to use a couple of services. You're going to see what is the catalog of services that we're going to use, but it will be very centered around AppSync. So yeah, the page that you see here is what we will build. Well, actually not, we're not going to develop the front end and the widgets, but we're going to have some pre-baked functionality for some parts of the app and we're just going to plug in how you could then build the interactions with <a href="/tags/graphql">GraphQL</a> on the client side. Also on the server side, we're going to build an AppSync API. We're going to build <a href="/tags/authentication">authentication</a> on top of it. And we're going to cover both the API schema and all of the operations. So we're going to do both. We're going to cover queries. We're going to cover mutations. So rights. And we're also going to do the, if we have time, we're going to do the real-time functionality. So how you can use the <a href="/tags/graphql">GraphQL</a> subscriptions to create reactive UIs that are driven by AppSync.So if we go over to what, or if we have a quick overview at the high level <a href="/tags/architecture">architecture</a> that we will implement, this is what it looks like. It's actually quite simple. So on the client side, we have some web clients, mobile. What we're going to use is to help us build the connection and the integration with AppSync and also with some <a href="/tags/authentication">authentication</a>. We're going to use Amplify. And Amplify is both a service and a library, <a href="/tags/aws">AWS</a> library and service that help you build web applications and not only build full stack applications, but focus on web and mobile. And it does a lot of the tasks that you'd usually don't want or do not care too much because they're not focused on around your business. So things such as setting up a <a href="/tags/ci-cd">CI CD</a> pipeline, building and transpiling your codes, handling connectors to <a href="/tags/authentication">authentication</a>. These things are bundled within Amplify and then you can use the client side library to plug these features into these services automatically for you. So it just, it simplifies things. From an <a href="/tags/authentication">authentication</a> perspective, we're going to test, we're going to use two methods for <a href="/tags/authentication">authentication</a> today. We're going to use API keys and we're going to use the more traditional user identity flows. So we're going to use JWT tokens based on OAuth. And you're going to understand when we're going to use each type of <a href="/tags/authentication">authentication</a> method, because we're going to do something interesting.Then on the entity that will validate the <a href="/tags/authentication">authentication</a>. So for the API key, that API key will live as part of <a href="/tags/graphql">GraphQL</a> of AppSync. So AppSync does that <a href="/tags/authentication">authentication</a> by itself, but for validating the JWT tokens, we're going to use Amazon Cognito and Amazon Cognito, nothing more than just the <a href="/tags/aws">AWS</a> ADP offering. So it's something that you, if you were building this yourself, you would not necessarily be tied to Cognito. You could bring in either your third-party IDP or your organization's IDP and that it would still work because AppSync provides these types of integrations. Then if you look on the backside of things, we're going to have a set of resolvers, which what they will do as I explained before, is just pulling <a href="/tags/data">data</a> from the <a href="/tags/data">data</a> sources and making them fit the schema that is available to your clients. So the <a href="/tags/data">data</a> store that we're going to use is Amazon DynamoDB. For the ones that do not know, Amazon DynamoDB is Amazon's offering of a NoSQL <a href="/tags/database">database</a>. It has its own specification, it has its own feature. So I think it's a NoSQL <a href="/tags/database">database</a> has its own set of characteristics and the way that it is designed, Amazon DynamoDB is a key value <a href="/tags/data">data</a> store, it's really focused and it's really optimized for key value lookups at <a href="/tags/scalability">scale</a> for millions of records.So I think we are ready to start. I think I gave enough context. Let's start. We're going to start by building what the <a href="/tags/workshop">workshop</a> is about. So we're going to start by building AppSync. And these first sections, we're actually going to be provisioning the services. We're going to build the foundations. And then as we set this foundation, then we can really start <a href="/tags/testing">testing</a> and making queries so that you can understand how you could, what type of use cases you could really use <a href="/tags/graphql">GraphQL</a> for. So the first part with designing an API, <a href="/tags/graphql">GraphQL</a>, REST, I think the interface contracts is it should always be your center stage. In <a href="/tags/graphql">GraphQL</a>, because you have this idea of a versionless system, you could always evolve your schema, but it's important that you model it properly because this can have an impact not only on <a href="/tags/performance">performance</a> but also organization. So the type, I think that the main type that I want us to focus here is the book type. So we're going to have an object of type book. You see here a set of attributes, and then these attributes have types. Types in <a href="/tags/graphql">GraphQL</a> are called scalar types because you have a very restricted set of types available. The actual entire list of scalars is available in this thing, but actually I just want to cover here the ones that are here because they cover actually most of the use cases. So you have strings, you have integers, you have IDs.

In <a href="/tags/graphql">GraphQL</a>, because you have this idea of a versionless system, you could always evolve your schema, but it's important that you model it properly because this can have an impact not only in <a href="/tags/performance">performance</a> but also organization. So the type, I think that the main type that I want us to focus here is the book type. So we're going to have an object of type book. You see here a set of attributes, and then these attributes have types. Types in <a href="/tags/graphql">GraphQL</a> are called scalar types because you have a very restricted set of types available. The actual, the entire list of scalars is available in this thing, but actually I just want to cover here the ones that are here because they cover actually most of the use cases. So you have strings, you have integers, you have IDs. IDs are like unique ashes, which are really good fitting, which are really fitting for specific or unique IDs. And then you could see here that you have this exclamation mark, and this is basically a syntax for specifying that these attributes is required. So everything that does not include this means that it would be optional, but if it includes it, it's required. Another thing here, I think this is, you could guess it, it's a list, so an array of genres. So what we're going to do is, and maybe this is important, two things that we need to clarify. All of the things that we're going to cover for this <a href="/tags/workshop">workshop</a>, we're going to do it via the <a href="/tags/aws">AWS</a> <a href="/tags/cli">console</a>, just because it's simpler and it's more visual for you, so I think it's really easier for you to follow. However, obviously you could use <a href="/tags/cdk">CDK</a>, Terraform, any type of your infrastructure as <a href="/tags/code">code</a> of preference. You could definitely do it, but here for simplicity reason, we're going to use the <a href="/tags/cli">console</a>. You also get some benefits of using the <a href="/tags/cli">console</a> because we have the <a href="/tags/aws">AWS</a> service teams put a lot of effort into creating configuration wizards that do a lot for you behind the scenes, and you're going to see it.

And then this is the first important information. The second one is, when you open your account here, you should be in EU West1. Okay, so for us to be able to create our API, all of us should navigate to this page, so we just need to click it, and it opens automatically, hopefully. And then you should be in Ireland, so the <a href="/tags/workshop">workshop</a> was configured for Ireland, so let's make sure that all our regional services sit within the same region. So to create the AppSync API, I don't know for the ones, if you are not familiar with <a href="/tags/aws">AWS</a>, don't worry. So we're just going to really use the search bar. I think it's straightforward, so we want to go to <a href="/tags/aws">AWS</a> AppSync, and you get presented with this button because we don't have any AppSync yet created, any API yet created, so we're going to use this configuration wizard, and this is what I was saying about the service team providing, putting a lot of effort in to make sure that the creation process is simplified. So what we want to select is, we don't want to cover Merged APIs. We're not going to cover them in this <a href="/tags/workshop">workshop</a>. Actually, it's one of the <a href="/tags/deep-dive">advanced</a> sections, so if we have the time, it would be cool to go over it, but if not, you can still do it after the session, but we're going to do just regular <a href="/tags/graphql">GraphQL</a> APIs. For the ones that are experienced in <a href="/tags/graphql">GraphQL</a>, Merged APIs is an option for schema stitching, but at compile time, it's an AppSync thing. Instead of doing run-time stitching of the schemas from different sub <a href="/tags/graphql">GraphQL</a> APIs, you just compile it in a single API to your entire org or your entire project, so it's a really powerful feature. There's a couple of use cases. So we're going to <a href="/tags/creativity">design</a>, we're going to choose the <a href="/tags/creativity">design</a> from scratch feature, and we're going to call our API Books API. We're not going to worry about private APIs, so we're going to keep our API public. However, this would be a possibility if you wanted your API to only be accessible via VPC or you wanted to restrict it to your org, it's something that you could do. You could see here that you could associate it to a VPC. Maybe I should explain what is a VPC. To make it simple, you can just think of that as being your own private network. It can be a corporate network, like if you work in a company, but it can also be something private that maybe you don't want to share with the world. So maybe you're building APIs inside with other APIs, you combine all of that together, and you just expose maybe the final API to orchestrator perhaps at the end to the application. So it's just a way to kind of keep things, let's say, not all into the public internet. Thank you, Emmanuel. Thank you. So for the <a href="/tags/graphql">GraphQL</a> type, what we're going to use here, because we are using a DynamoDB table, we're actually going to use this option to get already a DynamoDB table associated to the <a href="/tags/graphql">GraphQL</a> API. And you'll see that behind the scenes what this will do is, based on the model, on the <a href="/tags/data">data</a> model that we define, it creates both the <a href="/tags/database">database</a> and the schema automatically for you. So this is nice to have. And our model is book, right? We're building book type of objects and then the fields here you can really just copy. This will be the, you can see here that these attributes match the <a href="/tags/data">data</a> model that we'll have in the schema. So we have the ID, title, author, you see all these type of fields. And you can see here they're required and not required. So we're going to populate all these fields in the <a href="/tags/cli">console</a>. You can do it at your own pace. While you do that, maybe if so, can provide a bit of explanation, right? So this is probably a crucial step when you're designing such APIs, right? You need to think about what's your <a href="/tags/data">data</a> model and you want to model that properly because otherwise later on, it'll be a bit more difficult to change it. It's possible, but it will be bind directly to the schema as well. So this would be, and then when you look at your problem, you need to look at what is the domain, what is the domain that this API is covering and then model it accordingly. Because you will see this is, so right, DynamoDB, it's a <a href="/tags/database">database</a>, it's a NoSQL <a href="/tags/database">database</a>, but still has things like indexes, has things like primary keys. So it will be relevant to get it right. For sure. Yeah. This is something that, thank you Emmanuel. But when I think Dynamo, especially DynamoDB is designed for use cases where you really understand your <a href="/tags/data">data</a> and how you will consume <a href="/tags/data">data</a>. And if you do it correctly, you can extract the most <a href="/tags/performance">performance</a> out of your, out of these <a href="/tags/database">database</a>. It's not really a general purpose <a href="/tags/database">database</a> that works for every type of use cases. At least <a href="/tags/aws">AWS</a>, we try to push for purpose builds technology and databases is not an exception. And DynamoDB, you have to really understand what type of access <a href="/tags/patterns">patterns</a> are associated to your application to be able to <a href="/tags/creativity">design</a> a model that makes sense from a business perspective, but also from a technology perspective. That being said, it's not necessary to use DynamoDB. You can use any sort of SQL <a href="/tags/database">database</a>, whether that's Postgres or MySQL. You can use any of that. It's not a must. It's just for the sake of this example that we use DynamoDB because it's <a href="/tags/serverless">serverless</a> and it's simple to provision and no need to wait for a server to be spun up in half an hour. Or I don't know, depending on how big that is. And no matter whether you use SQL or NoSQL, a bit of <a href="/tags/data">data</a> modeling, it is no matter of required. I see a question from Christophe asking, can you set up the model with CloudFormation? I think you will find in the same <a href="/tags/workshop">workshop</a> there, you find the <a href="/tags/cdk">CDK</a> variant, which is essentially a smarter way of doing CloudFormation. So yes. So maybe if you say the <a href="/tags/data">data</a> model, the <a href="/tags/graphql">GraphQL</a> model, no, you should not do it with CloudFormation simply because we typically use CloudFormation for defining <a href="/tags/aws">AWS</a> resources. And when you define, you create your AppSync API with CloudFormation, but the actual configuration should be defined in its own file. So there is the specification file, a configuration file for the <a href="/tags/graphql">GraphQL</a>. And this is what you would use to define your <a href="/tags/data">data</a> model. And then you would attach it to your CloudFormation resource, if this makes sense. All right. So I hope I gave everyone enough time to fill in these fields. So now that we have this, this will be the blueprint for building our bot. Again, I said again, repeating myself, but the DynamoDB table and your <a href="/tags/graphql">GraphQL</a> schema, you'll see how this happens behind the scenes. Obviously, if you're building this yourself, you would have to do it separately. And then for the resolver runtime, here we have two options. Usually the option that we recommend is AppSync simply because it's more up to date and it's a type of runtime that's currently getting more love from the service team in terms of new features are usually released first in this type of runtime. So this is usually the one that we recommend for our customers. Miguel, you have a type or a mistake in the Java. It should be array of strings.

Thank you. No, but yes. No, yes. I did not see this array column. No, yes. Thank you. I think it's all good now, right? I think so. It doesn't change a lot, right? In terms of, but just so that we are on the same thing. Yeah, it would notice it in the schema immediately, but yeah, good catch. So for the table name, we're going to call it. I'll try to follow the example so that it's consistent for everyone.And here talking about primary key, sort key for everyone that is familiar or everyone that is not familiar with this idea of primary key and sort key. So a primary key works as in relational databases in the sense that it uniquely identifies a record for your <a href="/tags/database">database</a>. And then the sort key is specific to DynamoDB in the sense that you can use a primary key in a sort key to make the composite key. So you also have the idea of composite keys as you have in relational, but the use cases for sort keys in DynamoDB are somewhat different. And maybe you can help me here, Emmanuel, because I'm missing the words. So with primary keys, you'll be using it when you need to get specific records. And with sort keys, you can do other types of queries based on filtered expressions or reject expressions. Sorry, I had to unmute you. Yeah, definitely. So primary keys as in any other <a href="/tags/database">database</a>, you can just simply get that specific item by the primary key itself. With the sort key, you can think of it of like, you have your table right and you have your primary key. And when you add a sort key, you're able to essentially find that specific item within that specific space. So let's say you could have a primary key of pets and you would like, you could have like sort key around geographies, right? Then you can do super efficient queries by searching for pets in, let's say, Germany or I don't know, whatever, what you might have. So I hope that gives you a bit of an idea on how that would work. Thank you.And then this would be essentially the default way to query your <a href="/tags/database">database</a>. Every time that you want to interact with your <a href="/tags/database">database</a>, you would have in the case will not include any sort key. So you would have to always provide this primary key. And this is something that by <a href="/tags/creativity">design</a> with DynamoDB always need to provide a primary key. And then you have this, we have this idea of indexes. And this is, again, takes the same concept of the indexes in relational databases. But in DynamoDB, it works slightly differently because it, it or it works similarly, in the way that it gives you <a href="/tags/performance">performance</a> ways to query your <a href="/tags/data">data</a>, but for different access <a href="/tags/patterns">patterns</a>. So in the default, in the default, the default, expect that you would query <a href="/tags/data">data</a> by your book ID. And we're adding additional indexes to facilitate queries for by author ID, and then also by publisher. So publisher ID. And then we're not going to use any sorting to keep it simple. Next, I think at this point we have, we can we can go quickly recap all of the things that we went through. So we designed an API from scratch. We specified the name of our API. We decided that we wanted to create DynamoDB table immediately to be absent. So this will come in handy because it will generate a lot of the things for us. We specified our <a href="/tags/data">data</a> model, and we specified some details about our dataset. So with this said, we are now ready to proceed create and wait. So while we wait, I think it will take maybe 10 seconds more. What's happening behind the scenes is that everything that we just went through, it's going to be provisioned. So we're going to have a table together with the API working together. And I think right after this, you'll be able to run essentially your first queries. Of course, once we update, probably the schema. So, and you will see for the rest of the <a href="/tags/workshop">workshop</a>, how easy that was to create our own first API without necessarily waiting for minutes or hours or whatever. And what can we do with this fancy API that we just created? Yeah. I just want to quickly show it to you, both these resources. So you can see that the books table's already created and you could see... Sorry. There's nothing in it. Yeah. Yeah. Now what you can see here that the attributes are defined as part of the table. And then at the same time, our API, you can see here that it's already available. So it's already accessible. And next thing that we have to do is to actually update the schema. Because one of the use cases that we need our book recommendation to support is that, yes, this so ideally, or every time that we create a... We're adding a new item to, or a new book recommendation to our application. We have to provide this unique identifier for the book. And if we consider this idea as an ISBN, like a unique book number, we have... That could be a situation where that book, that we want to bring in that book ID, and we don't want it to generate. So if you were building your application, usually you generate these IDs as you create them in your <a href="/tags/database">database</a>. But we want to here to also extend to the scenario where you could bring in that ID. So one of the things that we will change here is that for this input, and what is an input. An input is another definition or another definition for our schema that, as the name suggests, is an object type used for queries, queries and mutations.

So what is a type is more associated to how it is connected on the back end, on the <a href="/tags/data">data</a> store. The input can be slightly different. And this separation makes sense, because a lot of the times the way that you see <a href="/tags/data">data</a> may... Or the way you query <a href="/tags/data">data</a> is not... It does not necessarily translate to how it is stored. So these separations just keep things neat.And what we want to do here is essentially add the possibility to when you create a book, you can provide this ID. That's the only change that we're making, at least for now. Maybe if you can go back to the schema and scroll up a little bit up here. Sure. Exactly. So just wanted to say that on this type book, for example, you could have also subtypes. So you could have a book and then you could have... Instead of having the book and the book, you could have a... Instead of having the author ID, you could have a type called author, which will be its own type with name, I don't know, is the person, where is he from, which country, et cetera. You could do something like that. And then in the book input, essentially, you would have... You could pass all that information in and <a href="/tags/graphql">GraphQL</a> would take care on storing those details into different <a href="/tags/data">data</a> stores.So you could have, for example, one DynamoDB table for the books and another table for authors. And then you would basically be able to store that into different things on the <a href="/tags/backend">backend</a>, but from a user perspective, they don't see that. In our case, we have things quite simple. So we don't need to worry about that. But that would be the use case where you could do this, having these separations of types and do composite types on top of it. I think in the presentation, we had an example with user posts, comments, and so on. Yeah, exactly. This is where the idea of graphs comes into place.

Yeah. Well, it went well, went well. No, I think we can go to the next session, the next section. So we're almost done configuring our API. The last thing we need to do is <a href="/tags/automated-security">security</a>. And we take <a href="/tags/automated-security">security</a> really seriously at Amazon. So as of now, if we wanted to expose our API, anyone could just come in and create books, change it. So we want to add some access control. And we specified in the beginning that we wanted to do it in two ways. So add API keys and also JWT tokens. And maybe we can start with the API key because it's more straightforward.So AppSync provides this possibility of bringing in your API key, so you do not need to maintain it in a secret store or somewhere safe. AppSync provides this store for you, so you can manage it here. And the way that you can create the app, the actual <a href="/tags/workshop">workshop</a> should create an API key, but you may see some delay. So what you can do just to make things easier is, you can create one yourself and you see how straightforward it is. What's important to say maybe about this API key, as all API keys in fact? API keys should be used with care because a lot of the times it's really hard to... Once you give, if someone gets hold of this API key, they can really disturb and misuse your application, then they can cause harm. So the way that you protect your API key is extremely important. There's many ways to reduce the surface area so you can use API key rotation, encryption to make sure that the access to these API key is actually limited. So there's many <a href="/tags/automated-security">security</a> controls that come as a responsibility when you use API keys, but sometimes it's needed. In certain use cases, you may want to have maybe admin use, admin endpoints or maybe during early development stages where you don't have yet your IDP connected in. It may come in handy to use API keys, just be aware that it's usually something that needs to be taken with a lot of care into production, into production systems. This itself provides the API key authorization. However, and at the same time, it does two things because not only we create an API key, but by creating an API key, we define the primary authorization nodes because we didn't have any other configures. So what this basically defines is that now if you try to query our API, if you do not provide this API key, you would get rejected. So it itself, it's better than not adding anything, but we're going to look into some more options that you can secure API. So they have here the possibility to, you can have maybe some nice description for your API key. Required, but yeah. Nice to have. Now, into the second <a href="/tags/authentication">authentication</a> method, and here we're going to cover Cognito. So with Cognito, we're going to essentially reproduce what would be the behavior of an IDP on a <a href="/tags/data">data</a> we provided, but using just built-in technology. So what Amazon provides is, it simplifies this process of <a href="/tags/authentication">authentication</a> to you. Also, user management, if you want to run some authorization. There's built-in controls that make Amazon Cognito really good if you need something really quick, and that provides tight integration with some <a href="/tags/aws">AWS</a> services. So this is, it ties very well with most of the API services from <a href="/tags/aws">AWS</a> and we're going to create a user pool. So if we, and I'm going to explain what is a user pool. If we use the search bar and we go to Cognito, maybe let's go on a separate tab, but if we go to Cognito, we're going to create a user pool. And what is a user pool? It's just a user list. So it's a store for users. It's your personalized user store for your application. And again, you can use the configuration wizard to make things easier. Maybe I would like to just like to add something here. So the whole reason why we want to do this is because at the end of the day, we want to integrate our API into an application, right? So users need to have a way to sign up, to log in and register and all these kind of things, right? And we use Cognito here, but this could be replaced by anything like Okta, or Othero, or anything that you may be familiar with already or from <a href="/tags/azure">Azure</a> as well, the <a href="/tags/azure">Azure</a> AD. So it works, it's just an implementation of the OIDC specification. Just like AppSync is an implementation of the <a href="/tags/graphql">GraphQL</a> specification. So nothing specific, we just use this one here to make things super simple. But it will work with any sort of other IDP that you are familiar with. Yeah, yeah. Really well pointed out. Yeah, because this is going to be a user facing API. So it makes sense to have some sort of user flow. Thank you. So we're going to use the defaults of the <a href="/tags/workshop">workshop</a>. I don't want to actually go too much into the detail, why we're choosing username, why user email, because it's not actually too relevant. But maybe there are some sections which are relevant in this. On those ones we're going to focus, or we're going to spend a bit more time. Password policy, we're not going to worry about password policy now. MFA, let's keep MFA out again for simplicity, for our demo purposes, definitely recommend in production to step any sort of multifactor <a href="/tags/authentication">authentication</a> would be preferable, especially if you have access to sensitive <a href="/tags/data">data</a> or critical operations. And what do we have here? I think we're going to use just email only as well. So here in this menu, I think you can just click anything before everything defaults. And then in the signup experience, we're going to enable self registration. Again, here, I think we're not changing anything. We're going to keep the default IDC attributes. Yeah, let's so in the signup experience, we're also not going to change anything. Maybe in the message, it's important to point out. Here, we're going to change something. So instead of using Amazon SES, we're going to use Cognito. And the reason we're going to do this is for simplicity, but bear in mind that this is actually not recommended for production workloads. So if you wanted to use Cognito as cognitive user pools as to <a href="/tags/authentication">authenticate</a> your users, you should probably use the recommended approach with a more scalable service. You can see here that with Cognito, you actually be limited to 50 emails a day, which is just may not be scalable to your application.

But if you're just doing a small POC, it would be totally acceptable. And now to the user pool name. What are we calling our user pool name? It's important that you write exactly the same and OK sensitive because this will be later on used on the front end. So it's important that we'll have the same names here.Thank you. Yeah. Otherwise we probably need to change something in the application, right? So in the initial app client, we're not going to change. We're going to keep public clients because this is going to be user-facing applications, going to be used by web applications. So this basically means that instead of using the flows for confidential clients that where you can safely or securely start your credentials, this basically means that you will not be able to do it and you're going to use like this side of access tokens, which expire after a couple of hours. I don't want to cover the OAuth too much in detail here, to be honest. And then on the app clients, <a href="/tags/workshop">workshop</a> app clients in the <a href="/tags/deep-dive">advanced</a> in the <a href="/tags/authentication">authentication</a> flows, we want to select a user password. This will be our <a href="/tags/authentication">authentication</a> method. We're not going to change the defaults of refresh token TTL or access token TTL. We're just going to keep the defaults. And then I think that's it. Yes. So hopefully everyone is on, is catching up or didn't fall behind. We're just going to do a quick, a quick recap to make sure everything is fine. Yes, it is fine. So if you're satisfied with the result, you can just press create user pool. And again, with all the <a href="/tags/aws">AWS</a>, with, again, as with most of <a href="/tags/serverless">serverless</a> <a href="/tags/aws">AWS</a> services, this just gets managed behind the scenes for you. And you can already see that the user pool is already available. So already available for you. And the last part of this section is actually we're going to create a user for ourselves. So we're going to create a user for ourselves. So we're going to create a user for ourselves, because this is what we'll use to then test the end-to-end flow between our application and our API. So the way that you can create the user, even though we, I think we had like a self-registration flow, we're going to just use the <a href="/tags/aws">AWS</a> <a href="/tags/cli">console</a> to make things easier. And then it's really important that you put a send an email invitation. And I'm pretty sure you only need an email. Maybe let's use the suggested by the <a href="/tags/workshop">workshop</a>. So the email is what's important because that's where you'll get the temporary password for you to log in. Then you will be prompted to update it. So this will be generated to you automatically. Alternatively, you can also set the password so that you can just keep the email stuff against just so that we get some time, but I'll totally up to you. You will have to change the password either way. So whether you set your own password, but maybe it's hard to come up with a password that is compliant. Otherwise, you can leave that generate one. And that will be sent to over email. And once you log in for the first time, you'll have to change it anyway. But yeah, let's follow the <a href="/tags/workshop">workshop</a> here. And you can already see that the user is already available. So one of the cool things that we're actually not going to cover in this <a href="/tags/workshop">workshop</a> is, there's more to Cognito that is invoked by having your users track here. So you also, you'll be able, you are able to include some, or to implement some sort of authorization, more <a href="/tags/deep-dive">advanced</a> authorization, which we're not going to cover here. We're just going to do basic authorization based on identity, but you could bring in your roles, your attributes and start building complex authorization systems. So this is something that would be possible with Cognito and with any other IDP to be honest, but yeah, I just wanted to point out, and this essentially concludes the setup part. But this point, at this point, we have everything in place. So we have just to recap. We need to update the <a href="/tags/data">data</a> model. Yeah. Ah, yes, true. True. We need to update the <a href="/tags/data">data</a> model. That is very true. Because one of the things I forgot. Thank you for reminding me. So if we want to update the <a href="/tags/data">data</a> model because we want to test something specific, so remember the authorization mode that we defined for our API. So right now we just have the API key. So everything, all operations that are available by our API are authorized by API key. However, one of the things that we want to simulate here is multiple authorization modes because something that AppSync supports and the flow that we want to simulate here is that in order to create books, you would need to identify yourself as a user. And if you're just trying to do read operations or you're just trying to get the book catalog or doing any other type of read operation, then you could use the API key. And this is easily achievable with AppSync because you can plug in a couple of different authorization models. I actually want to cover them already before we drill down. So you have, we've already talked about API keys. The next one, which we're going to use is Cognito user pools. So this means that it would link your identity to Cognito. So you will be expected to provide some sort of identity. This will be in the form of a JWT token. And then we also have other types of authorizations, which authorization modes that we're not going to cover here. So we have <a href="/tags/aws">AWS</a> <a href="/tags/lambda">Lambda</a>, and this is very common in, we use it a lot with our customers because it provides you with a custom authorization option. So you can build on top of your IDP, run different authorization checks based on what is the <a href="/tags/data">data</a> being requested by whom at which time.

So you can build with <a href="/tags/lambda">Lambda</a>, you can go as crazy as you want. And then you have more traditional and simplified authorization methods. So you could plug in IEM and with IEM to identity and access management, you would secure your API using the <a href="/tags/aws">AWS</a> IEM signatures. So what this means is that it's very, it's fairly common for not for user facing applications, but for service-to-service communication, where maybe the other service is also an <a href="/tags/aws">AWS</a> service. And you can sign your request with that service identity, IEM for <a href="/tags/aws">AWS</a> identity, and then send that request over to be authorized.Then the final option is also the OpenID Connect that allows you to connect directly to your IDP. But the one that we're actually, we already talked about API keys, we're going to do the Cognito user pool because we've already included it. And what we're going to do is these separation of which operations will be done, the API key and which operations will be authorized via access token is done in the schema. And it's done with the concept of schema directives.So now, yes. So now we've configured the Cognito pools. We've... Just to recap. So in this section, we've created our API. We created two authorization modes. One of them, API keys built into AppSync. The other, Cognito. We created this Cognito user pool. We registered our user, and we configured which operations should be authorized by Cognito and which one should be authorized via API key.

What we're going to do? Before that, you need to add the authorization mode Cognito here as an additional authorization method. The order does not matter, does it?Sorry, you're right. I'm terrible at following step by step. You're totally right. Let's say the schema. We still need to... This is not enough because we need to wire it so that AppSync knows that it needs to use a specific Cognito user pool. AppSync does not guess. So we need to configure these additional authorization modes. And you can see here, so that the authorization modes that I described, we're going to select Cognito user pool in our region. The region that we're using for the <a href="/tags/workshop">workshop</a>. You could see here that you select a specific user pool. It's not random. Maybe this thing of the client ID rejects, you can apply some sort of <a href="/tags/validation">validation</a> already in the access token, I believe. No, this is the client ID. So to prevent let's say abuses, like DDoS attacks, people sending random client IDs in there. Oh, I thought it was... Okay. So when you created the Cognito user pool, you also created a client. Maybe if you go to that, if you still have it open. Yeah, here you have the app integration part tab. So that's basically how you're going to create. There it is. The <a href="/tags/workshop">workshop</a> app client. Exactly. So you have a client ID here. Obviously, for a web application to talk to this, it will require a client ID. You can create... There's a limit I think of 25 on how many clients you can specify for a user pool. But basically, any sort of application would need that. Again, nothing specific to Cognito here. If you use <a href="/tags/azure">Azure</a> AD or Okta or Ozero or what have you, it will work exactly the same way. You will need the client ID. In some cases, if you have a confidential type of client, you would also need a secret. But for the purpose today, we just have a client ID. And that Rex expression essentially would limit people trying random client IDs against your API. So it will essentially be removed before they even hit it.So now, yes. So now we've configured the Cognito pools. We've... Just to recap. So in this section, we've created our API. We created two authorization modes. One of them, API keys built into AppSync. The other, Cognito. We created this Cognito user pool. We registered our user, and we configured which operations should be authorized by Cognito and which one should be authorized via API key. So with this, we have the foundation to start using our API, because now it has operations and it's secure. So now, we can... In theory, we can already even like query the API. But I will leave that to you because we have this <a href="/tags/testing">testing</a> and <a href="/tags/debug">debugging</a> section. And I just want to follow the <a href="/tags/workshop">workshop</a> flow to not get people confused. Emanuel, I think now you can take over, because... Yeah, sure. Let me see if I can get this right. Okay. So I hope... Let's get rid of this Windows and whatnot. I hope that you'll be able to see my screen. I have a slightly larger screen that I'm sharing. So I hope that is still visible for everyone. Miguel, maybe you can confirm. Is it readable? I can confirm. Everything is readable. Perfect. Cool.

Is it readable? I can confirm. Everything is readable. Perfect. Cool. So we had just the schema that we just created. Maybe I would like to spend a bit of time describing it in a bit more detail. And then, actually, I would love to try a couple of queries to just validate what you just described there that you can use the API key only for reads. And if you want to use the Cognito user pools, works both for reads and writes. And then we're going to move into those in real time, which is very, very interesting and exciting. So now a little bit of ideas here around this schema. So we have a bunch of types, right, that we already spent some time describing. We have the base type book. And then we have... I'll leave this book connection for a bit. Then we have this input, which is used for mutations. Then we have another type for deletes. And then we have a type for filtering. So you will see that <a href="/tags/graphql">GraphQL</a> is quite capable here. So we will spend a little bit of time also playing with the queries. You'll be able to see that you can do very <a href="/tags/deep-dive">advanced</a> queries, such as filtering. So let's say you want a book that maybe has a specific publisher ID or that is in a publication year between 2005 and 2010. So you can do all kinds of crazy, interesting queries without necessarily changing the API, right? So comparing again with the REST API world, we need to implement different query parameters and path parameters for different things that you may want to get. <a href="/tags/graphql">GraphQL</a> has this kind of built natively and you don't need to necessarily do anything. And you'll see that some of that magic will be done also through resolvers. So aside from these things, I want to also maybe clarify this part with a book connection. So as any smart API should do, we have the concept of pagination, right? We cannot get all the books that maybe we have in our store that maybe will be returning hundreds of thousands of books. So we'll probably want to limit the amount of books that we get in a request. And then we can essentially go page by page and get the next 25 or the next 50, depending on page size. So this is what that is for. And now you'll see, as I mentioned, right, we have different types of filters. These NE and EQ, they're basically just short for equals or less than, greater than, et cetera. We have contained, so right for string types, different, different things. And maybe the other things that is very interesting, right? I think we covered it in the presentation, but maybe we didn't look at the schema that much is that we have a couple of, let's say high level types. And then we have mutations. Those are things that we change. So we create, we update and we delete, and then we have queries. So these are reads, right? We want to get something, we want to get a specific book or we want to get the list of books and we want to get filtered list of books and different other things. So we can create all of that. And then for the real time part, we'll cover when we get there, we have the subscription and I'll leave it when we get to there so that we keep, let's say, excited for a bit later. So now what I wanted to do is maybe to try a couple of queries. So if you go on this queries tab on the left side, you'll see that you have everything that was listed in the schema in here. So you have the mutations, we have the queries, and maybe we should try a couple of mutations and then a couple of queries to see how that works. Okay. So if we go here into the <a href="/tags/workshop">workshop</a> back again, and if you go to <a href="/tags/testing">testing</a> your API, you should have a couple of mutations that we can take so that we can have a bit of trial and we see what happens. Okay. So I'm gonna copy that into my thing, and I'm using the API key. So just so that you see what's going to happen. So just as we described, right, we're gonna get here not authorized. Why do we get the unauthorized here? It's because I cannot move this. Okay, now it's because in here, in the schema, in the mutation, for the create book, we only have to need the user pools as a directive. So we don't have to, as we have in the queries, the API key, right? If I would change it and add the API key, then I would also be able to create books without an API key. So for us, in order to create API keys, we'll need to change this now authorization mode to Conneto user pools. You're gonna have to click login with the user pool and select the client ID that we created. And here comes in play the user that we created for <a href="/tags/testing">testing</a>. So it was tester and I created a password. In your case, you will need to use the default password that was generated for you on email. And once you click login, there will appear another dialogue that asks you to create a new password. I already done that while Miguel was presenting, so I don't need to do it. But that's basically something that you need to go through. It should be very quick. And after I logged in, you will see that I am now logged in and I will be able to create now my mutation, right? So I was simply able to create a mutation. Now I want to explain a little bit on what's going on here. So I created a mutation, right? And I passed this input, an ID, an author ID, publication year, title, and publisher ID. If you remember when we created the <a href="/tags/data">data</a> model in here, a couple of fields were mandatory, right? So the ID, the title, author ID, and publisher ID. Later on, we changed the ID to no longer be mandatory. Otherwise, DynamoDB will simply create an ID for you. But we still have these three fields that are mandatory. Everything else is optional, right? So if you look again at the request, we passed in here only five fields. But what happens if I want to now send, let's say, more information? So say, some description that essentially split up my formatting. So I will probably just add it here.

So I can add some description to this book, okay? And I will do it on purpose so that you see what will happen. So my new book, just something simple. So we simply now updated another book. And you'll see that the response has not changed. The reason why here in this, within those curly braces, we specify what we want to get back of this request, right? And I did not pass the description. So I simply created the book, but we cannot tell if it's different or not. So now if I add the description and I run it again, I should get my new book, right? So just wanted to give you this two kind of things that you don't have, the fields that are not mandatory, you don't need to pass them in. And when you pass them in, you don't necessarily want to get them back. So you have all this flexibility. So let's create maybe a couple of more books from these examples here, just so that we can play a bit more with some other things.So now we created another book. I want to try now a little bit, some queries. So we will do the list books. So let's try to run that. Again, here, we will need to provide what are the things that we want to get back, right? So at the moment, I have nothing. But if I want to just get the author ID in the description, I can run that query. And you see, I created a couple of books. And I just get the description. And some of them have nothing because we didn't add them. But some already created with the description. And if I want to have more information, I can add everything in here and I will simply get more information from the <a href="/tags/data">data</a> source. What is the point of this is basically showcasing the power of <a href="/tags/graphql">GraphQL</a>, the fact that you can get as much <a href="/tags/data">data</a> or as less <a href="/tags/data">data</a> depending on your use case. So let's say, if you have a, as you will see in the front end actually, you have a list of books right, just showing as a list of products, you maybe just want to get a couple of information, maybe the picture, the book title, and maybe when it was published. And then once you click on that book, you maybe want to get the whole product description, then you will call the same endpoint. But we just asking for more information, right? So then you don't have this, let's say, issue of asking more <a href="/tags/data">data</a> than you actually need, but simply getting the right <a href="/tags/data">data</a> that you need in that specific page, right? So your queries will run super fast and do not risk of exposing too much <a href="/tags/data">data</a> that you don't need.So we run a couple of queries. Maybe also want to see, so this is a list of books. We can also run maybe a specific book by author perhaps. So let me see if I can get an author ID, one, two, three here. I can simply run that. Oops. Let's see, maybe I will remove this part. And here, same thing, I want to get, say, publisher ID and author ID just to verify. So now I simply get all the books by author index, all the books with author one, two, three, and I think there was another one, seven, eight, nine, if I'm not mistaken. Yeah. So we have also a book with that one. So again, super powerful. Just by creating that <a href="/tags/data">data</a> model that we spent, I don't know, a half an hour doing, then now we have all these possible filters and so on. And cool. Now, maybe we want to, I see there is some activity going on in the chat, but I'm actually not sure what this is. I'm confident that Miguel is taking care of that. If there's something unclear, feel free to ask. Maybe now we'll go into this real-time aspect of the application, right? So so far we have done these queries and mutations, right? Those are equivalent of get posts. We didn't do any sort of patch or delete, but you get the point. Now we want to move into another area of, let's say, strengths for <a href="/tags/graphql">GraphQL</a>, right? So we mentioned at the beginning that a lot of the use cases, when it comes to <a href="/tags/graphql">GraphQL</a> are essentially subscriptions or real-time updates. And rightfully so we had, I think, a big project if you follow football with a big, let's say, soccer league in Europe. And essentially the use case there was the fact that you would have an application on your phone and you would want to get live updates of what's happening in the match. And you think that, or maybe you're interested only in who scores and whatnot, but actually those updates would be a lot more interesting. So like for important events such as penalties or risky situations, where there's, let's say, anticipation building up, so you will get all this update live. And all I can tell you that performance-wise actually we managed to get the API so fast that the application was faster than what was happening on the TV. If you don't know what's going on when you watch TV, even if it's live sports event, it's not essentially live. There's a bit of delay. Depending on what you're watching, it can be 30 seconds, one minute of delay. So between what's happening physically in the stadium and what's streamed on TV, and with, let's say, what we were doing and the way we were streaming the <a href="/tags/data">data</a> is that the application was too fast. So it was reporting events that were happening ahead of time as they were happening on TV, just to showcase you how performant this could be. So in the end, we had to do some sort of artificial delay so that, let's say, the app would be synchronized with what was happening in the live stream. But the idea here is that those use cases are for real-time applications. It uses WebSockets as a technology behind the scenes. And basically, you're able to get a real-time <a href="/tags/data">data</a> stream. And this works at <a href="/tags/scalability">scale</a>. So you could have, let's say, one application with thousands of users being subscribed, and all of them would get the event at the exact same time. There are not a lot of use cases that would need this kind of real-time applications, but it can also be used for other things. So let's say you are creating, let's say, a simulation job or any other, let's say, long process running. The way you could traditionally do it in the rest world would be that, you create your job with a post on a specific resource, and then you would have, let's say, a get on the same resource to get the status. And maybe you do that with a polling of, I don't know, 10 seconds or 30 seconds, depending on how long that job would be. And every this time, let's say 10 seconds, every 10 seconds you'd call that resource to get the status. Well, you will not need to do any of that with subscriptions in AppSync, because essentially you subscribe into the status updates, right? And once the status has changed, your application will be automatically notified. So you have this kind of nice top-sub subscription mechanism, and it's handled entirely seamless for you.

Well, you will not need to do any of that with subscriptions in AppSync, because essentially you subscribe into the status updates, right? And once the status has changed, your application will be automatically notified. So you have this kind of nice top-sub subscription mechanism, and it's handled entirely seamless for you. So there's no need for you to do anything except for creating this beautiful schema here that is already found out, that we already did in the AppSync. I'll just briefly cover it a little bit.So we have here a different type, right? So before we had queries and mutations and other base types. And now we have a new type, which we call subscriptions. And basically, we have a couple of them here. We have on create book subscription, on update book subscription, and on delete book subscriptions. There is some naming convention in here, as you see. So it's on event. And those events are specifically mutations, right? So we want to listen for events on a specific change in the object. And in here, because we just have creates and updates and deletes, we have one subscription for each. And again, syntax-wise, right? So these are the objects that you can possibly ask for when you listen on this subscription, right? So let's say you subscribe, and you want to see when a book is updated, you can ask for this type of periods. And this is the schema, right? This gives you control as a server to tell the clients what is possible for you to ask. And of course, you as a client, you can ask any of those things, but you cannot ask something that the schema does not specify. I think it's very clear here.And now this directive here, <a href="/tags/aws">AWS</a> subscribe, basically says, okay, this event is listening on what? And in our case, it will be listening on create book. Similarly, applies on update book and delete book, right? And we will actually try it out and see how that works. You see probably here the explanation. We will actually take this subscription on create book, and we will listen to it, and we see how that works. So I'm going to go into AppSync. I'm going to copy that. I'm going to do a run. So you see now that it says subscribe to one mutations, right? And there's like this loading circle in here, showcasing that it's actually loading. Maybe what I could have done is also show you the network piece. I will do a reload and clean everything up here on the network side, so that we see what's actually happening if you're interested in network layer.

Let me see if I can somehow make this a bit smaller so that I can copy. Maybe not. Okay. I will do that and then network again. All right. So let's see here. And we're looking for actually it's not in here. Is it? One second. I think it's in here. Correct. So you'll see this is essentially the web socket that is connected. You'll see a couple of interesting things in here. This is basically just the connection keep alive. There will be messages coming into it from time to time. From time to time. What will be interesting is that once I create a mutation on CreateBook, you should see that message coming through. Of course, the <a href="/tags/cli">console</a> will also display it, but just wanted to show it on the network, as well.So I'm going to create a new tab for queries and I'm going to create a new book. So we're going to go here, <a href="/tags/testing">testing</a> your API, and we're going to take this CreateBook3 mutation and we're going to put it into here. Right. So we're going to run this. Oops. Okay. We're going to run this one. Oh, I copied the whole thing. Sorry. I just wanted to copy the first, the third one. Of course I'm using the API key, not allowed. So again, I need to login with my username, password. In fact, I can type it correctly. Again. Okay. So now. Perfect. So we created another book and first of all, you see here on the right side, we have received the <a href="/tags/data">data</a>, right? So we've received the subscription <a href="/tags/data">data</a> and you'll see that it only shows the ID and title. And the reason why that is, is because we, when we subscribe, we only ask for ID and title. Of course, we could ask all the things that we have in the schema, which is publisher ID, title, author ID, all the other <a href="/tags/data">data</a> that is to be found in the schema. But in our case, we only ask for ID and title. Although in the mutation, we send a lot more information. Right? So again, it allows you flexibility as a client to ask for whatever <a href="/tags/data">data</a> you wanted. And hopefully here, we should also see that in the WebSocket stream, we received the same payload that is displayed here on the right hand side. So that's how you will see it on the front end, essentially. You receive, as you listen to the stream, as you subscribe to the stream, you receive a continuous stream of <a href="/tags/data">data</a> and you will have to be able to <a href="/tags/react-components">react</a> on that event. Fortunately, if you have a front end <a href="/tags/frameworks">framework</a>, like <a href="/tags/react-components">React</a> or <a href="/tags/angular">Angular</a>, that's super, super simple to do. And there's like built-in functionality for that. So you will be able to receive the information quite easily and update your <a href="/tags/user-interfaces">UI</a> seamlessly. Right? So there's no need for the <a href="/tags/user-interfaces">UI</a> to do refreshes and change URLs and whatnot. Right? The update can self change without any sort of interaction from the user or any sort of additional network calls that can be expensive. It's a continuous stream of <a href="/tags/data">data</a>. Great. So that would be the part for the real time subscriptions. Obviously, we can try the same thing with on update books, on delete books, but I think, I hope that you kind of understood the gist of it. So I will not go through trying out the delete book or the update book subscriptions.Maybe one thing that it's important to point out, Emmanuel, is that this type of subscription, you can use it as sort of for real time updates, but you cannot think of it as a durable notification story. So anyone that is subscribed, it's like a pub sub, but without persistent storage. So if there are active subscribers at the time that are subscribed to a specific topic or to specific mutation, they will get this info. But if you come in late, you will not get these messages. Correct. You will not get this history. Yes, of course. You'll only get newer updates. Correct. There is sort of ways to deal with it, but it's not part of the topic, but indeed that is correct. Again, depends really a lot on your use case. The use case that I gave with the sports or the use case that I just gave with, let's say, having a job that is long running and you want to just get updates on that, I think do not suffer from this. But there could be potentially like games, for example. If you leave the session and you join later, you will need to get all those things stacked up. And there's also this additional functionality around offline interaction, but again, not covering that right now.

If you leave the session and you join later, you will need to get all those things stacked up. And there's also this additional functionality around offline interaction, but again, not covering that right now.The question was, can it send different events to different users on the same subscription? No. Right. All the subscribers will get the exact same payload as I just demonstrated. And then the other one is, is it possible to send events without additional mutation? For example, directly from EventBridge? No.Now maybe we can spend some minutes into AppSync resolvers. So we run all these queries and mutations and subscriptions, right, but we haven't really looked at what's happening behind the scenes, right. So let's maybe take a look, because we interacted with the API, but we never really looked at the <a href="/tags/data">data</a> storage layer, right.

So you will see when we create the subscriptions in here, basically have this directive that says, what am I listening to? What type of event? And you cannot listen to events that are not coming from mutations in AppSync. So you cannot listen to events that are coming from EventBridge or a DynamoDB <a href="/tags/data">data</a> stream or Kinesis for that matter, if you're familiar with that, it's only words from mutations. But you could create, if you want like a composite workflow. So let's say if you have an event coming from EventBridge, you need to have a handler for that event. And then that event can trigger a mutation in AppSync and create kind of that nice, let's say, well-integrated pipeline. But no, by default, no, it's not possible. It would be cool. I agree. Right. Because then with EventBridge, you can connect that piece in so many places, and you could have like a twin flow. But no, it's only working, subscribing to mutations. So changes in the <a href="/tags/data">data</a>, right. So you have like an API, you want changes into that <a href="/tags/data">data</a>, those events are coming from somewhere else. Yeah, the alternative, right, with EventBridge is that you can connect EventBridge to SNS and you have a pop stub mechanism there as well that you can work with. But this really is specific to the <a href="/tags/graphql">GraphQL</a> API. Yeah.

Cool. Now maybe we can spend some minutes into AppSync resolvers. So we run all these queries and mutations and subscriptions, right, but we haven't really looked at what's happening behind the scenes, right. So let's maybe take a look, because we interacted with the API, but we never really looked at the <a href="/tags/data">data</a> storage layer, right.So if you go now back to DynamoDB, which is our persistent <a href="/tags/data">data</a> layer at this point, you will see we have our books table, and now we should be able to see all the things that we have created, right. So you see that we have these IDs with author ID, with description, publication, year, publisher ID, et cetera, title, and so, so many things. How this is actually being populated, and how does <a href="/tags/graphql">GraphQL</a> or AppSync knows how to retrieve this, right, and this works with the resolvers.You will see that the way we have created the resolvers right now is with AppSync resolvers, <a href="/tags/javascript">JavaScript</a> resolvers, that are built-in to the service directly. So we're going to maybe have a look at one of them. So say we want to see a query resolver, maybe for these books we can do that. So we clicked on that resolver, maybe I clicked too fast, so let's maybe go back again. So on the resolver side, for query, we have this resolver here, books table, and you'll see that it opens a bit like this, and there's some <a href="/tags/javascript">JavaScript</a> <a href="/tags/code">code</a> in here that you may be asking, what is this?Basically what this resolver <a href="/tags/code">code</a> does, it essentially makes a query against the <a href="/tags/data">data</a> source. So it has this function called request, this is essentially the part that it goes to the <a href="/tags/data">data</a> source, and then we have a response function that essentially responds back to the requestor. Now why this can be super interesting and super powerful? Well, you can customize what is being sent to the <a href="/tags/data">data</a> source, in our case DynamoDB, and what is being returned to the client.In simpler terms, let's say you're making a request to DynamoDB to return a list of books, okay? Fair enough, we can leave this request super simple. But in the response, once we get the results from DynamoDB, we can do, for example, simple transformations. What that could be, so let's say we can have a price, and maybe in DynamoDB we have a price with 10 digits, what we can do in here, we can essentially round that price with only two digits. Or do we want to change a name of a field, or do we want to do some simple aggregations like, let's say, you want to get, let's say, how many books in a specific genre do you have in here.So you can do all these simple calculations in here, and I gave you the example for response because it's a bit more maybe easy to grasp. You can do similar things in the request. As an example, say there's a request for going to DynamoDB, but you want to get those, let's say, the responses, so when you make the request to DynamoDB, ordered by a specific field. So, say, you want to get all these books from this author, listed by price in a descending order, right? Obviously, you could also do that in the response, once you get to the response from the <a href="/tags/database">database</a> itself, but it's more efficient to do it in the <a href="/tags/database">database</a> layer itself.That's kind of the power of using those <a href="/tags/javascript">JavaScript</a> resolvers. Obviously, it's quite limited in terms of things that you can do, so you cannot do here, for example, returning 100,000 items from a <a href="/tags/database">database</a>, and expect that you will be able to do complex calculations and whatnot. That will not be possible, but for simple things, it works quite well. And we have here, on the right side, lots of example queries and batch operations and whatnot. So, let's say, if you want to get the top 10 items or top 100 items, and that is, for example, the limit for batch operations that have a specific property. So, let's say I want to have the first 100 books, right? Works with pagination. The first 100 books that are coming from this author or that have, let's say, a price over or less than 100 euros.Or that's still 100 euros for a book. That's quite a lot. But you get what I'm trying to say, right? You can do all these kind of complex things in the resolvers. And that's how it works behind the scenes. And those resolvers are native resolvers. There is also other type of resolvers. I don't know if it's necessarily worth going at that level detail. Miguel already explained that you can have a <a href="/tags/lambda">Lambda</a> resolver. That's kind of the most powerful thing. Because in a <a href="/tags/lambda">Lambda</a>, you can have your own custom write time. So, you can <a href="/tags/code">code</a> in Python if you don't like <a href="/tags/javascript">JavaScript</a>, for example.Or if you have, let's say, people in the team that do not know <a href="/tags/javascript">JavaScript</a> and they want to <a href="/tags/code">code</a> in Python, you can use a <a href="/tags/lambda">Lambda</a> resolver and <a href="/tags/code">code</a> in Python. It works very similarly. So, you have a function that makes a request and a function that returns the response. But you can just do a lot more powerful things because <a href="/tags/lambda">Lambda</a> itself is a service. It has a lot more compute power than this AppSync run time. So, this AppSync run time that you see also here in the bottom left, I do not know by heart, but it's like milliseconds. You cannot run for half a minute or something like this. So, it will have to be quite small.The other important part, right, and we maybe did not discuss that much, is this resolver, it works against the <a href="/tags/data">data</a> source. In our case, the DynamoDB table. And maybe it's a good time to discuss what other type of <a href="/tags/data">data</a> sources you can use in AppSync. So, if I go back to schema, you also see that I can attach resolvers to any sort of field. So, what can this, let's say, result into, or what kind of, again, additional functionality you can have, is what I was hinting before to composite types. So, let's say if you have this type book, and then instead of the author ID, you'd have another type called author, you could attach a resolver to that specific field, and you can fetch, for example, the information related to authors from another <a href="/tags/database">database</a> or another <a href="/tags/data">data</a> source.And that's why I wanted to discuss a little bit on how that would work. So, if you were to attach another resolver to a specific field, you can choose between a unit and a pipeline resolver. We'll talk also about pipeline resolvers in a bit. And the runtime we already discussed, the VTL, it's an Apache language, it's honestly awful to work with. The reason why is, like, super verbose and hard to read. And so, you probably want to use the <a href="/tags/javascript">JavaScript</a> runtime. And then you have a couple of <a href="/tags/data">data</a> sources. And in here, you have native <a href="/tags/data">data</a> sources to AppSync. And you can also have custom ones.So, the native <a href="/tags/data">data</a> sources to AppSync are DynamoDB, OpenSearch, <a href="/tags/lambda">Lambda</a> functions, HTTP endpoints, event bridge, and relational databases. That means you do not need to write any sort of <a href="/tags/code">code</a> to integrate with this. We just integrate with DynamoDB. You saw that the <a href="/tags/code">code</a> is automatically provided to you by AppSync. Same with OpenSearch, <a href="/tags/lambda">Lambda</a> functions, HTTP endpoints, and so on. With HTTP endpoints, you already have the possibility to combine with other APIs. So, for example, you could combine a <a href="/tags/graphql">GraphQL</a> API with a REST one.

So, say, that information about the authors could come from a REST API that is managed by another team, for instance. Or you can have a pricing API that just returns prices for books, and you want to resolve that information from another API that is managed by someone else. That could be easily done with HTTP endpoints. And of course, if you want to really go custom, so one of these things, and we have with our customers, you always have the option of a <a href="/tags/lambda">Lambda</a> function. So, with a <a href="/tags/lambda">Lambda</a> function there, you can request <a href="/tags/data">data</a> from literally any source of <a href="/tags/data">data</a> source you can think of. Let's say from a storage on-prem, from a <a href="/tags/database">database</a> on-prem, from S3, from literally anything that you can think of. So, you have all these possibilities. Essentially, you're not constrained to anything. The power is that if you use any sort of those <a href="/tags/aws">AWS</a> services that are listed here, you have native integration and you do not need to <a href="/tags/code">code</a> anything with the <a href="/tags/lambda">Lambda</a>. You have the full flexibility, but you have to <a href="/tags/code">code</a>, which is a great thing, I think. We all love to <a href="/tags/code">code</a>.

But sometimes we just want to also be more productive. And back to here, I also want to talk a little about pipeline resolvers. So, as the name suggests, a pipeline resolver is just essentially a chain of resolvers. So, essentially, let's say you will get from, let's maybe go to the schema again and look for an example. And the book example works here nicely. Let's say if I had these books. And we will, let's say the first step of this pipeline resolver is to fetch all books that are published in 2024. Okay? That would be, let's say, step one. In a step two of such a pipeline resolver, it could be that we query another API to say which of these subset of books that were already published in 2024 are from a specific, can be found in a specific city or can be purchased from a specific retailer. Right? Which can, again, be a totally different API. It can be an external API as well. Right? So, if you think of having an <a href="/tags/e-commerce">e-commerce</a> solution built on top of this, it can be something totally different. And then in the end, right, the user who made the query initially would get all this information kind of bundled in. So, he gets all the books that were published in 2024 and says, okay, these books can be found in New York, at these places, maybe with also addresses, with opening times perhaps, right? So, you can enrich the <a href="/tags/data">data</a> quite a lot by implementing all these pipeline resolvers. Now, again, in the rest of the world, you can also do that. But that will require on the client side a lot more calls. So, first, they get the list of books and for each book, make the other API calls. So, you move essentially all that heavy lifting on the server side rather than on the client side, which is always a win. Right? Clients should always be, or ideally should always be thin clients. Without having to do any sort of heavy computation and of course every time making like lots of requests on the <a href="/tags/frontend">frontend</a>, you will essentially lose time and the customer experience is maybe not as great. So, I think that's a bit of a word on the resolver. All of that is, of course, was explained here and there's a lot more, let's say, examples in terms of what you can do with conditions inside those resolvers. But I think I covered quite a bit of what I wanted to hear. And the reason why I maybe did not want to follow this much, because I also want to build the application and I want to see how that looks like and try it with you together. So, I would like to go now into this integrating your API part.So, so far, we have built an API. And now, we would like to essentially connect this API with the <a href="/tags/frontend">frontend</a>. So, that we see how that application talks to Konecto to <a href="/tags/authentication">authenticate</a> the user and then how it fetches the <a href="/tags/data">data</a> from the AppSync. So, for that reason, we will use a service called Amplify. Do not need to know too much about it, it's just a way to essentially host our <a href="/tags/frontend">frontend</a>. And in order for us to deploy and host that <a href="/tags/frontend">frontend</a>, we will use a <a href="/tags/cloud">cloud</a> ID, it's called Cloud9. So, you can click on that link that will directly redirect you here. And I think I should have already an environment, but I need to switch the regions. So, going to Ireland, I should already have an environment. Let's maybe, I need to move this thing from somewhere. Okay. So, I can start this environment to take a couple of minutes maybe to initialize. And essentially, what we will do from this environment, you will see that we have, maybe I can, while this is initializing, I can show you already, we have essentially a repository in CodeCommit. So, you can think of this as Git repository, nothing too fancy here. We will have a <a href="/tags/frontend">frontend</a> repository and a <a href="/tags/backend">backend</a> repository. And what we will do from Cloud9 is essentially deploy this <a href="/tags/frontend">frontend</a> repository into Amplify and then we will be able to access the application and maybe do a couple of <a href="/tags/code">code</a> changes to demonstrate how that talks to the API. So, here are Cloud9 environment. It's already initialized. You see that we have the <a href="/tags/backend">backend</a> and <a href="/tags/frontend">frontend</a> repositories. So, we will simply go to that specific repository. We will run <a href="/tags/npm">NPM</a> install, I think it was dash dash and no log level. Never mind. It will do the <a href="/tags/npm">NPM</a> install, so installing all the <a href="/tags/modules">modules</a> required for the <a href="/tags/frontend">frontend</a>. And after that, we will run these commands. And what this command will do, it essentially connects the <a href="/tags/frontend">frontend</a> with the Cognito user pool that we just created before. So, it's just a configuration on the <a href="/tags/frontend">frontend</a> side. Once we run these commands, I'll show you exactly how it looks like. But we're just waiting for the <a href="/tags/npm">NPM</a> install to finish. I hope that you're all in here and you're able to initialize Cloud9 and run through it. Then I don't usually work with Cloud9. But it's really nice if you want to run stuff directly in the <a href="/tags/cloud">cloud</a> without necessarily having anything installed on your computer. And for instance, I could connect to this Cloud9 from my work computer, but also from my private computer from anywhere in the world. It's kind of powerful in that way. And I have access to the repositories. Obviously, if you're not online, so you don't have any internet connection, that could be quite tough. But there's interesting things that you can do with it. So, we're waiting for that to install. Maybe one thing while that's loading, another thing about Cloud9 is that you can plug it into the VS <a href="/tags/code">Code</a> remote explorer. So, you can <a href="/tags/code">code</a> from your VS <a href="/tags/code">Code</a> IDE with your plugins. But then behind the scenes, it's just an SSH to Cloud9. So, it's something that we see some of our customers using because they need this stable environment or similar environment for everyone. Exactly. For sure, it's an <a href="/tags/enterprise">enterprise</a> problem where they want everyone to have the exact same setup. Sometimes, we see there's people using different IDEs locally, right? And that could run into misconfigurations of them and create style issues when it comes to formatting and whatnot. So, in this way, they can provision this environment the same for everyone and have a unified experience regardless of what they're using on the local.

For me, for example, I prefer to use PyCharm. But Python works. Yeah, yeah. I think with intelligent, most intelligent IDEs also work. It's a bit more work. Yeah, of course. Yes. It's an SSH standard at the end of the day. So, pretty much anything that can connect to that, you can do it even in game or whatever. Okay. This is taking a bit of time, but I think it should be almost there. Okay. So, now it's finished. We're gonna run this GenerateConfig. Behind this GenerateConfig, why it was important to name the user pool exactly like it is in the <a href="/tags/workshop">workshop</a> is because this batch file essentially looks for that user pool with the name in the <a href="/tags/workshop">workshop</a> and generates this configuration. And let's look at the configuration that we just generated. So, it refers to these ones. We could obviously also populate this by hand, right? This is the <a href="/tags/graphql">GraphQL</a> endpoint, the API key, <a href="/tags/authentication">authentication</a>, and the user pool, so on. Obviously, you can get all of that information, for example, from AppSync. That's an important point, actually, here. So, this is the <a href="/tags/graphql">GraphQL</a> endpoint that we have now configured here. Important, right? So, for you, if you want to access your API, this is the single endpoint. It's not like in REST where you have lots of resources and you have HTTP verbs. No. In <a href="/tags/graphql">GraphQL</a>, you have a single HTTP verb, so every single query mutation subscription requirement is like a post, and then you have the WebSocket endpoint, which is exactly this one. That's it, yeah. And we essentially with this batch, we just generated this configuration, and now we're going to commit those changes, and we're going to push them to the Git repo. In a normal environment, you will not push to the main branch, but we're forgiven here. We are in a <a href="/tags/workshop">workshop</a>. And now the last step that we want to do is just we want to deploy this repository into Amplify so that we can access the beautiful application that was just created. So, here, I'm going to go to Amplify. We're going to click on create get started. We're going to host your web app. We don't want to build it. We already have it. We're going to choose the source as being called commit. It supports other Git repositories, as you can see here. We'll choose the <a href="/tags/frontend">frontend</a> repository, the main branch. And we're gonna leave everything as default. And next, and save and deploy. And this will take us, I think, a couple of minutes to provision, build, and then deploy. Once that is available, we will have this link, and we will open the application to see how it looks like. This is a simple <a href="/tags/react-components">React</a> application, but it's available through the <a href="/tags/workshop">workshop</a>. For the reason of time, we did not <a href="/tags/code">code</a> something from scratch. But we will make a few changes just so that you see how that works and how simple it is actually to connect to the API. While that is maybe building and deploying, I will talk a little bit about the application itself. So, once we will open the page, we can create a new account, or you can use the account that we already created, whichever way. Probably use the account that we already created so that we gain some time. But you have a signup feature, and the way this works is that it's connected to the committer user post that we just created. Similar flow would work for any other identity provider. And after that is done, we will essentially connect the application to the API, to get all the books. All right? So, we will just do the read part. I don't want to spend too much time. We don't have a lot of time left to do all the real-time updates and so on. But at least that is the books part I would like to see with you. So, let's wait for this part to finish. And then we throw that together. Lovely. So, now we have our application. As I mentioned, we can sign in with the user that we created before. Or we can create a new account or be in the interest of time. I will use the user that I already created before. So, now you see that I'm already logged in. But now I click on books, and nothing happens. All right? So, our front end is not connected to anything. So, what we will do in the next five minutes maybe, we will connect the front end with the API. And we will see all the books that we had. So, let's do that real quick. So, we will go to integrating your API, use the API part. We will skip this, use the create books API for now.

And we want to use the list books API, okay? So, it says that in the <a href="/tags/cloud">Cloud</a> 9 IDE, we want to open this specific file, in this particular directory, and to make some changes. Okay? So, the changes is that this is a <a href="/tags/react-components">React</a> application. If you're not familiar, you can go directly to the solution piece. And I'll copy this and I'll explain how this actually works.So, we go into here, in <a href="/tags/cloud">Cloud</a> 9, into the front end repo, under components, under books. And in here, there should be a comment that says, on line 47, this books, and there's a user effect. Right? So, what we want to do is essentially call the API and get all the books that we already created. So, we have a function here, a <a href="/tags/javascript">JavaScript</a> function that makes a call to the <a href="/tags/graphql">GraphQL</a> API to the query list books. Right? This comes from the schema itself. We set a couple of variables. So, for example, this is probably way too high. We don't want to list all the books that I mentioned. We probably do the pagination that I mentioned. So, we can get, let's say, only the first 100 books or whatever. And then with the next token, we could technically iterate to get the next 100 books, and so on. And here, we have essentially some error handling, and that will be very straightforward. And what we will do here, we will commit our changes and push them, and then deploy once again. Of course, we need to save the file. So, I'm using a Mac. I'm doing a Command S here. But in case you have a Windows, you might need to do a Control S, or go to file and then click save. Go from here and then save. So, we committed our changes. Now, we can do a push. And the beautiful part is that now the amplifier will again, once again, build this and deploy it. And we should see the changes into our <a href="/tags/frontend">frontend</a> very soon. So, let's give that a minute.Now, maybe while this is deploying a bit of word. So, here we did everything manually, but in an <a href="/tags/enterprise">enterprise</a> scenario, essentially there is tools. For example, CodeGen that can generate, for example, the schema for you on the <a href="/tags/frontend">frontend</a> based on the <a href="/tags/graphql">GraphQL</a> endpoint that you just had. So, that can be quite powerful, right? If you need to create classes, interfaces right on the <a href="/tags/frontend">frontend</a> to deal with the objects, you can simply give this tool, the <a href="/tags/graphql">GraphQL</a> endpoint. It will download the schema, right? And it will generate all these classes and interfaces for you so that you gain quite a bit of speed instead of creating everything manually. Obviously, in our case, we did not do any of that. But again, it's because we're doing a POC or rapid prototyping. In an <a href="/tags/enterprise">enterprise</a> scenario, you would need to do all of that. Yeah.And you get like the <a href="/tags/typescript-libraries">TypeScript</a> definition files. So, you get the IDE linking and highlighting immediately. So, that's really powerful. Exactly. You see here, for example, there is an example where they have a schema. Again, this can be downloaded at runtime. It generates all the interfaces and all the <a href="/tags/code">code</a> associated with it and all the types that is required on the <a href="/tags/frontend">frontend</a>. So, this is how you would do it in an <a href="/tags/enterprise">enterprise</a> scenario. What we did there is just something that we want to see the application working. Just want also to give you that perspective. Maybe another thing, Dimon. Sorry for interrupting. But you're seeing Amplify here. We use Amplify as a library here, but you actually do not need to use Amplify. Of course. You can just connect to AppSync with any <a href="/tags/graphql">GraphQL</a> client. In theory, you could even... We saw some customers using <a href="/tags/apollo">Apollo</a> client on their <a href="/tags/frontend">frontend</a> application to connect to AppSync because it's a compatible <a href="/tags/graphql">GraphQL</a> implementation. Exactly. Now, you see that after we just inserted our query to the API, we get this list of books. Maybe it's not the best. Here, on this settings icon, you have an option to generate books. We will create a couple of them just so that we see how this nice actually gets populated. Maybe after 5, 10 seconds we'll stop and refresh the page so that you see how many books actually it created. Okay. Maybe that's enough. We created 100 books. This is enough. Now, we have all this <a href="/tags/data">data</a> being published in here so that's quite nice. And we have also the pagination implemented so we can keep going as we need. Now, obviously, you can make all this more complicated. I think in the next step of the <a href="/tags/workshop">workshop</a>, we will be able to do real time updates. For example, we can... Of course, if you had the creation.

We could create a book called the API, and then the <a href="/tags/frontend">frontend</a> will not need to call again the API to get all the books. It will simply subscribe on this ad book mutation and the <a href="/tags/frontend">frontend</a> can update behind the scenes. So, this is quite powerful. And the theme updates can be also propagated to all the users. So, if you do not... All the other users already are here. Maybe they do a search. Well, this search now will also include the book that someone else has created. And yeah, this is a very naive example, but think of <a href="/tags/e-commerce">e-commerce</a>, for example. People adding new products into your <a href="/tags/e-commerce">e-commerce</a> every day or every minute or what have you. You're getting those updates seamlessly. So, that's quite powerful.Looking at time, to be honest, I think this is where I would like to stop. Obviously, you can continue to do the mutation part as it is described in the <a href="/tags/workshop">workshop</a>. And then, also do the subscription. So, then you see how it works end to end. There is an aspect of maybe monitoring and <a href="/tags/observability">observability</a> that I would like to quickly cover. So, obviously, you would like to know what's happening in the API in case you want to <a href="/tags/debug">debug</a> or in case there are errors. This is very easily done within AppSync because you have these nicely integrated <a href="/tags/aws">AWS</a> services. So, you can simply take a box in the settings and then you have the locking enabled and you can <a href="/tags/debug">debug</a> all of that using CloudWatch. And, of course, if you want to go more <a href="/tags/deep-dive">advanced</a>, you have the X-ray as well. So, then you can track what's happening to do your request from the moment you tap sync to the actual <a href="/tags/data">data</a> source to DynamoDB and you can also do <a href="/tags/performance">performance</a> analysis or whatnot.CloudWatch is just a solution that basically collects information and it's a complex service in the sense that it collects both logs that are helpful for you to <a href="/tags/debug">debug</a> things but also metrics. And CloudWatch has a lot more features than that. I don't want to go into details but it's like the go-to place for monitoring and logging things. And maybe what would be interesting also if you want to explore, as I mentioned, this lab will be open for two days. You could also try to integrate AppSync, as I mentioned, with other <a href="/tags/data">data</a> sources like REST APIs or even do the merged APIs. The fact that you can do queries, mutations, and subscriptions. You can do low-level <a href="/tags/data">data</a> access management. So, it can get quite complex and all of that is possible. I just wanted to essentially give you a flavor of how things could look very different in <a href="/tags/graphql">GraphQL</a> and how <a href="/tags/graphql">GraphQL</a> is superior in those kind of <a href="/tags/data">data</a> access use cases compared to REST. So, all the core concepts are kind of covered. Obviously, you can make things super complex, right? You can filter what the query that comes from the user can get in return. So, filter out essential responses. There's a lot more to it. So, you can still play around with this <a href="/tags/workshop">workshop</a> in here. There's a guide step by step for every single thing, but I hope that you got familiar with the core concept and the basics and hopefully you'll be able to create your first <a href="/tags/graphql">GraphQL</a> API independently, maybe even at your future employment.

But even so, I think you kind of got exposed to the basics of <a href="/tags/graphql">GraphQL</a>. The fact that you can do queries, mutations, and subscriptions. And what is kind of the use case for everything and how can you do like basics of authorization as well. So, all the core concepts are kind of covered. Obviously, you can make things super complex, right? Just like as in REST, you can do super complex authorization systems, for example. Obviously, <a href="/tags/data">data</a> can be super sensitive. You can do low-level <a href="/tags/data">data</a> access management. So, say someone is accessing to some books that they're not allowed to see. You can build a complex authorization system around that and you can filter what the query that comes from the user can get in return. So, filter out essential responses. So, it can get quite complex and all of that is possible. I just wanted to essentially give you a flavor of how things could look very different in <a href="/tags/graphql">GraphQL</a> and how <a href="/tags/graphql">GraphQL</a> is superior in those kind of <a href="/tags/data">data</a> access use cases compared to REST. Super complex filtering capabilities, as I mentioned. So, there's a lot more to it. So, you can still play around with this <a href="/tags/workshop">workshop</a> in here. There's a guide step by step for every single thing, but I hope that you got familiar with the core concept and the basics and hopefully you'll be able to create your first <a href="/tags/graphql">GraphQL</a> API independently, maybe even at your future employment.And with that being said, maybe I'll go back to the slides because there's a couple of things that I wanted to mention. Let me see. I need to stop sharing from that screen to another one. Cool. So, I would like to move back to conclusions here. So, what we have seen when we start building applications based on <a href="/tags/graphql">GraphQL</a> with some of our customers is that they gain a lot of speed when building applications. The reason why is because they don't need to <a href="/tags/code">code</a> every single thing and oh, there's now a new query pattern and I need access to these 10 additional fields. 10 is an exaggeration, but maybe two additional fields. Well, now, you guess what? You need to build a query parameter and subsequent logic at compute layer that fetches that <a href="/tags/data">data</a> from the <a href="/tags/database">database</a>. So, there's a lot of work for every single change and when you deploy <a href="/tags/graphql">GraphQL</a> for this type of <a href="/tags/data">data</a> intensive application, especially reads, it makes it super, super easy to do. And of course, because of that, they're much faster to be able to go to market because obviously they spend less time coding and just configuring things, creating schemas and that's super easy to deploy, try it out and so on. So, iterate much, much faster. They can do a lot of <a href="/tags/automated-security">security</a> stuff as well. So, we already covered like these super naive API keys and we need to use tools or let's say identity-based access controls, but they can do more, even more complex stuff with the <a href="/tags/lambda">Lambda</a> authorization. So, there they can build those complex authorization systems that can control who has access to <a href="/tags/data">data</a>, what level access to the <a href="/tags/data">data</a> they have, which fields can be visible. So, let's say some type of users can see pricing information or supply information for the book scenario that we had. Some users are not able to. So, maybe the customer facing users only can see those books where they can buy, how much they cost, but they cannot see where they're coming from. And of course, all of that comes with an associated cost saving because it's all running <a href="/tags/serverless">serverless</a>. So, there's no servers behind the scenes that need to stay up all night. All the pricing is done basically on how many requests do you have and how many of those, how many customers do you have? So, scales quite nicely. You don't have a big upfront cost and you saw how easy it was to deploy. So, for us, it was we were able to do in, I don't know, an hour and a half or two hours to create a whole API and connect that API to a funded application. And voila, we have it. We did not need to wait for anything. It was very easy for for us to create and having it up to run. And now, because I don't use it, I don't pay for it. Like we stopped using it. No need to turn off anything, no need to manage anything. There's no operating system, nothing of that, no <a href="/tags/automated-security">security</a> concerns, etc. And in the end, we would like to leave you with a couple of takeaways. Just because <a href="/tags/graphql">GraphQL</a> now is a new way of, or let's say another way of doing things, it doesn't mean that is the answer for all of our problems. REST still has its place in the world. And we will not use now <a href="/tags/graphql">GraphQL</a> for, I don't know, super simple things that are not <a href="/tags/data">data</a> related. So, it doesn't mean it's not a replacement and also, we should keep an open mind that maybe other new technologies will appear in the future. And we always need to adapt. Just like with the programming languages, back 20 years ago <a href="/tags/php">PHP</a> was the old and old. <a href="/tags/php">PHP</a> is nowhere today. So, we just always have to keep an open mind towards evolving technologies. With <a href="/tags/graphql">GraphQL</a>, you get this power of over <a href="/tags/data">data</a>. And you're able to build better experiences for your user, right? Because you do not need to either overfit to get more information that is actually needed. So, therefore, having <a href="/tags/performance">performance</a> degradation, making too many requests, et cetera, but also you can fetch the right amount of <a href="/tags/data">data</a>. So, making essentially being super frugal with the network connection. Also keep in mind, right, that not all users coming from browsers, super powerful Macs, they may be coming from an Android device that is 10 years old. So, being frugal with the resources that you have available is super important. And of course, as I said, it's not one over the other, depending on the types of use cases that you have, choose the right technology. And <a href="/tags/automated-security">security</a> is important, right? We said at <a href="/tags/aws">AWS</a> that is a top priority. So, it's always super important, do not expose your APIs to the public without having the internet, right? Without having the proper <a href="/tags/automated-security">security</a> requirements put in place. And always monitor what happens in your API, put rate limiting in there, put, I don't know, geography restrictions in there. We did not talk about all of that, but there is additional <a href="/tags/aws">AWS</a> services, but not only. If you build your <a href="/tags/graphql">GraphQL</a> API elsewhere, make sure that it is properly secured before you start exposing, because, believe it or not, there is bad actors out there that are scanning the internet every day for <a href="/tags/automated-security">vulnerabilities</a> and ways to expose, let's say, companies and customer <a href="/tags/data">data</a>. So, with that being said, I would like to thank you for coming with us today, and I hope you learned something today that you can apply, and I will invite you to also fill this survey in. I think I can also put it into the chat. I'm not really familiar with your offerings, but I saw that there's some caching functionality that can be linked to the <a href="/tags/graphql">GraphQL</a> API.

And so, I was interested in how one could solve the problems of caching <a href="/tags/validation">validation</a> with <a href="/tags/graphql">GraphQL</a>, maybe a bit. Like, do you have some experiences with getting your <a href="/tags/graphql">GraphQL</a> APIs always fresh, or how does that work? Is it just a TTL, or... So, I think you're talking about the Amplify part of it. So, as we mentioned, Amplify is both a service... well, three things. It's a service, a <a href="/tags/cli">CLI</a>, and a library <a href="/tags/frameworks">framework</a>. I'm no longer sharing the right screen, so maybe I will reshare on the right one. So, there's a functionality in the library called <a href="/tags/data">Data</a> Sync, and I think that's what you're referring to. So, this is what you're probably looking for. So, this is more of an <a href="/tags/deep-dive">advanced</a> pattern, where essentially, through the library, the front end is able to do, let's say, local changes, and once, the connection would be restored back to the <a href="/tags/graphql">GraphQL</a> endpoint. So, you can think of it as a spotty connection, right? You're on a train, working in your application, then 30 seconds, you lost connection. This <a href="/tags/data">Data</a> Sync, essentially, will register all the changes you make, and once you get the connection back, it will send back to the server. This works for, let's say, mutations, or changes that you're making. For queries, it also works a similar way, or subscriptions work a similar way. So, let's say, you are offline for quite a bit of time, you have a stake in your front, and once you gain, again, connection to the server, your local state will be automatically synced with the server. This happens, how to say, transparently. There's no need for you to <a href="/tags/code">code</a> anything, and then you have this interval of refresh in seconds, and also the caching functionality. Yeah. But this is more of a front end aspect. Maybe, and sorry, I'm talking about the back end? Yes, exactly. Maybe I can provide some insights on this. I've actually never gone too deep into it, but I know that it's definitely possible to cache on the server side. Then, you define a cache TPL. You can define it usually per resolver, and then, for the cache, for keeping the cache fresh, it is on your responsibility to invalidate the cache, and you can do this on a per resolver basis. If you know that you are running a mutation, as you are doing the mutation, you would also do a cache eviction in the resolver <a href="/tags/code">code</a>. As you update the <a href="/tags/data">data</a>, you also invalidate the cache for the specific ID. It's all left to the engineers, so there's no platform-specific solution. Yeah, that's cool. All right, that was my question. Thanks a lot. No worries. Have a nice one. All right. Thank you as well. Wish you the same to you, and I think we can close it out here. Bye, guys. Bye-bye. Thank you, everyone. Thank you.

Node Congress

Node Congress 2024

Build Modern Applications Using GraphQL and Javascript

Construye Aplicaciones Modernas Utilizando GraphQL y Javascript

The Workshop introduces the concept of building an application using GraphQL API in AWS. It highlights the importance of learning the latest technology and its adoption by enterprises. The challenges of building APIs are discussed, with a focus on GraphQL as a solution. The Workshop covers topics such as schema design, authentication, authorization, real-time updates, and integration with frontend applications using AWS Amplify.

Come and learn how you can supercharge your modern and secure applications using GraphQL and Javascript. In this workshop we will build a GraphQL API and we will demonstrate the benefits of the query language for APIs and what use cases that are fit for it. Basic Javascript knowledge required.

Emanuel Scirlet

Miguel Henriques

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2024

C3 Dev Festival

Join me at C3 Dev Fest, a contemporary software engineering festival!

Register to win an all-paid trip to Amsterdam. Elevate your career with industry experts and workshops & rock 3 dance stages at the after-party!

C3 Dev Festival 2024

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

React Summit 2024

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

TechLead Conference 2024

React Advanced

React Advanced Conference 2024

Productivity Conference

Productivity Conference 2024

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.