Posts

I’ve been recently working on a Slack bot and Slack delivers all events (webhooks) to the same URL that you can configure. That means you need to distinguish between different events types based on the payload (request body). In the past, I’ve seen that Rails apps usually reimplement their own “slack routing” within a single controller action. I wanted to share a different solution that I came up with. Let’s do routing in rails routing. ...

I was working on a Hono project where I needed to convert a JSX element to a string. I couldn’t find an easy way to do it in the official documentation. It turned out to be rather easy, even though all the LLMs were clueless :). const component = <MatchesList matches={matches} /> const htmlString = component.toString() Now, I will remember.

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