Sometimes the best insights come from a casual conversation, even when the topic is rather important. That's why we decided to have a relaxed yet meaningful chat with our FatCat Technical Team Lead, Luka Patarčić, about the migration from Gatsby to Next.js for our FatCat Coders page.
Luka shed light on the recent changes regarding Gatsby, resulting in the need for other frameworks, explaining why we opted for Next.js. During our discussion, he delved into intriguing specifics, outlining the primary challenges, essential steps, and the overall impression of the migration process.
So, let's start with the context surrounding the recent changes in Gatsby in the form of questions and answers from our Tech Lead Luka!
What Happened to Gatsby?
Luka: In February 2023, Gatsby underwent an acquisition by Netlify, leading to the discontinuation of Gatsby Cloud. The alternative presented by Netlify was their in-house Cloud Platform. This change caused significant apprehension among developers regarding Gatsby's future. That is why people sought new hosting platforms, the primary choices were Netlify and Vercel. Although both offer nearly identical features, the negative sentiment towards Netlify, stemming from the closure of a beloved hosting service, prompted many to shift to Vercel.
For Which Alternative Did We Opt?
Luka: Considering the uncertain future of Gatsby, we decided to transition to a different framework for better long-term support. Next.js emerged as the logical choice, being backed by a prominent company and widely embraced by React developers.
Next.js encompasses essential features like static build output and draft mode, and presents opportunities for future enhancements such as image optimization, incremental static regeneration, server-side rendering, and more. Although Astro and Qwik were also considered, the pivotal criterion for choosing a new framework was its React support. Opting for anything else would entail a complete project overhaul rather than a simpler migration to a different meta-framework.
What Was Our Main Goal?
Luka: Our primary aim was to ensure seamless functionality by transitioning to Next.js. We wanted the migration to maintain the consistency in components, while making changes in areas such as the data layer, routing, SEO, and images.
Next.js proved to be a great solution, particularly considering the enhancements introduced in its two latest versions – Next.js v13 and v14.
How Was the Team Organized for Such an Endeavor?
Luka: We engaged two developers in the website development. We divided the workload into larger segments such as the data layer, Next.js configuration, and assets. Following this, we distributed the workload among pages and within their respective components. Minimizing conflicts was a significant challenge due to the system's tight coupling.
And Which Segment Was the Most Challenging?
Luka: The fundamental aspect of transitioning the system to Next.js was primarily centered around the data layer, which notably differs between Next.js and Gatsby. A robust data layer was crucial; without it, longer build times and a diminished developer experience would ensue.
Previously, our primary method of data retrieval involved using Gatsby's plugin, gatsby-source-contentful, which managed data retrieval and synchronization from Contentful. However, this approach was no longer feasible, so we looked for an alternative solution.
We decided to employ Contentful's JavaScript SDK, which boasted numerous functionalities but lacked certain essential components we required. To address these gaps, we developed several helper functions that encapsulated and streamlined critical aspects of data retrieval. Additionally, we introduced caching support to expedite builds and reduce the number of requests made. Ultimately, we successfully transitioned the data layer to leverage the new features offered by the Next.js router.
What Other Key Steps Were Important, As Well?
Luka: Optimizing images was also crucial for us. Initially, we used gatsby-image for static optimization during build time. However, with Next.js, we can optimize images on request. Also, we currently utilize and support next-image, resulting in reduced image sizes and quicker page loading times for certain pages as a result of this transition.
And What About SEO?
Luka: Regarding SEO, Gatsby plugins like gatsby-plugin-sitemap, gatsby-plugin-robots-txt, and gatsby-plugin-manifest were previously used to create an SEO-friendly site. With Next.js 13, new built-in SEO tools were introduced. We were able to leverage all the tools offered by Next.js without integrating any third-party libraries.
Thank You, Luka! So What Are Your Final Thoughts on This?
Luka: The migration process and picking up speed progressed swiftly. An essential advantage was the shared use of React, significantly expediting the rewrite process. Next.js provided a quicker development environment through HMR, further contributing to our faster rewriting pace.
We have faster and better builds thanks to Next.js and its features. These features include ISR, where we don't even have to start the entire build process; instead, the page invalidates and generates on the server.
If You Are Interested in Learning More…
Our Tech Lead Luka is happy to answer any inquiries you may have regarding this journey and beyond. Reach out to us, and we'll gladly tell you all about our latest endeavors. We're here to assist with any unique challenges or provide support in this field as needed. :)
Share this article: