Note: This is the text of a presentation given at GraphQL Finland 2018, as such the language may in some cases be slightly awkward for a blog post. You can find those slides on Speaker Deck.

GraphQL is still in its early stages and thus these are very exciting times, indeed! Traditionally the GraphQL team has taken the approach of defining the bare minimum in the specification that was deemed needed and otherwise letting the community come-up with defining problems and experimenting with solutions for those. One such example is how metadata about the location in the graph where errors occurred during execution were added to the specification.

This is great in the sense that we still have the ability, as a community, to shape the future of a GraphQL specification that we all want to use, but on the other hand it also means that we may need to spend significant amounts of time on thinking about these problems and iterating. Seeing as we all strive to have backwards compatible schemas, it’s of great importance that we know of the various iterations that people have experimented with and what the outcome was.

This is our story of thinking about and working with errors, thus far.

Read on →

Why pair program? As new engineers join Artsy, we've been experimenting with different programming cultures - Yuki came from Pivotal Labs where they have a strong pair programming culture and introduced it at Artsy - it's been about a year and a half and we're all really loving the changes he's introduced.

I asked Yuki if he'd pair program with me on a blog, post on Pair Programming, and this is it. He's going to dive into what pair programming is, why you should do it, what are good mental models to think about, the techniques you can use to make it work, what hardware you might need and how Yuki persuaded so many of us to start doing it more often.

— Orta

Read on →

Engineering is an inherently long-term process. The Artsy engineering team has been around for 7 years, and that's quite a lot of time to get things done. We use software that keeps track of changes over time thanks to source control, but tools like git only help keep track of small passages of time. I want to keep track of events that could take months to ship.

We've been doing a lot of long-term introspection as a team in 2018. Externally, this has been visible through things like opening our docs and creating our engineering principles. I'm expanding on this with an idea that I took from my work in building large open source projects: Highlight docs.

Read on →

As Artsy Engineering grows in 2018, we have so many newcomers looking for context: they want to understand the systems they'll be working in day-to-day. Awesome! But it's not enough to understand the systems themselves, it's often helpful to understand the history of how we ended up where we are.

Frontend web development has changed a lot during Artsy's existence, and it continues to advance at a blistering pace. It's easy to get caught up in the churn of frameworks and languages and tools, so I want to use this post as an opportunity to contextualize each transition that Artsy's web presence has made over the past seven years. We've changed technologies, but we've tried to do so with care and attention. Documenting these decisions is important (and is ideally done contemporaneously), but even with the best documentation, sometimes our own documentation is unclear to us.

In an effort to help contextualize our web frontend (which is open source), this blog post will document the major transitions that Artsy's web presence has made over the past seven years. Let's begin!

Read on →

For what feels like the last 3-6 months, I've been trying to figure out how to know what the commit is for the Docker runtime in Peril. Roughly: every master commit on Peril triggers a Docker image on Docker Hub for the environment in which JavaScript is running. There's a lag between creating the commit, having the image ready on Docker Hub, and Peril using the new image. There's also space for these automated systems to go wrong, so I'd like to be able to be certain in logging.

I've thrown a lot of commits and time every few weeks at this, so now that I've figured it out, I'll give you an idea of what I needed to do to make it work in a micro-post.

Read on →

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.

Read 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.

Read on →

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.

Read on →

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 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.

-- 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 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:

Read on →