Skip to main content

· 9 min read
Peter Dyer

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.

· 6 min read
Peter Dyer

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.

· 5 min read
Peter Dyer

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.

· 14 min read
Peter Dyer

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).

· 5 min read
Peter Dyer

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