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
After writing this post I was inspired to go further with the Apollo Client. It had been a while since I used subscriptions so I decided to continue to add subscription support to both the Server and Client from the previous post. This ended up being much more involved than I expected. There are a few little tricks that make it more difficult than I was expecting. However, I have come out the other side with an even better understanding of both the Apollo Server and Client, and in particular, the Apollo Client cache.
In this post we will create a very simple (and not practical) Todo API using AWS AppSync with an AWS Lambda Data Source. This example is meant to outline the steps involved in the process and in no way creates a useful API.
We have a page called Admin that is managed via local state. To make use of this page we need to start tracking a user's role somewhere so that we can use it to figure out what to show the user in the application.
Have you ever needed a quick GraphQL server to test or try something? On occasion I do and I often end up building a server locally from scratch. Libraries like apollo-server make this super simple.
To build a basic GraphQL server I install apollo-server, graphql, uuid (for easy id generation) and nodemon (to hot reload any updates I make). I add a little hard-coded data, define a graphql schema and add a few resolvers.
In a recent project a few different streams of work converged. I thought it might be worth capturing some of the things I learned in a post.
I have previously used the Apollo Client. A lot of my work with it predates the release of React Apollo 2.1 where the Query and Mutation components were introduced. At the same time, I have been embracing render props whenever and wherever I can. It has become my preferred integration pattern whenever an option exists. So, it made sense to circle back on using the Query and Mutation components (they leverage render props) when the opportunity arose.
I recently started work on a project that uses AWS AppSync (AWS's GraphQL service). AWS AppSync provides a GraphQL client that is an extended (or enhanced) version of the Apollo Client. I believe the AppSync client exists to provide a more seamless AppSync experience but it also includes some extra bits such as offline capabilities.
The timing was perfect to not only learn about AppSync but to re-visit the Apollo Client and update my knowledge there too. Whenever I learn something new I tend start with a very simple project that I can later build on to do something more meaningful. That's exactly what I did in this case.
In this post we will create a very contrived ToDo App in React leveraging AWS Amplify and AWS AppSync. This post assumes a basic understanding of AWS Amplify (link to the docs below). You can get away without knowing very much about AWS AppSync, but the end result may not mean very much to you.
Our application navigation is working great where we are leveraging react-router. However, we do have an issue when we perform navigation outside of our application. For example, if a user is logged in and they use the browser's address bar and enter a route we get what we probably think of as unexpected behavior - the application refreshes and the user is logged out. In fact, what is happening is that the state is flushed when the application is refreshed; which is what is happening when the user leverages the address bar in the browser. The same thing happens if we use the browser's refresh button or closes and reopens the browser. In this post we will address this undesirable behavior.