In this post we will add category and home landing pages to our blog. We will add HTTP 404 responses for invalid URLs as well.
This post picks up where we left off in Part 3: Adding API Gateway and the Article Page. If you did not go through that post, you can get the project files we will be using as our starting point here.
Let's start by adding some logic to handle requests for items that do not exist in our DynamoDB table. At the same time we will also create a variable ($type) that will help us later as we do things that are specific to the article page or the landing pages. Add the following to your page.yaml file after #set($items = $input.path('$.Items')) so this new content should start on line 3.
In this new VTL code, the first thing we do is set a variable $count to the size of the array that is returned. We then have an if..elseif..else based on that $count variable. If $count is 0 we know our table did not have any data to return for that query, so we should respond with a 404 and a clear message to inform the user. Next we handle the condition where $count is 1 and the current path contains the entire sk of that 1 item. I added the and condition so that when we are just starting and only have one post so far, the home page does not end up using the article page template. Then we get to the else condition, all other combinations of data (count > 1 or count is 1 but that 1 item's sk is not completely in the path) will have the $type variable set to category. We will use that $type variable throughout the rest of this post to handle items that are specific to one page type and not the other.
Next, let's set the page title based on certain conditions. I do not want the page title to always be the same thing. I like for the home page to have the base page title, then the category pages to have a page title to let you know you're on a category page, and then the article page titles can include the title of the article. To do that, replace the line <title>W3.CSS Template - $items[0].heading.S</title> in our page.yaml file with the block below.
You will notice in the code block above that we are not using the $type = category condition for the category page. We were unable to use that condition in this case because that same condition applies to the home page (as there are only two distinct page types article and category), all future uses of category will be identical. However in this case we are creating a distinction between the home page and a category page. So we are identifying the category page as not an article page and has more than two slashes in the context path.
Now we will introduce the changes to the main content section of the page, which will be different for article pages vs category landing pages (including the home page). The easiest way to make this update is to just replace that section of the page.yaml file and then we'll talk through what the new section is doing. The block below will replace from the line <!-- Blog entries --> to the line <!-- Introduction menu -->.
Now let's go through what we just changed. The main change here is creating a main content section for when $type is article and when it is not (landing pages). Another update is within the article page header we are now looping through the sk value to create links to any categories the article may be nested underneath. This will allow you to have many levels of categories, if you would like. We have also wrapped the article description and date in a condition to verify description is not empty, this is to cleanup for HTTP 404 response as I did not have any content I wanted to put in the description field for a 404 response.
The aspect that is very different from the landing pages to the article page is since the landing page will potentially have many articles to list, it is truncating each article to its first paragraph. That was the idea I came up with on how to easily give a preview of each article, open to other ideas.
Now we will update our openapi.yaml file. Our category landing page will be served by the route that we already defined in our openapi.yaml file. The route we defined in the previous post is using a greedy path that accepts everything after the slash for the API Gateway's root. So the category requests will go there as well. That is not a problem, the minor modification we need to make for the query to support the category requests will still allow the article requests to function properly. In our query to support that greedy path request, we will change it from looking for an exact match on pk and sk, to looking for a match on pk with an sk that begins with the provided path parameter. This will match the single article, when an article is requested, while still matching the entire category when a category is requested.
To make that change all you have to do in the openapi.yaml file is replace the line 'KeyConditionExpression': 'pk = :pk and sk = :sk', with 'KeyConditionExpression': 'pk = :pk and begins_with(sk, :sk)',
Now for our final change for this post, to create a root route for the home page. As we discussed in Part 2: Planning the Data Model our home page will use the access pattern 'Get all articles sorted by date' that is not limited to a single category. This will be achieved by leveraging the Local Secondary Index (LSI) we created on our DynamoDB table. An LSI uses the same pk, but a different sk. The sk for our LSI is date, so we can get all articles sorted by date. Add the following to the paths section of your openapi.yaml file, I like to put the root route as the first route in the paths section.
You will notice that this route's configuration is almost identical to the greedy route that we are using for everything else. The only differences are this is using another index, this is querying by only pk (to get all articles), and I specified False for ScanIndexForward so that the newest articles will be a the top of the page.
Now run sam deploy and wait for AWS SAM to deploy all of our updates. When it is complete you can browse directly to the root of our API Gateway endpoint (as it is output by the sam deployment). You will see that the home page is now working. You can also append a non-existing page to the URL to see the HTTP 404 response.
Our project directory at the end of this post is available here.
Thanks for reading. If you have any feedback or questions, please leave a comment or message me on Twitter/LinkedIn (links on the right side bar).
Top comments (0)