About

Testing GraphQL APIs can be challenging due to their flexible nature. While clients can request data in countless ways, we need a testing strategy that remains robust regardless of how the API is consumed. And one that can scale with the growth of your app. The main pillar are proper, exhaustive type specs so I want to focus on that together with a couple best-practices that you can establish. First, we want our tests to be integration tests that go through all the involved layers (GQL types, database, authorization policies, etc, as much as possible). ...

Today I wanted to share with you a trivial pattern, that I call “technical key”. In rails apps, we typically use surrogate keys (autoincremented ids without any business meaning) as a primary key for database tables. However there are cases where our code depends on database data. In my previous article, I shared the case where the code assumed certain team exists and finds it in the database. There are many cases like that in Rails apps, where we give users the power to configure certain aspects of the app via UI and the configuration is stored in the database. ...

Over the years of working with large, mature, monolithical Rails applications, I realized a subtle problem. Many, even experienced teams put their constants in suboptimal namespaces. On one hand such placement is logical, but on the other it leads cluttered code that mixes low-level and high-level concepts. It does not help with keeping our monolith modularized either. Consider a common scenario in a Rails application: the Team class. As your application evolves, you might find yourself adding constants like this: ...