Author’s note: This article reflects my own experiences and opinions. AI helped me edit and organize the writing.

Until two months ago, I was on an infrastructure team we have at Artsy, called Sapphire. Although we were aware of everything being shipped to the Artsy mobile app, and strived to make product teams’ lives easier by improving developer experience and platform stability, we didn’t really build product features very often. Or at least I didn’t.

I was part of Sapphire for over a year and a half. Before that, I was building products, as I had almost always done.

Right before switching to Sapphire, LLMs started getting better, and back then Sonnet 3 and Opus 3 were among the best. I enjoyed using them for small tasks, but they weren’t really special without much context. I often didn’t even think of using an LLM when a task got complicated, and trusted only myself with it.

Then came Opus 4.5. And oh boy.

Read on →

The past year has been an exciting one for our mobile apps (Artsy, Folio and Palette Mobile) and we started to finally get closer to where we want to be: High-performing and developer-friendly React Native applications, enabling rapid feature iteration and a superior user experience.

We would like to share with you some of the improvements we made that might also be applicable to your react-native app.

Read on →

Where to begin! Where to begin…

Lets start with a good measure of success, one that I think most engineers could agree on: a from-scratch rebuild of a complex, internal tools app. Success with rebuilds is often fleeting, as many can attest. There’s risk involved. Extending the challenge further, lets assign (most) of the task to a team of platform engineers who aren’t too familiar with modern front-end technology – and then say that we succeeded.

Is Artsy crazy? Or is Next.js (along with our team 🙂) just that good? Well, it’s a little of both. And it’s a little bittersweet, in a way. Here’s our tale.

Read on →

Lately, I’ve been getting involved with some sketchy stuff. You know what I’m talking about–data migrations.

I’ve been rolling out changes that have a significant risk of breaking our production environment for mission-critical services. It’s been exciting work (keep your eyes out for more posts on the exact project, coming soon™️), but I’ve definitely caused a couple incidents along the way.

After accidentally taking down a key service for a couple hours, I decided I needed to have a better pre-deploy process for these changes. I did some thinking and came up with a short checklist to run through before I press the shiny green button.

Read on →

At Artsy, we love TypeScript. We use it in most of our node/web/mobile repos. Today, I want to talk about a specific case we found while trying to make our types more strict on palette-mobile, which is our Design System for React Native.

Check this out:

const welp: "hello" | "world" | string // `welp` is of type `string`.

Like the comment says, even though we have two specific strings, the fact that we do a union with string, makes welp have a type of just string. This is because both "hello" and "world" are strings, and the union tends to go to the type that includes the most.

Think of set theory and bubbles.

Read on →

We recently got a report from one of our galleries in the Los Angeles area that they weren’t showing up on our Los Angeles exhibition listings.

I fielded the report and right away confirmed: when we asked our core API for /shows?near=<los angeles coordinates>, sure enough this gallery partner didn’t make the cut.

Turns out they are based in Santa Monica, a separate and neighboring municipality. They must not be within the 25km radius that we use by default for these sorts of queries.

Case closed. Or so I thought.

Read on →

At Artsy, exploring ways to improve the developer experience is part of our makeup. Whether it’s implementing hot-swapping for Express.js or integrating the Rust-based SWC compiler into our front-end build pipeline, we’re always trying to reduce the amount of time it takes for a code cycle to take place. CI is no exception. When a developer opens a PR, we want to ensure they get timely feedback. Do their unit tests pass? Does the app build correctly? And how about smoke tests? Each of these jobs are complex processes that take time, and the more one can parallelize said tasks the less devs will need to wait. Scaled out to a whole engineering org, minor improvements to CI can be radical.

In this regard, two things came across our radar recently that we’d like to share: sharding via Jest, and a (free) way to parallelize Cypress.io integration tests via CircleCI’s split command.

Read on →

Amongst the many, many things that organizations have to contend with around cookie consent laws is Apple’s very own browser, Safari. Did you know that Safari will only retain a client-side cookie for 7 days? This is in support of Apple’s Intelligent Tracking Prevention (ITP) feature, designed to protect a user’s privacy.

These privacy efforts are great but, in hand with laws like GDPR and CCPA, their rollout often creates a UX nightmare for users without some extra care. Here at Artsy, we’ve landed on a way to make things slightly less bad and want to share our approach.

Read on →

How do you tell when it’s time to deprecate a system? If something mostly works OK, is it worth spending time and effort replacing its functionality?

At Artsy, we realized several years ago that we needed to be able to group a bunch of artworks together. If we wanted to have a page with all of the ceramics by Lucio Fontana, or contemporary prints from the IFPDA Fair Sprint 2022, or a gift guide curated by Antwaun Sargent, we needed to have a way to make that happen.

We decided to call these things “collections,” a reasonable name for a collection of artworks. In order to create them, we developed a service called KAWS, named after the artist (whose works we wanted to put in several of these collections).

Now, 4 years later, we’ve taken down the service and folded its functionality into Artsy’s main database and API, Gravity.

Let’s talk about why and what we learned along the way.

Read on →

As I am writing my first blog post for Artsy, here is a short introduction on who I am: My name is Kaja and I am an engineer in our Berlin entity. As a Ruby-born programmer I am calling myself a backend engineer, but that also may change and is more about emotional identification and less about what I actually do (as you will see in this blog post). My background is not in engineering at all. In university I graduated in philosophy and historical linguistics, both the most impractical but most beautifully theoretical subjects I can think of. I really love being in the world of ideas and thought experiments that challenge the current status of what is, as opposed to what is thinkable.

Read on →