{"id":1321,"date":"2020-04-17T13:15:22","date_gmt":"2020-04-17T11:15:22","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1321"},"modified":"2021-03-24T12:28:08","modified_gmt":"2021-03-24T11:28:08","slug":"how-to-tame-graphql-aws-appsync-amplify-and-cloudformation-to-the-rescue","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/how-to-tame-graphql-aws-appsync-amplify-and-cloudformation-to-the-rescue\/","title":{"rendered":"How to tame GraphQL: AWS AppSync, Amplify and Cloudformation to the rescue!"},"content":{"rendered":"
The Serverless paradigm<\/strong> nowadays is a common way to implement novel web-based and mobile applications<\/strong>: differently from the classical architecture where the backend is exposed by one or more web servers persistently connected to the database, the backend of a serverless application<\/strong> is typically deployed using FaaS<\/strong>\u00a0 (Function as a Service<\/strong>) services and the database is one of the novel managed, scalable, NoSQL databases which can be queried directly using stateless https API calls. On AWS (Amazon Cloud Services) an architecture like this is typically implemented using <\/span>AWS Lambda<\/span><\/a> Functions (FaaS) and DynamoDB (NoSQL database). If a SQL database is needed (e.g. for complicated and\/or strongly hierarchical data structures) DynamoDB can be replaced by <\/span>Aurora Serverless<\/span><\/a>, a Postgres (and MySQL) compatible and automatically scalable database completely managed by AWS that can also be queried through HTTPS APIs calls using the novel <\/span>AWS RDS DataApis<\/span><\/a> service.\u00a0<\/span><\/p>\n In a typical REST APIs application<\/strong>, the Lambda functions are invoked by AWS API Gateway<\/strong> who receives the https requests from the users\u2019 clients, retrieves the parameters and forwards them to the Lambda functions who performs the business logic and finally return a response to the API Gateway who can further modify and decorate it, before returning it to the client. In this setup, the Authentication<\/strong> of the users is often managed through AWS Cognito which is a User Sign-Up, Sign-In, and Access Control service managed by AWS. If Cognito is used the API Gateway can be configured to forward the requests to the Lambda functions only if they comes with a valid Cognito JWT token in the Authorization header: the Lambda function<\/strong> should then manage the User Authorization<\/strong> (can this user perform this action on that resource?) fetching user identity and\/or permissions from the Cognito JWT token. Sometimes it could be useful to call the API gateway using the AWS IAM authentication (through Cognito Identity Pools) instead of the basic Cognito authentication: in this way, the API of our application will be protected by the same extremely safe IAM v4 signature algorithm used by AWS to protect its own APIs: if fact all HTTPS calls to the AWS services\u00a0 (e.g S3, SQS, etc) are signed using this algorithm. Furthermore using the association between Cognito Groups and IAM Roles we can perform several types of basic authorization directly at the API gateway level and you won\u2019t even be billed for unauthorized requests!<\/span><\/p>\n