DEV Community: Anton Reindl

Quick Tip: Nuxt & Storyblok Error Handling (e.g. 404)

Anton Reindl — Sun, 21 Apr 2024 07:38:48 +0000

Welcome to my new Quick Tip series:

Today we are looking at Error Handling when building websites with Nuxt and Storyblok as CMS. If you haven't tried the two tools, go check out one of the awesome tutorials. It's a perfect match for all your projects.

Today we are looking into one specific use case:

Build a blog post detail page with a dynamic slug in the URL param
Fetch the content from Storyblok CMS
If the content cannot be found (Storyblok returns 404), Nuxt should show an error Page
The solution must work with Server-Side-Rendering and Server-Side-Generation

Solution

<template>
    <YourArticleDetailPage :story="story" />
</template>

<script lang="ts" setup>

// Get the Slug from the Route
const route = useRoute()
const slug = route.params.slug

// Load the Content from /blog
const story = await useAsyncStoryblok(`blog/${slug}`)


// Handle the Error
if (!story.value) {
    throw createError({
        statusCode: 404,
        statusMessage: 'Page Not Found',
        fatal: true,
    })
}
</script>

Noteworthy:

The most important part of the solution is fatal: true in the error object. This will trigger a full-screen error page in Nuxt and redirect the user to the error page.

Now you can go ahead and create the error page with error.vue - as described here. Remember: the error.vue must be kept in root, not /pages

That's it for today's quick tip.

Retry and Recursion in asynchronous Vuex Actions - a naïve approach to Firebase Image Resizing

Anton Reindl — Thu, 01 Jul 2021 08:58:34 +0000

In a web application we have recently built using Vue.js and Firebase, we needed an image uploader that enables the user to upload images (e.g. a profile picture). After the upload the image should be scaled down and resized to a set of predefined sizes. For that, we leverage the very neat Firebase extension Storage Image Resize. This extension is easy to configure and use. It gets the job done: every time a new image is uploaded to Firebase Storage, it starts the resizing and adds the scaled images to the same folder.

Disclaimer: This article assumes prior knowledge in Vue, Vuex and Firebase and will not cover those basics. It's not a tutorial but instead conceptualizes a software engineering pattern.

Update from July 2022: Resized Event available

Finally, Firebase added an event to know when the resizing is done. See Changelog

Problem

But in the simplicity of the server-side resizing there also lie problems: The frontend application neither knows if or when the backend process has started nor completed. It is totally independent. The only way to know if the process has been completed successfully is to check if the scaled files are present on the Storage.

The resize extension is a cloud function and based on our tests we experienced execution times between 200ms and 2s (cold-start). Depending on the uploaded image size, the process can also take longer. In our configuration the function needs to create 4 predefined image sizes. Therefore there could be cases where the resized image is not yet ready to be used in the frontend application if called in a sequential way. So how can this potential unknown delay in process be solved?

Solution

First of all: there are different solutions to this problem. We sought for a solution that has (1) a high cohesion with the uploader component itself and does not require additional backend jobs and (2) can fail nicely with a fallback solution.

Here is a schematic depiction of the process:

In our real application we implement the following workflow:

User selects file [Uploader Component]
Upload action uploads file to Firebase Store [Vuex Store Action]
Upload action returns the DownloadUrl for the storage object [Vuex Store Action]
In parallel, on server side, the resize cloud function starts to process the images triggered automatically by the upload[Uploader Component]
User is informed in the UI that the resizing starts [Uploader Component]
The Uploader Component triggers the function to get the resized image url (tryGettingResizedDownloadUrl()) [Vuex Store Action]
The tryGettingResizedDownloadUrl() function will try to create a DownloadUrl. If it fails, it will wait 800ms and then retries again by calling itself recursively. As soon as it finds a downloadUrl for that image, this Url is returned. It finds a download url by repeatedly checking if the file exists on the storage filesystem which matches the defined filename pattern (filename_${width}x${height}.{fileExtension}). After x-retries it stops and returns null.
If the tryGettingResizedDownloadUrl()-function does not deliver a result and returns null, the full-size image is stored in the database as a fallback.

Why a naïve approach?

A naïve implementation is an implementation that has taken shortcuts for the sake of simplicity or by lack of knowledge (e.g. when the backend completed). It will not account for all the possible uses cases or try to fit in every situation. In potentially 99% of the cases, this naïve wait-and-try-again will be successful. Of course there can be other failures, but these are edge cases. We optimize for the standard case and make sure to fail nicely if something unexpected happens. This makes sure that other parts of the application are not affected by this implementation.

Implementation

The Vuex Action in the storage.js Vuex-Module.
Here we have implemented the naïve wait-and-try-again approach:

As you can see, the retry is implemented as a try-catch-block. In case of failure, the retry variable is increased, the action waits 800ms (await sleep(800)) and the recursively calls itself again (return dispatch('tryGettingResizedDownloadUrl', { url, size, retry })). It is crucial to add the return before the dispatch(), otherwise the action won't return anything.

In our frontend Vue Photo Upload component we interact with the Vuex action:

As you can see, the resizedUrl variable awaits the the results from the action and is either a string containing the URL or null. In case of the latter, fullImageUrl is saved.

Conclusion

For us, this naïve retry-approach is a very feasible option. Whenever the naïve approach fails we receive a ticket in Sentry - our application monitoring platform. We acknowledge that there are more secure solutions. But retrying makes a lot of sense in our case and it makes sure the upload and resizing is cohesive and implemented in a step-by-step process.

What do you think about this solution? Let us know in the comments.

Template

Here is the template for a recursive retry function in Vuex:

Software Architecture Documentation - The arc42 Notion Template

Anton Reindl — Tue, 09 Mar 2021 10:13:26 +0000

Our company uses Notion as our central workspace to organize work and document things. It's a great tool and we are really happy with it. The simple, fast and yet extremely powerful user-interface was the key advantage of Notion when we chose it over the very popular Confluence by Atlassian.

So obviously it's also our go-to-tool for documenting the software architecture in our projects. When we document software architecture we use the very pleasant arc42 template. It was created by Dr. Peter Hruschka & Dr. Gernot Starke and is available in multiple formats. The template is free to use.

We prepared a Notion clone of the arc42 template to accelerate your work and make it easier to get started.
Simply duplicate the page to your workspace:

UPDATE from October 2023

Our documentation was growing a lot. At some point, the single-page template was too cluttered and the loading times increased.

There we added a new and more organized template with subpages and new database. We recommend you use this one.

Arc42 Template with Subpages

If you are new to arc42 I can really recommend the book Arc42 by Example: Software Architecture Documentation in Practice by Gernot Starke und Stefan Zörner. It helped us a lot to get started with documenting.

So here are our key take-aways:

Be correct: name one responsible person who owns the architecture and carefully instruct others to provide chapters of the architecture documentation.
Make it maintainable: the architecture documentation should be the single source of truth and very easy to adapt. Notion has a built-in version control that allows clear revision of chapters. Use the discussion and commenting feature to discuss architectural decisions in the document.
Stay accessible: first of all, only document the relevant things - avoid unnecessary stuff and focus on the really important parts of the architecture. When you write documentation avoid overly complex language. Me short and precise. It's documentation, not a novel.
Write iteratively: software architecture evolves over time. It's not something that can be done 100% upfront. It will grow together with your application. So make sure that it gets updated on a regular basis and is part of your (agile) development process.

I am happy to hear your thoughts on documenting your architecture in the comments.

PS: Again thanks to Gernot Starke und Peter Hruschka for providing this great template for free.