Hey there! My name is Anson and I work on the Platform team at Artsy. Recently, we faced an issue where a certain Enzyme test we wrote using mock tracking was failing, but we couldn't figure out why. Luckily, with some help from Orta and some clever thinking, we figured out what was going on.
The Artsy Engineering team recently underwent the process of defining our guiding principles; you can read through the pull request here and the finished principles here. In this blog post, I'd like to use our experience of defining these to answer the following questions:
- Why define engineering guiding principles?
- What makes principles different from company values?
- How to define guiding principles?
Let's dive in.
Artsy is growing up. We have thousands of subscriber galleries paying 3 to 4 figure monthly fees. As we're starting to see a real market-fit, and have started to mature our organization. For example, this year we introduced product managers into our 8 year old company to help us figure out how to build the right things. We actually started having open headcount on Engineering again, for the first time in years.
As a part of maturing, our team has really had to start considering how to make parts of our culture explicit instead of implicit. We have new, awesome folks wanting to understand why things are the way they are as well as folk who are raising up to new responsibilities only to find them completely un-documented.
In-part, having a consistent team for so long hasn't made it worth the time to document things everyone knows, but growth is very happy to disrupt that balance. Now we're shipping documentation updates weekly, to all sorts of places. In trying to write an awesome document, which I'll cover later, I looked at how we had consolidated our documentation over the last few years, and saw that we had fragmented due the tensions around wanting to write publicly.
This post covers that tension, and how we came about to the new docs setup.
Programming generally requires getting into a good flow state and working on a tricky problem for some time. In the last 2 years, most of my work at Artsy (and in the OSS world) has been less about longer-term building of hard things, but working on many smaller tasks across a lot of different areas.
Somehow, during this period I managed to end up in the top of "most active" GitHub members, I feel like a lot of this is due to doing Open Source by Default at Artsy and second to being good at context switching. I want to try and talk though some of my techniques for handling context switching, as well as a bit of philosophy around adopting and owning your tools.
Hey all, we have another guest post, this one comes from Sibelius Seraphini - a very active contributor to Relay and its eco-system. When we spotted he had wrote an amazing article on how the networking aspects of Relay comes together, we wanted to expand his reach and inform more people on how Relay comes together.
Data fetching is a hard problem for apps. You need to ask yourself a lot of questions: How do you ask for data from a server? How do you handle authentication? When is the right time to request data? How can you ensure you have all the necessary data to render your views? How can you make sure you're not over-fetching? Can you do lazy loading? When should you trigger lazy loading of data? What about pre-fetching data?
You don’t deep dive if you don’t know how to swim
TL;DR Relay Modern Network
Relay will aggregate the data requirements (fragments) for your components, then create a request to fulfill it. The API to do this is via the Relay Environment:
The Relay "Environment" bundles together the configuration, cache storage, and network-handling that Relay needs in order to operate.
This post focuses on the "network-handling" part, the Network Layer. The network layer's responsibility is to make a request to a server (or a local graphql) and return the response data to Relay. Your implementation should conform to either FetchFunction for a Promise-like API, or SubscribeFunction for an Observable-like API.
This article will provide 5 implementations of a Relay Network Interface, each of one providing more capabilities than the other one, eventually enabling GraphQL Live Queries and Deferrable Queries.
You can see the code for these 5 network layers on GitHub here, open source under MIT license: https://github.com/sibelius/relay-modern-network-deep-dive.
We're at 9 months of serious usage of Peril in Artsy. However, I've been worried.
Three months ago I started building out a "true" staging environment for Peril, one that allows any user or org on GitHub to click a button and have Peril running on their account. Pulling this off has two real interesting problems. Problem number one, security. Problem number two, my wallet.
Both of these issues stem from one simple problem: I need to run other people's code on my machines and I think they should be able to store data. Which to be quite frank, is horrifying for a side-project. So, this post explores one of main aspects which I've architected Peril to make this problem tractable. Avoiding storing state in the form of data.
Hi! I'm Erik, a software engineer on the Purchase team. One of the most visible payoffs from Artsy's investments in React Native over the past two years has been the opening up of our mobile codebase to contributors like myself coming primarily from web stacks. It's nice to be able to build mobile interfaces with the same declarative API used by so many of our web projects, but sometimes we still need to bridge the divide to our Objective-C and Swift ecosystem. One such case: replacing the app secrets typically loaded from a deploy environment or web developer's dotenv file.