At a former employer, my Vice President of Engineering and Operations had a reputation for his language. He also had a reputation for his deep passion for things like site availability, incidents, downtime, and almost anything related to making sure the company's website was up and running, and especially that the end users were having a good experience using it.

I'm the technical writer at k6. If you're on this site, you probably know what k6 is. But, to reiterate the essentials: When I started five months ago, I knew I had some work to do because: Really, my "professional programming experience" culminated in some shell two-liners. Fortunately, the k6 team gave me a set of challenges to get up to speed. In this article, I go over the eight challenges the k6 team gave me and present the ways I solved them (I don't promise elegance).

For many companies, performance is the main reason to go with GraphQL. But is that a valid argument? Often developers compare GraphQL to REST APIs and see the N+1 requests (or over-fetching) as an important reason to go for GraphQL. Let's put that to the test and explore if GraphQL APIs actually can outperform existing REST APIs. For this, we'll take a GraphQL-ized REST API (from JSONPlaceholder) and test the performance of GraphQL and compare it to the REST approach.