In this post, we will briefly go through how the frontend adapted with the changes of our platform. Catawiki has a rich history and because of that, developers have had to be creative. In follow-up posts, we’ll be diving deeper on what the impact of those changes has been on the tech side, but first – the overview!
As you might have already read on our blog, Catawiki started out as a catalogue for stamps and comic books.
At the time of Catawiki’s release in 2008, the popular framework was Ruby on Rails. Rails was the natural choice for the type of content that the founders wanted to share with the public and it turned out to be the right one for the job. The content was static, the admin panel was simple and the work on the site was efficient. “Frontend” was not really a thing back then as most people worked on full stack development. The more dynamic parts of the site were made with the help of jQuery. And for the needs of our platform, jQuery was the perfect tool for the job; alongside Ruby on Rails, jQuery enabled development to move fast and efficiently.
For Frontend, this was the most interesting period. In 2014 and 2015, Catawiki received big rounds of investment. There was confidence in the company’s business model and to accommodate the growth planned, a solid technical foundation was needed.
With more people working on the platform and more needs, it was clear that we needed to introduce some new tooling to accommodate these changes. After having a look at the technology landscape at the time we have given some thought of what fits best for our platform, the expertise of the engineering team at Catawiki and the level of support from the open source community.
So here is the shortlist of important technologies:
It was the up-and-coming library at the time, with the backing of a big company which made us confident in introducing 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 has improved our velocity with tackling difficult problems with ready made solutions. The simplicity of the tool has also enabled the wider engineering team (Backend) to be able to contribute to our codebase with the same quality and efficiency.
After almost 5 years of writing React at Catawiki, we can say with confidence 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 has made hiring easy.
At some point 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 major 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 learn faster.
Finally, Webpack has been a rock-solid choice at Catawiki, especially since the introduction of the Webpacker gem that seamlessly integrates Webpack into the Rails framework assets pipeline. We have briefly considered tools like Rollup but the ecosystem around Webpack has proven to be good enough.
We have just rebranded the look of Catawiki across all of our platforms.
While we’re still happy with our current tools, looking at where we are now, we want to further integrate those tools to keep on improving the development and user experience.
To accommodate for that we are working on the following:
Rails has been a blast so far but we want to go a step further and unify the technologies from the server to the client. Using NodeJS to serve our markup has been the natural choice but NextJS will bring that experience to the next level (pun intended). Right now, we are working on our first frontend specific microservice written with NextJS.
To bring typing to the next level at Catawiki, we have introduced io-ts, which enables runtime typing checking for IO bound operations like API calls. io-ts is part of the fp-ts ecosystem and brought in a dash of functional programming flavour to our code base, for a more declarative way of solving problems.