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.

Read on →

Hey all, we have another guest post, this one comes from Sibelius Seraphini - a very active contributor to Relay and it's 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.

-- Orta

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 to pre-fetching data?

Relay is a framework for building data-driven applications which handles data fetching for you. For an introduction to Relay, read their docs, and also check out my Relay talk at React Conf BR.

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.

Read on →

We're at 9 months of serious usage of Peril in Artsy. However, I've been worried.

To get you up to speed on Peril, Peril is a tool that takes GitHub webhooks, and makes it easy to build one-off actions. It does this by having a per-account settings JSON, that connects JavaScript files to events from webhooks. So, for example, you can write a rule which runs when closing an issue in GitHub that looks for associated Jira tickets and resolves them. Peril provides no implicit actions like that, it instead offers a JavaScript runtime environment optimised to this domain so you can make actions to fit your needs. Like a collection of single-file probots.

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.

Read on →

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.

Read on →

The sixth, and last in our JavaScriptures series on the Artsy omakase. This talk covers a lot of the tooling basics for setting up a web JavaScript project. In this talk Chris covers the how to use Webpack and Babel in a fresh application.

Read on →

The fifth in our JavaScriptures series on the Artsy omakase. This talk is the second part on state management inside JavaScript projects. In this talk Chris and Eve cover the basics of how we handle interacting with local state in our different applications.

Chris and Eve create three demos which cover using Reacts setState, Redux and Unstated to make complex applications.

Read on →

The fourth in our JavaScriptures series on the Artsy omakase. This talk is the first part on state management inside JavaScript projects. In this talk Alloy covers the basics of how we handle interacting with external state with our GraphQL API metaphysics.

Alloy takes our existing demo application from the previous JavaScriptures and converts it to use Relay with all of the Artsy tooling.

Read on →

React Native has a lot of buzz around it. It is some serious and cool tech, yet can feel like a big departure from your native iOS codebase. At Artsy, we like it. It has been the right choice for us. We've documented our journey and reasoning quite extensively, but naturally, developers around the world are still wondering whether the trade-offs make sense to their team, and their situation.

Enter Artsy x React-Native.

Who better to partner with than Facebook? We're bringing a day full of hands-on informative insight and practical play. With the focus on what building world class applications with RN can be like.

We'll demo, through talks and workshops, how to add React Native bit by bit to an existing codebase, set your tooling up for success, and create solid animations.

We want Artsy x React-Native to be about getting you up to speed with the framework, so you can make your own decisions going forward.

As I write this, I have completed my first ever engineering on-call rotation at Artsy, so naturally I had to write a blog post about some of the things I learned.

Read on →

Over the past few months, we've been working on formalizing an on-call support process for our engineering team. This post details our current state and how we decided what system would work best for us.

Read on →