Hey there! In this post, I'm going to share the details on how the process unfolded behind the creation of haveabook.eu, flydigit.io, and even this very blog. Get ready for some insider info on what technology we used before, why we switched to our current tech stack, how it made our lives easier, and the challenges it presented.

How was haveabook.eu website born

From the very beginning, Have a Book company had been using WordPress to showcase content on its website. Most of the time, this platform had served us well, offering a fairly simple page builder, making both content addition and management quite enjoyable. Whenever an additional exceptional need arose, installing a plugin from the widely available repository usually did the trick, and voila, everything worked like a charm.

Unfortunately, as time went on, our needs grew even further. We had to expand our brand's online presence, which meant fine-tuning our website's SEO even more rigorously. We started outsourcing website maintenance to external software houses.

Of course, each software house used its preferred builder. When we needed another overhaul, another software house would start from scratch using a different builder they were familiar with. This process ended up costing us more money.

The situation with plugins also began to overwhelm the developers and also the website. While their installation, management, and functionalities were often impressive, they didn't always play nicely with each other. Unfortunately, the sheer number of plugins significantly slowed down the website for users. Sure, we could have sought help optimizing the site, but we decided to try a different approach.

Give It A Go

On my shoulders rested the choice of technology for our new website. At that time, my main experience lay with the React.js framework. It was great for web applications, but had its quirks with websites. Google, for instance, struggled to index pages built with this technology, for a fairly simple reason. React operates in a way that presents a nearly empty HTML file as its entry point, filling it with content only after a user interacts with the page. This setup makes little difference to users but poses a challenge for Google's crawlers, as they can't execute JavaScript and thus see only the nearly empty HTML file.

Fortunately, someone took it upon themselves to tackle this issue, leading to projects like Next.js. This framework, while leveraging React for website creation, generates a complete structure with multiple HTML files, one for each page. This is achieved because Next.js can process the source code of a page in three ways:

• Static Site Generation (SSG): The page's code is compiled entirely into an HTML file.
• Client-side Rendering (CSR): The page's code includes scripts that are appended to the HTML file along with content, executed by the user's browser.
• Server-side Rendering (SSR): The page's code includes scripts executed on the server, delivering a fully-rendered HTML file to the client (similar to how it's done in Wordpress).

Additionally, Next.js provides support for SEO, image optimization, and many other features to streamline website development for modern challenges.

OK, but what about content?

Next.js came to the rescue in one aspect: how to structure and present our website. But there was still one more issue to tackle: how to fuel haveabook.eu with a content. Pretty quickly, along with the team, we concluded that the answers lay in headless CMS technologies. It’s a system where you can add content in a structure you design, but it doesn't present the content itself, hence ‘headless’. Headless CMS's job is to provide content to the website-building tool, in our case, Next.js.

We pondered over two solutions: Sanity.io and Strapi, and the latter won the day. Strapi is a delightful headless CMS that also allows self-hosting, actively supported by its creators and boasting a large user community. It also offers i18n support, which was crucial for haveabook.eu.

With two the most critical components chosen, it's worth mentioning that we decided to write the site's code in TypeScript to enhance the readability of types used in the application. For styling, we opted for Tailwind, ensuring a clutter-free styling experience.

Flydigit.io, this Blog and conclusions from this trip

Relatively recently, we created a new sub-brand, FlyDigit, and needed blogs for both ventures, along with websites, of course. Drawing from our adventures with the Have a Book website, we decided to stick with Next.js. Additionally, we embraced a new method of building websites, the App Dir approach.

Have a Book continues to use Page Dir, mainly due to its multilingual capabilities. Adapting the multilingual support to a new website-building approach would have been time-consuming, and if it ain't broke, why fix it, right? The bigger change is that for the new sites, we no longer use Strapi for content management. This time, we opted for Sanity.io, for a rather simple reason—it requires less maintenance as it doesn't need to be self-hosted like a headless CMS.

With Strapi, there's practically no limit to the amount of content, but it's a matter of how much you're willing to spend on server and database resources. In Sanity, we don't pay for servers or databases; the provider takes care of that, and payment is based on how extensively the headless CMS is used. Luckily, Sanity.io offers a quite generous free plan.

Furthermore, Next.js and Sanity.io integrate seamlessly, streamlining configuration and query building between services. Of course, it's worth noting that the flexibility offered by Next.js inherently presents a few small challenges that you wouldn't encounter when building a site, for example on Wordpress. For instance, in a CMS, you're somewhat guided in how the site will look on tablets and phones. In the new approach, together with my colleagueElena, a UI/UX designer, we had to think about how each element would appear on a PC versus a phone, and of course, script it ourselves. However, help is always at hand. For example, for navigation on the blog.haveabook.eu site, we used the NextUI component package, which provided us with a ready-made logic; we just had to give it our own look.

To sum up, we've come a long way building our three sites, making many decisions along the way, some of which we later questioned. But both experience gained, knowledge of the tools, and flexibility in delivering content to our clients are invaluable.