Touching the sky: using Nuxt for the Motive.co website

Developing a product from scratch is a long road you need strong foundations for. In terms of how development teams collaborate to create such a product, choosing the right framework is a massive part of it.

At Motive, we needed to have a website where we could explain what Motive Commerce Search is to the world so that shop owners could join the best e-Commerce search to drive their sales. While defining that website, we decided that Nuxt was the most logical choice to build it with.

As time passed, Motive.co evolved and so did the technology, so I want to tell you a bit more about how we ended up using Nuxt3 and enjoying a project based on Server-Side Rendering (SSR). There isn’t a better feeling than that of working with the latest available technologies on a daily basis!

Keep reading to learn more about the experiences during the process, since the very beginning.

Motive.co’s first steps

Our initial needs for the project were just some static pages where we could tell the world what Motive is and have people engage with the product in its first stages. We weren’t really asked for something too sophisticated, but rather just some landing pages where we could start explaining the product.

Based on those needs, the team went for Nuxt, as we had some experience dealing with this technology to develop static pages. At that time, Nuxt2 was an already stable and recognised technology that fitted the needs we had, and we created the first Motive.co based on it.

Its performance was just perfect to develop those static pages quickly, and it worked more than fine to design some common abstractions that we could turn into reusable vue2 components and layouts. After a couple months, we launched the first version of the website, a static web page based on Nuxt2 and hosted in a S3 bucket. It all seemed to work well, but those initial needs we had soon grew as fast as Motive Commerce Search did.

The tables turned

It was pretty much plain sailing until new requirements started to pop up. Our project needed to evolve and our marketing team needed to access the website so that our content writers could autonomously publish new content in the Motive.co blog that was created to let the world know about us.

There was the option of sticking to a static solution, but the downside was that every little change that was published would trigger a new deployment of the whole project to have the updated version visible. Therefore, we decided to externalise the writers’ content into a headless CMS running on Strapi to avoid deploying the whole website every time something was published. With this CMS, we could have an API REST solution that consumed the CMS data from the website.

If we were to preserve our current static architecture, that would imply many client-side requests, so we transitioned our project to a SSR one. That includes the server piece, which would be in charge of requesting the CMS data and retrieving it to clients in an already-rendered version of the blog:

//nuxt.config.ts
export default {
   target: ‘server’
}

This was a huge step in terms of performance, but also a challenge in splitting the implementation between the server-side and client-side. However, the Nuxt framework made this change smooth and understandable. Apart from changing the project build mode, we also needed to change our infrastructure to support a server hosting the project, so we had to say goodbye to the static S3 bucket.

Ascending to dev framework heaven

At that point, we had what we needed, but Nuxt was building its next major release: Nuxt3. This new release could grant us a better developing experience, based on Vue3, using Vite as a bundler and with a greater focus on SEO performance.

We were sure we were getting on that train, so we started the migration process of integrating the nuxt/bridge dependency in our Nuxt2 project, which was the forward-compatibility layer that allowed us to experience some Nuxt3 features in a Nuxt2 project. Just like magic:

//nuxt.config.ts
import { defineNuxtConfig } from ‘@nuxt/bridge’

export default defineNuxtConfig({
// Your existing configuration
})

We made the necessary adjustments to fit the nuxt/bridge requirements and had a stable version running on it, but we knew the future was going to bring some glory and we were ready to shine.

The next step was moving from the nuxt/bridge to the latest Release Candidate (RC) version of Nuxt3, which we considered mature enough to start the migration to the final version. We removed all nuxt/bridge references, did some testing and adapted the development accordingly. Some of the Nuxt2 modules we were using back then were not ready in Nuxt3, so we searched for alternatives, and even used some beta version (like for i18n):

//nuxt.config.ts
import { defineNuxtConfig } from ‘nuxt/config’

export default defineNuxtConfig({
    //nuxt3 configuration
})

The hardest part was now behind us, and we’ve been using Nuxt3 ever since the stable version was released in #NuxtNation2022. There were no surprises, as we had already moved to the latest RC, so changing to the stable one was a matter of changing a number. We felt like we touched the sky and now we have Motive.co using one of the most recognised and powerful technologies in the industry.

Being part of the community

Working with Nuxt also makes us feel part of the community, and pioneers in the use of state-of-the-art tech tools. Without the latest tools, we couldn’t offer the latest software either.

Of course, this is not the finish line for our website, more is yet to come. For now, we’re happy to enjoy all the features Nuxt3 brings to the table and we’ll have a sharp eye on the future for the next challenges that may come our way.

If how we use technology also captivates you, why not check out our product at Motive.co or join us by taking a look at our careers page.