This is part of a series about decisions my team made with our GraphQL schema. Check out that post for context, or to read about other decisions we made. One of the bad decisions we made when building our schema was defining a scalar field with a name that would likely be used in the future by a full object. Let’s say you’re modeling a Building containing multiple Rooms, and you start with a schema like this: ... Read more

This is part of a series about decisions my team made with our GraphQL schema. Check out that post for context, or to read about other decisions we made. One of the core promises of GraphQL is that you can build an API without versioning or breaking changes. Breaking changes occur when a field gets removed or its return type gets modified. In a perfect world, you’d continue adding fields and types as your API evolves without ever needing to remove or modify anything. ... Read more

This is part of a series about decisions my team made with our GraphQL schema. Check out that post for context, or to read about other decisions we made. Let’s say you’re modeling the users in a set of companies. Each company has offices scattered across multiple cities, each of which is split into departments that contain a collection of users. It might be tempting to model your schema like this to keep it lean: ... Read more

This is part of a series about decisions my team made with our GraphQL schema. Check out that post for context, or to read about other decisions we made. For fields that could potentially return a huge set of data, returning the entire result set in an array just doesn’t cut it. We have one field that returns time series data scoped to a time range, and that field could potentially return millions of results when scoped to a large enough time range. ... Read more

This is part of a series about decisions my team made with our GraphQL schema. Check out that post for context, or to read about other decisions we made. Pretty much every API needs to support an access pattern where you need to be able to query for a single user, and you also need to query for multiple users. (Replace “user” with any type of data your application models. ... Read more

I love GraphQL. Since deploying our initial GraphQL API at SwipeSense, the speed at which we’ve been able to build new capabilities into our applications has been unparalleled by any REST-based system I’ve worked with. If I had to pick a downside to adopting GraphQL, I’d say it’s the newness of the whole ecosystem. The spec is very loose (by design), and it hasn’t been around long enough for many best practices to emerge. ... Read more

About three years ago, I was involved in the most heated argument I’ve experienced thus far in my career. I wish I could say it was about something important with long-term consequences, like a decision about which data store or framework to use. Nope. It was about code formatting. Specifically, the argument was about tabs vs spaces in a spectacle that was a little too similar to a scene from Silicon Valley.

Everyone I’ve worked with agrees that code should follow a consistent style. It’s easy to set up a linter that will fail your CI build when these styles aren’t being followed. But standard linters fail to accomplish two things that I’ve always viewed as necessary evils when programming with a team: deciding on styles, and following them.

My world was rocked when my team started using Prettier. Prettier is an opinionated code formatter. It automatically formats your code based on styles that the creators of the tool have decided upon.

... Read more

A couple weeks ago, I migrated my blog from Tumblr to a static site generator. (I ended up settling on Hugo, but my choice of tool is irrelevant for this post.) When it came to deployment, I decided to have the generated HTML live on GitHub Pages since it’s free, easy to set up, and my source code (content, theme, and configuration) were going to live there anyway.

The easiest way to accomplish this with minimal setup is just to have your site generator output your built site in a folder called /docs. Rebuild your site after any change you make, push to master, and you’re good to go.

This solution was fine at first, but it got a little annoying having to manually re-build my site and commit the output of that build on every change. Not to mention the fact that committing build artifacts to version control broke my heart a little. I wanted a way to keep only my source chances in my git history (with the build folder in .gitignore), and have the build and deployment process happen automatically when I pushed my source code to GitHub.

... Read more

There’s a Black Mirror episode rankings thread where dozens of people have ranked every Black Mirror episode. I thought it would be interesting to average up all the rankings to get a general consensus of people’s favorite and least favorite episodes. Without further ado, here’s each episode ordered by its average ranking from that thread:

... Read more

I live with four other hungry college students. I've been cooking for them (and friends that occasionally join us) about once a week. Here are some of my favorite recipes, along with some of my personal notes.

... Read more