This post is going to feel like a bit of a repeat of #25 where we added the back-end to support the administration of Properties. In this case we are going to add the back-end support for Settings. We will use settings when we manage individual properties, specifically, the settings we want to manage will be applied to the images loaded to the Media Library.
In this post we are going to rewrite the Function we created in part 1 but in this post our API will use AWS Cognito for authentication (as opposed to an api key). Our scenario is the same as part 1 and we will use the same GraphQL client (graphql-request).
In a previous post I discussed calling a REST API from Lambda. In that post we were calling out to an external API to gather data. In this post I want to follow those same patterns but call a GraphQL API. For this post to make sense you should review the previous post.
In this post we will begin wiring up the ability to manage properties in our GUI.
In this post we will continue where we left off in the previous post. We will add the required back-end pieces to manage properties.
In this day and age, the era of serverless applications and microservices, it is not unusual that one back-end needs to call another back-end to complete a task. Recently, I found myself needing to make an API call from the server-side (back-end) of a serverless application written with the AWS serverless stack. I'm intentionally using a small s with AWS serverless as I am not referring to the AWS Serverless reference architecture but to an application that leverages an AWS back-end without using servers. In particular, I am leveraging AWS Amplify and AppSync (if you have found this post you have likely seen my posts regarding those technologies) which are, as of the time of this post, not part of the AWS Serverless reference architecture.
To this point we have built a lot of boilerplate code. That is, what we have built is code that really isn't specific to our application, it is code required by any application. We've built authentication and authorization, we've build our navigation, etc. Now we will start to work on the features that define this specific application.
In the past few Media Library posts we haven't spent a lot of time thinking about testing. In this post we will catch up on any missing tests and fix at least one broken test.
In the last Media Library post (#21) we addressed client-side authorization. That is, we established how the front-end renders the app based on who the user is, or better said, what the user's role is. You can think of this as a courtesy to prevent the user from doing things they should (will) not be allowed to do. We still need to implement code on the server that similarly controls what the user can do and what data they have access to. This will save naive users from getting into trouble, but also will prevent malicious users from doing things we don't want them to do.
In this post we address the server side of authorization. It might sound strange to say we need to address server side authorization in a serverless application but in fact, authorization, introduces a somewhat unique challenge to serverless applications (like the one we are building).
This is going to be my last post in our recent, impromptu series of posts about Apollo Client, and to a lesser extent Apollo Server. In the first posts we created a very simple Apollo Server and connected it to an equally simple Apollo Client. We worked with various techniques to keep our client and server in sync while also providing users a good user experience. In the end we implemented Optimistic Response where the client is immediately (optimistically) updated and the data sent to the server replaces the optimistic result after a round trip to the server.
The relevant posts are:
In the next post we implemented Subscriptions in both Apollo Client and Apollo Server. This is a useful feature when we want users to be immediately updated based on the activity of other users. In doing so we learned a lot about not only subscriptions but also how the Apollo cache works.
The relevant post is: Apollo Subscriptions