Crafting the Content Models

My first step was to think about content modeling. The basis for good content modeling is to consider all the objects, sub-objects, relationships, and presentation contexts. Since I was creating a blog, I started with content types for authors and posts, the two core objects of a blog, and most of the attributes of these two objects mapped cleanly to simple elements in Kentico Kontent content types. 

I had two smaller objects to consider as well. I needed these to create references to Wikipedia and to enable simple HTML embeds. Rather than living in the content inventory as re-usable items, editors embed them in the main body of a post as components. This gave greater structure to content in the body without sacrificing flexibility or adding unnecessarily to the content inventory. 

Another type of object that I needed to model was what I call a presentational object. These objects provide additional context for the presentation of other objects or provide details for a specific delivery channel.  For my blog, I created three presentational objects. The first was a generic page object, and the remaining two were objects for taxonomy detail and configuration of defaults. 

Since multiple objects needed some of the same fields for metadata and defining the title/featured image, I used Kentico Kontent’s content snippets feature. This saved me time when defining my models and helped ensure that my models were uniform when it made sense. 

Finally, there were also a couple of relationships to consider for posts. Authors and posts needed to have a many-to-many relationship. In this case, posts had a direct dependency on authors, but authors didn’t have one with posts, so I modeled this relationship by adding a linked item element to the post content type. Posts also had a relationship with each other via categories. I opted to use a Kentico Kontent taxonomy to manage this. I considered creating a special content type for tags, but didn’t feel that I needed the flexibility of allowing editors to create these on their own. Further, I liked that taxonomy enforced clear definition and that it had its own APIs to make it easier to query. 

Consuming the Content

After getting the content models in place, I started on the implementation. Since this was one of my first projects with Vue.js, I stumbled through this at first. Eventually, I did settle on a few patterns and practices that I liked.

I used the excellent JavaScript SDK and model generator to make working with the REST endpoint easier. It gave me a huge jumpstart but added some complexity that I didn’t want to expose in my Vue.js components. As a result, I ended up creating a set of wrappers around the SDK and models to simplify things. I had to add some additional mapping code, but this mapping made working with the content much easier in the end. 

The wrappers also made it easy to add in a rudimentary caching strategy. My approach was to use the URL that the SDK would request as the key and store the results of the query in an in-memory cache object. I didn’t add anything fancy like timed invalidation or persistence, but that should be easy to add later. 

One more implementation detail that I should note is my approach to URLs. For authors and taxonomies, I elected to use a “slugified” version of the codename, as I needed them to be unique and knew that they wouldn’t need customization. Blog posts were more complex. For these, I used a combination of the URL slug and the publish date so that the URLs would be friendly. One complication I needed to overcome was that when linked in other items as hyperlinks the publish date wasn’t available. I solved this by implementing a redirect handler to redirect to the proper route based on the GUID passed to the handler. For generic pages, I used the URL slug element but noted in the guidelines that content editors needed to specify a unique value for this since this isn’t enforceable at this time. The routing tries to find a generic page based on the passed slug and returns the first match. If it doesn’t find a match, it shows the 404 page instead.

Launching the Site 

When it came to deploying my project, I wanted to check a few boxes. First, I wanted it to be free. Second, I wanted to have continuous deployment. Netlify handled both of those requirements nicely. Once the initial deployment was configured, I enabled a couple of features targeted at making single page applications like mine more SEO friendly. One critical thing I needed to do was add a wildcard redirect handler so that all paths resolve to the index page. This way, if somebody bookmarks a page my application would still load properly. Netlify also offers a prerendering option (currently in beta) that enables search engines to crawl the site. 

Going Deeper

To take a closer look at this project, you can explore the code on GitHub, and you can find the deployed site at kontent-sample-app-vue-blog-travel.netlify.com to see the final product. If I've inspired you to create a blog, you can get your hands on a free trial of Kentico Kontent.