Using logs to power up your Rails development workflow
When working on Rails applications, I find tailing the development log and watching it as I navigate through pages very useful. Some of the questions that should be in the back of your mind while looking at it are:
- Am I hitting the right URL, with the proper HTTP method?
- Am I sending the right parameters? (Are they all necessary?)
- Are there any warnings/exceptions that I should handle?
- Does the ORM generate the right SQL statements?
- Is my request taking a longer time than expected?
- Am I making unnecessary 3rd party API requests?
The first three questions have relatively more straightforward answers, and I won’t expand on them in this article.
The first two are not necessarily bad things, but they are design problems that lead to code complexity and tech debt. They might happen in cases where Rails (or your framework of choice) is acting as an API server, which only responds with JSON responses. In those cases, you might not be using the most specific/accurate requests, or you might be sending more parameters than necessary.
Does the ORM generate the right SQL statements?
If you keep this one in mind (and you’re not already using bullet), you might become aware of N+1 problems, or that you’re loading/eager loading things you might not need. Or the fact that a single query could be taking way longer than you expected.
Is my request taking a longer time than expected?
According to Nate Berkopec of “The Complete Guide to Rails Performance”, the average app server response time should be 300 ms. Your log should include the response time, and you should be aware of your slowest endpoints, and what you can do about them, or if there’s a trend between requests that use the same models. APMs like Skylight and Scout help with this once your code is running in production.
Am I making unnecessary 3rd party API requests?
It’s preferable to have a high signal/noise ratio in your logs, which is why libraries like quiet_assets are so popular (it’s now part of Rails). However, you should consider logging 3rd party API requests if you aren’t already. High response times for these are tougher to work with, since they are usually out of your reach, but it can help you understand if your app’s response time is slow because of them.
Also, it might be the case that your application is making more than one external API request in a row, allowing you to catch these, and you might be able to change the code to make fewer requests while accomplishing the same task.
Log as much as you can without losing focus of what’s essential. Libraries such as Lograge can help you clean up logs, which might be useful if you configure it correctly. Rails 6.0 will also begin logging object allocations rendered in each view, so you can keep track in development of which rendered views are heavier on memory usage. Decreasing object allocations also improves response times.
Try to keep an eye on the log when you’re running your code in development (tail your test logs too), and keep in mind these questions to help keep your codebase tidy.