The Frontend Journey

As Catawiki is a company with a relatively long history, our developers have had to be adaptable and creative to keep up with changes to our platform over time. In this post, we’ll present a brief overview of how our frontend has evolved throughout the years.

From the beginnings until the first major investment — (2008–2014)

As you might have already read on our blog, Catawiki started in 2008 as a catalogue for stamps and comic books.

At the time, Ruby on Rails was a popular framework for web development. It was well-suited for the type of content the founders wanted to share with the public, since it was static and the admin panel was simple. In those early days, the concept of ‘frontend’ wasn’t really a thing, as most developers worked on full-stack development. Dynamic elements of the site were created using jQuery, which was a good fit for the needs of the platform and allowed for fast and efficient development. However, as the company grew and the platform became more complex, the frontend began to take on a more important role.

Catawiki gets serious (2014–2020)

The period from 2014 to 2015 was a significant time for Catawiki’s frontend. We received large rounds of investments, indicating confidence in our business model and paving the way for growth. To support this growth, it was necessary to build a solid technical foundation. With an expanding team and increasing demands, it became clear that we would need new tooling to meet these challenges. The engineering team at Catawiki evaluated the technology landscape and carefully considered which tools would be the best fit for the platform, taking into account the team’s expertise and the level of support from the open-source community. As a result, we introduced the following technologies.

React

It was the up-and-coming library at the time, with the backing of a big company, which gave us the confidence to introduce it to Catawiki. It enabled us to write reusable UI components at scale, with a very nice unidirectional-data-flow way of thinking. The support of the open-source community improved our velocity by allowing us to tackle difficult problems with ready-made solutions. The simplicity of the tool also enabled the wider engineering team (Backend) to contribute to our codebase with the same quality and efficiency.

After almost 5 years of writing React at Catawiki, we can say with certainty that it was the right choice. It remains the most popular library, it stays true to what it is, and the popularity and ease of use have made hiring easy.

TypeScript

Our codebase and contributor count started growing rapidly. One of the ideas was to introduce typing to our frontend codebase. We initially introduced Flow from Facebook, but after some playing around with Typescript and the initial experience with Flow, we decided to go with Typescript. The key reasons were:

• Better error messages in Typescript
• No need to version the type definitions like Flow (~20k lines)

It has proven useful when rewriting bigger code chunks and making the code more explicit, which in turn has helped people unfamiliar with the code to learn faster.

Webpack

Finally, Webpack has been a rock-solid choice for Catawiki, especially since the introduction of the Webpacker gem that seamlessly integrates Webpack into the Rails framework assets pipeline. We briefly considered tools like Rollup, but the ecosystem around Webpack has proven good enough.

Catawiki 2.0: 2021 and beyond

Catawiki completed a rebranding effort across all platforms at the end of 2021. We want to continue improving the development and user experience by integrating our tools more closely. To achieve this, we are focusing on the following areas:

NextJS

We want to take things a step further by separating our frontend technologies from our backend. This will allow us to have more flexibility and freedom to dictate the technology direction in the frontend. To do this, we’ve chosen to use NextJS. We’ve already migrated multiple pages to NextJS and have built three frontend-specific microservices with it. We plan to expand both the number and the content of these microservices in 2023.

fp-ts/io-ts

We have introduced io-ts, a tool that adds runtime typing checks for IO operations such as API calls. io-ts is part of the fp-ts ecosystem and brings a functional programming approach to our code base, allowing us to solve problems in a more declarative way.

Shared frontend libraries
To improve the developer experience (DX) in the frontend, we have been working hard on consolidating our utility functions into a reusable library that encapsulates our frontend config logic and more. We also now have a better unified and robust design system with reusable components that better represent the Catawiki UX identity.

In future posts, we’ll delve deeper into the technical details and impact of these changes, so stay tuned!