React Native is a new native library that vastly changes the way in which you can create applications. The majority of the information and tutorials on the subject come from the angle of "you are a web developer, and want to do native".

This makes sense, given that the size of the JavaScript/web audience is much bigger than native developers, and far more open in the idea of writing apps using JavaScript. For web developers it opens a new creative space to work, however for native developers it provides a way to work with different tools on the same problem. Considering that most developers with a few years on the platform will be comfortable with the Xcode suites of tools, recommending a change this drastic is a tough sell.

We've been using React Native now for about a year and a half, and have started to slow down on sweeping changes inside the codebase. This is great because it means we're spending less time trying to get things to work, and more time building on top of a solid foundations. Now that we're settled, it's time to start deeply understanding what happens with React Native.

I'd like cover a lot of the common questions we get asked about from the perspective of native developers:

  • What is React Native?
  • How do you use React Native?
  • When is React Native a good technology choice?

This article covers an awful lot, so free up at least 45 minutes, make a tea and then come back to this on your computer. It's worth your time if you're interested in all the hype around React Native.

Read on →

Danger came out of two needs. One from the needs of a growing dev team working together full-time, and the other from the needs of a completely asymmetric large Open Source project.

A work environment dev team is a complex place. You naturally grow, and to grow safely you add process. Process is a mixed bag, it's a net benefit at the trade-off of individual's time vs team cohesion. You want to grow your team guided by smart applications of process.

On the other hand, working on a large open source project, it's easy to feel overwhelmed at the amount of work that needs to get done on a daily basis. The growth of your OSS team probably doesn't tie to the amount of work that needs to be done. Especially if you're like me, and you don't want to be maintaining OSS as a 2nd full-time job.

So what do you do? Well in a work environment you don't really have a choice, as a team you hold each other to the rules that you set. In OSS, you sacrifice your spare time or you can find time at work, you could stop or you could burn out.

And this is the environment in which the idea of Danger was incubated.

Today mark version 1.0 of the second version of Danger. I'm going to cover what they are, how they continue to grow and what I see their trajectory as.

Read on →

After examining the data stored in one of our high-throughput systems, we realized it might include sensitive user data. To reduce the number of people that are technically able to access the data and reduce the risks associated with a potential data theft, we decided to encrypt certain database fields.

Our Goal

Encrypt sensitive fields without any downtime.

Read on →

In the 1990s, Harvard researcher Amy Edmonson made the unexpected discovery that in hospitals, higher performing teams reported making more mistakes. This is unexpected because one would assume that better performers would make fewer mistakes. In fact, the number of mistakes isn't what distinguishes higher-performing teams, but rather it's their attitude towards discussing – and learning from – their failures.

I've spent the past eight months reading more about psychological safety: the shared belief that team members won't be punished for speaking up with mistakes or questions or ideas. As a result, I've been trying to operationalize psychological safety on my own team, and part of that includes discussing and learning from our mistakes. At Artsy, we candidly discuss site outages or production bugs on the web, but haven't historically been great at communicating about iOS problems.

I want to start doing more retrospectives after things go wrong. So this week, I held my first iOS retrospective.

Read on →

Hey there everyone, it took us two years to make our GraphQL implementation support any mutations. We opted to keep it read-only for quite a long time because we use GraphQL to consolidate multiple APIs, but as we start new projects as GraphQL + databases then understanding mutations becomes much more important.

Last month, I talked with the team at about having them talk through Relay mutations comprehensively as a guest post on the Artsy Engineering blog. So, I'm really excited to introduce this great post on the topic by Nikolas Burk.

-- Orta

The Magic behind Relay Mutations

Relay is a powerful GraphQL client for React and React Native applications. It was open sourced by Facebook alongside GraphQL in 2015 and is a great tool for supporting you with managing your app's data layer.

In this post, we are going to explore how Relay mutations work by looking at a React Native app. The code can be found on GitHub. Our sample application is a simple Pokedex, where users can manage their Pokemons.

Note: We're going to assume a basic familiarity with GraphQL in this article. If you haven't heard of GraphQL before, the documentation and the GraphQL for iOS Developers post are great places to start. If you're interested in learning more about Relay in general, head over to Learn Relay for a comprehensive tutorial.

Read on →


Artsy was launched in 2012 as the "Art Genome Project" and grew exponentially ever since.

By 2014 we had 230,000 works of art from 600 museums and institutions and launched our first business, a subscription service for commercial galleries, bringing over 80,000 works for sale and partnerships with 37 art fairs and a handful of benefit auctions. That year collectors from 82 countries inquired on over $5.5B of art.

By 2015 we doubled our "for sale" inventory and aggregated 4,000 of the world's leading galleries and 60 art fairs. We also launched two new businesses: commercial auctions and online media.

Finally, in 2016 we, again, doubled our paid gallery network size to become the largest gallery network in the world and grew to become the most-read online art publication as our highly engaging editorial traffic ballooned 320%. We also launched a platform to bid in live auctions and a consignments service with all major auction houses.

The Artsy Business in 2017

Artsy in 2017 is a very wide platform and it can be challenging to characterize simply. But when you boil it down to its essence, Artsy offers information and a marketplace. Our written content and fair coverage keep people informed about the art world, and the Art Genome powers our tools for exploration. Through our partnerships with the major player in the art market, galleries and auction houses, we offer our users a unified platform for buying and selling art.

Internally we consider Artsy to have three businesses: Auctions, Content and Listings.

  • Auctions: Auction houses and charities use Artsy as a sales channel for a commission because collectors want to discover and buy art in a single, central platform that excels at surfacing the art they want from a global market.

  • Content: Brands pay Artsy to reach the first art audience at scale by enabling evergreen content online and for offline engagement during art world events.

  • Listings: Galleries, Fairs and Institutions subscribe to Artsy for a fee because we bring a very large audience of art collectors and enthusiasts to their virtual doors.

The Artsy team is now 166 employees across three offices in New York, Berlin and London. The Engineering organization is now 28 engineers, including 4 leads, 3 directors and a CTO. In this post, we'd like to comprehensively cover what, and how we make the technical and human sides of Artsy businesses work.

Read on →

Like anyone working on a non-trivial app in the iOS world who values their time, we use fastlane. fastlane is a suite of tools that makes it much simpler to automate the very manual processes provided by Apple for deployment.

We've adopted it in a relatively piece-meal manner in different projects, converting custom in-house code to something provided by the gem. Over time we found what pieces of the suite work for us. I've adopted another today: match.

match automates setting up your iOS projects for code signing. One of the most arduous orthogonal tasks which every dev team learns and then forgets.

In using match, we have given away a bit of control with code signing, and so this post is going to dig into; what we used to have, and how it works now with match instead.

Read on →

While Artsy is the largest database of Contemporary Art online, it's not exactly "big data". To date, we have published over 500,000 artworks by more than 50,000 artists from over 4,000 galleries, 700 museums and institutions across over 40,000 shows. Our team has written thousands of articles, hosted hundreds of art fairs and a few dozen auctions. We have over 1,000 genes from the Art Genome project, too.

There're just over a million web pages generated from this data on Generating sitemaps to submit to Google and other search engines for a million pages never seemed like a big deal. In this post I'll describe 3 generations of code, including our most recent iteration that uses Apache Spark to generates static sitemap files in S3.

Read on →