DEV Community: Catawiki

Migrating a static Hugo blog to AWS Amplify

Aristide Bouix — Tue, 02 Nov 2021 08:43:17 +0000

Fond of Cloud, Open Source and new technologies, Aristide leads the implementation of security controls on Catawiki’s Auction platform. In this publication he describes the historical technical considerations that applied to his personal website architecture built on AWS since its creation in 2016 to today.

Blog’s Origins

Back in 2016, I used to work as a Django developer, and as such, after starting working on AWS, I decided to host a personal website as a Django blog on AWS Elastic beanstalk.
The blog was extremely minimalistic and configured to use two small AWS VMs, one for the application and another one for a Postgres database hosted in a private subnet. It also involved an S3 bucket to load some static content such as images.

Diagram 1: An Elastic Beanstalk 2-Tiers Architecture

While this approach was convenient to start getting familiar with AWS and leveraging several of their based infrastructure services (VPC, CloudWatch, S3, RDS, Route53 ...), it had many drawbacks, such as:

Django framework is heavy to maintain and update for a side-project
Past the AWS free tiers, keeping two running VMs as small as they were wasn’t cheap ¹
It simply couldn’t scale for more than 10 simultaneous users without autoscaling

Going static

A bit later in 2017, I started hearing about these magic websites that could be built almost instantly using a static site generator and found that S3 could be configured to host them in one click. Therefore, I’ve benchmarked the two most popular solutions at that time, the Ruby engine Jekyll and the Go version called Hugo. As you can deduct it from this post’s title, I’ve gone for the second one as it was lighter and faster to build.

With a static website, I wasn’t required any longer to keep a dedicated database to host my blog posts, users and their comments. Instead, I’ve chosen to rely on external SaaS services such as Disqus for comments and Algolia for searching. Both solutions allow generous free-tiers usage for non-commercial use.

As serving content outside AWS is expensive, I’ve also added a Cloudfront distribution in front of the S3 bucket and was able to add a Lambda@Edge function in my website’s HTTP request responses². Lambda@Edge allowed me to add additional security to my website, such as preventing serving content from a non-explicitly allowed domain with a Content-Security-Policy (CSP) HTTP header. I also actively monitor the messages returned by these security headers through the excellent monitoring platform Report-URI from Scott Helm. The website architecture, therefore, was simplified as shown below:

Diagram 2: Static website hosted on S3

This structure is much cheaper and more scalable and can serve thousands of users for less than €5 per month.

A remaining caveat was that it was difficult to restrict access to the S3 website from the CloudFront³ service only. As described here, the usual AWS best practice of setting an Origin Access Identity (OAI) is incompatible with S3 website endpoints. The only workaround is to set a hardcoded “password” in an HTTP header supported as a condition in the S3 bucket policy. In addition, you need a few additional resources to get an automated CI/CD deployment from a Git repository (AWS CodePipeline) or some monitoring and alerting (Cloudwatch Alarms).

Moving to Amplify

AWS Amplify was initially a response from AWS to the popular simple web app hosting solution Firebase from Google⁴. It designates a toolset integrating many AWS services (CI/CD, Authentication, CDN, hosting, monitoring ...) in a single place.

Let’s see how it works. First you create a new hosting and choose the appropriate versioning service where the Hugo website skeleton is stored, in my case GitHub:

Then Amplify will automatically detect what framework it should use to build the project and propose an appropriate build configuration. Furthermore, in the advanced setting, you can configure Amplify build to use a custom docker image stored in ECR (Elastic Container Registry) and environment variables.

And voila! The website is now live on an amplifyapp.com provided URL.

Another powerful feature of Amplify is that you can easily host different versions of your project based on different Git branches; this enables you to run a testing version of a new feature before rolling it out to your main website. However, you may not want to expose this staging branch to the outside world. The good news is that AWS Amplify permits to effortlessly set a Basic Authentication in front of any website’s version. The less good news is that for an AWS managed service, I would also have expected the possibility to log in a user based on their AWS IAM identity.

As I already own a Route53 hosted zone, let’s change the default amplifyapp.com provided URL to my usual custom domain⁵. This will create a new CloudFront distribution with a free wildcard SSL certificate for your root domain and subdomains.

If you follow this step, you may find that the console only redirects the root domain to the www subdomain during creation. For further redirection options, there is an additional 'Rewrites and redirects' menu that you can configure as follow.

The rationale in this configuration is that by default AWS Amplify Redirect unknown URLs to the main page, so if you wish to show your own ‘404 not found page’ , it is better to advertise it as a ‘404 (Rewrite)’ instead of a ‘404 (Redirect)’.

Also, for SEO, it is better to replace the default ‘302 (Redirect - Temporary)’ HTTP return code to ‘301 (Redirect - Permanent)’. A 302 return code may confuse Search Engines that will continue to reference the wrong URL, as the redirection is supposed to be temporary, ending up slowing the initial loading time of visitors coming from the wrong URL.
Personally, I highly recommend choosing either your root or www subdomain and redirecting all other site references to it. Indeed, Search Engines tend to get confused when they’re getting the same page at different URLs. Do the same for the HTTP version of your site to HTTPS as you enjoy a free AWS managed SSL certificate, that will also decrease your domain spread.

The last screenshot is for the custom header editor that I’ve particularly enjoyed, there you can define your site HTTP headers in a yaml format⁶. It is much more convenient than maintaining a lambda@Edge function. My only catch on this menu concerns the editor that I find quite basic. So I copy paste the code and edit it in a separate editor.

There are a few additional power user functionalities that I don’t use for my relatively simple personal blog, so I won’t detail them here. These advanced functionalities include an Admin UI to configure team access to a serverless backend, direct CloudWatch monitoring and Alarm integration, and Pull Request system to merge changes between different branches and the master.

Cost Analysis

This study wouldn’t be exhaustive without a full pricing comparison between the AWS Amplify and a custom Cloudfront+S3+Lambda integration. I will simplify it a little, since I’ve configured CloudFront, my S3 costs were very low, and Lambda@Edge costs have remained within the Lambda Free Tiers. Below is a breakdown of the different potential costs:

	CloudFront+S3+CodePipeline	Amplify
Build	$1.00 per active pipeline per month $0.005 per build minute (Frankfurt using general1.small)	$0.01 per build minute
Storage	$0.0043 per 10,000 GET and all other requests (Frankfurt) $0.0245 per GB - first 50 TB / month of storage used (Frankfurt)	$0.023 per GB stored per month
Egress	$0.020 per GB - All data transfer out to Origin (Europe) $0.085 per GB - first 10 TB / month data transfer out $0.0120 per 10,000 HTTPS Requests	$0.15 per GB served

One of the strengths of AWS Amplify is that costs are fixed for any region you operate in. This can prove more beneficial in certain geographic areas such as Asia Pacific, Australia or South America, where outbound traffic varies between $0.11 to $0.12.⁷

Here is a more literal comparison based on my website costs for July 2021:

	Consumption	CloudFront+S3 costs	Amplify theoretical costs	Theoretical savings
Build	1 active pipeline 3 build minutes	$1 + $0.015	$0.03	$0.97
Storage	10,000 GET and other requests 0.15 GB of storage	$0.0043 + $0	$0	$0.0043
Egress	300k HTTPS requests Europe 2.5 GB served 130k HTTPS requests US 1.3 GB served	$0.4+$0.2+ $0.15 + $0.15 = $0.9	$0.6	$0.3
	Total	$1.91	$0.63	$1.28

By using AWS Amplify, I got the same features for a third of the price while saving me from maintaining the underlying service components. This result is biased by the cost of keeping one running pipeline and relatively low traffic during summer.

Conclusion:

AWS Amplify is a managed service shipped with CloudFront, S3, CloudWatch, CodePipeline, Cognito, API Gateway and even a serverless backend. Therefore, it perfectly fits smaller size projects based on static websites or frontend oriented frameworks such as React, Vue or Next.js.

While using AWS Amplify is convenient, if you operate a high Annual Rate Return service with more than 500k users, I would consider it more profitable to spend the additional Engineering effort to finely configure the corresponding underlying services⁸. My conclusion to this blogpost is that, no matter how great a managed service such as Amplify, the Return On Investment decreases as consumption goes up. Therefore, the main target audience of AWS Amplify is individual developers to medium-sized applicative projects.

Cover photo by Scott Major on Unsplash.

I even considered at the beginning to reserve 2 instances for 3 years to decrease the cost and discovered that the smallest instance sizes (t2.micro and t2.nano) were not eligible. ↩
For the curious reader, I’ve detailed in a previous post how I achieved this result. ↩
AWS’ Content Delivery Network, used to locally cache static data and thus cut down egress costs. ↩
From which the pricing model has been largely inspired. ↩
Beware: I got an error at this step because the main root domain (aristidebouix.cloud) was still attached to the old CloudFront distribution. If you also migrate your website from a Cloudfront+S3 setup to Amplify you should first remember to remove the domain redirection in your old CloudFront distribution. ↩
See the service documentation for reference. ↩
Note: the cost to serve HTTP requests is actually lower on CloudFront than for HTTPS requests probably due to a slightly lower impact on server CPUs. If as me you block or redirect HTTP requests then all your traffic will be billed as HTTPS requests. ↩
To the exception perhaps if your main market is located in expensive AWS regions such as South America, Australia or Asia Pacific. ↩

How Catawiki Migrated SSO’s with Zero Trust and Zero Downtime

Paul Moreno — Tue, 21 Sep 2021 11:28:47 +0000

Co-authored by James Thompson

Catawiki is a fast-growing 700+ person company, and we’re super busy tackling the challenge of growing our teams across new countries around the world.

Each month we onboard around 40 new employees working remotely throughout Europe and Asia. This is supported by a close working relationship between HR, IT and Information Security.

To continue providing a smooth new-employee experience and minimise data risks, we decided to overhaul our SSO and Identity Provider (IdP). This post covers our journey.

When we decided to migrate our IdP we had already been working with an IdP vendor for 3 years, and so most of our mission-critical apps were already accessible through an SSO portal. We also had our HR database connected to the IdP, and our employees were familiar with using MFA to secure their apps. However as we looked towards the coming years, especially with the explosion of remote-working, we saw lots of areas we could improve on:

Things we wanted from an IdP

Zero Trust Security

We can work from anywhere, so there’s no such thing as a trusted network. We need to be sure to validate the devices used to access Catawiki data; we can’t risk having someone use an unpatched public computer to check their email or access our customer data. And finally, because we can’t trust passwords, we verify the user with MFA. You can learn more about Zero Trust in this article.

Zero-touch enrolment

The IT team wanted the ability to drop-ship a brand new Macbook straight from the warehouse to a new employee. After enjoying the unboxing experience and connecting to wifi, the security policies should automatically be pushed to the device, authorizing access to Catawiki data and SaaS tooling with their IdP credentials and MFA.

Low effort onboarding and offboarding

Our employee data is already stored in an HR database, so we needed to make use of this and automatically create a person’s accounts when they’re hired. Even better, we wanted to give them access to the onboarding platform before their first working day so that Day One isn’t as stressful. When someone leaves the company, we can use the same philosophy to close accounts at the right time.

A long term SSO/IdP partnership

Changing your IdP is not a trivial task. We needed to choose a vendor who could grow with us and meet our headcount growth in a 5-year time frame.

Choosing a vendor

After researching the IdP market, we went ahead and engaged the IdP market leader Okta for a PoC, checking in great detail that the tooling could meet our requirements from August to November 2020. After a successful PoC, we moved on to find an implementation partner.

Finding a partner

Having small IT and Security teams forces efficiency. This drove the decision to enlist professional services to help with the implementation from an external consultant. After shortlisting a few vendors, we chose a specialist with strong experience in migrating between different IdP’s. To minimise the risk of any service interruptions, we planned and thoroughly prepared the migration over several months with multiple checkpoints.

Making the switch

The IdP portal is the ‘front door’ for access to Catawiki apps. So how did we handle replacing that door whilst people are constantly walking through it?

There were two main technical challenges involved in migrating Catawiki from one IdP to another:

Setting up federation between the old and new IdP platforms

By setting up an inbound federation from the old IdP to Okta, we were able to migrate our SaaS apps in 25 scheduled batches rather than at one time. From the user’s perspective, they continued using the old IdP portal as normal to access their SSO apps, but federation would be redirected to the new IdP only if the app was migrated.

This massively reduced the risk of the project and ultimately allowed us to complete the project with zero downtime or outages, even for apps with hundreds of users.

Migrating each SSO app

After establishing inbound federation from January to March, we then moved each SSO app from the old IdP to Okta after thoroughly testing in a staging environment. This was tricky because each vendor uses different naming conventions for SAML configuration so there’s an element of detective work to find the correct settings for dozens of apps.

Once an app was migrated to Okta, users were seamlessly redirected by the inbound federation setup when accessing from the old portal.

Securing the virtual perimeter

Utilizing a customized mutual TLS implementation, we were able to establish a virtualized perimeter for our SSO integrated apps. This way, we were able to not only identify and authenticate users but also devices. We also have the flexibility to monitor attempts to use unauthorized devices, make app-specific exceptions for consultants or freelancers for projects, and gain additional telemetry for our threat detection solution. Once the migration was complete, we were confident in both “who” and “what” can access our data across our cloud applications. Going forward, we’re taking advantage of Apple’s Secure Enclave to add another layer of security authorization for our trusted devices.

Finalising the migration

Once March rolled around, we successfully had all users federating into their apps through Okta. However, they were still accessing via the old IdP portal.

The final step was to make sure all staff knew how to access their apps via the Okta portal instead of the old portal. With some outreach through Slack and our support channels, we had this covered.

Conclusion

Deciding to swap out your IdP is not easy! A lot of work and patience is needed, along with an experienced migration team and open communication across your business. But it is possible to do so smoothly, giving you a solid foundation to build on as working outside of the office continues.

Why you should join Catawiki now

Ozgen Gungor — Fri, 07 May 2021 14:32:59 +0000

Imagine you are on the racetrack, in the driver’s seat, with the engine humming. The crew are working rapidly to fill up the tank and check all the systems, to make sure you are ready to step on the gas and accelerate.

That’s how it feels for me today when I look around (virtually) at Catawiki. There’s a certain sense of anticipation, a rush of excitement about where we are, and where we plan to be next year. Every conversation I have is making me more excited about the opportunities ahead for Catawiki.

We are already in a great position to grow and become a world-class tech organisation. Nevertheless, we don’t take that lightly. We want to use every opportunity to improve our way of working, our tooling, our infrastructure and our organisation.

Let me share a bit more context.

Historical reasons

Catawiki is an organisation that has found its product-market fit. We have gone through a few learning cycles so far that have helped us solidify our value proposition and product engineering methodology. In the past couple of years, we have proved our ability to scale up our business.

Going back to the analogy from earlier; we have already built this car that is strong, fast, sustainable and has enough mileage on the odometer to show for it.

What makes Catawiki different is that we are not just a successful business, but a great place to work as well. This is evidenced by more than 80% of our team telling us they would recommend Catawiki as an employer to their friends and family. We also have a great list of powerful values that help maintain our great culture. As I settled into my role, I got to know these company values and observed that they were embraced by everyone I met. Very briefly:

Be Open: Being open-minded and collaborative at all times, across roles and responsibilities
Be Geeky: Embracing technology and scalable solutions regardless of the nature of the task at hand
Be Passionate: Helping people find objects around their passions and applying the same principle to our work
Delight our customers: We help people find objects they love, customers’ experience goes beyond the object and every interaction is an opportunity
Move in sync: Autonomy and alignment go hand in hand (see what I did there?)
Take ownership: Drive end-to-end, see things through, realise value.

Furthermore, with the latest investment round of €150 Million, we are in a great position to invest further in our organisation.

An exciting future

Currently we are working on paying our technical debt off and simultaneously building new tracks for faster product iterations.

I have to admit, it is amazing to operate in an environment where the current technical debt level is taken so seriously. The necessity and urgency of clearing the tech debt is widely recognised and supported throughout the entire organisation.

We deploy all the best practices and tooling in order to craft world class experiences for our customers. For example; we use customer journeys, dual-track product development practices, OKRs, research and data practices to align and direct our efforts for maximum impact.

On the engineering side, we are well on our way to moving towards a microservice-based architecture that will set us up for increased scalability and agility. We are designing our technology platform for where it should be, embracing maturing technologies like service mesh or event-driven architecture.

Furthermore, our organisation is growing and we are addressing the much-needed growth framework and career ladders that will carry us into the future.

Adding these all up, we have plenty of interesting and impactful challenges. This means all of us here have a great chance of making a significant impact and taking part in this growth journey.

My personal why

While I was drafting this post, Iulia —our Technology Recruiter— reminded me to share my own reasons for joining Catawiki.

As I went through the interview process, a couple of parameters were important to me, so I tried to use the interviews to get a clear signal on what these looked like at Catawiki:

Potential: What’s the organisation’s potential for growth and for the role?
Visible Impact: Does the role allow me to have a fast impact and feedback cycles?
Growth: Will I have a manager I can learn from?
Balance: Can I maintain a great work/life balance while I do all above?

The short answer to all of the above was a clear “Yes”. I had found an organisation that was successful, stable, yet ripe-for-growth. I could see that everyone here has a chance to make a difference and observe the results quickly. I am glad that I will be working with a great team and be able to learn a lot from their experience in building and growing product engineering organisations. Finally, everyone seemed happy to work here and I can confirm for me the experience has been the same so far!

There’s no better time to join Catawiki. So jump on the driver’s seat with us as we continue to accelerate into the future.

Follow this link to join our community!

The iOS journey

Maarten van der Velden — Fri, 30 Apr 2021 10:02:39 +0000

Co-authored by Steve Overmars

Catawiki is more than a great website, we also develop and maintain native mobile apps for both Android and iOS. This post will cover the history of our iOS app and evolution of our technological stack.

The Early Days (2014-2016)

When Catawiki was up-and-running as an auction website, around 2013-2014, we started looking into new ways of reaching our customers and seeing opportunities in the world of smartphones. An external company was attracted to start work on native mobile apps for both Android and iOS and a dedicated API was set up to support this.Eventually the first internal iOS developers were hired to release and expand the app. Initially, this app only contained bidding and buying functionality.

At that stage, the architecture of the app was pretty standard for its time: using Objective-C and an MVC architecture.The v1 generation of our app was only available on iPhone. In late 2015, we started working to make our app available on iPad, by making it universal. This means that we bundled iPhone and iPad screens in one app. It was released as our v2.0 in 2016, after testing this with external beta testers, for the first time. These testers were current app users and colleagues.

In 2016, another team started building a separate app for Catawiki Sellers to submit lots for sale and to maintain an overview of these lots throughout the auction and sales process. With this change, we also slowly started introducing our first frameworks to be able to share code across the two apps.

During this time, some pain points of the old approach became visible: having two separate apps made it harder to reuse the same code, having separate mobile teams and a dedicated mobile backend made it harder to keep feature parity with the backend and web teams, and increased the technical debt. It was also confusing for users and hard to scale up the teams in a growing company.

On a technical level, Swift was released and became a mature programming language and we started running into the issues with the MVC pattern: plenty of hard-to-maintain Massive View Controllers, lots of tight coupling which made maintenance difficult and new features that were hard to make.

Towards a More Mature App (2017-2020)

Around 2016-2017, a lot of big changes were about to happen to the Catawiki iOS app, both for users, for developers and for the code itself. After our first experiments with it in 2016, we decided to develop all new features in Swift from 2017 onwards.

In 2017, we also integrated our seller app into our buyer app. We did this by extracting the seller code into an SDK, a separate Swift Framework, marking the start of modularisation of our code incrementally into separate frameworks. This became v3.0.

To also start solving the maintenance issues involved with MVC, we started building new features in the VIPER architecture. This has helped us a lot in giving our code more structure, making features and screens more reusable.

Later in 2017, the development teams were reorganised and the mobile developers were integrated into full-stack feature teams. This helped us focus on getting rid of all the discrepancies between the mobile apps and web, including a push to use the same APIs for all three platforms.

The combinations of all these changes, while still having a small team of around four iOS devs, meant that most of the transitions we started around this time weren’t completed overnight. Because there was also ongoing development for new features and fixes for our live app, we had to be very pragmatic in migrating to Swift, VIPER, Frameworks, and new APIs. We tried to do it all at once when a certain screen was scheduled for big features or changes, but in general the process required longer.

A New Hope (& Brand) (2020-)

We were heading in a good direction. We accelerated our evolution when we started work on the Catawiki 2.0 branding. Simultaneously, we grew our iOS platform team to nine developers. Because of this, we were able to focus on some of our oldest parts of the code, and bring them up to the latest standards. This is a good example of how we take managing our technical debt seriously. In September 2020, we were able to release the new brand (v4.0), and are continuing to migrate the last old parts of the app to make them Swift, VIPER and use up-to-date Microservice APIs, while also creating more Swift Frameworks. We expect this effort to be finally finished by the end of 2021.

Will that mean iOS developers at Catawiki will be “done”? Besides our product and UX people coming up with ever new and improved features, we’re already looking towards the iOS tech stack of the future, like how SwiftUI could (or rather, will) replace UIKit in our app, and whether VIPER will still be a good architecture for us in that case.

If you’d like to join us on our journey of continuously improving our apps and delighting our customers, give us a shout!

Cover photo by Ernesto Velázquez on Unsplash.

Where did our monolith go?

Vladimir Bobrov — Thu, 01 Apr 2021 10:24:07 +0000

There is a lot to be said on the pros and cons of a monolith vs microservice software design (just Google a few). To briefly sum things up; while monolith applications are often still the best choice, organisations are increasingly leaning toward microservices architecture. Many companies recognise the importance of increasing overall engineering efficiency through team/unit autonomy and access to a wider labour market. And most are facing similar challenges in their journey to microservices.

Starting a transformation without a plan imposes significant risks. Many challenges must be tackled beforehand which play a foundational role in the success of adopting a monolith system. These include data input, output, processing, error handling, and the UI, which are usually written once and reused across the whole monolith.

Now, imagine multiplying these entities by the amount of stacks or a number of services we envision to expand into. Missing a common layer and principles across services will harm engineering efficiency by a lot. After all, if engineers are to produce tangible value. we must address common problems before we can put a foot in new water on a scale of 50+ people.

Get ready

At Catawiki, we’ve built a foundation with an app skeleton repo, automation and guidelines to enable teams to consistently deliver new services. Besides that, we've built libraries with the most essential tools helping us to streamline integration. This simple 2-step plan is for many adopters often just the tip of the iceberg. And the hidden part is bigger, further away we are from Cloud Native toolchain.

Organisational-wide standards are vital for the success of the microservices journey. It is best to start early with an internal SDK, OpenAPI specification and infrastructure as code. Nowadays, these problems are solved with a myriad of services, tools and well-established standards. Some monolith code will likely come in handy or become a blueprint for a common library that each app may depend on.

Focus on Data

Most applications are dealing with data and underlying storage. While an application layer is usually scaled by simply multiplying compute workload, a data layer eventually becomes a bottleneck.

Inefficient data structures and data-querying algorithms are the biggest problems we'll have to deal with when scaling an application. Frederick Brooks, the author of The Mythical Man-Month, says:

The programmer's primary weapon in the never-ending battle against slow systems is to change the intramodular structure. Our first response should be to reorganize the modules' data structures.

Microservices can bring in significant costs if the data design is not addressed properly. Replacing in-process code execution with cross-host API calls via extra virtual and physical processes costs user time and is more expensive for businesses to operate. In fact, the efficiency of any service depends on how data is stored and exchanged among services.

As the data architecture becomes so important, we'll have to be smart about how we denormalise and exchange it. Categorise data and its usage, establish data exchange rules and apply the right tools for specific use cases. It is always difficult to change data structures at a later stage, so best to ensure storage scales x10-x100 times and return the right value for the years ahead.

Realising the effort

When everything is moving fast in a growing business, it’s not easy to change overnight. To create a system developed from scratch by five people over five years, a quick estimate suggests the time needed amounts to at least 50.000 hours of engineering work. Of course, rebuilding a monolith into microservices might be less expensive than the original investment, as we may borrow from the old system some code and established business logic.

However, for an established business, a rapid rebuild from scratch is usually not an option as it requires us to stop feature development in the old system to avoid ending up a never-ending cycle of catching up with updates. This means that we have to build a new system and features working alongside the old one, exchanging and duplicating data and features, in order to provide clients with a gradual transition away from the original system..

It's true that an effort like this can cost any company a huge amount of time and resources. Nevertheless, organisational and innovation benefits of modern Service Oriented Architecture (and Microservices specifically) will easily outweigh any benefits of a Monolith system in the long run. To make a transition successful and get buy-in from the company at large, it is important to plan things ,with a clear rationale as to why you’re doing this and an understanding of the goals.

Be organised

An organisation with hundreds of people is a complex structure. After years of slow progress in our journey to Microservices, we've realised a lot of things. Perhaps the most important one is that this challenge is purely in the hands of engineers and as such must be driven by engineers.

Photo by airfocus on Unsplash

To better organise ourselves, we've built a company-wide Engineering Roadmap reflecting all steps of migration, accounting for people we have and/or will be hired this year. And with a clear vision of what this is going to bring us, we've committed to making a huge leap this year toward a better, more efficient and scalable foundation of our unique platform for passionate enthusiasts all around the world.

A few months later down the road, we're extremely satisfied with the results and the progress we've made so far. Although this year has just started, we are already planning for exciting engineering challenges in 2022 and beyond!

Cover photo by Boba Jaglicic on Unsplash.

The Frontend journey

Srgjan Dimitrijevikj — Wed, 17 Feb 2021 16:18:09 +0000

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!

From the beginnings till the first major investment - (2008-2014)

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.

Catawiki gets serious (2014-2020)

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:

React

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.

TypeScript

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.

Webpack

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.

Catawiki 2.0 2021

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:

NextJS

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.

fp-ts/io-ts

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.

Cover photo by @kaleidico from Unsplash.

Changing the rails

Vladimir Bobrov — Mon, 30 Nov 2020 17:23:32 +0000

When an online business takes off, there is always an imminent desire to be at the forefront of technology. An increasing belief that the business is on the right track fuels a fear of falling behind competitors — a feeling that can help push a company to success as much as it can hold it back. In the very beginning of our journey, Catawiki made a few technological choices it owes a large part of its success to.

Back in 2008, it was hard to find a more prominent web-development framework than Ruby on Rails. Even though Ruby as a programming language was never the most popular one, the shift of paradigm in web-development introduced by the Rails core team predetermined the success of the framework. As for many emerging Web 2.0 businesses, it was the obvious choice that helped us to focus on things that matter — continuous innovation.

Challenges faced

Six years after Catawiki was founded, the moment to make a bigger technological leap to support expansive growth arrived, facilitated by the company’s global recognition¹. By the end of 2014, we at Catawiki faced the inevitable question: “how can we best support our business growth with our current technology while keeping the promises we’ve made to our customers?”.

What is a simple question at first glance became more complicated when we look at what challenges we had already been facing and what that meant for scaling our platform 10 100 times. Some of the challenges included:

Regular outages and “Friday’s on fire” caused by the increase of visitors and bidders
On-premises infrastructure with a high degree of manual system management
Lack of development and staging automation constraining engineering team growth
Monolith service combining practically two different businesses — auctioneering and collectors platforms

Tackling the issues

Even though these challenges looked frightening, we had a great team of engineers who recognised the issues and acted on opportunities to improve every day. The most significant challenge that popped up on the radar was not just to double or triple the engineering team to cope with increased amounts of issues and support business objectives, but to rethink the way we build things for the future.

One of the first things we tried to do was to move away from the monolith service by building new features (or rebuilding old ones) in a standalone application. This approach, which at first seemed promising, proved to be unsuccessful in the end, yet it brought us lots of learnings.

Monolith systems can be successful and in the early stages of business development this is the only way forward. Many businesses wouldn’t reach their success if the only thing they cared about was pure engineering excellence. In the end what makes great products successful is actually trying, failing a few times before finally succeeding in what you believe could work for many people. This in turn creates a large amount of technical debt a successful company should solve sooner or later when the business takes off.

By the beginning of 2015, we were a few months away from doubling our engineering team to about 25 engineers and we realised we needed to make our own shift in how we were going to shape our technological future.

Stay tuned to find out more about Catawiki's journey and what led us to success!

https://www2.deloitte.com/gr/en/pages/technology-media-and-telecommunications/articles/fastest-growing-tech-companies-emea.html ↩

Meet the Catawikians: Bozhidar

Iulia Nicolaie — Thu, 12 Nov 2020 16:40:37 +0000

Hi, I’m Iulia. I’m part of Catawiki’s recruiting team. We’re responsible for bringing high-quality humans to Catawiki across our offices.

During my time here, I’ve talked to a lot of developers who are curious about working for Catawiki. So I thought that it would be nice to start sharing what it’s like to work here by having some quick coffee chats with our engineers.

Today, I would like to introduce you to Bozhidar, our software engineer from the payments team.

Hi Bozhidar! Would you mind telling us a little bit about yourself?

Hello! I am Bozhidar and I’ve worked as a software engineer for about 4 years already. I’ve been working full time at Catawiki as a software engineer while also pursuing a part-time International Business bachelor. My interests gravitate towards tech, leadership, and psychology, wildlife, and sustainability.

What attracted you to Catawiki in the first place?

I think the first thing is the marketplace approach. Coming from Uber and looking at other companies like Amazon, Google, Valve, etc. I strongly believe the marketplace model is a strong one in this digital world. During my interview process, I was impressed both by the technology that Catawiki is using as well as the kind of people that work here.

It’s wonderful to have you here. Since a lot of our audience probably isn’t familiar with Catawiki, could you talk about the company and the work that you do there?

Catawiki is not the place you go to in order to satisfy your “musts” and “needs”. It’s the place you go to when you want to satisfy your “wants”. Or as I like to say, it’s the place you visit when you want to treat yourself to something special. It is a curated marketplace for all kinds of special objects you can’t find elsewhere. Whether that’s an ancient gold coin, another post stamp for your stamp collection, or a Porsche 911 from the 70s, Catawiki is where you will be able to find these special items and many more.

Could you tell us a little bit about your role and a little bit about what this Payments team is at Catawiki?

My role as a software engineer in the Payments domain and the team’s role, in general, is to keep the quality bar for money movements as high as possible. There are three main pillars that play a role here - reliability, speed, and safety/security. There are teams inside Catawiki that work solely on the supply side or on the demand side, but in payments, we are at the cross-section of the two.
On the demand side, we are responsible for processing payments from our buyers while offering as many options of payment types as possible. On the supply side, we are responsible for verifying that our sellers are compliant (to prevent fraudsters) and also for making sure the ones that are verified and sell objects receive their money.

What is special and particular about software engineering at Catawiki?

I would say the special and surprising part for me was to see how much infrastructure and tooling exists behind the scenes that are ready to serve the developer. There is an entire platform engineering team whose sole job is to optimise, automate and provide tooling so that their client (the other engineers) can focus on what’s really important, which in most cases would be the end-user business logic.

Could you share any advice for software engineers who would like to join Catawiki?

I think whether you’re a senior engineer or not, one thing that is very important in this ever-changing world is to stay open-minded. Being in an organisation with people from more than 50 nationalities plays a huge role in collaboration. At the end of the day, no matter how senior someone is, a person can move very fast alone, but they can go further together as a team.

Finally, are there any books or blogs or other resources that you’ve found helpful recently?

Well, there is one book, which I actually read quite some time ago, but I often think about it especially as a software engineer. It’s by Cal Newport (who is actually a computer science professor at Georgetown University) and the book is Deep Work.

So inspiring. Thank you for your time Bozhidar!

Thank you as well Iulia, looking forward to the next coffee chat.

So how did we begin?

Vladimir Bobrov — Thu, 05 Nov 2020 11:34:17 +0000

Perhaps it would be good to take a tour far back to 2008 and give our audience a picture of where, we as a business, came from.

Originally Catawiki was built by two Dutch gentlemen (René and Marco) with the idea to help collectors around the world organise and exchange their items. As it usually happens, one of the founders (René) thought the idea could actually work as he was himself a passionate Tintin comic strips collector. And the other founder (Marco) knew how to build it.

Catawiki went live in 2008 and was designed as a catalog system with detailed information about items as if it were a wiki. Hence where the Catawiki name comes from!

Thanks to WaybackMachine we can even show you how it looked like back then

via: web.archive.org/web/20080914004650/http://www.catawiki.nl

Just a few years after, in the mid-November of 2011, Catawiki hosted its very first auction. Since then the Catawiki business as we know it today started taking off.

You can even find how the advertisement campaign of this exciting moment looked like (on the right side of this screenshot)

via: web.archive.org/web/20111215035153/http://www.catawiki.nl

And if you are curious about what was the very first lot that was auctioned and successfully sold on Catawiki, here you go

“Storm 1 - De diepe wereld, Hardcover, 1e Druk 1978” was our very first lot sold in Comics Auction (Dutch). Starting with the initial bid of just €5 the price rose x17 times and it went for an impressive €85!

Storm is a soft science fiction/fantasy comic book series, just one of many others you can find on Catawiki platform among many-many other objects. Stamps, coins, paintings, jewelry, cars are just some of the dozens of object categories. Whether you are a passionate enthusiast or a collector seeking for a missing piece, you have a pretty high chance to find what you’re looking for!

Wow, what a “selling” detour we’ve just made! 😊

Let's think for a moment about the tools we employed back then to bring Catawiki online:

Rails - the most modern and powerful web development framework the world has ever seen by that time!
HTML - Internet as we know it wouldn’t exist without.
CSS - without it Catawiki website would look like from ‘90s.
jQuery - breaking through DHTML technology, still used by 73% of the 10 million most popular websites by mid-’19 (according to Wikipedia).
Solr - enterprise-search platform using Lucene search engine.
MySQL - “the World’s Most Popular Open Source Database” which was hard to argue about.
Linux - to run all of the above on the Internet.

Throughout the years we’ve changed quite a few things: half of the stack was replaced with more modern tools and another half has changed so much that you can hardly find a similarity. And of course, we have added a few dozens of newer tools and technologies! 😅

What stayed the same was continuous change. That thing which is not always easy and many times compared with “changing the tires of a car which is running at full speed, staying on top of it”.

And this is exactly what we will be talking about in our next blog posts!

Hello World!

Vladimir Bobrov — Thu, 15 Oct 2020 07:49:35 +0000

Perhaps any Engineer remembers the excitement of seeing this very first message when their first program or webpage comes to life! And so here we are at Catawiki, excited about the launch of our Engineering Blog

The idea behind having a Catawiki Engineering blog didn’t come overnight and was rather hanging in the air for a few years. We’ve put a good amount of diligence to embark on this journey, being completely sure we will provide useful content for our visitors and engage with our audience in a meaningful way.

At Catawiki, we’re building our amazing product with the help of incredible engineering concepts and tools like Cloud, Kubernetes, Microservices and BigData. It is not a secret that those can be used and built in many different ways, and despite our struggle to find the best solution for a specific purpose, we cannot claim that our way is the only true way to build things right.

Nevertheless, we believe that sharing the Catawiki Engineering stories will help many of our peers. Especially those who may be looking for examples of the same or similar problems they are faced with as part of an emerging tech organisation.

We are aiming to share our stories of successes and failures. Although you may find more of the former ones and less of the later ones, we will make sure to share the essential learnings we went through on the way to success. We believe we can achieve greater success if we help our readers avoid falling into traps, as those might be easy to overlook in the landscape of the current technology environment.

We also think it is important to share our stories in a structured form. We will post stories on different topics: Frontend, Backend, Mobile, Systems, Data, Security, Reliability, etc. Any post will be tagged with a corresponding topic name. And that’s not all!

Many companies during their growth from a small startup to a unicorn follow very similar phases. Especially during the migration to Microservices! Thus we would like to present our readers with some content which clearly pertains to different phases of our development. To make the posts stand out, our authors will tag them by corresponding phase names.

Phase	Years	What is this phase about?
Catawiki 0.0	2011-2014	Ancient times, before the expansive growth of Catawiki.
Catawiki 1.0	2015-2017	Our journey to Service Oriented Architecture (Microservices) begins, we can even call it the Great Expansion. Phase when we’ve focused on building facades around our Monolith system.
Catawiki 2.0	2018-2020	Phase when our Microservices Universe cooled down and we started departing from Monolith. We also call it Independence from Monolith.
Catawiki 3.0	2021+	Time when we’ll finally say “Farewell Monolith...” and open the door to the new world!

We hope you will find our posts as useful and interesting as we’ve found it challenging to wade through the building of modern Engineering at Catawiki!

What are Web Standards and how does Web Browser work?

Ilya Lyamkin — Wed, 27 May 2020 13:10:38 +0000

Let me tell you a story. Once I was building yet another date picker component for our design system. It consists of text input and pop-up with a calendar that shows by clicking on it. Then pop-up can be closed on click outside or if the date was selected.

Most implementations of the click outside logic made with actual click listeners attached to the DOM. However, I wanted to build our date picker accessible, so you could open a calendar with tabs and close the same way. Additionally, click listeners may conflict with each other if you put several date pickers on the page.

What if you could just rely on native focus and blur events instead of detecting clicks outside? They naturally support tabs, touch and click events, and already implemented in the browser. The only problem you need to solve in this case is when you click on the pop-up but without date selection: focus shifts to the calendar, triggering blur event on the text input and eventually closing the pop-up.

At this point, I started wondering if there is a way to click but do not shift a focus. After quick googling, I found a way to do it: prevent the default action of the mouseDown event for the pop-up. Just like that in one line, all clicks worked but the focus was still on the text input.

It seemed like that's the solution, let's move forward, but something inside of me was stopping me from that. Why specifically mouseDown and not mouseUp prevents focus but propagates click? Is it some part of the living standards? Can we rely on that? Does it work cross-browser? React Testing Library that we used to do integration tests also didn't support it and I'd have to change simulation function.

What is Web Standard?

Alright, since the Stack Overflow answer wasn't enough for me, so what could be a better place to learn about browser behavior than the web standards?

You probably heard about W3C or World Wide Web Consortium. It's an international community that develops open standards for the Web. W3C makes sure that everyone follows the same guidelines and we don't have to support dozens completely different environments. If you visit their website, you'll find the list of all standards they're working on.

Let's have a look at the one document that might have an answer to our questions - UI Events Standard. This document specifies the DOM event flow, defines a list of events and their execution order. If you thought that standards are boring, obscure, and hard-to-understand text blocks, then jump straight to DOM Event Architecture section that explains event bubbling and capturing with nice pictures and still being very specific as standard supposed to be. You'd be surprised by the quality of it, it's really well-written with a lot of examples and recommendations.

It also has a definition of our mouseDown event and its default actions:

"Many implementations use the mousedown event to begin a variety of contextually dependent default actions. These default actions can be prevented if this event is canceled. Some of these default actions could include: beginning a drag/drop interaction with an image or link, starting text selection, etc. Additionally, some implementations provide a mouse-driven panning feature that is activated when the middle mouse button is pressed at the time the mousedown event is dispatched."

Alright, so our event has some default actions, but there is nothing specific about focus because it really depends on browser implementations. Let's check them out.

Introduction to browser engines

A modern browser is a quite complicated piece of software with the codebase around tens of millions of lines of code. So it's usually split into several parts.

To find a place where focus events are defined, we need to get an overview of what each part is responsible for. Let's start with Chromium and its design documentation Getting Around The Chrome Source Code. As you can see there is a lot of modules responsible for different logic.

Let's briefly go over them to get the idea of how it works together.

chrome: it's a base app with startup logic, UI, and all windows. It contains the projects for chrome.exe and chrome.dll. Resources such as icons or cursors you can also find here.
content: it's a backend of the app which handles communication with child processes.
net: this is the networking library that helps to make queries to websites.
base: a place for common code shared between all sub-projects. This could include things like string manipulation, generic utilities, etc.
blink: it's a rendering engine that responsible for the whole rendering pipeline including DOM trees, styles, events, V8 integration.
v8: a final big part of a browser - Javascript engine. Its job is to compile JavaScript to native machine code.

As you can see browser consist of several independent parts that talk to each other via API. The most interesting parts for developers are usually Blink and V8. Browser defined default actions are not part of V8, but Blink should have all of them defined and implemented. But before we jump into the Blink codebase, let's understand how web browsers work from a user point of view.

Rendering pipeline

Imagine you enter domain address in a browser, then it fetches and loads a bunch of assets: HTML, CSS, and JS files, images, icons. But what would happen next?

As a first step, HTML files would be parsed and turned into a DOM tree. The DOM is not only the internal representation of the page but also an API exposed to Javascript for querying or modifying the rendering through a system called "bindings".

After the DOM tree, the next step is to process the CSS styles. For that purpose browsers have a CSS parser that builds a model of the style rules. Having built a model for style rules, we can merge them together with a set of default styles supplied by the browser and compute the final value of every style property for every DOM element. This process is called style resolving (or recalc).

In the next layout part, we need to determine the visual geometry of all the elements. At this stage each element gets its coordinates (x and y), width, and height. The layout engine calculates and keeps records of all overflow areas - which part is visible and which is not.

As we got all coordinates for all elements, it's time for painting. For this operation, we use coordinates from the previous step and color from style rules and combine them into a list of painting instructions. It's important to paint elements in the right order so that they stack correctly when they overlap. You can modify order via z-index style rule.

Let's execute our list of painting instructions and convert them into a bitmap of color values. This stage is called raster. At this moment we also take our images and decode them into bitmap as well.

Later the rastered bitmap will be stored in GPU memory. This stage includes libraries that abstract the hardware and issuing calls to OpenGL and DirectX on Windows. When GPU receives the instructions to display bitmap, it draws pixels on your screen.

Now we have the most important parts of the rendering pipeline. But what would happen if you scroll the page, or some animation would be applied? In fact, rendering is not static. Change is represented via animation frames. Each frame is a complete rendering of the state of the content at a particular point in time. The real challenge in this process is its performance. Smooth animations require generation at least 60 frames per second. It would almost impossible to complete a full pipeline 60 times in a second especially on slow devices.

What if instead of always re-rendering everything, we provide a way to invalidate an element at a specific stage. E.g. if you change the color of the button dynamically, the browser will mark this node as invalidated and it would be re-rerendered on the next animation frame. If nothing is changed we can reuse the old frame.

That's a good way to optimize small dynamic changes in the content. Let's think about change in big regions of content. For example, if scroll the page, all pixels have to be different now. For that purpose a page is decomposed into layers that raster independently. A layer can be fairly small and represent only one DOM node. Those layers then will be combined together on another thread called the compositor thread. With this optimization you don't need to re-raster everything, but rather do it for small layers and then correctly combine them together.

Now we have a little overview of what Blink does and how rendering pipeline looks like. Let's dive into the code.

Navigating Blink codebase

It seems like we are finally at the finish line. Let's open the Blink repository and look around.

We can quickly realize that even though we narrowed down a lot from our original question, it's still too big to manually find a specific line of code responsible for preventing focus.

Let's try to search by our event name in Google:

mousedown site:https://chromium.googlesource.com/chromium/blink/+/master/Source

It leads us to the EventHandler file where you can find implementation details for a lot of input events. Including the most important line for us:

bool swallowEvent = !dispatchMouseEvent(EventTypeNames::mousedown, mev.innerNode(), m_clickCount, mouseEvent);

dispatchMouseEvent return value means "continue default handling", so swallowEvent is true in case of preventDefault usage.

Just below there is a call for focus event which is triggered only if swallowEvent == false.

swallowEvent = swallowEvent || handleMouseFocus(MouseEventWithHitTestResults(mouseEvent, hitTestResult), sourceCapabilities);

Apart from focus handling, you can explore all default actions of the mouse down event including selection, drag-drop, and scrollbar cases. It also implements mouse release and double clicks events - everything is there.

Gecko and WebKit

At this point, we already spent some time discovering browsers source code and have a pretty good understanding of their structure, so why not check Firefox and Safari altogether. Firefox's browser engine called Gecko and Safari's - WebKit.

Gecko also has an overview page for developers, so you'd get an idea of the main concepts of it. Based on the experience with Chrome, you can find a neat 6000 lines of code EventStateManager file with events default actions and behavior. I've included a specific line in the link, so you won't have to go through it all.

WebKit is a browser engine from Apple used in Safari and other Apple products. Chrome's Blink was forked from WebKit, so they have a lot of things in common and it wasn't a problem to find events implementation in their version of EventHandler file.

Now since we made sure we can prevent mousedown event safely, I can step back and finish the PR with the date picker.

Conclusion

Together we went a journey from a simple problem to the introduction of Web Standards and browser implementation details.

Don't be scared by the hidden complexity of existing modules even if it's a browser or compiler. It will be a fun journey in the end. The chances are you can easily find things to improve, and more importantly, get unique insights into how things actually work. I've learned a ton of stuff during this deep dive and encourage everyone to do the same. Browsers will provide excellent documentation along the way at the point that I'm not sure why I need anything else.

Relevant links for further reading

Do you know what DOM is? How it's represented internally? What's the purpose of events? I'd highly recommend DOM Standard to everyone from beginners to more experienced developers. "An event signifies an occurrence, not an action." - my favorite part of it.
Official website of the W3C community.
Getting around Chromium codebase.
Design documents published by Chromium developers.
Life of a pixel - introduction into rendering pipeline of Chrome.