Build a Universal GraphQL API to Accelerate Frontend Development with AWS AppSync

welcome everybody thank you for joining this session my name is stefano sandrini i'm a solutions architect at aws and today i'll be talking about how to build a universal graphql api to accelerate front-end development so let's have a look at the agenda for this session the main topic is how we can use graphql and a service called aws appsync to build modern apis that can help developing your application faster in addition during the session we will have a look at some use cases such as real-time applications and we'll take a look at some advanced features of appsync such as security and authorization for your graphql api so when building a modern application company needs to focus not only on the front-end but also on how to face several challenges on their back-end side they need to build efficient apis that can go anywhere and meet the customers where they are apis that are scalable reusable apis that can connect to multiple data sources and be usable by multiple clients they need to be able to engage with their customers and that also means delivering the right data at the right time and last but not least developer and teams needs to be able to develop their application faster so today our customers are building three main things universal apis to connect applications to multiple data sources real-time applications applications that include chat functionality fan engagement and location aware notifications and more in general mobile first applications so consumer apps iot or connected devices apps field services application and offline support application so let's have a look now at what is graphql how it works and what are the main advantages let's imagine we have some sort of front-end application you are building where a user can access their data by a web browser and a mobile device it can be anything an e-commerce social media app a collaboration tool a chat application you can pick one so usually modern applications expose data from back-end services using apis api is a very important construct that connects your front-end to the back-end and basically apis allow applications to interconnect interact and integrate with internal or external services from all sorts so with traditional apis usually multiple endpoints are exposed these endpoints can access the same data source with different access patterns and different requirements sometimes you may have that each endpoint can access a separate data source so for example here we have three different databases we can imagine we have one for orders one for products and one for inventory so let's say we are talking about an e-commerce application so imagine now that we have users accessing data from different devices a mobile phone and a laptop users login into the system and want to retrieve their data and in order to do so they need to access the api endpoints to load the required data to their devices with traditional apis such as rest api for example loading the data is done sequentially first i need to access the endpoint a to retrieve some of the data and populate the application user interface accordingly the response payload in a traditional api is usually static no matter the device i'm using i know i'm always going um to get the same payload maybe it's a big json object with tents or even hundreds of fields but mobile devices have smaller screens so they need to display less data while a laptop web browser has more screen size so it can display more data however since the response payload is static both devices receive the same amount of data from the api endpoint and the front-end application has to manually pick and choose the fields in the json payload it needs to display and discard the rest of the data so maybe there's data that neither the mobile app nor the web browser need and this data needs to be discarded so this is a classic situation that we call over fetching data at the end of this process we are successfully load uh part of the data in our user interface and we can fill the screen in green both on mobile device and in the laptop but there's more work to do when i want to fill the screen part that is in blue now i have to load more data to populate that part maybe i pick a specific id i retrieve from the endpoint a and i need to pass that id to the endpoint b in order to retrieve some more data so while i over fetched some data from endpoint a i also under fetch data because now i need to make a second api call to the endpoint b to get the full data set that i needed so same as before since the response page is static both devices receive the same amount of data from the api endpoint and again a mobile device requires considerably less data so again i have over fetching and again the front-end application has to manually pick and choose the fields in the json payload finally i may have a main part of my screen the one in red that i need to populate so again i'm going to call the endpoint c and now my data is fully loaded in my application and now my application users can interact with the full data set so with a traditional api approach in order to get the data that i needed i had to make three api calls because i was either over fetching or under fetching data in each one of these calls i was getting more data than what i needed from both devices now let's take a look at how graphql works and why graphql is important for modernizing your api and your front-end application so with graphql i have a single api endpoint exposed to all clients and i only need to make a single api call so the client can define the data it needs and the data is retrieved from multiple data sources automatically for me at the same time the mobile app reaches the exact same endpoint of the web application and received a customized payload with only the data field that it requires because the client can define the data it needs so as you can see the payload sent to the web app and the payload sent to the mobile app have different sizes which means that network calls are optimized and the payload is reduced according to the client this also means an easier and faster way for development of my front-end application because i have only one api request no business logic for request orchestration and the payload is exactly the payload that i need therefore there's no need to pick fields from the static payload i can just focus on building my front-end application building an engaging user experience and i can just have the data that i need nothing more and nothing less i can also have other apis or microservices as data sources as we are showing the slide and we can use the graphql api as a single interface to connect and aggregate multiple microservices with our application so we have the graphql api acting as a data layer and an interface to connect and communicate seamlessly with multiple backend services another important thing to remember is that graphql is agnostic to data sources so that allows you to easily abstract the api from different applications and different data sources you can have any type of data source behind a graphql api you may have a relational database a no sql database an http data source a rest api it doesn't matter it's completely fine to mix and match different databases and multiple apis behind a single graphql api so what exactly is the definition of graphql and how it works on the data modeling part graphql is defined as a query language for apis and at the same time i run time to fulfill those queries graphql as the name implies is a data query language it use a typed system that allows you to understand data requirements and get also meaningful errors and also it make it easier for you to use the api and to create prototype you can define a graphql api with a schema based on a schema definition language and this schema that is called the graphql schema is where you define different types so different way to model your data such as the user type you can find in the slide and you can also define its property fields you can also define operations for your graphql api so we have three types of graphql operations we have queries that you can use to read data we have mutations that you can use to modify or write data and we have subscriptions subscriptions are linked to mutations and allows you to send real-time notifications to subscribed clients whenever data is changed by annotation also you can see in the blue boxes what is called the selection set the selection set represents the collection of fields you define to be returned in a graphql operation and these collection of fields is defined at the client side so when a client perform a query let's say the get post query we can find in the slides it may require as a response just the id and title fields when perform a create post it may requires as a response payload just the id and the date and same thing for subscriptions when the client subscribe to a real-time notification related to the oncreate post notation it can receive just the id the title and the author this is very important because again this is the way that clients can specify what is the data that they need nothing more and nothing less so for example a mobile device can specify a smaller selection set than a web browser desktop application we talk about graphql now it's time to talk about aws hapsync how it works and how it can be used together with graphql to create modern apis for your front-end application so appsync is a managed serverless graphql service it connects to resources in your aws account and that allows you to make your data available also in real time and in an offline situation it can be used as a graphql facade to aws service it allows you to perform um conflict detection and resolution in the cloud instead of doing it in the client so again it's a way to simplify your client-side development appsync also integrates with enterprise security features such as identity and access management cognito user pools open ndconnect compliant provider or you can use api keys so how exactly aws appsync works again you may have multiple type of application you are developing front-end application web mobile uh real-time dashboard application that shows data in real time coming from sensors from iot devices or offline first applications this application interacts with the single api endpoint provided by appsync and then through appsync you can access data directly from natively supported data sources you may access data from dynamodb tables from aurora serverless databases or elasticsearch clusters your front-end applications through appsync can also access anything you have in your account using lambda functions or even rest apis using http type of data sources you can also use http type of data sources to connect directly your application through appsync to other aws services such as step functions or eventbridge using the original endpoints so again that's how you can use appsync as a graphql facade to any aws service it's also possible to use what is called the local resolver and we can think about the local resolver as a kind of a pub sub channel when data where the data is not persisted so you may have front-end applications and you want to send message between clients you don't want to persist messages in any data source you can use this type of data source and using it as a pub sub channel so how can i get started using appsync and graphql to get started um you need to model and define your data in the graphql schema the data model in the schema also tells api consumers so for example your frontend application what data is exposed to authorized clients and it also acts as a kind of an automatically generated api documentation we also mentioned that graphql has a built-in runtime component where developers can customize their own business logic and that business logic is exec it is executed at the api layer these runtime component are called resolvers and basically they provide the logical glue between the data defined in the graphql schema and the data that is actually in the data sources and using resolvers you can map an operation or even a single field of a type that it is defined in your graphql schema with a specific data source and that allows you to retrieve data for different fields in different data sources with a single api call so again these are the main components in an app sync api the graphql schema when we define our data modeling and the data that is exposed to api consumers the resolvers where we have the business logic running at the api layer and data sources so we talk about resolvers so let's have a look at a simple resolver example so let's say we have in our graphql schema type post that basically models a post in a classic blog application so we have a type post with some fields some of them are required some of them are strings some others are integer let's say we want to create a resolver to write a new post on a dynamodb table with aws app scene you can leverage velocity templates so you can write request and response template to transform uh for example the graphql request into the request with the right payload for the right data source so in this specific scenario with the payload for dynamodb so and this is how you can write the velocity template resolver for a write request for a mutation it performs a put item on a dynamodb it provides the payload so the attribute values for fields that need to be stored in dynamodb by retrieving data from the payload of the incoming graphql request of course things can be more complex you may want to add if if then statements default values and conditional expression so here we have another example of a put item operation but with more complexity and more conditional statements we mentioned that appsync leverages velocity template or vtl to provide a fast compute runtime layer to resolve graphql queries or or fields sometimes you may want to use what is called the direct lambda resolvers so basically if i have an nws lambda function as a data source i can use what is called the direct lambda resolvers which makes a velocity template optional so it makes basically easier to work with lambda and graphql giving you more flexibility when developing graphql resolver and appsync with lambda data sources because you can use your programming language or runtime of choice to define your graphql resolver business logic because that business logic will reside in the aws lambda function and not in the velocity template resource and if i'm using an aws lambda function as a data source i can also access securely any vpc resource i may have in my account so for example i may want to use a lambda function to query a relational databases um running on amazon rds or amazon aurora or maybe i want to use an aws lambda function to invoke an application load balancer endpoint to interact with fargate amazon ecs or amazon eks so aws lambda is the data source that you need to use if you want to access vpc resources or resources that are not natively supported by aws appsync so when i use the data lambda resolver um the vtl is is disabled um appsync automatically sends the full context object of the api request call uh directly to the lambda function and the context object contains data related to authorization identity query arguments request headers as well as the info object so here we have an example of an info object in addition to providing the field name part name variables of a query um the info object also exposes details about the selection set and that makes possible to make calls to data sources that are fine-tuned based on the expected data from from the client so based on the selection set so for example the info object comes handy when a type is backed by a primary data source and is also composed of fields was types are backed by other data sources so let's say for example that we have an application data and data is stored in a sql database hosted on amazon rts we may have a post type and a comment type and post and comment entries are stored respectively in rds table posts and the rds table uh commands and let's say we also have a get post query a graphql query and that query is attached to a direct lambda resolver to query the relational database because again uh as we've mentioned you need an aws lambda function to query relational databases on amazon rds if we invoke this get post query um with the uh specific selection set you may find in the slides we receive an info object like like this one so again we have the field name get post parent type name query we may receive variables so for example the id of the post and then we can receive the selection set list so what our clients are requesting id content and then the list of comments with the id and the content why this is so important it's important because then in the lambda function that it is invoke we can create a specific business logic that can return the right data and it is very efficient because it can interact just with the data source that it is needed so for example what i can what i can do in the lambda function i can double check if i have uh comments in the selection set if i don't have any comments i just need to query the post table and return the post table because i don't need to return comments while on the other side if i need to return comments as well after query the post table i need to query um the comments table by using the post id so again this is a very efficient way to be efficient both on the back and side because i can interact just with the data source that i need to interact with but on the other side it's a it's a way to be very efficient also on the front-end side because again i can just retrieve the data that i need depending on the view that i'm building on my front-end application so let's stretch the concept a bit with another specific scenario like an e-commerce system so we can imagine there are different services in um the application backend and these different services are accessible using different technologies i may have user data stored in dynamodb highly scalable nosql table orders are accessed through a rest api the current inventory stock is checked using a lambda function [Music] and pricing information is in a sql database using amazon aurora serverless for example so with a classic and traditional api approach such as a rest approach client applications would have to make uh four or even more than four um different api calls to which uh of these services and these calls are using different api endpoints um and again this increase the complexity on the client side also again we will find our front-end application in the same scenario we mentioned earlier we can either over fetching or under fetching data and the complexity at the front-end layer is increasing so what we can do with graphql and app sync we can again combine features from from both aws absint and graphql using one single api endpoint that can retrieve data from multiple data sources with one single uh api request so with a single network call and from a single endpoint we can retrieve data from dynamodb from amazon api gateway from aws lambda and from amazon aurora and what clients receive is just a single payload receiving user profiles and orders depending on the selection set requested and again everything is just with one single network call from a single api endpoint and the backend com the back-end complexity is abstracted also front-end development team or api consumer team can add new features or even new application without basically waiting for a specific backend team to implement new apis and also since graphql is is self-documented um and can leverage introspection the introspection make it easy for frontend development team to learn what data is available from the single unified graphql endpoint so again with one single request with one single endpoint i can retrieve just the data that i need nothing more nothing less and the backend complexity is abstracted of course talking about front-end application that leverages api and back-end we need to talk about security and authorization um with aws appsync you can create graphql apis that can be used by the application and this interaction is over the internet so api endpoints are publicly reachable but while the api endpoints are publicly reachable they never allow unauthorized access a method of authorization a token in the request stater or for example signing the request itself with database credentials is always required to access your appsync api so with aws appsync you can create graphql apis that can leverage one or more authorization method and these are what what is available for you you may use api keys you may want to use amazon cognito user pool open ad connect compliant provider identity and access management or even aws lambda absent apis must have a default authorization mode defined globally but it's also possible to add additional authorization mode in the same api as well as mix and match these modes linking for example specific authorization providers to specific types field of opera or operation in the graphql schema and in order to do so um you can use appsync specific directives to configure authorization and security at your data definition layer directly in the schema so here we have an example uh with a flight type so a kind of a fly type of application so the type of flight is defined in the graphql schema and we define conito user pool as the default authorization mode in the api so when a user is part in this specific example of the cognito group frequent flyers can actually access all data from type flight all fields but maybe we need to expose specific fields in the flight type for guest users guest users are not logged in users so they are not part of acquinito user pool they will connect probably using an api key so we can say when the request is invoked using an api key the departure airport code and departure airport name and the id are exposed to the client and also we can say that we want to add also identity and access management authorization mode so again if the request use identity and access management fields available are the id the arrival airport code the arrival airport name the arrival city and the arab locate so when do i have to uh use each specific authorization mode what are the use case for selecting the right authorization mode let's start with api key api key use the http editor x api key usually api key are hard coded in the application so that means that usually you're going to use api key for getting started with your development so you are in the development phase you don't have uh user management already built in in your application you can just use the api key when you want to create some sort of public apis so if you remember you must have a default authorization mode defined for the aws appsync api so the closest scenario to a public api is the one related to the api key because it's hardcoded in the application or you can use api key again when you don't have any specific authorization requirements for example when you are modeling a guest user then we mentioned that you have cognito user pool so you are managing your application users using cognito cognito will provide a json web token that specify claims and attributes of your users and you can use the integration we need to use a pool to create granular access control with uh leveraging aws apps in directives so for example uh here in the slide we have um a directive that specify that the list of posts so a specific post query can be performed by users that are part either of the bloggers group or the readers group so when to use connector user pool when you are managing cognito uh for authenticating user uh in your application when you want to connect your user with social identities for example and when leveraging the jwt provided by cognito you want to interact with other aws services as well you can also use uh openld connect authorization mode still a json web token uh provided by an idc identity provider you can perform granular access control based on claims so at resolver layer you can um inspect claims inspect what are uh groups containing claims and again if the user is part either of of the bloggers group or the readers group then the user is authorized otherwise it's not authorized so i can perform granular access at the resolver layer uh when to use open id connect um usually when you have an already existing user directly uh directory that leverage an open id can uh open the connect identity provider again you are authenticating user in-app but with the same gwt token you you don't want to interact with other aws services we mentioned also identity and access management basically this is the classic scenario when you want to do machine to machine integration so back-end systems that leverage aws credentials to interact with your graphql api provided by appsync so for example iot systems that sends data uh to a graphql endpoint and you can basically leverage im policies to specify access to the api so classic example is an ec2 instance or a lambda function and again you can specify policies at the execution role of identity access management so by mixing multiple authorization on type operation and field level leveraging the default authorization mode and leveraging additional uh authorization provider you can address your specific scenario for your front-end application that leverage a graphql api we mentioned also about a classic use case and we already mentioned that you can use graphql api as a facade to multiple data sources you may have or maybe multiple microservices that you may have in your backend but another classic example is real-time use cases and real-time applications so you basically can leverage aws appsync to enable scalable real-time collaboration use cases so maybe collaboration tool or chat application um appsync takes advantage of graphql subscriptions to perform real-time operations by pushing data to clients that choose to listen to specific events from backhand you can have thousands or even millions of clients subscribed to a specific mutation collapsing so and that means that you can easily make any supported data source in aws a real-time data source and the connection management is handled automatically uh for you by appsync to the client and the service and that means that a backhand can easily broadcast data to connected clients or clients can send data to other clients depending on the use case in an easy way um when a client's invoker invokes a graphql subscription a secure websocket connection is automatically established and managed by the bls app sync um and that connection will remain constantly connected to your backend so how does it work in practice um after authorized clients make a subscription code that is linked to a specific mutation a websocket connection is established providing a secure channel between the client and appsync clients can also be subscribed to multiple mutation and the related subscriptions all share the same websocket channel so in this specific example we have multiple clients uh mobile clients web clients desktop clients all connected to the same appsync single endpoint and we have a single dynamodb table as a data source but that's not important it works the same way with any supported aws apps in data source so if a client execute a mutation for instance a create post or a create message let's say on a chat application that mutation is invoked against the single graphql api endpoint in appsync appsync then perform authorization checks and then execute any business logic that is defined in the resolver and then it sends a request to dynamodb to create an item in the table so it performs in this specific scenario a put item in the table after the data is saved to the data source appsync automatically broadcasts data to all connected clients and each client can have a different selection set defined so for example let's say a mobile client might just need an id in the title while a web client may have the id the title and the descriptions so again that's a very efficient way for clients to just receive the data they need arguments can also be defined in the subscription and that means that let's say you don't want to broadcast to all clients a message you can basically define clients listening just for a particularly id for instance on a chat application you may want to listen just for a chat group id and just receive new messages for that specific group very classic scenario and if we stress the concept a bit in the same sense this can be done in a one-to-one uh fashion so only one client receives subscription data so again thinking about the chat application we may have one-to-one private conversation and only users in that specific private conversation can receive the message so this is how clients front-end application can easily interact by sending messages to other clients not just chat messaging of course but also again collaboration tool payload for example it can be either one-to-one or one-to-many but what about back-end data how can i push back-end data to connected clients to connected front-ends i may have a back-end process for example i may have a lambda function and that back-end process executes a mutation against appsync so again we are in a situation that is same as before appsync send a request to dynamodb after performing authorization check and executing resolver business logic then it performs the put item on a dynamodb and after the data is saved to the data source appsync automatically broadcast data to all connected subscribed clients so as you notice app single needs to be aware of a mutation in order to send subscription data so what happens if i already have a system i want to create a new application a new front-end application that wants to be notified in real time but the legacy system already writes data in dynamodb without using any aws apps implementation so let's say if we have a back-end process that writes directly to dynamodb this is what we call an out of band request what we can do we can consume a dynamodb string for example using a lambda function and then the lambda function again performs a mutation against appsync of course now we don't want to save data twice oh and we don't want to overwrite data to dynamodb and here's when um local resolvers comes handy local resolvers are internal to appsync and they work as a pub sub channel as mentioned earlier and no data is persistent so the local resolver is executed successfully and then data is broadcasted to all subscribed clients so using appsync is also a very efficient way to empower real-time collaboration front-end application with simplicity because the real-time data management connection management scalability fan out broadcasting of data all these things are handled by appsing so your teams can just focus on front-end application building your business use cases and building your requirements and focusing on requirements instead of dealing with the complexity of infrastructure management and websocket connection management at scale managed graphql with appsync is being used by multiple companies across multiple industries from bmw group to to aldo uh bmw rev leveraged graphql using appsync to build scalable and universal apis for uh data providers and consumers uh peacock is a streaming service launched by the comcast corporation um that use a graphql apis provided by aws appsync and again um in the blessed absence allowed aldo to focus on implementing features in that application instead of managing their system and in its infrastructure and this adds velocity in the development of front-end application also customer in the media are using um graphql provider api provided by appsing for example sky italia they wanted to deliver a better fan experience by pushing real-time data updates during live broadcasts of sports events and after deploying the new version of their api that leveraged appsync they decreased the time needed to propagate game data in real time to users from a few minutes to milliseconds and also they saw their costs reduce it of the 30 percent and they expect even bigger civics in the future in conclusion i encourage you to visit our resources page to learn more about appsync how to get started we have a website we have documentation we have a github repo where you can find samples we have a blog channel and we have multiple resources that you can that you can visit thank you for for joining this session uh this session was focused on how to build a universal graphql api to accelerate front-end development i hope you enjoyed the presentation my name is stefano sandrini i'm a solutions architect at aws and thank you again for joining the session

Channel: AWS Online Tech Talks

Views: 1,307

Keywords: AWS AppSync, GraphQL, GraphQL subscriptions, Real-time applications, Web and mobile applications

Id: cKUsLBPiScU

Length: 47min 1sec (2821 seconds)

Published: Thu Oct 21 2021