Hi! Let's talk a little bit about user authentication. We'll discuss it through the context of authentication within Artsy's ecosystem of applications, but ideally the same concepts will translate into other systems as well. The goal here is to build an understanding of (1) what exactly authentication is, (2) how it works, and (3) how to use artsy's specific infrastructure to delegate authentication for a new application to the existing ecosystem.

There are two primary authentication flows that we use at Artsy. We support user authentication through OAuth to allow users to log into our applications by delegating authentication to Gravity, our primarily application API. Alternately, we support app authentication for those cases where an application will only be called by other applications. We don't care about user authentication in this context, there's no need to redirect to a login screen etc - we just need to establish permissions between services. In both cases you'll be working with JSON Web Tokens (JWTs), and the difference is how the token you're looking at is generated.

User authentication happens at login - when the user provides their credentials to our server, our server confirms that they are who they claim to be and then generates a cryptographically signed token that encodes a few facts about that user.

App authentication, by contrast, all gets done in advance. We create the token manually, and share it with whatever application we want to grant access to.

In this document we'll first develop an understanding of what OAuth is and how it works. Then we'll examine the tokens we're using to get a better sense of what kind of information we have to work with. Finally, we'll go into how to set up authentication for users and for applications, building on the knowledge we've established.

Read on →

Volt is the internal app name of Artsy CMS, and our partners use it to manage their inventory and presence on artsy.net. It's a Rails-based UI app that talks to many API services. We use RSpec extensively to cover controller, model, view, and feature specs. As of Jun. 2018, Volt had 3751 specs and 495 of them were run with JavaScript enabled. It took about 16 mins to run on CircleCI with 6x parallelism.

Capybara-webkit was introduced from the very beginning of Volt for testing JavaScript-enabled specs via headless WebKit browser. It's been providing a lot of confidence for the past 4+ years; however, a few reasons/growing concerns have encouraged us to look for (more modern) alternatives:

Read on →

Hey everyone! I'm Justin, a senior engineer here at Artsy. I've been here for about 6 months and I'm a bit overdue on my first blog post. This will be one of a series of posts I'm dubbing roads and bridges (thanks Orta) describing infrastructure and tooling work here at Artsy.

Backstory

Here at Artsy we have a lot of internal dependencies. Keeping these dependencies up to date across all of our projects can be a bit of a headache. For example, there's Palette (our design system) which is consumed by Reaction (our react component/app library), Emission (our React Native application), Force (our main site), and Positron (our editorial creation tool). That's not even an exhaustive list. As you can imagine, after making an update to Palette we have to make a lot of Pull Requests to get everything synced up across our many projects. And that's just one dependency.

Read on →

This year TypeScript gained a new feature that punches far above its weight.

Working through our (enormous) backlog of unsorted TypeScript "Suggestions" and it's remarkable how many of them are solved by conditional types.

-- Ryan Cavanaugh, TypeScript maintainer

Conditional types probably aren't something you'll write every day, but you might end up using them indirectly all the time. That's because they're great for 'plumbing' or 'framework' code, for dealing with API boundaries and other behind-the-scenes kinda stuff. So, dear reader, read on! It's always good to learn how the sausage is made. Then you can make sausage of your own.

Typewurst! 🌭

Read on →

Let's talk about email HTML.

If you've never worked on emails before, you might think the process works something like this:

1. Write some HTML, but maybe with a few more tables than you usually use since emails like those.
2. Render it in your browser. Nice! Looking great.
3. Send yourself a quick test. Just like in your browser! Sweet!
4. Send that PR and move on to the next thing.

In reality, it's more like this:

1. Write some HTML with more tables than you think could possibly be necessary. There's no way it'll break with all these tables, right?
2. Render it in the browser. Cool, looks fine.
3. Send yourself a test, and send one to a service like Litmus or Email on Acid that renders the email in dozens of clients
4. Looking good in Gmail...good in Apple mail...wait why is it completely broken in Outlook 2007 (and 2010, 2013, and 2019)? And Yahoo Mail on Internet Explorer? Shoot.
5. Better add some more tables. That's usually the solution.
6. Well...that didn't work. Find a post from 2009 in a forum for Netscape enthusiasts that implies you might want to add an extra Outlook-only table using <!--[if mso | IE]> with role="presentation" and cellpadding="0" cellspacing="0". Maybe that'll work.
7. Outlook 2007 is fixed! Nice! Oh...but now it looks broken on iPhones. Back to the drawing board.

Read on →

Artsy's New York HQ occupies four top floors of 401 Broadway, located in historic Tribeca at the intersection of Broadway & Canal St., famous for its sellers of fake designer bags. Five elevators carry you up to our breathtaking views, albeit slowly.

Despite having been fully rebuilt in the last few years these machines are simply too few for the too many people working in the building. The lobby gets packed in the morning. The floors are crowded with coworkers waiting for an elevator to go to lunch around noon. Elevators make all local stops.

Because everything is a technology problem, I decided to improve this situation during our fall hackathon by building a Slack bot to call the elevator. Slack it, keep working for a few minutes, then dash out when you hear the elevator "ding", collectively gaining hours of productivity!

Read on →

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 →